Industri perisian telah mengalami transformasi dramatik sepanjang dekad yang lalu, dan tidak semestinya ke arah yang lebih baik. Apa yang dahulunya merupakan kraf kolaboratif di mana pembangun secara aktif membentuk produk kini telah menjadi barisan pemasangan untuk menyelesaikan tiket. Perubahan ini mewakili lebih daripada sekadar perubahan dalam aliran kerja—ia secara asasnya mengubah cara perisian dibina dan siapa yang boleh membuat keputusan mengenainya.
Kematian Autonomi Pembangun
Pembangunan perisian moden telah berkembang menjadi hierarki yang tegar di mana jurutera semakin terputus daripada keputusan produk. Perbincangan komuniti mendedahkan corak yang menyerlah: pembangun yang dahulunya mengambil bahagian dalam proses reka bentuk, mempersoalkan keperluan, dan mengambil pemilikan keseluruhan ciri kini mendapati diri mereka terpinggir kepada melaksanakan tugas yang telah ditetapkan tanpa konteks atau input.
Transformasi ini tidak berlaku semalaman. Apabila syarikat berkembang lebih besar dan berusaha untuk mengurangkan risiko proses pembangunan mereka, mereka memperkenalkan lapisan pengurus produk, pereka bentuk, dan penganalisis perniagaan antara pembangun dan masalah perniagaan sebenar. Hasilnya adalah sistem di mana jurutera dijangka melaksanakan daripada berfikir, membawa kepada apa yang digambarkan oleh ramai sebagai persekitaran seperti kilang yang memfokuskan pada daya pengeluaran berbanding inovasi.
Pengurus Produk: Peranan yang menggabungkan fungsi penganalisis perniagaan tradisional dengan tanggungjawab pemilikan produk, selalunya tanpa pengetahuan teknikal yang mendalam.
Garis Masa Perubahan Peranan Pembangunan Perisian:
- Sebelum 2013: Pembangun terlibat dalam proses reka bentuk, ketua kejuruteraan mengendalikan perancangan projek
- 2013+: Pengenalan pereka bentuk sepenuh masa dan pengurus produk khusus
- Masa Kini: Hierarki tegar dengan pembangun sebagai pelaksana dan bukannya pembuat keputusan
Kebangkitan Pembuat Keputusan Bukan Teknikal
Mungkin perubahan yang paling ketara adalah peralihan kuasa membuat keputusan teknikal daripada jurutera. Di mana ketua kejuruteraan dahulunya merancang keseluruhan projek dan bekerjasama secara langsung dengan pihak berkepentingan, pengurus produk khusus kini memiliki ciri dan menentukan pendekatan pelaksanaan kepada pembangun yang sebenarnya memahami kekangan teknikal.
Pemisahan ini telah mewujudkan geseran dan ketidakcekapan. Jurutera melaporkan terpaksa berunding dengan pemilik produk mengenai penambahbaikan teknikal asas, sambil diberitahu untuk merangka usaha pemfaktoran semula dalam istilah perniagaan untuk mendapat kelulusan. Ironinya jelas: syarikat mengupah pembangun pintar tetapi kemudian memberi ganjaran kepada mereka yang hanya mengikut arahan tanpa mempersoalkan gambaran yang lebih besar.
Komuniti menunjukkan masalah asas dengan pendekatan ini. Apabila orang yang bergelut dengan operasi komputer asas diberi kuasa ke atas proses pembangunan perisian, hasilnya boleh dijangka bermasalah. Hutang teknikal terkumpul, keputusan seni bina tidak dipersoalkan, dan kualiti keseluruhan perisian terjejas.
Evolusi Peranan dalam Pasukan Perisian:
- Tradisional: Pakar bidang + Penganalisis perniagaan + Reka bentuk dipimpin pembangun
- Moden: Pengurus Produk (menggabungkan pelbagai peranan) + Pereka UX/UI + Pembangun (pelaksanaan sahaja)
- Impak: 10 kali ganda lebih ramai orang dan bajet untuk 75% peluang hasil yang sederhana
 |
|---|
| "Tiket bergerak Kerja tidak" Ini menyampaikan keterputusan antara penyiapan tiket dan pembangunan yang bermakna |
Hakisan Kemahiran Tukang
Apa yang hilang dalam peralihan ini melampaui kecekapan—ia adalah sifat asas pembangunan perisian sebagai disiplin penyelesaian masalah yang kreatif. Pembangun menggambarkan perasaan terputus daripada kerja mereka, menganggap kod sebagai sesuatu yang kepunyaan orang lain daripada berbangga dengan kemahiran mereka.
Saya semakin kurang menyukai kerjaya saya sepanjang 10 tahun yang lalu kerana saya telah melihat setiap syarikat pergi ke arah ini.
Simptomnya jelas: permintaan tarik diluluskan tanpa perbincangan bermakna, tugas hutang teknikal kekal tidak disentuh sehingga kecemasan timbul, dan setiap penambahbaikan memerlukan tiket berasingan, anggaran, dan kelulusan. Jurutera dilatih untuk kekal dalam lorong mereka, tidak digalakkan daripada bertanya mengapa ciri penting atau mencadangkan penambahbaikan di luar skop sempit mereka.
Persekitaran ini terutamanya mempengaruhi pembangun yang lebih baru, yang dilatih dari awal untuk memfokuskan pada tiket yang ditulis dengan baik daripada memahami keseluruhan sistem atau mengambil berat tentang matlamat projek yang lebih luas. Hasilnya adalah generasi pengaturcara yang kemahiran utama mereka adalah menavigasi alat pengurusan projek daripada menyelesaikan masalah teknikal yang kompleks.
Tanda-tanda Pembangunan Berasaskan Tiket:
- Tiada pemahaman tentang tujuan ciri selain daripada tarikh akhir penghantaran
- Permintaan tarik diluluskan tanpa perbincangan
- Hutang teknikal diabaikan sehingga berlaku kecemasan
- Semua penambahbaikan memerlukan tiket dan kelulusan berasingan
- Jurutera menganggap kod sebagai milik orang lain
Janji Palsu Halaju
Pendekatan yang didorong tiket menjanjikan produktiviti yang boleh diukur melalui metrik halaju dan mata cerita. Pasukan boleh membakar 30 mata setiap minggu dan berasa produktif, tetapi pergerakan ini sering menyamarkan kekurangan kemajuan sebenar. Pembaikan pantas menjadi periuk api teknikal, keputusan reka bentuk tidak pernah dinilai semula, dan pangkalan kod menjadi penggalian arkeologi penyelesaian jangka pendek.
Isu asasnya adalah halaju mengukur aktiviti, bukan keberkesanan. Syarikat akhirnya membelanjakan lebih banyak wang untuk mengupah berbilang pakar untuk peranan yang sebelum ini dikendalikan oleh ahli pasukan yang lebih sedikit dan lebih serba boleh. Pengurangan risiko yang dikatakan datang dengan kos inovasi, kecekapan, dan kepuasan kerja.
Mencari Jalan Ke Hadapan
Walaupun isu sistemik ini, sesetengah pembangun dan pasukan sedang mencari cara untuk mengekalkan kualiti dan tujuan dalam persekitaran yang terkekang. Kuncinya nampaknya adalah merebut semula kebebasan kecil: meningkatkan kualiti kod semasa kerja biasa, bertanya soalan walaupun jawapan diketahui, dan menganggap tiket sebagai sempadan daripada penutup mata.
Untuk pembangun individu, penyelesaiannya mungkin melibatkan mencari syarikat yang lebih kecil atau niche khusus di mana kecemerlangan teknikal dan pemahaman mendalam masih dihargai berbanding pematuhan proses. Komuniti mencadangkan bahawa syarikat permulaan dan syarikat yang memfokuskan pada aplikasi kritikal prestasi menawarkan persekitaran yang lebih baik untuk pembangun yang ingin berfikir melampaui tiket seterusnya.
Industri yang lebih luas mungkin perlu mengiktiraf bahawa trajektori semasa—walaupun kelihatan mengurangkan risiko—sebenarnya meningkatkan kos dan mengurangkan inovasi. Perisian yang paling berjaya secara historis datang daripada pasukan di mana pembangun memahami konteks teknikal dan perniagaan kerja mereka, bukan daripada barisan pemasangan peranan khusus yang bekerja dalam pengasingan.
Rujukan: Ticket-Driven Development: The Fastest Way to Go Nowhere