Industri perangkat lunak telah mengalami transformasi dramatis selama dekade terakhir, dan tidak selalu menuju ke arah yang lebih baik. Yang dulunya merupakan kerajinan kolaboratif di mana developer secara aktif membentuk produk, kini telah menjadi jalur perakitan penyelesaian tiket. Perubahan ini lebih dari sekadar perubahan alur kerja—ini secara fundamental mengubah cara perangkat lunak dibangun dan siapa yang berhak membuat keputusan tentangnya.
Kematian Otonomi Developer
Pengembangan perangkat lunak modern telah berkembang menjadi hierarki yang kaku di mana engineer semakin terputus dari keputusan produk. Diskusi komunitas mengungkapkan pola yang mencolok: developer yang dulunya berpartisipasi dalam proses desain, mempertanyakan persyaratan, dan mengambil kepemilikan atas seluruh fitur kini mendapati diri mereka terdegradasi menjadi pelaksana tugas-tugas yang telah ditentukan sebelumnya tanpa konteks atau masukan.
Transformasi ini tidak terjadi dalam semalam. Ketika perusahaan tumbuh lebih besar dan berusaha mengurangi risiko proses pengembangan mereka, mereka memperkenalkan lapisan-lapisan product manager, desainer, dan analis bisnis antara developer dan masalah bisnis yang sebenarnya. Hasilnya adalah sistem di mana engineer diharapkan untuk mengeksekusi daripada berpikir, yang mengarah pada apa yang banyak orang gambarkan sebagai lingkungan seperti pabrik yang berfokus pada throughput daripada inovasi.
Product Manager: Peran yang menggabungkan fungsi analis bisnis tradisional dengan tanggung jawab kepemilikan produk, seringkali tanpa pengetahuan teknis yang mendalam.
Lini Masa Perubahan Peran dalam Pengembangan Perangkat Lunak:
- Sebelum 2013: Developer terlibat dalam proses desain, pemimpin teknik menangani perencanaan proyek
- 2013+: Pengenalan desainer penuh waktu dan manajer produk khusus
- Saat ini: Hierarki yang kaku dengan developer sebagai pelaksana daripada pengambil keputusan
Kebangkitan Pembuat Keputusan Non-Teknis
Mungkin perubahan paling signifikan adalah perpindahan kekuatan pengambilan keputusan teknis dari engineer. Di mana pemimpin engineering dulunya merencanakan seluruh proyek dan berkolaborasi langsung dengan stakeholder, product manager khusus kini memiliki fitur dan mendikte pendekatan implementasi kepada developer yang benar-benar memahami kendala teknis.
Pemisahan ini telah menciptakan gesekan dan inefisiensi. Engineer melaporkan harus bernegosiasi dengan product owner tentang perbaikan teknis dasar, sambil diberitahu untuk membingkai upaya refactoring dalam istilah bisnis untuk mendapatkan persetujuan. Ironinya sangat terasa: perusahaan mempekerjakan developer pintar tetapi kemudian menghargai mereka yang hanya mengikuti instruksi tanpa mempertanyakan gambaran yang lebih besar.
Komunitas menunjuk pada masalah mendasar dengan pendekatan ini. Ketika orang yang kesulitan dengan operasi komputer dasar diberi otoritas atas proses pengembangan perangkat lunak, hasilnya dapat diprediksi bermasalah. Technical debt terakumulasi, keputusan arsitektur tidak dipertanyakan, dan kualitas perangkat lunak secara keseluruhan menderita.
Evolusi Peran dalam Tim Software:
- Tradisional: Ahli materi + Analis bisnis + Desain yang dipimpin developer
- Modern: Product Manager (menggabungkan berbagai peran) + UX/UI Designer + Developer (hanya implementasi)
- Dampak: 10x lebih banyak orang dan anggaran untuk peluang 75% hasil yang biasa-biasa saja
 |
|---|
| "Tiket bergerak, Pekerjaan tidak" Ini menyampaikan ketidaktersambungan antara penyelesaian tiket dan pengembangan yang bermakna |
Erosi Keahlian
Yang hilang dalam transisi ini melampaui efisiensi—ini adalah sifat fundamental pengembangan perangkat lunak sebagai disiplin pemecahan masalah yang kreatif. Developer menggambarkan merasa terputus dari pekerjaan mereka, memperlakukan kode sebagai sesuatu yang dimiliki orang lain daripada bangga dengan keahlian mereka.
Saya semakin tidak menyukai karier saya selama 10 tahun terakhir atau lebih karena saya telah melihat setiap perusahaan menuju arah ini.
Gejalanya jelas: pull request disetujui tanpa diskusi yang bermakna, tugas technical debt tetap tidak tersentuh sampai keadaan darurat muncul, dan setiap perbaikan memerlukan tiket terpisah, estimasi, dan persetujuan. Engineer dilatih untuk tetap di jalur mereka, tidak didorong untuk bertanya mengapa fitur penting atau menyarankan perbaikan di luar ruang lingkup sempit mereka.
Lingkungan ini terutama mempengaruhi developer yang lebih baru, yang dilatih dari awal untuk fokus pada tiket yang ditulis dengan baik daripada memahami seluruh sistem atau peduli tentang tujuan proyek yang lebih luas. Hasilnya adalah generasi programmer yang keterampilan utamanya adalah menavigasi alat manajemen proyek daripada memecahkan masalah teknis yang kompleks.
Tanda-tanda Ticket-Driven Development:
- Tidak memahami tujuan fitur selain tenggat waktu pengiriman
- Pull request disetujui tanpa diskusi
- Technical debt diabaikan sampai terjadi keadaan darurat
- Semua perbaikan memerlukan tiket dan persetujuan terpisah
- Engineer menganggap kode sebagai milik orang lain
Janji Palsu Velocity
Pendekatan yang didorong tiket menjanjikan produktivitas yang dapat diukur melalui metrik velocity dan story point. Tim dapat membakar 30 poin per minggu dan merasa produktif, tetapi gerakan ini sering menutupi kurangnya kemajuan nyata. Perbaikan cepat menjadi ranjau teknis, keputusan desain tidak pernah dievaluasi ulang, dan codebase menjadi penggalian arkeologi solusi jangka pendek.
Masalah mendasarnya adalah bahwa velocity mengukur aktivitas, bukan efektivitas. Perusahaan akhirnya menghabiskan lebih banyak uang untuk mempekerjakan beberapa spesialis untuk peran yang sebelumnya ditangani oleh anggota tim yang lebih sedikit dan lebih serbaguna. Pengurangan risiko yang seharusnya datang dengan mengorbankan inovasi, efisiensi, dan kepuasan kerja.
Menemukan Jalan ke Depan
Meskipun ada masalah sistemik ini, beberapa developer dan tim menemukan cara untuk mempertahankan kualitas dan tujuan dalam lingkungan yang terbatas. Kuncinya tampaknya adalah merebut kembali kebebasan kecil: meningkatkan kualitas kode selama pekerjaan reguler, mengajukan pertanyaan bahkan ketika jawaban sudah diketahui, dan memperlakukan tiket sebagai batas daripada penutup mata.
Untuk developer individu, solusinya mungkin melibatkan pencarian perusahaan yang lebih kecil atau niche khusus di mana keunggulan teknis dan pemahaman mendalam masih dihargai daripada kepatuhan proses. Komunitas menyarankan bahwa startup dan perusahaan yang berfokus pada aplikasi kritis kinerja menawarkan lingkungan yang lebih baik untuk developer yang ingin berpikir melampaui tiket berikutnya.
Industri yang lebih luas mungkin perlu mengakui bahwa lintasan saat ini—meskipun tampak mengurangi risiko—sebenarnya meningkatkan biaya dan mengurangi inovasi. Perangkat lunak yang paling sukses secara historis berasal dari tim di mana developer memahami konteks teknis dan bisnis dari pekerjaan mereka, bukan dari jalur perakitan peran khusus yang bekerja dalam isolasi.
Referensi: Ticket-Driven Development: The Fastest Way to Go Nowhere