Estimasi: mimpi buruk para software developer
The highest form of ignorance is to reject something you don’t know about.
— Wayne Dyer
Kali ini saya ingin berlelucon lagi. Yap sebuah lelucon lagi dari saya karena semua tulisan saya termasuk buku saya dianggap sebagai lelucon yang sangat tidak masuk akal di industri software development Indonesia bagi kebanyakan orang. Kali ini saya ingin berlelucon mengenai estimasi, hal yang paling membuat hidup software developer menderita dan tidak memiliki kehidupan. Saya sudah terlalu sering melihat software developer yang hidupnya menderita hanya karena estimasi. Hal ini membuat saya tergerak untuk berlelucon mengenai hal ini.
Satu hal yang saya suka lakukan adalah mempertanyakan kenapa saya melakukan sesuatu, asking profound questions. Mungkin bisa dibilang hobi saya adalah men-challenge status quo. Satu hal yang sering saya challenge dalam dunia software development adalah estimasi. Estimasi dalam industri software development lebih banyak mudaratnya daripada manfaatnya. Dalam pertemuan-pertemuan dengan para eksekutif saya sering menanyakan kepada mereka apa manfaat dari estimasi dalam software development. Dan jawaban yang saya dapatkan hingga hari ini adalah:
- Untuk memprediksi kapan software akan selesai.
- Untuk memprediksi berapa banyak software developer yang dibutuhkan.
- Untuk memprediksi berapa banyak biaya yang dibutuhkan.
- Untuk mengetahui kapan kita bisa mengintegrasikan pekerjaan kita dengan 3rd party.
- Untuk mengetahui siapa yang bisa disalahkan ketika estimasinya salah.
- Karena kita menghasilkan revenue dari estimasi.
Doubt is not a pleasant condition, but certainty is absurd.
— Voltaire
Intinya manajemen butuh estimasi untuk dapat memprediksi. Yang saya tanyakan berikutnya adalah, apakah mungkin untuk mencapai semua tujuan tersebut tanpa menggunakan estimasi sama sekali (NoEstimates)? Menurut mereka hal tersebut tidak mungkin.
Can somebody please estimate the percentage of worldwide programming effort that is burned in dysfunctional behaviour driven by “deadlines” that are just “guesses”?
— Kent Beck
Pertanyaan berikutnya yang saya tanyakan kepada mereka adalah adalah, apa mudarat dari estimasi dalam software development. Jawaban yang saya dapatkan hingga hari ini adalah:
- Ketika estimasi dijadikan deadline.
- Ketika estimasi salah software developer diminta untuk lembur.
- Waktu yang dihabiskan untuk menghasilkan estimasi tidak menghasilkan direct value untuk kostumer.
- Ketika kostumer meminta tambahan fitur namun estimasi tidak boleh ditambah/disesuaikan.
- Ketika estimasi dijadikan parameter komitmen, kalau estimasi dari software developer salah maka mereka dianggap tidak berkomitmen terhadap proyek.
- Ketika akurasi estimasi dijadikan sebagai Key Performance Indicator (KPI) software developer.
- Ketika software developer memberi buffer dalam estimasinya.
- Ketika manajer proyek memberi buffer tambahan di atas estimasi dari software developer yang sudah memiliki buffer.
- Ketika estimasi digunakan untuk mencari siapa yang salah atau bertanggung-jawab.
You never change things by fighting the existing reality.
To change something, build a new model that makes the existing model obsolete.
— R. Buckminster Fuller
Mungkin kita belum benar-benar belajar dari semua kegagalan seputar estimasi dalam software development. Mungkin pandangan kita tidak bisa melihat dari perspektif lain bagaimana untuk mencapai tujuan kita tanpa menggunakan estimasi sama sekali.
Bila estimasi digunakan untk memprediksi, setelah semua pertanyaan di atas tersebut saya menanyakan lagi kepada mereka mana yang lebih predictable: jadwal keberangkatan kereta api Shinkansen atau jadwal keberangkatan pesawat. Semua eksekutif dapat dengan mudah menjawab kalau jadwal keberangkatan Shinkansen jauh lebih predictable dibandingkan jadwal keberangkatan pesawat. Lalu kenapa bisa demikian, bukankah sudah ada estimasi jadwal keberangkatan di boarding pass pesawat para penumpang? Because predictability does not come from predicting (or estimating). Untuk keberangkatan pesawat terdapat banyak variabilitas yang bisa menyebabkan jadwal penerbangan terlambat seperti cuaca, bencana alam, jumlah antrian di landasan, penumpang yang telat, permasalahan teknis bahkan terorisme. Ternyata walaupun jadwal keberangkatan pesawat sudah diestimasi, tetapi tetap saja tidak se-predictable jadwal keberangkatan Shinkansen.
Whenever there is fear, you will get the wrong numbers.
— Edwards Deming
Dalam dunia korporat juga terdapat banyak variabilitas yang menyebabkan software delivery tidak predictable. Dan kebanyakan variabilitas ini bukan kesalahan dari software developer. Ketika delivery software tidak predictable, maka estimasi pun tidak dapat dihandalkan. Oleh karena itu estimasi kita selalu salah.
- Highest Political Power Wins (HiPPoW)
Pimpinan perusahaan yang tidak menerima kata TIDAK dari orang-orangnya adalah salah satu variabilitas dalam software delivery. Orang-orang ini menggunakan kekuatan politiknya untuk meng-override keputusan yang telah dibuat oleh orang-orangnya. It’s my way or the highway. Akhirnya mereka secara tidak langsung menjadikan diri mereka sebagai bottleneck karena orang-orangnya jadi takut membuat keputusan. Orang-orangnya selalu mencari persetujuan para HiPPoW sebelum membuat keputusan mengenai requirement dalam proyek software.
2. Misalignment between departments
Tidak selarasnya keinginan antar departemen mengenai requirement dalam software adalah salah satu variabilitas yang menyebabkan software delivery menjadi tidak predictable. Hal ini seringkali disebabkan oleh karena para pimpinan departemen sudah diberi target yang menyebabkan konflik antar departemen. Ketika orang-orang di dalam perusahaan diukur menurut satuan tertentu, mereka hanya berperilaku menurut ukuran yang diperlakukan kepada mereka tersebut. Oleh karena itu pimpinan departemen hanya memikirkan kepentingan departemennya saja. Misaligment menghambat proses delivery software.
3. Unclear goal and objectives
Tujuan tidak jelas menyebabkan requirement berubah-ubah. Belum lagi kalau perubahan tersebut harus menunggu persetujuan dari HiPPoW. Lebih bahaya lagi kalau ada perusahaan-perusahaan yang mengganggap Agile sebagai alasan untuk berubah-ubah pikiran, padahal sebenarnya kesalahan ada di sisi mereka karena mereka tidak tahu arah tujuan mereka. Agile bukan berarti tidak memiliki visi yang jelas mengenai tujuan akhir. Paradigma seperti ini yang menyebabkan software delivery tidak memiliki prediktabilitas.
4. Technical Debts
Technical Debts dalam software development dapat berupa lack of tests automations, lack of deployment automations, lack of documentations, dirty and tightly coupled code, defects, bad design, dsb. Technical Debt seringkali muncul karena software developer memotong jalan pintas demi memenuhi deadline. Software developer harus memotong jalan pintas karena pimpinan perusahaan hanya peduli dengan short-term wins. Walaupun Technical Debt muncul karena tekanan dari manajemen, Technical Debt juga dapat muncul karena software developer tidak memiliki keahlian untuk mengembangkan software secara professional, mereka tidak memahami apa yang perlu dilakukan oleh software craftsman. Technical Debt dapat menghantui software developer di kemudian hari yang dapat memperlambat software development. Technical Debt adalah variabilitas yang dapat membuat software delivery menjadi tidak predictable.
5. Overburden (無理 muri)
Memaksa software developer untuk lembur demi memenuhi deadline hanya akan berakhir pada overburden. Sama halnya dengan di dunia manufaktur, overburden dalam software development dapat berakhir pada kualitas rendah. Overburden dapat menghasilkan Technical Debt di dalam software. Software Developer yang terlalu dipaksakan kinerjanya tidak akan bisa berpikir dengan jernih bagaimana menghasilkan software dengan kualitas tinggi. Overburden adalah salah satu variabilitas yang menyebabkan delivery software development tidak dapat diprediksi.
6. Multitasking
Multitasking dalam software development bukan hanya pengerjaan beberapa proyek sekaligus dalam satu satuan waktu saja namun dapat juga berupa interupsi. Interupsi ini bisa berupa “urgent request” dari sisi bisnis maupun meeting yang menghabiskan banyak waktu. Interupsi menyebabkan software developer tidak bisa berkonsentrasi untuk menghantarkan software secara maksimal. Multitasking menyebabkan flow efficiency dalam software delivery menjadi rendah. Bila flow efficiency-nya rendah, maka software delivery menjadi tidak predictable.
Sekarang bukankah tidak adil bila software developer disalahkan estimasinya tidak akurat padahal penyebab-penyebabnya adalah variabilitas yang berada di luar kendali mereka? Dari sini kita belajar satu hal: predictability comes from removing variabilities. Predictability comes from stabilising the system where software developer is working.
As teams progress, they first struggle with estimation, then can get quite good at it and then they reach a point where they often don’t need it.
— Martin Fowler
NoEstimates dimulai dari mindset of greatness. NoEstimates is about being great in delivering software so estimate becomes irrelevant. NoEstimates akan berhasil anda lakukan di perusahaan anda bila anda mulai perspektif yang benar, perspektif yang ingin meng-coaching software developer agar menjadi seorang craftsman dan niat baik untuk menghilangkan variabilitas di dalam sistem korporat anda. NoEstimates tidak akan pernah berhasil dilakukan di organisasi anda bila dimulai dari sudut pandang prediktabilitas. Anda tidak akan pernah berhasil melakukan NoEstimates bila anda masih memiliki mindset Nazi yang hanya ingin memeras software developer hingga tetesan darah terakhir.
Transformation comes more from pursuing profound questions than seeking practical answers.
— Peter Block
Setelah membaca artikel ini, apakah sebagai pimpinan perusahaan anda benar-benar mau mencoba untuk menstabilisasikan sistem dalam perusahaan anda sehingga estimasi menjadi tidak relevan lagi? Maukah anda secara tulus memberikan coaching kepada software developer agar mereka menjadi ninja developer? Maukah anda berinvestasi untuk menghilangkan variabilitas dalam software delivery di perusahaan anda agar software delivery menjadi predictable? Apakah anda bisa membantu software developer untuk menjadi seseorang yang dapat menghantarkan software sebelum kostumer berubah pikiran? Apakah anda bisa membuat software delivery se-predictable jadwal keberangkatan kereta Shinkansen? Yang lebih penting lagi, maukah anda membantu software developer untk dapat tidur nyenyak setiap malamnya? Ah saya lupa, ini adalah pertanyaan-pertanyaan yang tidak tepat ditujukan kepada anda. Anda pasti sedang berpikir kalau saat ini saya sedang berlelucon lagi seperti biasanya. Atau mungkin anda berpikir hal tersebut terlalu mahal untuk diinvestasikan dan menekan software developer untuk lembur ketika estimasi mereka salah masih jauh lebih murah untuk dilakukan.
Aaah software developer, memang buruk sekali nasibmu. Mungkin engkau harus bersabar menunggu satu generasi lewat untuk benar-benar bisa melihat perubahan cara berpikir di industri software development di Indonesia.
Bila anda menemukan manfaat dari artikel ini jangan lupa untuk menekan tombol 👏🏻 di bawah sebanyak mungkin agar lebih banyak lagi orang yang dapat melihat artikel ini dan mendapatkan pencerahan baru. Terima kasih atas dukungannya untuk memodernisasikan cara berpikir orang-orang dalam industri software development di Indonesia. Semoga industri software development di Indonesia bisa menjadi lebih baik ke depannya.
