Seni Mengatakan "Belum Final": Kebiasaan Kecil yang Menyelamatkan Tim dari Rework
Banyak rework di tim engineering bukan terjadi karena orang "nggak jago", tapi karena satu hal yang kelihatannya sepele: status keputusan yang nggak jelas.
Kata "draft" sering dibaca sebagai "boleh jalan dulu", sementara yang menulis draft menganggap "draft" artinya "belum di-lock, siap berubah kapan saja". Begitu ada perubahan, muncullah kalimat klasik: "Kalau bisa ikut contract di draft aja ya, soalnya UI sudah menyesuaikan."
Di titik itu masalahnya bukan ISO timestamp, enum, atau field naming. Masalahnya adalah ekspektasi yang tidak disepakati: kapan sesuatu boleh dianggap final, siapa yang berhak memfinalkan, dan bagaimana cara tim memberi sinyal "ini masih bisa berubah" tanpa memperlambat delivery.
Gejala yang Sering Terjadi (dan Mungkin Familiar)
Coba bayangkan scene ini.
Kamu ngasih masukan di group chat soal API contract. Reasonable, well-thought, bahkan sudah kamu cross-check sama best practice. Ada yang jawab dengan sopan, tapi intinya: "Mending ikutin yang di draft, soalnya sudah disesuaikan UI."
Pesan itu terdengar efisien. Tapi ada dua sinyal tersembunyi yang sering terlewat:
Sinyal #1
Implementasi sudah jalan berdasarkan sesuatu yang belum disepakati secara formal.
Sinyal #2
Diskusi bergeser dari "apa yang benar untuk jangka panjang" ke "apa yang paling murah untuk sekarang".
Dan ini bukan kasus satu kali. Kalau kamu perhatikan, ada kalimat-kalimat pemicu yang sering muncul di tim mana pun:
"Biar konsisten ke depan."
"Biar nggak perubahan dua kali."
"Udah terlanjur diterapin."
Semua kalimat itu valid sebagai concern. Tapi berbahaya kalau dipakai untuk mengunci keputusan sebelum ada approval yang jelas.
Akar Masalahnya: Status Keputusan Itu "Invisible"
Kebanyakan tim engineering punya dokumentasi. API spec ada. ERD ada. Confluence page ada. Tapi yang sering tidak ada adalah bahasa yang konsisten untuk status keputusan.
Akhirnya semua orang pakai interpretasi sendiri. Dan di sinilah chaos dimulai.
Draft yang jadi pedoman
Dokumen masih eksplorasi, tapi sudah dipakai sebagai acuan implementasi production.
"Proposed" = "Approved"
Sebuah proposal yang baru diajukan dianggap sudah disetujui hanya karena tidak ada yang membalas.
Chat = keputusan final
Diskusi di Slack atau WhatsApp dianggap keputusan final, padahal belum ada sign-off dari siapa pun.
Intinya: tim tidak kekurangan dokumen. Tim kekurangan decision protocol.
Kenapa Orang Tetap Implement Duluan?
Sebelum kita lanjut ke solusi, penting untuk memahami kenapa ini terjadi — tanpa menyalahkan siapa pun.
Orang yang implement duluan biasanya bukan karena ceroboh. Mereka punya alasan yang masuk akal:
- 01Mengejar speed — Mereka ingin unblock dirinya atau tim FE/BE yang sudah menunggu. Niat baiknya: jangan jadi bottleneck.
- 02Takut idle time — Di culture yang mengukur produktivitas dari output, "nunggu keputusan" terasa seperti tidak kerja. Takut dibilang lambat.
- 03Menghindari risiko "nunggu yang nggak turun" — Pernah nunggu approval yang tidak kunjung datang? Akhirnya orang belajar: jalan aja dulu, minta maaf kemudian.
- 04Asumsi keputusan lead akan sama — "Lead pasti setuju kok, jadi jalan dulu aja." Kadang benar. Tapi ketika salah, biayanya mahal.
Ini penting untuk dipahami supaya framing-nya bukan "lead vs team", tapi "kita vs sistem yang belum matang".
Dan jujur — kadang lead sendiri ikut berkontribusi. Membiarkan ambiguity terlalu lama, tidak menutup keputusan, atau terlalu lama memberi final answer. Kalau kita mau fair, ini tanggung jawab bersama.
Prinsip Kunci: Bedakan yang Mahal dan yang Murah Berubah
Tidak semua keputusan teknis perlu gate yang berat. Yang perlu jelas bukan detailnya dulu — tapi tingkat kepastiannya.
Ada keputusan yang sifatnya:
Mahal kalau berubah. Response shape global, error schema, enum canonical, auth flow, database schema inti. Ini butuh gate yang jelas sebelum implement.
Murah diubah. Copywriting message, label UI, minor field optional, wording error message. Ini bisa agile — jalan dulu, iterasi kemudian.
Kalau tim bisa membedakan dua kategori ini, mereka tahu mana yang boleh "jalan dulu" dan mana yang harus "nahan dulu". Sederhana, tapi powerful.
Amazon menyebut konsep ini sebagai "one-way door vs two-way door" decisions. Keputusan one-way door — yang sulit atau tidak mungkin di-reverse — membutuhkan deliberasi yang lebih hati-hati. Keputusan two-way door — yang bisa di-rollback dengan mudah — boleh diambil cepat, bahkan oleh individu. Tidak perlu birokrasi untuk keputusan yang bisa di-undo.
Toolkit: Lima Kebiasaan Kecil yang Berdampak Besar
Bagian ini yang bikin artikel ini (semoga) actionable. Ini bukan framework besar yang butuh approval CTO — ini kebiasaan kecil yang bisa kamu mulai besok.
A. Satu kalimat yang mengunci status
Biasakan setiap keputusan teknis punya satu baris status. Bukan paragraf panjang — cukup satu kalimat yang menghilangkan ambiguity.
Status: Draft— Boleh implement sebagai spike, jangan merge ke main.Status: Approved— Aman dipakai implement production.Status: Final— Breaking change harus lewat RFC.
B. Definisi "boleh mulai coding" yang jelas
Bikin rule sederhana yang semua orang bisa hafal:
- Draft — Boleh buat PoC atau spike. Tapi jangan jadikan dependency lintas tim.
- Approved — Boleh implement production. Tim lain boleh build di atasnya.
- Final — Boleh publish contract. FE/BE lock. Perubahan harus melalui proses formal.
C. Sinyal visual di dokumen
Kalau pakai Notion, Google Docs, atau Confluence — pasang di paling atas dokumen: Status: Draft | Owner: @nama | Last updated: 28 Feb 2026 | Next review: 3 Mar 2026. Kecil. Tapi efeknya besar. Orang yang buka dokumen langsung tahu: ini belum final, jangan jadikan acuan production.
D. Jalur "alignment cepat"
Masalah terbesar bukan perbedaan pendapat — tapi lamanya resolusi. Satu perbedaan teknis yang dibiarkan berlarut di chat selama 3 hari bisa jadi 3 hari rework. Saran: kalau ada perbedaan yang berpotensi jadi rework, jangan dibahas panjang di chat. Pindahkan ke 15 menit call. Keluar dengan keputusan + status yang jelas. Tulis hasilnya. Selesai.
E. Beri ruang untuk pushback — tanpa mengunci keputusan
Pushback itu sehat. Yang tidak sehat adalah pushback yang disampaikan dengan "udah keburu" sebagai argumen utama. Ajarkan tim format pushback yang konstruktif: "Saya setuju tujuan A. Risiko kalau kita ubah sekarang: B. Opsi kompromi: C. Kamu prefer yang mana?" Ini jauh lebih produktif daripada debat panjang tanpa struktur.
Template Wording: Tegas tapi Tetap Membangun
Kadang yang bikin orang ragu bukan prinsipnya — tapi cara menyampaikannya. Ini beberapa template yang bisa langsung dipakai:
"Secara teknis masuk. Tapi kita perlu lock status dulu: ini masih draft atau sudah approved?"
"Kalau kita implement sebelum sign-off, itu dianggap spike ya. Jangan jadikan referensi final."
"Saya ingin kita cepat, tapi cepat yang mengurangi rework. Yuk align 10 menit biar jelas."
Kalimat-kalimat ini tidak menghakimi. Tidak menyalahkan. Tapi jelas: ada mekanisme yang perlu diikuti sebelum sesuatu bisa dianggap "jalan".
Penutup: Definisi Kecepatan yang Matang
Di banyak tim, "cepat" diartikan sebagai "mulai duluan". Siapa yang paling cepat ngoding, dia yang paling produktif. Siapa yang paling cepat deliver, dia yang paling valuable.
Tapi setelah bertahun-tahun memimpin tim engineering, saya sampai di satu kesimpulan yang mungkin tidak populer tapi saya yakin benar:
Tim yang cepat bukan tim yang selalu mulai duluan. Tim yang cepat adalah tim yang cepat membuat keputusan yang jelas, dan cepat mengubah arah tanpa drama — karena dari awal statusnya transparan.
"Belum final" itu bukan penolakan. Bukan cara untuk memperlambat. Itu adalah mekanisme kontrol risiko — cara tim mengatakan: "kita boleh cepat, tapi kita juga tahu di mana batas aman untuk cepat."
Kalau tim bisa menyampaikan status keputusan secara eksplisit, mereka bisa tetap cepat sambil meminimalkan rework. Mereka bisa tetap agile tanpa harus bayar harga rework di sprint berikutnya.
Dan itu dimulai dari kebiasaan kecil. Satu label status. Satu kalimat alignment. Satu call 15 menit yang menyelamatkan 3 hari kerja.
Kalau "belum final" terdengar memperlambat, itu tanda kita belum punya cara yang sehat untuk memfinalkan.
Pernah mengalami rework yang seharusnya bisa dihindari kalau status keputusan lebih jelas dari awal? Saya penasaran cerita Anda.