11.8 Rencana Pengiriman yang Lengkap
Bayangkan Anda sudah menyusun urutan pengerjaan yang realistis. Tim engineering sudah tahu work package mana yang dikerjakan pertama, mana yang menunggu, dan mana yang bisa jalan paralel. Tapi tiba-tiba kepala operasi bertanya, "Kapan kami perlu menyiapkan monitoring?" Tim security bertanya, "Kapan kami bisa mulai review?" Manajer produk bertanya, "Kapan user testing dilakukan?" Pertanyaan-pertanyaan ini muncul karena delivery plan yang hanya berisi jadwal development tidak cukup untuk menjawab kebutuhan semua pihak.
Delivery plan yang lengkap harus mencakup seluruh siklus hidup solusi, bukan hanya fase coding. Ini berarti plan harus menjawab enam area sekaligus: development, testing, security review, deployment, operation readiness, dan post-release verification. Masing-masing area punya aktivitas, dependensi, dan pihak yang bertanggung jawab.
Development adalah fase yang paling sering mendapat perhatian. Di sinilah work package dikerjakan, kode ditulis, dan komponen dibangun. Tapi development tidak bisa berjalan sendiri. Ia membutuhkan input dari solution architecture, akses ke environment development, dan keputusan teknis yang sudah ditetapkan. Dalam plan, development perlu menunjukkan milestone apa yang akan selesai di setiap sprint atau iterasi, dan bagaimana hasilnya diverifikasi.
Testing bukan aktivitas yang terjadi di akhir. Ia harus dimulai sejak work package pertama selesai. Ada beberapa level yang perlu dijadwalkan: unit test oleh engineer, integration test antar komponen, system test oleh tim QA, dan user acceptance test oleh pihak bisnis. Setiap level testing punya kriteria masuk dan keluar. Misalnya, integration test baru bisa dimulai jika komponen yang terlibat sudah stabil dan environment integration sudah siap. Plan yang baik menunjukkan kapan setiap level testing dimulai, berapa lama, dan siapa yang terlibat.
Security review sering menjadi bottleneck karena dianggap sebagai aktivitas terpisah yang dilakukan di akhir. Padahal security review bisa dimulai lebih awal. Arsitek bisa mengirimkan diagram dan alur data ke tim security sebelum development selesai. Tim security bisa mulai menganalisis potensi celah tanpa menunggu kode jadi. Dalam plan, security review perlu dijadwalkan sebagai aktivitas paralel, bukan aktivitas yang menunggu giliran.
Deployment bukan sekadar menekan tombol. Ia mencakup persiapan environment produksi, konfigurasi infrastruktur, migrasi data, cutover plan, dan rollback plan. Deployment yang baik adalah deployment yang sudah diuji di environment staging dengan skenario yang sama dengan produksi. Plan deployment perlu menunjukkan kapan dry run dilakukan, kapan cutover terjadi, dan berapa lama waktu yang dibutuhkan.
Operation readiness sering terlupakan. Tim operasi perlu tahu komponen apa saja yang harus dimonitor, metrik apa yang perlu diwaspadai, log apa yang harus dikumpulkan, dan siapa yang dihubungi jika terjadi insiden. Semua ini butuh persiapan. Dalam plan, operation readiness bisa berupa checklist yang harus dipenuhi sebelum go-live: dashboard monitoring sudah siap, alert sudah dikonfigurasi, runbook sudah ditulis, dan tim operasi sudah mendapat pelatihan.
Post-release verification adalah fase yang memastikan solusi benar-benar berjalan seperti yang diharapkan setelah live. Ini bukan sekadar mengecek apakah aplikasi bisa diakses. Verifikasi mencakup validasi fungsional, pengecekan performa, pemantauan error rate, dan konfirmasi dari pengguna awal. Post-release verification biasanya berlangsung beberapa hari hingga minggu pertama setelah go-live, tergantung pada kompleksitas solusi.
Semua area ini harus muncul dalam satu delivery plan yang terpadu. Bukan enam jadwal terpisah yang tidak saling bicara. Development, testing, security, deployment, operations, dan verification adalah satu rantai yang saling bergantung. Jika testing molor, deployment ikut mundur. Jika security review baru dimulai setelah development selesai, jadwal bisa kacau. Plan yang lengkap membuat semua pihak melihat keterkaitan ini dan bisa menyesuaikan ekspektasi sejak awal.
Berikut contoh struktur YAML yang merangkum enam area tersebut dalam satu rencana terpadu.
delivery_plan:
phases:
- name: Development
activities:
- code
- unit_test
owner: engineering
milestone: API v1 siap
- name: Integration Test
activities:
- integration_test
owner: qa
depends_on: Development
- name: Security Review
activities:
- security_audit
owner: security
depends_on: Development
- name: Deployment
activities:
- dry_run
- cutover
owner: devops
depends_on:
- Integration Test
- Security Review
- name: Operation Readiness
activities:
- dashboard_setup
- alert_config
- runbook
owner: operations
depends_on: Deployment
- name: Post-release Verification
activities:
- functional_check
- performance_monitor
- error_tracking
owner: qa
depends_on: Deployment
Setiap fase memiliki pemilik, aktivitas, dan dependensi yang jelas sehingga semua pihak bisa melihat keterkaitan dan menyesuaikan ekspektasi sejak awal.
Berikut diagram yang merangkum enam area tersebut dan alur dependensinya.
Setelah plan selesai, pertanyaan berikutnya adalah: bagaimana memastikan plan ini realistis dan bisa dieksekusi? Di sinilah AI bisa membantu membuat draft awal, tetapi keputusan tetap ada di tangan arsitek dan tim.
