- Ketika ada tekanan dari luar tim pengembang untuk menurunkan estimasi tanpa fakta baru, estimasi berubah seolah-olah menjadi objek negosiasi, sehingga kepercayaan dan kualitas perencanaan agile sama-sama memburuk
- Jumlah pekerjaan yang sebenarnya pada umumnya tidak bisa dikurangi sesuka hati oleh tim pengembang, dan tim memperkirakan upaya berdasarkan kecepatan tim, data story yang sudah selesai, dan throughput saat ini
- Jika demi menyesuaikan estimasi yang lebih rendah orang melewati proses atau menurunkan kualitas, jadwal mungkin tampak memendek untuk sementara, tetapi besar kemungkinan akan kembali sebagai biaya yang lebih besar di kemudian hari
- Percakapan yang lebih produktif bukanlah “buat lebih rendah,” melainkan melihat bersama anggaran, bagian yang paling memakan waktu, ketidakpastian terbesar, alternatif, pemecahan story, dan validasi awal
- Jika dalam ruang lingkup fitur yang tetap hanya angkanya yang diturunkan, itu akan menciptakan ekspektasi yang keliru tentang kapan sesuatu bisa dikirim ke pelanggan, dan perlu ada diskusi untuk menghapus fitur yang membutuhkan upaya tinggi tetapi bernilai rendah
Distorsi yang muncul ketika estimasi ditekan tanpa fakta baru
- Sering terjadi situasi ketika pemangku kepentingan di luar tim pengembang, dengan pengetahuan teknis atau pemahaman codebase yang terbatas, berkata “Tidak, itu membutuhkan upaya yang lebih sedikit daripada itu” sambil mencoba menurunkan estimasi
- Di permukaan, mereka tampak meminta “estimasi yang lebih baik”, tetapi dalam banyak kasus yang sebenarnya mereka inginkan adalah estimasi yang lebih rendah
- Jika estimasi diperlakukan sebagai angka yang bisa dinegosiasikan, baik pemangku kepentingan maupun tim pengembang akan mencapai kesepakatan yang tidak memuaskan, dan bisnis akan memiliki ekspektasi yang buruk tentang kapan perangkat lunak bisa dikirim ke pelanggan
- Sebagai kutipan rujukan terkait, terhubung ke Is tasking developers with creating detailed estimates a waste of money?
Estimasi lebih dekat ke prediksi daripada kontrol
- Ada situasi ketika estimasi memang bisa diperdebatkan
- saat story didiskusikan di dalam tim pengembang
- saat ada fakta baru yang memengaruhi jumlah pekerjaan sebenarnya
- Jika pemangku kepentingan dari luar yang tidak memahami detail implementasi dan tidak memberikan informasi baru meminta estimasi yang lebih rendah, itu mirip dengan mengatakan kepada ahli meteorologi bahwa “ramalan besok salah dan cuacanya akan lebih baik”
- Ahli meteorologi tidak mengendalikan cuaca, melainkan membuat ramalan berdasarkan pengetahuan dan data pengamatan
- Tim pengembang juga hampir tidak mengendalikan jumlah pekerjaan yang sebenarnya, dan memperkirakan upaya yang diharapkan berdasarkan pengetahuan dan data
Apa yang bisa dan tidak bisa dikendalikan tim pengembang
- Tim pengembang membuat estimasi dengan menggunakan kecepatan tim yang sudah mapan, data peninjauan story yang telah selesai, dan proses yang membaik di setiap sprint
- Untuk mengurangi jumlah pekerjaan, mereka memang bisa melewati sebagian proses dan mengirim perangkat lunak dengan kualitas lebih rendah
- Ini bukan cara yang direkomendasikan
- Sering kali biaya yang harus dibayar setelahnya justru lebih besar
- Tim mungkin punya ruang untuk meningkatkan kecepatan, tetapi pada saat membuat estimasi mereka harus menggunakan throughput saat ini, bukan throughput masa depan yang diharapkan
- Jika di perusahaan muncul percakapan seperti “tinggal bekerja lebih lama”, lingkungan seperti itu hampir merupakan resep menuju bencana
- Sebagai contoh pengalaman terkait, terhubung ke 3 komentar Reddit:
Percakapan yang seharusnya dilakukan alih-alih sekadar memotong angka
- Pengembangan perangkat lunak itu kompleks, dan sering kali memakan waktu lebih lama daripada yang dibayangkan orang
- Jika pemangku kepentingan melihat situasinya sebagai hanya bisa membelanjakan sampai jumlah tertentu, maka alih-alih menurunkan estimasi, hal-hal berikut perlu didiskusikan
- berapa banyak yang bisa dibelanjakan untuk story ini
- bagian mana dari story yang paling banyak memakan waktu
- di mana ketidakpastian terbesar berada
- alternatif apa yang ada untuk menangani bagian yang memakan waktu dan ketidakpastian itu
- Opsi untuk mengubah cara validasi dan pengiriman juga perlu ditinjau bersama
- memecah story dan mengirimkannya dalam beberapa bagian
- memvalidasi setiap bagian sedini mungkin
- jika memungkinkan, memvalidasi dengan prototipe
- Terutama untuk fitur yang membutuhkan banyak upaya tetapi memberi nilai paling rendah, perlu dicari cara untuk mengeluarkannya dari story
Mengubah pertanyaan jadwal menjadi lebih berguna
- Dibanding pertanyaan yang mendorong penurunan estimasi, pertanyaan yang memperjelas hubungan antara fitur serta jadwal/ruang lingkup jauh lebih produktif
- Pertanyaan berikut, yang dibahas dalam tulisan terpisah, ditautkan di sini
- Kapan Feature A bisa dikirimkan
- Apa yang bisa dikirim sebelum akhir kuartal berikutnya
- Bisakah Feature A dikirim sebelum akhir kuartal berikutnya
- Tulisan terkait: converting story points to hours
2 komentar
Kalau judul asli artikelnya diterjemahkan dengan DeepL, hasilnya seperti ini:
Apakah ada orang yang berkata, 'Tidak, itu butuh usaha yang lebih sedikit!'?
Komentar Hacker News
Analogi bahwa “menekan tenaga penjualan untuk menaikkan penjualan/kuota itu seperti meminta ahli meteorologi menghadirkan sinar matahari” tampaknya tidak terlalu tidak adil dalam konteks ini
Dalam praktiknya, ini lebih mirip dengan menuntut agar pekerjaan yang sama diselesaikan lebih cepat, yaitu bekerja lebih efektif
Jika tenaga penjualan diminta menetapkan kuotanya sendiri, mereka kemungkinan akan memilih angka yang aman dan realistis agar tidak terlihat gagal, karena ada banyak kompleksitas dan ketidakpastian dalam menutup kontrak
Namun angka itu bisa lebih rendah daripada yang dibutuhkan bisnis, sehingga diberikan kuota yang lebih tinggi agar mereka berusaha sedikit lebih keras untuk mencapainya
Ini menjadi lebih penting terutama jika imbalan terhubung langsung dengan pencapaian angka tersebut
Meski begitu, tenaga penjualan tidak terus-menerus menulis bahwa “kuota yang mereka tetapkan sendiri itu sakral, hanya tenaga penjualan yang boleh menentukannya, dan manajemen yang menuntut hasil lebih tinggi dari itu adalah orang yang tidak paham”
Analogi yang lebih dekat adalah ketika tim penjualan mengatakan untuk sebuah transaksi tertentu, “peluang closing 70%, annual recurring revenue sekitar 5 juta dolar,” lalu manajemen menjawab, “bisakah itu dijadikan 80% dan 7 juta dolar?”
Menaikkan peluang closing sambil juga menaikkan harga mungkin saja memungkinkan, tetapi seperti menyelesaikan fitur dalam setengah waktu, itu akan memerlukan perubahan besar atau kompromi di suatu sisi
Hanya saja, jauh lebih baik menyelesaikannya lebih cepat daripada estimasi daripada mengubah estimasi menjadi target yang didorong oleh harapan
Yang terbaik adalah menyusun pekerjaan berdasarkan prioritas dan prasyarat, memastikan ada cukup banyak story yang benar-benar siap dikerjakan, dan saat mendesak, menugaskan tiket secara strategis meski harus menanggung biaya jangka panjang berupa ketidakseimbangan kemampuan tim
Jika ada tekanan waktu, semua hal yang “bagus kalau ada” harus dihapus dari setiap fitur atau dipindahkan ke bagian bawah backlog, dan konsultasi dengan tim lain atau pakar eksternal harus diberi batas waktu yang ketat
Rapat dan gangguan yang tidak perlu harus dihilangkan, developer harus bisa menolak rapat atau memblokir kalender mereka, dan standar untuk refactoring harus dinaikkan sehingga hanya dilakukan bila manfaatnya jelas sebanding dengan biayanya sebelum tenggat, dengan pendekatan seperti meminjam dari masa depan
Namun, perlu sangat berhati-hati agar cara seperti ini tidak dijadikan cara kerja standar
Jika 10% lead bisa dikonversi, maka ketika dibutuhkan 5 deal alih-alih 4, kurang lebih cukup dengan menelepon 10 orang tambahan
Perbandingan yang lebih baik untuk software adalah membangun bentuk bangunan baru, misalnya rumah kubah geodesik, dalam keadaan belum punya pengalaman dan belum benar-benar tahu masalah apa saja yang akan dihadapi
Lalu Anda diminta memberikan estimasi yang akurat, dan setelah itu ditekan untuk menurunkannya lagi
Yang paling penting adalah perilaku menipu pelanggan, dan ini bukan sekadar “melebih-lebihkan secara wajar demi perusahaan”
Misalnya menjanjikan hal yang tidak bisa dipenuhi perusahaan, atau menjual fitur masa depan sambil menuntut death march yang mengorbankan kualitas dan keberlanjutan
Walaupun pihak C-level tidak melihatnya, akibatnya tetap terjadi
Ini bukan berarti estimasi developer harus dipercaya begitu saja, tetapi itu lubang kelinci yang lebih dalam dan terlalu melelahkan untuk dibahas sekarang
Itu hanya akan membuat pemahaman terhadap jadwal menjadi lebih tidak realistis
Sangat mungkin untuk mencari solusi kreatif lain yang menyelesaikan masalah yang sama, atau memahami ruang lingkup apa yang bisa dipangkas agar target tercapai
Tetapi itu sama sekali berbeda dari sekadar berkata, “lakukan persis pekerjaan yang sama, hanya saja lebih cepat”
Saat topik estimasi muncul, para pengembang sering kali hampir tidak pernah benar-benar melihat dari sudut pandang bisnis, dan tidak berusaha memahami mengapa estimasi dibutuhkan serta mengapa yang lebih singkat selalu dianggap lebih baik daripada yang lebih lama
Sebaliknya, mereka cenderung berusaha menjaga kesakralan pengembangan perangkat lunak, sambil makin memperlebar jarak antara engineer dan “orang-orang lainnya”
Dalam proses itu, sinisme dan sarkasme muncul, dan pada akhirnya menghasilkan estimasi yang tidak realistis
Saya sudah pernah menjadi pengembang, PO, manajer, direktur, sampai CTO, tetapi saya tetap terkejut melihat betapa banyak pengembang yang terlalu jauh dari realitas pemberian nilai dan faktor waktu
Sebagai pengembang, ketika ada yang bertanya berapa lama pekerjaan akan memakan waktu, lalu memberi kesempatan untuk menjelaskan, membantah, dan mempertahankan estimasi, itu justru sebuah keberuntungan
Kenyataan yang menyedihkan adalah bahwa pengembang sering kali tidak mahir ikut dalam percakapan di level bisnis untuk menyampaikan pemikiran, ide, kekhawatiran, dan usulan agar PM dan manajer bisa melihat kompleksitas pekerjaan dan melakukan diskusi biaya/manfaat yang sehat
Perlu dilihat apakah lead developer ikut rapat bisnis, apakah tim pengembang melihat angka dan anggaran, ikut menyusun roadmap, serta melakukan riset pengguna dan brainstorming fitur bersama orang bisnis/UX
Jika tidak, sulit mengharapkan pengembang akan memahami bisnis
Pemisahan antara pengembangan dan bisnis membuat masing-masing pihak terkurung dalam silo sambil berharap ahli di sisi lain memahami masalah mereka dengan baik, dan itu melahirkan anggapan pengembangan perangkat lunak sebagai sesuatu yang sakral
Banyak perusahaan tampaknya sekadar tetap berjalan meski perannya tersilo secara ekstrem, lalu mengira cara itu baik-baik saja hanya karena uang terus masuk
Biasanya hanya karena seseorang ingin memasukkan angka ke dalam PowerPoint untuk politik organisasi
Kadang memang dipakai untuk memutuskan akan melakukan A atau B, dan dalam kasus seperti itu yang benar-benar dibutuhkan bukan estimasi absolut, melainkan hanya estimasi relatif
Sesekali memang ada tenggat yang nyata, tetapi bahkan saat itu yang dibutuhkan bukan estimasi, melainkan “bisakah tanggal ini dipenuhi” atau, yang lebih berguna, “apa yang perlu dilakukan untuk memenuhi tanggal itu”
Bekerja sedekat mungkin dengan bisnis itu baik, dan alasan orang memakai perangkat lunak sejak awal biasanya juga untuk menyelesaikan kebutuhan bisnis
Namun dalam hal estimasi, sering kali memang mereka yang salah dan kita yang benar
Jika yang lebih singkat selalu lebih baik, maka semua estimasi sekarang saja dibuat 1 hari; apakah itu benar-benar lebih baik?
Jika seorang pengembang bisa menulis kode, membuat estimasi, dan mengirimkan sesuai jadwal bisnis, orang itu bukan karyawan melainkan pendiri
Yang mereka inginkan adalah orang-orang naif yang bisa mengirim seperti pendiri tetapi tidak mendapat bagian keuntungan
Sebesar apa pun usaha Anda atau usaha saya, bayi itu tidak akan lahir lebih cepat
Tidak ada bagian yang ambigu
Keluhannya ada pada cara pertanyaannya, seolah-olah pengembang bisa mengetahui kapan tepatnya pekerjaan akan selesai
Kemampuan seseorang untuk cepat memberikan nilai itu terpisah dari kemampuan memperkirakan berapa lama sesuatu akan memakan waktu
Orang bisa salah total dalam estimasi dan tetap memberikan nilai yang besar
Jika benar-benar ada cara untuk mengestimasi waktu pekerjaan perangkat lunak, perusahaan pasti akan mempekerjakan estimator profesional seperti mereka mempekerjakan tim produk
Tidak ada alasan harus meminta pengembang melakukannya
Tentu saja orang lain juga tidak bisa, dan karena pengembang setidaknya bisa menebak batas bawah, mereka terus didesak melakukannya, tetapi prosesnya sendiri jelas-jelas bodoh
Untuk tahu berapa lama sesuatu akan memakan waktu, Anda harus bisa membuat daftar semua tahap untuk melakukannya, dan dalam pengembangan perangkat lunak itu mustahil
Pengembang bisa memberi batas bawah untuk requirement yang diberikan, dan jika sama sekali tidak ada hal tak terduga, mungkin estimasinya akan akurat, tetapi dalam 95–98% proyek, estimasi selalu lebih pendek daripada kenyataan
Pada akhirnya, “estimasi pengembang” menjadi ukuran seberapa besar buffer yang ingin dimasukkan pengembang ke proyek kali ini
Meminta estimasi berarti membingkai percakapan secara sepenuhnya salah
Pertanyaan yang sebenarnya seharusnya adalah masukan dari pengembang tentang masalah yang dimiliki bisnis saat ini, masalah yang mungkin muncul enam bulan lagi, dan efektivitas biaya untuk menyelesaikan masalah itu
Setelah itu, keputusan kualitatif perlu diambil ke arah yang mengurangi risiko
Hasil terbaik dari estimasi perangkat lunak adalah ketika semua orang mengabaikan dan melupakannya, dan hasil selain itu justru merusak nilai bisnis
Saya paham intinya, dan memang ada risiko nyata yang besar di organisasi dengan pihak-pihak yang tidak bertanggung jawab
Tapi analogi ahli meteorologi kurang pas
Tugas utama ahli meteorologi adalah memprediksi cuaca, sedangkan pengembang pada umumnya adalah orang yang bekerja di dalam cuaca itu, dan pengalaman mereka dalam membuat prediksi yang akurat relatif lebih sedikit
Hal yang membuat frustrasi sebagai pemangku kepentingan adalah estimasi konyol yang bahkan tidak dimulai dari waktu pengerjaan dan juga tidak berakhir pada jangka waktu yang realistis
Terutama pada level pekerjaan mikro, dan ada kasus ketika tugas yang paling lama 30 menit jika saya punya akses dan bisa mengerjakannya sendiri justru dibalas dengan estimasi berminggu-minggu
Bahkan ketika itu menimbulkan biaya operasional yang serius dan masuk kategori “semua harus dihentikan dan ini harus ditangani”
Tentu saja pekerjaan 30 menit tidak benar-benar hanya 30 menit karena pengujian dan dokumentasi, tetapi makin ngawur estimasinya, makin rusak juga hubungan kepercayaannya
Perlu dibedakan apakah yang ditanyakan adalah waktu kerja aktual untuk tugas tertentu, atau waktu berlalu dari sekarang sampai saat diterapkan ke produksi
Di hampir semua tim, keduanya didominasi oleh waktu ketika pekerjaan sedang menunggu sesuatu, tetapi pada yang kedua ini jauh lebih parah
Waktu benar-benar mengetik di keyboard biasanya nyaris hanya kesalahan pembulatan dibanding koordinasi dan penjadwalan
Jika tim tidak sengaja berupaya membangun cara kerja yang bertentangan dengan intuisi, tiket rata-rata akan menunggu jauh lebih lama daripada waktu kerja nyatanya
Terlebih lagi, tim sama sekali tidak melihat ketimpangan itu, dan bahkan tidak sadar bahwa itu penting
Saya juga ingin cepat memperbaikinya dan menyerahkannya
Masalahnya, tanpa continuous deployment yang sepenuhnya otomatis, 30 menit itu bukan 30 menit
Pekerjaan 30 menit itu harus ditinjau apakah memengaruhi departemen lain, perlu penjadwalan, pemberitahuan, dan deployment, serta bisa melibatkan 2–3 orang tambahan
Jika itu pekerjaan terjadwal, totalnya bisa mendekati 2 jam lintas beberapa orang, dan jika itu hotfix atau tiket dukungan, maka bila ada proses QA di luar pengujian otomatis, kehilangan produktivitasnya bisa 4–6 jam
Ditambah lagi, jika 6 orang lain juga meminta “pekerjaan 30 menit” yang dampaknya ke orang lain di perusahaan belum jelas, tidak ada yang akan pernah selesai
Tim kami memang punya alur hotfix, tetapi itu harus benar-benar situasi darurat ketika operasi perusahaan berhenti
Kecuali kasus yang sangat jelas, permintaan itu harus datang dari kepala departemen atau lebih tinggi
Kerugian karena tidak semua tiket darurat bisa langsung dikerjakan jauh lebih kecil daripada kerugian ketika perbaikan untuk satu orang justru menimbulkan masalah bagi banyak orang atau membuat proyek besar yang strategis tidak selesai
Seharusnya ada cara di organisasi untuk memberikan akses yang diperlukan
Jika jawabannya mendekati “itu bukan pekerjaan saya”, maka organisasi itu terstruktur untuk menghargai komponen-komponen yang saling terhubung dengan tanggung jawab yang ketat
Dalam organisasi seperti itu, biaya komunikasi memang wajar sepenuhnya mendominasi kinerja output
Jika koordinasinya bagus, kualitas bisa tinggi, dan jika peran pekerjaannya jelas, throughput juga bisa tinggi, tetapi latensi rendah tidak akan pernah didapat
Waktu respons memang dikorbankan demi hal-hal lain
Dalam struktur seperti itu, estimasi 1 minggu untuk pekerjaan kecil pun merupakan hal yang bisa diperkirakan
Saat jadwal sudah penuh, pekerjaan baru sangat mungkin baru akan ditugaskan beberapa minggu kemudian, dan jika tanggung jawab yang terpecah mengharuskan dua orang atau lebih, waktu tunggu itu akan terus terakumulasi
Jika itu tidak cocok dengan kebutuhan pekerjaannya, berarti organisasinya sendiri tidak cocok untuk pekerjaan itu
Itu tidak efisien bagi semua yang terlibat
Tim kami punya otonomi besar, tidak menghitung waktu atau diawasi produktivitasnya dari luar, tetapi saat dibutuhkan kami memang tidak punya waktu untuk merapikan kode
Kalau terlihat ada pekerjaan “30 menit”, kami masukkan ke review pagi, lalu bertanya apakah ada hal yang berdekatan yang sekalian bisa dikerjakan saat menyentuh topik itu
Kalau tidak ada pun, kami tetap mengalokasikan satu hari, atau setengah hari kalau proyeknya sangat kami kuasai
Setengah hari pertama untuk menelusuri kode, dan setengah hari sisanya untuk pembaruan seperti komentar kecil, upgrade versi, perbaikan kode, atau mengganti nama variabel
Saya juga merasa mendorong kontributor individu melakukan hal seperti itu lebih efisien dari sisi waktu
Bagi kontributor individu yang baru bergabung, waktu itu membantu mereka mempelajari kode lama, dan pada akhirnya juga mengurangi masalah legacy selama mereka tidak membuat perubahan besar
Satu-satunya tongkat sihir dalam pengembangan perangkat lunak adalah menyederhanakan requirement
Requirement selalu salah
Terlalu luas, terlalu ambigu, atau didasarkan pada asumsi yang keliru
Kemampuan yang benar-benar hebat adalah membuang sebagian asumsi dan mengusulkan solusi yang disederhanakan
Itulah cara terbaik sekaligus satu-satunya untuk memangkas jadwal
Kalau requirement sederhana memang lebih mudah menjadi lengkap dan akurat, tetapi requirement yang nyata mungkin memang tidak bisa disederhanakan
Dalam kasus seperti itu, yang dibutuhkan adalah spesifikasi yang lebih baik
“They write the right stuff” tentang grup perangkat lunak shuttle pada dasarnya adalah kisah tentang hal itu: https://www.fastcompany.com/28121/they-write-right-stuff
Sebagian besar bug perangkat lunak sebenarnya adalah bug requirement, dan ketika requirement-nya bagus, kecepatan membuat perangkat lunak bisa jadi luar biasa cepat
Saya pernah melihat proyek yang berangkat dari repositori kosong sampai deployment produksi hanya dalam 2 bulan karena requirement-nya sepenuhnya jelas dan tidak berubah-ubah
Sebaliknya, saya juga pernah melihat implementasi fitur sekitar 30 baris terseret berbulan-bulan karena requirement yang ambigu dan terus berubah
Saat ini item-nya memang baru puluhan, tetapi katanya beberapa tahun lagi akan jadi ribuan
Desainer merancang seluruh alur pencarian berdasarkan dokumen product requirement setebal 20 halaman, dan baru setelah semua perencanaan dan persiapan selesai, engineering dipanggil untuk menulis story dan mengestimasi pekerjaannya
Biasanya mereka punya pengetahuan domain yang cukup, dan tahu apa saja yang dibutuhkan untuk membangun sesuatu dalam konteks seperti ini
Layak untuk membahas bagaimana mengubah cakupan demi keseimbangan biaya/manfaat yang sesuai bagi para pemangku kepentingan
Saya pernah melihat pengembang berasumsi bahwa pekerjaan yang dibutuhkan jauh terlalu banyak, dan juga non-pengembang yang mengabaikan bagian inti yang membuat waktu pengerjaan memanjang
Kadang orang mencoba membuat solusi yang digeneralisasi, padahal yang sebenarnya dibutuhkan mungkin hanya seseorang duduk seharian di depan spreadsheet dan memprosesnya
Sering ada pertanyaan ketika estimasi dianggap terlalu tinggi, tetapi hampir tidak pernah ada yang bertanya ketika estimasi terlalu rendah; itulah titik yang ingin ditangani planning poker
Idenya adalah semua orang menyampaikan tingkat kesulitan pekerjaan tanpa saling memengaruhi, lalu jika ekspektasinya tidak cocok, barulah didiskusikan
Sangat mungkin ada seseorang yang sedang melewatkan sesuatu
Alasan saya menganggap sesuatu itu sederhana bisa jadi karena saya melewatkan bagian rumit dari masalahnya, atau karena saya bisa melihat solusi yang lebih rapi
Contoh yang bagus adalah ketika pelanggan membuat permintaan yang mustahil secara matematis maupun fisik
Meski planning poker dilakukan seharian untuk keinginan seperti ini, hasilnya tetap bisa berakhir pada kompromi yang mustahil
Saat masih menjadi freelancer, saya lebih suka mendengarkan penjelasan menyeluruh tentang masalahnya, lalu bila perlu mengamati proses orang yang saat ini menanganinya dari balik bahunya, kemudian menghilang beberapa hari dan kembali membawa rancangan yang menurut saya paling elegan dan andal untuk menyelesaikannya
Kecuali orang itu sangat berpengalaman dengan masalah kompleks, kebanyakan orang cukup baik menjelaskan masalah mereka tetapi tidak bisa mengusulkan solusi
Solusi selalu dimodelkan dari hal-hal terbatas yang sudah mereka kenal
Saya benar-benar sering melihat requirement aneh yang tercipta dari asumsi berantai banyak orang, padahal sebenarnya tidak pernah diminta siapa pun
Misalnya membangun arsitektur microservice yang dapat diskalakan tanpa batas dan aplikasi single-page penuh hanya agar dua belas pengguna internal bisa mengunduh data ke spreadsheet Excel
Ada asumsi bahwa tim cukup akrab dengan keseluruhan kumpulan fitur, dan memahami cara memakai sistem yang menangani perbedaan yang tak terhindarkan seperti A memberi X sementara B memberi X*3
Cukup melihat diskusi tentang bagaimana Scrum dijalankan dengan buruk saja sudah menunjukkan bahwa asumsi-asumsi ini sama sekali tidak terjamin
Juga tidak mempertimbangkan bahwa karena perpindahan kerja dan fitur baru, tim bisa sewaktu-waktu keluar dari kondisi asumsi tersebut
Terlalu sering akhirnya orang hanya saling mengangkat alis, lalu “karena X yang akan mengerjakan, maka estimasi X yang dipakai”, atau memilih rata-rata/nilai minimum sehingga hanya orang yang mengestimasi lebih tinggi yang dirugikan
Kalau begitu, saya juga tidak tahu kenapa dari awal harus main poker
Ini bahkan lebih Machiavellian daripada itu
Perantaranya menginginkan transaksi di mana jika sisi depan yang keluar saya menang, dan jika sisi belakang yang keluar Anda kalah
Mereka ingin mendapat keuntungan dengan memberi angka rendah untuk meyakinkan pihak di kubunya
Jadi mereka memakai segala macam teknik agar pengembang menyebutkan angka yang mereka inginkan, tetapi tanpa terlihat seperti perintah atau paksaan
Kalau terlihat begitu, angka itu akan menjadi angka mereka dan permainan pun rusak
Tetapi jika pada akhirnya jelas memakan waktu jauh lebih lama, mereka bisa menunjuk angka yang diberikan pengembang dan berkata bahwa mereka hanya menyampaikan apa yang mereka dengar, jadi tidak bertanggung jawab
Satu-satunya bahasa yang dipahami tipe orang seperti ini adalah mengirim pesan dengan membuat hasil permintaan “peninjauan” estimasi selalu naik
Pertama, estimasi seharusnya berguna agar bisnis bisa beradaptasi, tetapi dalam kenyataannya tidak ada adaptasi sama sekali
PM ditekan oleh atasannya untuk menyelesaikannya paling lambat sekitar tenggat tertentu
Kalau estimasi saya toh tidak akan diperhatikan, lalu untuk apa mengestimasi?
Kedua, tim tidak punya insentif realistis untuk memberi estimasi yang realistis
Kalau akurat memangnya dapat medali? Pada praktiknya, semua insentif justru mengarah ke pembesaran beban kerja lewat estimasi
Ketiga, semua tarian dan ritual estimasi ini tidak lebih dari sesuatu yang diterima manajer agar terlihat lebih efektif dan berpengaruh daripada kenyataannya
Saat menjadi engineer, saya tegas mengatakan, “Tidak ada cara yang lebih cepat untuk melakukan ini, jadi jangan menekan hanya demi mendapatkan angka yang ingin Anda dengar”
Selesainya ya selesai saat memang selesai, dan saya akan membuatnya kokoh serta bagus, jadi jangan ganggu
Tetapi ketika sebagai manajer saya mendorong estimasi yang lebih kecil, itu karena secara realitas bisnis yang terpenting adalah mengirim sesuatu dalam jangka waktu yang ditentukan
Walaupun itu berarti mendirikan rumah kartu dan memangkas sudut-sudutnya, setidaknya kami harus bertahan cukup lama untuk bisa menangani masalah itu nanti
Saat itu dari sisi engineering muncul penolakan seperti yang mungkin juga akan saya lakukan jika berada di posisi mereka
Bahwa ini gagasan yang mengerikan, akan membuat kami gagal di masa depan, dan kalau ingin menghindari penderitaan nanti maka sekarang harus turun tangan lebih banyak
Sekarang saya kembali menjadi engineer, tetapi pengalaman sebagai manajer cukup membantu saat menghadapi kesenjangan seperti ini
Mereka adalah tipe orang yang “naik sampai 11”
Seperti amplifier di Spinal Tap, kalau output maksimum normal Anda disetel ke 9, maka ada ruang untuk menaikkannya satu tingkat lagi saat mereka menginginkannya
Tentu saja itu membuat Anda bekerja lebih lambat daripada semestinya
Tetapi jika Anda ingin menjadi pengembang yang “naik sampai 11”, tampak jelas bahwa hanya ada satu cara agar itu berhasil
Manajer saya dan para manajer di atasnya persis seperti ini, mendorong deadline sewenang-wenang bukan karena pelanggan menunggu, tetapi agar terlihat bagus di hadapan atasan mereka
Ketika estimasi itu pasti gagal, semua orang lalu angkat tangan dan mulai memasukkan orang ke performance improvement plan dengan alasan estimasi buruk mereka
Sebagai engineer, apa yang saya dapat dari hidup dalam stres terus-menerus seperti ini, bahkan sampai kehilangan waktu bersama keluarga dan teman?
Tidak lebih dari membuat estimasi bodoh manajer mereka terlihat bagus
Salah satu trik lama adalah membuat visi dan janji, lalu berkata, “Saya sudah melakukan bagian saya, sekarang tinggal engineering melakukan bagian mereka”
Saat sedang menuntaskan rilis, saya teringat pada manajer yang kadang menambahkan fitur tanpa berkata apa-apa, bahkan beberapa jam sebelumnya
Mereka bahkan menempelkan fitur ke rilis yang sebenarnya sudah selesai
Sepertinya di kepala orang itu, cukup dengan menempelkan fitur ke dalam rilis maka semuanya langsung selesai
Kendala terbesar adalah ketika proyek baru dijelaskan dalam satu paragraf, orang-orang langsung meminta estimasi.
Selain itu, rasanya selalu bergantung pada “seberapa besar utang teknis yang ada” setelah melihat kodenya.
Satu-satunya jawaban masuk akal yang pernah saya berikan sejauh ini adalah, “Saya perlu 1–2 hari untuk mendorong Anda memperjelas requirement, lalu menghentikan codebase sebelum mulai untuk mengaudit dan mencari risikonya.”
Apa ada cara yang lebih baik dari ini?
Tujuannya bukan membuat kartu yang sempurna, melainkan setidaknya membuat satu tiket untuk setiap hal yang tampaknya perlu dikerjakan dalam proyek itu.
Lalu akan muncul banyak kartu satu baris seperti “membuat endpoint API pembuatan batch” atau “memigrasikan data dari tabel lama ke tabel baru”.
Jika kartunya lebih dari 5, saya mengestimasi dengan
((jumlah kartu / jumlah developer) * estimasi hari kerja per kartu) + estimasi hari cuti.Memang tidak akurat, tetapi PM dan atasannya jadi merasa estimasi saat itu telah dipikirkan dengan matang dan masuk akal.
Kalaupun nanti perlu penundaan, lebih mudah menjelaskan bahwa “kita mengasumsikan semua kartu butuh waktu yang mirip, tetapi dua kartu ini ternyata outlier yang lebih besar dari perkiraan”.
Biasanya mirip proses sprint, tetapi tidak perlu melacak kecepatan sprint berdasarkan perasaan semata.
Pimpinan perusahaan meminta estimasi saat informasinya nyaris tidak ada, dan ketika saya bilang saya perlu mencari tahu lebih banyak dan melihat codebase, mereka bilang mereka “hanya” butuh estimasi untuk memutuskan apakah pekerjaan ini akan disetujui dan apakah proyeknya akan dijalankan.
Akhirnya saya berputar-putar sampai memberi estimasi besar, karena semua hal yang belum diketahui—termasuk yang cakupannya pun belum jelas—membuat angkanya jadi besar.
Lalu di mata pimpinan, itu jadi terlalu besar dan terlalu mahal.
Dalam istilah Agile, ini adalah tiket spike bernilai 3 poin, dan output-nya adalah requirement rinci, deliverable, dan estimasi beserta trade-off yang telah dipertimbangkan.
Ini cara yang sepenuhnya normal.
Anda bisa memberi estimasi sebelum spike, tetapi beri sebanyak mungkin catatan.
Misalnya, Anda bisa bilang “dengan keyakinan 60% kurang dari 3 minggu, dengan keyakinan 80% 5 minggu, dengan keyakinan 90% 6 minggu”.
Secara umum saya menolak estimasi tenggat yang lebih dari 1–2 minggu, dan sebisa mungkin lebih suka estimasi per bagian.
Misalnya, “proyek ini terdiri dari 7 deliverable, masing-masing membutuhkan 1–2 hari kerja”.
Suatu pekerjaan mungkin memang setara 10 hari kerja engineering, tetapi perhitungan tenggat pada praktiknya jadi tidak berarti karena prioritas bisa berubah dan alasan lainnya.
Kalau para “manajer” tidak memahami ini, sayangnya akan sulit tetap damai.
Jangan pedulikan utang kode dan kualitas, lalu buru-buru kirim sesuatu yang cuma nyaris berfungsi.
Maka mereka akan puas.
Adegan peretasan film aksi yang khas seperti ini.
Pemimpin: “Berapa lama untuk meretas mainframe?”
Teknisi: “Peretas lawannya sangat hebat, jadi minimal 2 jam.”
Pemimpin: “Saya kasih 1 jam. Kerjakan.”
Lalu dia terbang mengitari file system 3D.
Setiap kali melihat adegan seperti ini, saya menambahkan narasi dalam hati untuk teknisinya.
“Estimasi sebenarnya 20 menit. Saya mungkin akan selesai sekitar menit ke-50, lalu sibuk terbang 10 menit lagi di file system 3D supaya si pemimpin tidak kepikiran macam-macam.”
Tidak sepenuhnya benar.
Banyak fitur bisa dibuat dalam beberapa tingkat, dari versi yang sangat minimal sampai versi yang benar-benar dipoles.
Kadang rekan developer mengestimasi 2 minggu untuk fitur yang menurut saya paling lama cuma sehari, tetapi itu karena dia mengasumsikan banyak tambahan yang sebenarnya tidak diminta, atau dia tahu ada bagian yang saya tidak sadar ternyata diperlukan.
Jika diminta mengubah estimasi, anggap saja itu sebagai undangan untuk sedikit lebih mendiskusikan requirement dan implementasi yang diusulkan.
Mungkin ada solusi yang jauh lebih sederhana yang bisa mencapai 90% dan tetap dapat diterima.
Ahli meteorologi tidak punya pilihan seperti itu.
Perbedaan antara sekadar melempar combo box/kotak pilih dasar dan membuat elemen UI kustom yang jauh lebih cocok dengan konteks tidak tersampaikan dengan baik kepada orang-orang di luar IT.
Bisa dijelaskan dengan gambar, tetapi karena stakeholder tidak melihat dan menyentuhnya, mereka tetap tidak tahu apa yang sebenarnya akan terjadi.
Jadi biasanya Anda memang harus membuatnya benar-benar berjalan dan menunjukkannya.
Ada klien yang mengatakan “tolong buat sesederhana mungkin”, lalu ketika ditunjukkan GUI prototipe dan GUI desain final, kemudian prototipenya, mereka bahkan tidak melihat dua yang pertama dan langsung menyetujui.
Kalau didesak, mereka akan mencoba prototipenya dan bilang “bagus, lanjutkan”, tetapi setelah menyentuh sesuatu yang benar-benar berfungsi di server pengujian, mereka berkata “ini bukan yang kami maksud”.
Saya sudah mengalaminya mulai dari toko suami-istri berdua sampai perusahaan Fortune 500 yang komentarnya datang dari direktur regional dan CTO global.
Ini baru cerita frontend; backend dan DevOps adalah masalah yang sama sekali berbeda, tetapi di sana juga jarak antara versi minimal dan versi yang dipoles sangat besar.
Sekarang saya sudah paham permainan ini, jadi akhir-akhir ini saya menghasilkan banyak uang dari proses rusak ini.
Pada tahun 1975 Fred Brooks menulis ini.
“Untuk melahirkan seorang anak, dibutuhkan 9 bulan berapa pun jumlah wanita yang ditugaskan.”
Tidak ada ungkapan yang lebih baik dari ini.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Setiap kali menambah satu orang lagi, justru makin lama.
Pengiriman tercepat adalah dengan tidak mengganggu developer solo dan membiarkannya bekerja.