11.7 Menyusun Urutan Pengerjaan yang Realistis

Setelah solusi dipecah menjadi work package dan release slice, pertanyaan berikutnya selalu sama: "Kita mulai dari mana?" Jawabannya tidak sesederhana memilih yang paling menarik atau yang paling mudah. Urutan pengerjaan yang salah bisa membuat tim menunggu, integrasi molor, atau data migrasi jadi bencana di menit terakhir.

Bayangkan Anda punya tiga work package: integrasi dengan sistem lama, migrasi data pelanggan, dan pembuatan antarmuka pengguna baru. Kalau Anda mulai dari antarmuka, tim akan selesai cepat. Tapi saat mau integrasi, ternyata sistem lama butuh perubahan API yang tidak terduga. Antarmuka yang sudah jadi harus dirombak. Waktu terbuang.

Urutan yang realistis harus dibaca seperti rantai ketergantungan. Package mana yang harus selesai dulu agar package lain bisa dikerjakan? Integrasi dengan sistem lama mungkin menjadi dependency utama karena semua aliran data melewatinya. Migrasi data mungkin bisa jalan paralel, tetapi hanya setelah skema data final dari integrasi selesai. Antarmuka pengguna baru bisa dikerjakan paling akhir, setelah data dan integrasi stabil.

Di sinilah konsep dependency chain masuk. Anda perlu memetakan urutan kerja bukan berdasarkan keinginan, tetapi berdasarkan kebutuhan teknis dan logis. Buat daftar semua work package, lalu tanyakan: apa yang harus ada sebelum ini bisa dimulai? Apa yang bisa dikerjakan bersamaan? Apa yang harus menunggu hasil dari package lain?

Berikut adalah contoh definisi dependency antar work package dalam format YAML yang bisa Anda gunakan sebagai template.

work_packages:
  - id: wp-01
    name: Integrasi sistem lama
    depends_on: []
    risk: high
    ai_boost: low
  - id: wp-02
    name: Migrasi data pelanggan
    depends_on: [wp-01]
    risk: medium
    ai_boost: medium
  - id: wp-03
    name: Antarmuka pengguna baru
    depends_on: [wp-02]
    risk: low
    ai_boost: high

Berikut adalah diagram dependency chain yang menggambarkan urutan pengerjaan berdasarkan ketergantungan teknis dan prioritas risiko.

flowchart TD A[Integrasi Sistem Lama] -->|dependency| B[Migrasi Data] A -->|dependency| C[Antarmuka Pengguna Baru] B -->|paralel| C D[Persiapan Data & Pembersihan] --> B E[Test Stub / Mock Service] --> A F[AI-assisted Boilerplate] --> C G[Validasi Aturan Bisnis] --> B H[Dokumentasi Teknis] --> C A -->|risiko tinggi dikerjakan awal| I[Mitigasi Risiko] I --> A

Tapi dependency saja tidak cukup. Anda juga harus mempertimbangkan mitigation need. Package yang berisiko tinggi sebaiknya dikerjakan lebih awal, bukan ditunda. Misalnya, integrasi dengan sistem lama yang dokumentasinya sudah usang. Lebih baik menghadapi risiko ini di minggu pertama daripada di minggu terakhir saat tenggat sudah dekat. Dengan mengerjakan bagian berisiko lebih dulu, Anda memberi waktu untuk mencari solusi alternatif jika ternyata ada masalah besar.

Data migration juga punya urutan sendiri. Anda tidak bisa migrasi data sebelum target sistem siap menerimanya. Tapi Anda bisa mulai memetakan data, membersihkan data lama, dan menyiapkan skrip transformasi lebih awal. Pekerjaan persiapan ini sering tidak terlihat sebagai work package terpisah, padahal justru di sinilah sebagian besar waktu habis.

Integration readiness juga perlu dipertimbangkan. Apakah sistem yang akan diintegrasi sudah menyediakan API yang stabil? Apakah tim pemilik sistem lain punya kapasitas untuk membantu pengujian? Kalau belum, Anda perlu memasukkan waktu untuk menyiapkan test stub atau mock service agar tim tidak berhenti total.

Sekarang tambahkan satu faktor lagi: AI-adjusted capacity. Di era AI, kapasitas tim tidak lagi dihitung hanya dari jumlah orang dan jam kerja. Engineer yang memakai AI assistant bisa menyelesaikan tugas tertentu jauh lebih cepat. Tapi tidak semua tugas mendapat manfaat yang sama. Pekerjaan yang bersifat eksploratif, seperti mencari pola dalam data lama atau menulis kode boilerplate, bisa dipercepat drastis. Pekerjaan yang membutuhkan keputusan domain yang dalam, seperti memvalidasi aturan bisnis atau merancang skema data yang kompleks, tetap membutuhkan waktu manusia.

Karena itu, saat menyusun urutan, tempatkan pekerjaan yang bisa dibantu AI di fase yang lebih padat. Misalnya, jika minggu ketiga dan keempat diprediksi sangat sibuk karena dua dependency selesai bersamaan, gunakan AI untuk mempercepat pembuatan kode integrasi atau dokumentasi teknis. Sebaliknya, pekerjaan yang membutuhkan diskusi dan keputusan bersama sebaiknya ditempatkan di minggu yang lebih longgar.

Urutan yang realistis juga harus menyisakan ruang untuk belajar. Tim mungkin belum terbiasa dengan AI assistant tertentu. Atau integrasi dengan sistem lama ternyata punya keanehan yang tidak terduga. Jangan jadwalkan setiap jam kerja. Beri buffer untuk eksperimen dan perbaikan.

Setelah urutan tersusun, Anda akan memiliki peta jalan yang jelas: minggu ini kita kerjakan integrasi berisiko tinggi, minggu depan persiapan data dan migrasi paralel, minggu berikutnya antarmuka setelah data stabil. Setiap orang tahu apa yang harus selesai kapan dan apa yang harus menunggu apa.

Dengan urutan yang realistis, Anda siap menyusun rencana pengiriman yang lengkap. Bukan hanya urutan kerja, tetapi juga siapa yang mengerjakan, kapan diuji, kapan di-review keamanannya, dan bagaimana operasi menyiapkan diri.