Deadline Driven Development: metodologi software development terpopular di Indonesia
deadline (n): a date or time when something must be finished.
deadline driven development (n): when management believes that the only path to improved developer productivity is imposing arbitrary, unrealistic deadlines.
Ok mari kita lupakan sejenak metodologi mana diantara Waterfall, Spiral, Rational Unified Process (RUP), eXtreme Programming (XP), Jungkir-Balik, Feature Driven Development (FDD) ataupun kerangka kerja Scrum yang terbaik dalam mengembangkan software. Mari kita lupakan perdebatan sengit #AgileVsWaterfall®. Marilah kita yang terpecah-belah dari kubu Agile dan kubu Waterfall berteman untuk kali ini saja. Semua perdebatan antara kubu Agile dan kubu Waterfall hanya membuat pimpinan perusahaan semakin tertawa terbahak-bahak karena di mata pimpinan perusahaan cuma ada satu metodologi paling ampuh dalam software development yakni: Deadline Driven Development (DDD®).
Mau sebagus apapun dokumentasi dan sereligius apapun proses user requirement gathering yang kalian lakukan berdasarkan teori Waterfall, semua itu sia-sia karena pada akhirnya metodologi yang akan digunakan oleh pimpinan perusahaan adalah: Deadline Driven Development. Mau se-funky dan se-hippie apapun proses Design Sprint dan Design Thinking yang sedang ngetren dilakukan di startup, semua itu tidak lebih dari teori indah di atas kertas karena pada akhirnya metodologi yang akan digunakan oleh pimpinan perusahaan dan investor adalah: Deadline Driven Development. Minimum Viable Product (MVP)? Who cares? Di otak pimpinan perusahaan tidak ada yang namanya MVP, semua harus selesai apapun alasannya! MVP cuma teori indah dari negara-negara barat yang tidak relevan di Indonesia karena ujung-ujungnya pimpinan perusahaan tetap akan menggunakan Deadline Driven Development.
Beginilah cara perusahaan-perusahaan — baik di korporasi maupun startup — di Indonesia mengelola software development, dengan Deadline Driven Development (DDD®). Waterfall atau Scrum cumalah pembungkus manis dari Deadline Driven Development. Hal ini tidak disadari oleh banyak software developer di Indonesia, mereka masih terjebak dalam perdebatan antara Waterfall vs Scrum.
Deadline Driven Development telah membuat banyak software developer di Indonesia kehilangan sebagian dari hidupnya dan telah merusak industri software development di Indonesia. Dalam eXtreme Programming (XP) prinsipnya adalah apapun alasannya software developer hanya boleh bekerja maksimal 40 jam dalam seminggu namun dalam metodologi Deadline Driven Development prinsipnya adalah apapun alasannya kalau software developer tidak bisa menyelesaikan mandat dari pimpinan perusahaan sebelum deadline maka mereka harus L.E.M.B.U.R kalau perlu hingga matanya berdarah. Kalau Agile memiliki 12 prinsip yang dipegang teguh selama proses pengembangan software, dalam Deadline Driven Development cukup perlu 1 prinsip saja yakni: L.E.M.B.U.R — semua proses pengembangan software dalam DDD cuma berputar di atas 1 prinsip ini.
Kalau ada pakar Teknologi Informasi atau dosen yang pernah mengatakan kepada kamu kalau tidak ada silverbullet dalam metodologi pengembangan software, itu semua BOHONG karena sesungguhnya di Indonesia Deadline Driven Development adalah silverbullet tersebut. Silahkan saja tanyakan saja ke teman kamu yang berprofesi sebagai software developer apakah perusahaannya menggunakan Deadline Driven Development atau tidak. Yak, sepertinya Deadline Driven Development akan tetap eksis karena bahkan di startup keren yang ada ayunan dan XBox pun sangat religius dalam menggunakan Deadline Driven Development. Awalnya saya pikir hanya generasi baby boomers dan generasi-X saja yang menganut metodologi Deadline Driven Development, ternyata pimpinan perusahaan dari generasi-Y dan generasi milenial juga menganut metodologi ini di startup-nya secara religius.
Dan pada akhirnya jangan pernah lupa satu doktrin yang gemar diajarkan oleh dosen-dosen Teknik Informatika di Universitas kepada mahasiswa yakni: agar software developer tidak mengalami siksaan ini terlalu lama maka mereka harus menjadi analis bisnis atau manajer proyek yang akan kembali menyiksa software developer muda dan naif berikutnya secepat mungkin (tidak lebih dari 5 tahun).
Kenapa perlu ada deadline?
Deadline makes management looks like they are managing
Intinya manajemen ingin kelihatan kerja. Dengan adanya deadline maka manajemen akan kelihatan kalau mereka punya visi-misi, target, sense of purpose dan jargon-jargon lainnya dari jalur emasnya si motivator di televisi itu. Tanpa deadline maka software developer hanya akan malas-malasan tidak karuan atau hanya akan mencari pokemon di kantor. Prinsip dari Deadline Driven Development adalah deadline akan memotivasi software developer agar mereka giat bekerja dan tidak membuang waktu di kantor sia-sia. Di mata pimpinan perusahaan deadline dianggap sebagai motivator software developer yang clueless dan hanya peduli dengan gaji bulanan.
Asal muasal deadline untuk software developer
Dari mana datangnya deadline yang diturunkan ke software developer? Hampir tidak pernah ada deadline yang datang melalui proses kalkulasi ilmiah. Untuk kebanyakan besar pimpinan perusahaan, mereka terlalu malas untuk melakukan hal tersebut — toh di Indonesia prinsipnya adalah pimpinan perusahaan selalu benar. Namun berdasarkan pengamatan di lapangan, berikut beberapa asal-muasal deadline untuk software developer.
1. Hasil konversi estimasi dari software developer
Intinya di proses ini, pimpinan perusahaan atau manajemen akan meminta estimasi dari software developer dan estimasi tersebut secara otomatis dikonversi menjadi deadline. Ya sesederhana itu saja. Keliatannya ini lebih manusiawi dibanding asal-usul lainnya karena ada proses ngobrol dengan software developer tapi mengkonversi estimasi menjadi deadline tetaplah aneh karena dalam software development ada banyak variabilitas yang tidak bisa diprediksi.
Template obrolannya kira-kira sebagai berikut:
Pimpinan: Kira-kira butuh berapa lama untuk menyelesaikan fitur X?
Developer: Sekitar 2 bulan pak.
P: Ok 2 bulan lagi saya tagih ya.
D: Tapi etapi pak, itu baru estimasi saja lho.
P: Lho tadi kan kamu bilang 2 bulan. Sudahlah, saya mau bilang ke kostumer ini.
D: (Aaah kampret. Tahu gitu gw kasih buffer aja tadi).
2. Magic Date from the HiPPo (Highest Political Power)
Beberapa software developer cukup beruntung bisa melalui proses tanya-jawab terlebih dahulu dengan manajemen, terlepas apakah diskusi tersebut genuine atau tidak. Namun banyak software developer tidak seberuntung itu karena deadline yang diturunkan ke mereka tidak ada asal muasalnya sama sekali. Bagi mereka yang berada di posisi ini deadline adalah “a magic date that falls from the sky to the HiPPo’s (Highest Political Power) brain”.
Template obrolannya kira-kira sebagai berikut:
Product Manager: Jon ini fitur X harus selesai akhir bulan ini.
Developer: Kenapa harus akhir bulan ini cuy?
PM: Soalnya akhir bulan ini ulang tahunnya CEO Jon.
D: Whut the *?!*?
3. Useless conversation
Di proses ini, pimpinan perusahaan atau manajemen akan pura-pura menanyakan estimasi ke software developer, padahal sebelum bertanya ke software developer mereka sudah memiliki deadline di dalam otaknya. Pada dasarnya pembicaraan yang mereka lakukan dengan software developer bersifat useless karena hanya membuang-buang waktu dan tidak genuine.
Template obrolannya kira-kira sebagai berikut:
Pimpinan: Kira-kira butuh berapa lama untuk menyelesaikan fitur X?
Developer: Sekitar 2 bulan pak.
P: Duh bukannya saya ingin menekan kamu nih ya. Tapi kayaknya kelamaan deh. Bisa lebih cepat lagi tidak?
D: Itu fitur kompleks Pak bikinnya. Beneran deh.
P: 1 bulan saja bisa tidak?
D: Hah?!? Wah ga mungkin banget itu Pak.
P: Sudahlah kamu pasti bisa kok. Yakin sama diri sendiri.
D: (Jiaaah tau gitu kagak usah pake pura-pura nanya Pak).
4. Taruhan di lapangan golf
Namun yang paling parah yang saya temukan adalah ketika seorang CEO menentukan deadline sebagai taruhan dengan CEO lainnya.
CEO A: Jon bentar lagi gw bakalan launching e-commerce website nih. Mainan baru setelah selesai dengan bisnis yang lain-lain.
CEO B: Widih keren banget. Berapa lama lagi nih launching?
CEO A: Mau dibuat taruhan ga Jon? Lu yang nentuin tanggalnya deh.
CEO B: Ok deh. Kalau tim elu bisa deliver 3 bulan gw kasih Rp. 100 juta.
CEO A: Ok Jon. Deal. Kalau tim gw tidak bisa deliver dalam 3 bulan gw akan kasih elu Rp. 100 juta.
Secara singkat, prinsip lain dari metodologi Deadline Driven Development yang dianut oleh pimpinan perusahaan di Indonesia adalah: atasan selalu benar, software developer tidak perlu memperdebatkan asal-usul dari deadline.
Permasalahan dengan deadline
1. Deadline encourage software developers cut corners
Deadline akan mengarahkan software developer untuk mengurangi kualitas karena kalau waktu dan ruang-lingkup sudah dikunci maka satu-satunya yang bisa dimainkan oleh software developer adalah kualitas. Oleh karena itu menurut Jim Benson: “deadline is influencers of crap”.
Dan kalau anda masih berpikir software development adalah pekerjaan prediktif seperti konstruksi jembatan, anda harus menghilangkan cara berpikir tersebut jauh-jauh ke lautan yang dalam.
2. Deadline does not invite conversation with software developers
Slaves are not allowed to say no. Laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no. It’s the only way you can really get anything done.
— Robert C. Martin
Deadline yang dibuat sepihak akan memposisikan pimpinan perusahaan yang paling benar. Deadline yang dibuat sepihak adalah cara memimpin perusahaan dengan political power. Deadline yang dibuat sepihak menempatkan software developer bukan sebagai rekan kerja yang cerdas namun sebagai budak yang tidak bisa mengatakan TIDAK.
Jadi gimana dong?
We can’t solve problems by using the same kind of thinking we used when we created them. — Einstein
Untuk dapat membuat deadline menjadi tidak relevan di perusahaan, maka fundamental berpikir dan cara pandang terhadap software development harus dirubah terlebih dahulu. Daripada berorientasi pada deadline, pimpinan perusahaan dan software developer fokus pada optimising flow. Tujuan dari pendekatan berikut ini adalah berkolaborasi dengan software developer untuk mencari jalan keluar dan membuat opsi-opsi untuk mencapai tujuan. Pembicaraannya harus lebih terbuka dengan software developer dan tidak otoriter/sepihak. Dan lewat proses ini LEMBUR tidak pernah menjadi jalan keluar sama sekali.
1. Ukur Cost of Delay
Cost of delay adalah metrik yang sering saya gunakan belakangan ini untuk mengarahkan orang-orang di perusahaan-perusahaan di Indonesia keluar dari deadline-driven development mindset. Yang membuat saya heran ternyata banyak product manager di startup-startup di Indonesia yang tidak menggunakan metrik ini. Kebanyakan product manager hanya fokus ke user experience dan design thinking. Lebih parah lagi banyak product manager yang cuma menjadi proxy dari pimpinan perusahaan.
Cost of delay dapat dikalkulasi secara ilmiah namun dapat juga didapatkan dari pembicaraan yang sederhana. Pembicaraan seputar cost of delay harus lebih open-minded dan tidak sepihak kira-kira seperti ini:
Product Manager: Jon ini fitur X harus selesai akhir bulan ini.
Developer: Kira-kira kita akan kehilangan berapa rupiah kalau tidak selesai akhir bulan ini?
PM: Kira-kira kita bisa kehilangan Rp. 100 juta rupiah per hari Jon.
Setelah bisa mendapatkan cost of delay, urutkan pekerjaan berdasarkan cost of delay. Pekerjaan dengan cost of delay paling tinggi berada dalam urutan paling atas. Pekerjaan dengan cost of delay yang sangat tinggi harus di-slice menjadi beberapa fungsionalitas lebih kecil (langkah selanjutnya). Pekerjaan tanpa cost of delay yang jelas diletakkan diurutan pekerjaan paling bawah karena tidak masalah bila pekerjaan tersebut mau diselesaikan kapanpun juga.
2. Slice work into smaller cost of delay
Lalu bagaimana kalau cost of delay terlalu besar? Big-batch delivery is very risky, especially in 21st century. Pekerjaan yang membutuhkan waktu 2 bulan untuk diselesaikan berisiko tinggi dan kemungkinan besar harus di-slice menjadi beberapa fungsionalitas yang lebih kecil. Slice pekerjaan sehingga ada fungsionalitas kecil-kecil yang dapat dihantarkan dalam waktu secepat mungkin — idealnya setiap fungsionalitas yang di-slice tidak lebih dari 1 bulan pengerjaannya. Bila fungsionalitas yang sudah di-slice menjadi lebih kecil bisa dihantarkan dalam 1–2 minggu maka akan lebih baik lagi. Disini kita juga bisa melakukan descoping (mengurangi scope) sebagai teknik untuk slicing pekerjaan.
Setelah fungsionalitas besar di-slice menjadi beberapa fungsionalitas yang lebih kecil, ukur lagi cost of delay dari masing-masing fungsionalitas dan urutkan lagi berdasarkan cost of delay. Rinse, repeat.
3. Create options
One option is a trap.
Two options is a dilemma.
Three options provide a real choice.
Satu requirement yang dikunci tidak menyediakan pilihan bila requirement tersebut tidak berhasil diselesaikan pada tanggal yang diharapkan. Setelah pekerjaan di-slice dan cost of delay diukur, buat beberapa options untuk fungsionalitas kecil tersebut. Disini pimpinan perusahaan harus berkolaborasi dengan software developer untuk menghasilkan options.
Developer akan mengerjakan sebanyak mungkin dengan penuh tanggung-jawab (tanpa lembur) hingga tanggal yang ditentukan. Apa ada kemungkinan beberapa fungsionalitas kecil-kecil tidak terhantarkan? Ya ada kemungkinan, tetapi seharusnya fungsionalitas dengan cost of delay kecil yang berada di urutan bawah.
4. Deliver continuously, optimize flow-efficiency
Mulai deliver fungsionalitas kecil-kecil tersebut secara kontinu. Optimasi flow-efficiency dalam proses. Empower software deliver untuk menghantarkan software yang berkualitas. Secara proaktif hilangkan setiap hambatan yang ada dalam proses delivery agar flow-effienciency optimal. Fokus pada flow bukan deadline.
Bila proses ini konsisten untuk dilakukan secara kolaboratif dan dengan open-mind, deadline di perusahaan akan semakin tidak relevan lagi. Kelihatannya 4 langkah di atas cukup common sense kan? Tetapi realitanya tidak banyak perusahaan di Indonesia yang dapat melakukannya dengan baik karena pimpinan perusahaan tidak dapat menahan diri untuk tidak kembali ke metodologi Deadline Driven Development. Kalau tidak ada niat baik dari pimpinan perusahaan, ya Deadline Driven Development tetap menjadi silverbullet di dalam perusahaan-perusahaan di Indonesia.
Jangan lupa untuk menekan tombol 👏🏻 di bawah sebanyak mungkin agar lebih banyak lagi pimpinan perusahaan di Indonesia yang dapat melihat artikel ini dan merubah model kerja dalam software development. Terima kasih atas dukungannya untuk memodernisasikan cara berpikir orang-orang dalam industri software development di Indonesia. Semoga industri software development di Indonesia bisa menjadi sedikit lebih baik ke depannya.
