Belajar Sistem Lewat Proyek Marunda
Ada satu proyek yang membuat saya mulai melihat sistem bukan lagi sebagai konsep teknis, melainkan sebagai alat berpikir.
Proyek itu datang dalam konteks sekolah di Marunda. Bukan proyek besar. Bukan pula proyek yang terlihat rumit dari luar.
Namun di dalamnya, saya berhadapan dengan tiga hal sekaligus: forwarding, multi-agent, dan simulasi proses bongkar-muat kapal.
Dan yang sering luput saya ceritakan, proyek inilah yang pertama kali menerapkan Arthipesa v1 secara nyata.
Pada proyek ini, saya tidak bekerja sendiri. Saya memimpin tim kecil berjumlah tiga orang: satu junior, satu senior, dan salah satunya adalah teman satu kampus saya, :contentReference[oaicite:0]{index=0}.
Komposisi tim seperti ini memperlihatkan sesuatu dengan sangat jelas: sistem tidak hanya harus berjalan di mesin, tetapi juga harus masuk akal bagi orang dengan pengalaman dan cara berpikir yang berbeda.
Masalah utama proyek ini bukan pada tampilan atau fitur. Masalahnya adalah alur.
Ada banyak peran. Ada banyak kondisi. Dan ada proses yang tidak bisa berjalan paralel sembarangan.
Setiap agen punya tugas. Setiap keputusan berdampak ke tahap berikutnya. Satu kesalahan kecil saja bisa membuat simulasi tidak lagi masuk akal.
Di titik ini, saya sadar: menulis kode saja tidak cukup.
Saya harus memahami alur kerja nyata, lalu menerjemahkannya menjadi sistem yang bisa dipahami mesin dan manusia.
Forwarding mengajarkan saya tentang ketergantungan proses. Tidak semua hal bisa dipercepat. Tidak semua hal bisa dilewati.
Multi-agent memaksa pembagian tanggung jawab yang tegas. Ketika satu agen mengambil terlalu banyak peran, logika akan saling bertabrakan.
Dan simulasi loading vessel memberi pelajaran paling penting: waktu dan urutan adalah bagian dari sistem, bukan detail tambahan.
Tanpa urutan yang jelas, simulasi hanya menjadi animasi kosong.
Di sinilah Arthipesa v1 benar-benar diuji.
Struktur yang sebelumnya hanya terasa masuk akal di kepala, harus bertahan menghadapi diskusi tim, perbedaan sudut pandang, dan perubahan asumsi di tengah jalan.
Dokumentasi pun berubah peran.
Ia bukan lagi formalitas akhir, melainkan alat komunikasi dan alat berpikir.
Saya menuliskan alur sebelum menuliskan kode. Mencatat asumsi. Menandai keputusan yang mungkin berubah.
Bukan karena diminta, tetapi karena tanpa dokumentasi, diskusi akan berputar, dan sistem akan ditafsirkan berbeda-beda.
Di situlah saya memahami sesuatu yang menetap sampai sekarang: sistem yang baik membantu timnya berpikir selaras, sebelum membantu penggunanya.
Proyek Marunda tidak mengajarkan teknologi baru yang spektakuler. Ia mengajarkan saya konsekuensi memimpin sistem yang harus dipahami bersama.
Bahwa kompleksitas jarang datang dari satu hal besar, melainkan dari banyak keputusan kecil yang tidak pernah disepakati dengan jelas.
Dan bahwa sebuah framework—buatan sendiri maupun tidak— baru bisa dinilai ketika ia diuji di ruang nyata, bersama manusia nyata.
Pelajaran itu terus saya bawa, bahkan jauh setelah proyeknya selesai.