Tanyakan kepada pemilik bisnis mengapa proyek perangkat lunak mereka terlambat dan mereka biasanya akan menyalahkan pengembangnya. Tanyakan kepada insinyur mana pun yang telah mengirimkan lusinan proyek dan mereka akan mengatakan yang sebenarnya: mengapa proyek perangkat lunak tertunda hampir tidak pernah bergantung pada seberapa cepat orang dapat mengetik kode. Hal ini tergantung pada seberapa cepat keputusan dibuat di luar basis kode.
Saya telah memimpin pelaksanaan cukup banyak proyek, mulai dari sistem manajemen armada perusahaan hingga aplikasi seluler fintech, untuk melihat pola tersebut berulang dengan keandalan yang hampir mekanis. Perkiraan teknik biasanya mendekati. Antrean keputusan klien adalah bagian yang tidak diperkirakan oleh siapa pun, dan merupakan bagian yang benar-benar menentukan tanggal pengiriman.
Ini bukanlah pembelaan bagi para insinyur yang benar-benar lamban. Ini adalah pengalihan perhatian ke tempat jalur kritis sebenarnya berada, karena pemilik yang memahami hal ini memperbaiki linimasa mereka sendiri lebih cepat daripada perubahan proses apa pun di sisi vendor.
Antrian Keputusan Adalah Jalur Kritis yang Sebenarnya
Setiap proyek perangkat lunak memiliki lusinan keputusan kecil yang tertanam di dalamnya yang hanya dapat diambil oleh klien: kolom mana yang wajib diisi pada formulir, apa yang terjadi jika pembayaran gagal, apakah aturan diskon berlaku sebelum atau sesudah pajak. Insinyur dapat mengatasi ambiguitas selama beberapa hari, namun pada akhirnya ambiguitas tersebut menghalangi suatu pekerjaan tertentu, dan ambiguitas tersebut akan tetap ada sampai seseorang yang berwenang menjawabnya.
Perhitungan yang mematikan garis waktu sangatlah sederhana. Jika tim Anda memiliki sepuluh keputusan ini dalam satu proyek, dan masing-masing keputusan membutuhkan rata-rata 3 hari kerja untuk mendapatkan jawaban karena harus melalui dua orang dan satu rapat, itu berarti 30 hari kerja, enam minggu kerja, duduk di dalam apa yang tampak di atas kertas seperti sebuah bangunan sederhana. Kompres setiap keputusan ke hari yang sama dan Anda akan pulih enam minggu tanpa menyentuh satu baris kode pun lebih cepat.
Bagaimana Keterlambatan 3 Hari Menjadi Slip 3 Bulan
Efek gabungan inilah yang membuat hal ini tidak terlihat sampai terlambat. Satu keputusan yang diblokir tidak hanya memakan biaya selama 3 hari ketika keputusan tersebut tidak digunakan, namun juga memerlukan biaya:
- Biaya peralihan konteks ketika insinyur berpindah ke pekerjaan lain dan harus memuat ulang konteks ketika jawabannya tiba
- Biaya ketergantungan ketika fitur lain menunggu fitur ini selesai
- Biaya verifikasi ulang ketika waktu telah berlalu dan persyaratan sedikit berubah sejak pertanyaan pertama kali diajukan, sehingga jawaban awal perlu dikonfirmasi ulang
Tiga atau empat hal ini secara berurutan, masing-masing dengan pajak majemuknya sendiri, adalah bagaimana sebuah proyek yang seharusnya memakan waktu 10 minggu menjadi 22 minggu. Tidak ada yang berbohong tentang perkiraan tersebut. Perkiraan itu untuk pengkodean. Tidak ada yang memperkirakan latensi keputusan karena latensi tersebut tidak akan terlihat sampai Anda berada di dalam proyek dan menyaksikannya terjadi.
Pergeseran Persyaratan Adalah Gejala, Bukan Penyakit
"Persyaratan terus berubah" adalah alasan paling umum yang diberikan untuk penundaan, dan biasanya itu benar tetapi tidak lengkap. Persyaratan berubah karena klien tidak memiliki kejelasan penuh di awal, dan ini normal, tidak ada yang menentukan spesifikasi sistem secara lengkap sebelum membangunnya. Kegagalan sebenarnya adalah tidak adanya jalur yang cepat dan bernama untuk menyelesaikan perubahan setelah perubahan tersebut muncul.
Perubahan persyaratan yang diputuskan dalam sehari membutuhkan biaya sehari. Perubahan yang sama, jika harus menunggu rapat pengarah bulanan, biayanya sebulan, dan segala sesuatu di hilirnya juga molor sebulan. Volatilitas persyaratan diperkirakan terjadi. Lambatnya penyelesaian volatilitas adalah penyebab penundaan sebenarnya, dan hal ini dapat dikendalikan.
Cara Mengatasinya: Penentu Nama dengan SLASatu-satunya perubahan dengan pengaruh tertinggi yang pernah saya lihat dilakukan oleh pemilik pada timeline proyek mereka adalah menunjuk satu orang, dengan otoritas nyata, yang memiliki keputusan dalam waktu penyelesaian tetap, biasanya 24-48 jam. Bukan komite. Bukan "tim akan mendiskusikannya." Seseorang bernama manusia yang memutuskan atau secara eksplisit melakukan eskalasi dalam jendela itu.
Ini melakukan dua hal. Hal ini memberi tim pengiriman ritme yang dapat diprediksi untuk membuat rencana, dan memaksa ambiguitas muncul lebih awal daripada bersembunyi di dalam kotak masuk seseorang. Proyek yang saya selesaikan dengan penentu bernama dan SLA nyata mencapai tanggalnya. Proyek tanpa satu pun kesalahan sehingga sulit dilacak ke penyebab tunggalnya, karena penyebab tersebut didistribusikan ke lusinan penundaan kecil yang masing-masing terlihat masuk akal jika dipisahkan.
Jika Anda sedang mengevaluasi apakah akan membuat alat khusus atau membeli alat siap pakai secara khusus untuk menghindari overhead pengambilan keputusan ini, trade-off tersebut layak untuk dipikirkan secara eksplisit; Saya memaparkan kerangka kerjanya di Membangun vs Membeli Perangkat Lunak: Kerangka Keputusan untuk Pemilik.
Yang Perlu Diperhatikan sebagai Pemilik
Beberapa tanda peringatan awal bahwa proyek Anda sedang menuju kegagalan karena keputusan, bukan karena coding:
| Tanda peringatan | Apa yang biasanya dimaksud |
|---|---|
| Panggilan status mingguan terus mengatakan "menunggu masukan klien" | Antrian keputusan adalah penghambatnya, bukan pembangunan |
| Pertanyaan yang sama ditanyakan dua kali | Jawaban pertama tidak dimiliki atau didokumentasikan dengan jelas |
| Cakupan fitur terus "mengklarifikasi" di tengah sprint | Tidak ada jalur cepat untuk mengunci perubahan cakupan |
| Vendor terus mengutip ulang timeline | Mereka menyerap latensi keputusan Anda ke dalam perkiraan mereka |
Jika Anda melihat dua atau lebih masalah ini, perbaikannya bukanlah pembicaraan yang lebih sulit dengan pengembang Anda. Ini memberi nama pada penentu dan memberi mereka SLA.
Yang Dapat Dibawa Pulang
Alasan mengapa proyek perangkat lunak tertunda lebih sering disebabkan oleh latensi keputusan dibandingkan kecepatan pengkodean: penundaan persetujuan selama 3 hari ditambah dengan peralihan konteks dan rantai ketergantungan menjadi slip berbulan-bulan. Sebutkan satu penentu nyata dengan SLA 24-48 jam dan Anda akan memulihkan lebih banyak jadwal daripada perombakan proses apa pun di sisi teknik. Jika Anda sedang mengerjakan proyek dan mencoba mendiagnosis di mana timeline Anda sebenarnya bocor, percakapan tersebut layak dilakukan melalui partner.