12.5 Urutan Kerja yang Cerdas, Bukan Sekadar Prioritas

Setelah Anda memotong pekerjaan menjadi irisan vertikal, godaan terbesar adalah mengerjakan semuanya berdasarkan urutan yang paling menarik atau paling mudah. Atau lebih buruk lagi, berdasarkan urutan yang diminta stakeholder tanpa pertimbangan teknis. Senior engineer tidak bekerja seperti itu. Ia tahu bahwa urutan eksekusi irisan sama pentingnya dengan irisan itu sendiri.

Bayangkan Anda sedang membangun fitur integrasi pembayaran baru. Anda sudah memotongnya menjadi beberapa irisan: koneksi ke gateway pembayaran, logika retry, handling timeout, notifikasi ke user, dan dashboard monitoring. Mana yang Anda kerjakan pertama? Banyak engineer akan mulai dari koneksi gateway karena itu adalah inti fiturnya. Tapi senior engineer akan bertanya: apa yang paling berisiko jika gagal? Apa yang dibutuhkan irisan lain agar bisa berfungsi? Apa yang bisa memberikan pembelajaran paling cepat tentang sistem yang sebenarnya?

Sebagai contoh, berikut adalah daftar irisan fitur pembayaran yang sudah dipotong secara vertikal, lengkap dengan alasan prioritasnya:

// Irisan 1: Struktur data transaksi (fondasi, risiko rendah)
//   - Semua irisan lain bergantung padanya.
//   - Kerjakan pertama.

// Irisan 2: Koneksi gateway pembayaran (risiko tinggi, bukan fondasi)
//   - Integrasi eksternal, banyak ketidakpastian.
//   - Kerjakan kedua, saat masih ada waktu untuk adaptasi.

// Irisan 3: Logika retry dan timeout (bergantung pada struktur data)
//   - Bisa diuji dengan stub gateway setelah struktur data stabil.
//   - Kerjakan ketiga.

// Irisan 4: Notifikasi ke user (bergantung pada struktur data)
//   - Risiko rendah, bisa dikerjakan paralel dengan irisan 3.
//   - Kerjakan keempat.

// Irisan 5: Dashboard monitoring (bergantung pada semua irisan)
//   - Membutuhkan data dari irisan 1-4.
//   - Kerjakan terakhir.

Jawabannya sering kali bukan irisan yang paling terlihat.

Ada empat pertanyaan yang harus Anda jawab sebelum menentukan urutan kerja. Pertama, apakah irisan ini menjadi fondasi bagi irisan lain? Jika ya, kerjakan lebih dulu. Koneksi gateway mungkin bukan fondasi—Anda bisa membuat logika retry dengan stub terlebih dahulu. Tapi struktur data transaksi, misalnya, adalah fondasi. Semua irisan lain membutuhkannya. Jika struktur data berubah di tengah jalan, semua irisan harus diperbaiki.

Kedua, irisan mana yang memiliki risiko teknis paling tinggi? Risiko bukan berarti sulit. Risiko berarti Anda tidak tahu apa yang akan terjadi sampai Anda mencoba. Integrasi dengan sistem eksternal, misalnya, sering kali penuh kejutan: API tidak sesuai dokumentasi, response time tidak stabil, atau format data berbeda. Kerjakan irisan berisiko tinggi lebih awal, saat masih ada waktu untuk beradaptasi. Jangan menunggu sampai minggu terakhir untuk menemukan bahwa gateway pembayaran membutuhkan sertifikat yang proses pengajuannya memakan waktu dua minggu.

Ketiga, irisan mana yang memberikan pembelajaran paling cepat? Kadang irisan kecil yang tidak kritis bisa mengungkap asumsi yang salah tentang sistem. Misalnya, sebelum membangun logika retry yang kompleks, buat dulu irisan sederhana yang mengirim satu transaksi dan melihat bagaimana sistem benar-benar merespon. Pembelajaran dari irisan kecil ini bisa mengubah desain irisan lainnya secara signifikan.

Keempat, apakah ada irisan yang membutuhkan readiness dari pihak lain? Tim backend mungkin perlu menyediakan endpoint baru. Tim infra mungkin perlu mengatur firewall. Pihak ketiga mungkin perlu mengaktifkan akun testing. Jika Anda mengerjakan irisan yang bergantung pada pihak lain tanpa mengecek readiness mereka, Anda akan berakhir menunggu. Kerjakan irisan yang tidak bergantung pada pihak lain terlebih dahulu, atau pastikan readiness sudah siap sebelum Anda membutuhkannya.

Untuk memudahkan Anda menerapkan keempat pertanyaan tersebut secara sistematis, berikut adalah pohon keputusan yang bisa Anda gunakan sebagai panduan:

flowchart TD A[Mulai tentukan urutan irisan] --> B{Menjadi fondasi} B -- Ya --> C[Kerjakan lebih dulu] B -- Tidak --> D{Risiko teknis tertinggi} D -- Ya --> E[Kerjakan lebih awal] D -- Tidak --> F{Belajar paling cepat} F -- Ya --> G[Uji asumsi lebih dulu] F -- Tidak --> H{Butuh readiness pihak lain} H -- Ya --> I[Pastikan readiness siap] H -- Tidak --> J[Ikuti prioritas bisnis] C --> K[Urutan kerja cerdas] E --> K G --> K I --> K J --> K

Senior engineer tidak mengerjakan irisan berdasarkan urutan di dokumen. Ia menyusun execution sequence yang mempertimbangkan dependency, risiko, pembelajaran, dan readiness. Ia tahu bahwa urutan yang cerdas bukan hanya tentang apa yang selesai lebih dulu, tetapi tentang bagaimana setiap irisan membuka jalan bagi irisan berikutnya. Dengan urutan yang tepat, Anda tidak hanya menyelesaikan pekerjaan—Anda membangun fondasi yang membuat sisa pekerjaan menjadi lebih aman, lebih cepat, dan lebih bisa diprediksi.

Setelah urutan kerja ditentukan, tibalah saatnya untuk benar-benar menulis kode. Dan di sinilah banyak engineer tergelincir: mereka mengejar kecepatan dengan mengorbankan kualitas. Padahal, kualitas yang terjaga sejak awal justru membuat Anda lebih cepat dalam jangka panjang.