Memasang utang teknis di perusahaan perangkat lunak kecil India yang mengembangkan aplikasi & situs web: Siapa yang bertanggung jawab untuk itu?

Saya telah berada di industri layanan perangkat lunak India selama 10 tahun sekarang dan selama itu, saya telah melihat proyek yang bagus diselesaikan dan menghasilkan keajaiban. Saya telah melihat tim kerangka bekerja tanpa lelah dalam kondisi yang menyiksa untuk membangun produk yang telah dicintai oleh orang-orang di belahan bumi lain. Dan sementara ada kenangan indah dalam dekade ini mengerjakan beberapa proyek luar biasa, saya juga menyaksikan proyek menurun dan produk perangkat lunak menjadi rusak karena berbagai alasan. Itu telah terjadi lebih dari yang saya harapkan di sekitar saya dan di sekitar orang-orang yang saya kenal selama 10 tahun ini.

Banyak yang telah dibicarakan tentang proyek yang salah. Meme-meme mengerumuni internet tentang bagaimana seluruh hierarki saling mengejar seperti rantai makanan di hutan. Beberapa orang menyalahkan programmer karena menulis kode buggy, sementara yang lain mengutuk manajemen karena membuat janji tidak praktis yang tidak mungkin dipenuhi. Beberapa orang bahkan menyalahkan klien karena tidak memahami prasyarat teknis dan ketergantungan industri ini. Tapi saya hampir tidak pernah mendengar ada yang berbicara tentang Hutang Teknis, atau Hutang Kode, dan menangani masalah ini dengan cara yang beradab tanpa menunjuk satu sama lain. Tidak sekali pun saya menemukan istilah Tech Debt ini dari orang-orang di sekitar saya, atau dari acara-acara yang saya hadiri, atau dari blog-blog lokal yang saya baca.

Saya hanya menemukan istilah ini ketika saya membaca blog dan jurnal dari Lembah Silikon di Amerika Serikat. Ini berarti bahwa sebagian besar programmer dan eksekutif perangkat lunak yang bekerja di perusahaan pengembangan perangkat lunak kecil & menengah di India bahkan belum pernah mendengar istilah ini sebelumnya sampai sekarang. Jadi, izinkan saya mulai dengan menjelaskan istilah itu sendiri. Hutang Teknis, atau Hutang Kode adalah sebuah konsep dalam pengembangan perangkat lunak yang mencerminkan biaya tersirat dari pengerjaan ulang tambahan yang disebabkan oleh memilih solusi yang mudah (terbatas) sekarang daripada menggunakan pendekatan yang lebih baik yang akan memakan waktu lebih lama.

Biarkan saya memecahnya untuk membuatnya lebih sederhana. Ini adalah konsep untuk menghitung biaya penyelesaian masalah pemrograman dan desain yang mungkin meningkat karena memilih opsi yang mudah untuk membangun modul tertentu, atau keseluruhan sistem, daripada memilih metode terbaik dan paling efisien untuk membangunnya. Di bidang pengembangan perangkat lunak, fenomena kemalasan dan keterlambatan Anda yang kembali menggigit Anda terjadi jauh lebih sering daripada di tempat lain. Ini hampir seperti Karma mendapat representasi sosial menjadi judes oleh programmer.

Tolong, jangan salah paham, saya tidak menyalahkan semua hutang kode pada programmer. Pasti ada banyak entitas yang bertanggung jawab atas hutang kode yang pasti muncul di lebih dari 90% proyek di perusahaan pengembangan perangkat lunak berukuran kecil di India. Biarkan saya mencoba dan membahas beberapa di antaranya secara singkat:

1. KLIEN TIDAK SABAR & LEBIH CERDAS

Ya, saya akan mulai dengan menggigit tangan yang memberi makan dan melakukannya dengan kejam. Pasar untuk proyek pengembangan perangkat lunak outsourcing berukuran kecil sangat besar dan sangat terfragmentasi. Ada perusahaan yang benar-benar baik yang dengan sempurna membenarkan pasar global ini, sementara yang lain hanyalah perusahaan parasit yang memberi makan pengaturan yang sangat baik ini hanya karena tidak diatur dan tidak terkendali.

Hal ini menyebabkan klien melakukan kesalahan dalam memilih perusahaan yang tepat untuk bermitra berdasarkan kebutuhan mereka. Meskipun tidak memiliki keterampilan pemeriksaan yang tepat bukanlah kesalahan mereka, tetapi tidak ada yang harus disalahkan karena mereka tidak memiliki kecerdasan jalanan dasar dalam mengidentifikasi perusahaan sampah dari yang asli. Sekarang, begitu mereka setuju untuk melanjutkan dengan tim yang kurang berbakat, mereka mencekik harapan dan garis waktu yang tidak realistis pada mereka. Tidak hanya itu, beberapa dari mereka bahkan berlebihan dan menunjukkan betapa pintarnya mereka dengan membawa saran mereka sendiri dalam desain dan pemrograman. (#tidaksemuaklien )

Jika Anda pernah menjadi klien perusahaan pengembangan perangkat lunak, saya dengan rendah hati meminta Anda untuk membiarkan mereka dan mengizinkan mereka melakukan pekerjaan mereka. Cobalah pergi ke dokter atau pengacara dan beri tahu mereka apa yang Anda googling dan apa yang dikatakan tentang masalah Anda dan lihat reaksi di wajah mereka. Tidak ada ahli di bidangnya yang suka dinasihati tentang bidangnya sendiri oleh seorang noob. Insinyur perangkat lunak tidak terkecuali.

Jika Anda menemukan tim pengembangan perangkat lunak yang baik dan mereka tampak menjanjikan, beri mereka ruang dan mereka tidak akan merasakan dorongan untuk mengambil jalan pintas yang akan menghasilkan lebih sedikit hutang kode dalam proyek Anda. Dan coba tebak, sebagian besar waktu, itu kalian, klien yang membayar hutang kode itu. Pernah mendengar kata-kata: "Permintaan Ubah"? Saya yakin sebagian besar dari Anda pernah! Dalam skenario yang ideal, Anda seharusnya tidak pernah mendengar kata-kata itu dalam hidup Anda. Tapi itu jarang terjadi. Dan sering kali Anda mendengar kata-kata itu, semakin Anda gagal menjadi klien perusahaan perangkat lunak.

2. MANAJER LAZY & DEVIOUS

Ketika saya mengatakan manajer di sini, itu adalah siapa pun di posisi manajemen proyek dari sisi perusahaan pengembangan perangkat lunak. Baik itu manajer proyek, atau pemimpin tim, atau kepala pengiriman, atau pemilik perusahaan, jika Anda pernah mencoba mencuci tangan proyek dengan cepat hanya untuk menyelesaikannya dan menagih pembayaran, Anda adalah pihak untuk disalahkan juga dalam Utang Teknologi yang berjumlah besar ini dalam proyek Anda.

Meskipun bagian yang paling menyedihkan di sini adalah bahwa kalian tidak pernah membayar hutang teknologi yang berjumlah besar. Entah itu klien yang membayarnya dengan menggunakan produk di bawah standar, atau dengan benar-benar membayar lebih banyak uang untuk membersihkannya. Dan jika itu bukan klien, itu adalah pemrogram miskin yang membayarnya dengan harus bekerja berjam-jam jauh melampaui apa yang harus mereka lakukan. Tapi hampir tidak pernah orang-orang tengah ini, maka menurut saya, mereka harus menjadi entitas yang paling bertanggung jawab dalam topik utang teknologi ini.

Jika Anda pernah mempekerjakan salah satu dari mereka, kualitas terbesar yang harus mereka miliki adalah moralitas. Jika kompas moral mereka menunjuk ke arah yang benar, mereka akan bertanggung jawab dan mengambil keputusan yang tepat yang mendukung proyek, yang pada akhirnya akan mengarah pada lebih sedikit kompilasi utang teknologi. Ini mengingatkan saya pada kutipan terkenal dari Jack Ma di mana dia berbicara tentang memilih bekerja untuk pemimpin yang tepat. Sangat tepat dalam skenario ini di sini.

3. PROGRAMMER

Oh ya, saya tidak akan mengakhiri topik ini dengan menyalahkan kalian juga! Tapi hei, #notallprogrammers kan? Ya, tapi hampir 94% dari programmer. Setidaknya itulah yang dipikirkan CP Gurani, CEO Tech Mahindra, ketika dia membuat pernyataan mengejutkan beberapa tahun yang lalu bahwa 94% lulusan TI tidak layak untuk pekerjaan itu. Saya tidak tahu persis bagaimana dia sampai pada angka itu, tetapi sebagai produk dari perguruan tinggi teknik India dan telah menyaksikan seluruh ekosistem teknik TI selama 10 tahun terakhir, saya dapat mengatakan bahwa saya cenderung setuju dengan pernyataan Pak Gurani.

Saya tidak mencoba memperdebatkan apakah itu 94%, atau 90%, atau 80%. Tapi untuk memberikan analogi, hampir semua dari kita tahu bahwa kita membutuhkan tepung, air dan sedikit garam untuk membuat adonan, dan penggilas adonan untuk membuat chapati. Tetapi sangat sedikit dari kita yang benar-benar dapat membuat chapati yang dapat dimakan. Ini adalah proses sederhana yang mati, tetapi masih membutuhkan sedikit bakat dan banyak latihan untuk unggul dalam hal itu. Sama halnya dengan pemrograman. Kita semua tahu resepnya, tetapi sangat sedikit yang benar-benar menyingsingkan lengan baju kita dan mengotori tangan kita dan mempraktekkannya selama diperlukan untuk menguasai keahlian itu.

Oleh karena itu, bahkan ketika seorang programmer rata-rata ditugaskan pada sebuah proyek, dia tanpa sadar menulis kode dengan hutang teknologi yang tertanam di dalamnya yang tidak akan dia sadari sampai nanti. Dan jika Anda bertanya-tanya bagaimana industri berfungsi secara positif secara keseluruhan dengan sebagian besar programmer tidak cocok untuk pekerjaan itu, itu karena manajer mereka yang efisien dan senior berpengalaman mereka yang telah belajar banyak hal dengan cara yang sulit. Mereka membantu tangan dan pikiran segar itu dalam menavigasi jalur berbahaya penulisan kode yang optimal dan membuat pengiriman proyek layak dan tetap bebas dari hutang yang membebani. Dan akhirnya dengan perawatan yang tepat dan pelatihan para pemula tersebut untuk menjadi baik dalam pekerjaan mereka, atau mereka berakhir dengan penawaran perpisahan dengan industri TI.

Jadi, kesimpulannya saya merasa semua 3 pihak besar dalam kolaborasi ini harus berbagi kesalahan untuk menyusun hutang kode. Sekali lagi, jangan menganggap bagian ini sebagai bagian yang diturunkan untuk segala sesuatu yang salah dengan industri ini. Ini sama seperti industri lain di dunia dengan kengerian dan pahlawan yang adil. Bahkan setelah 10 tahun melakukan ini, saya masih tidak akan melakukan hal lain dalam hidup saya. Saya menyukai pekerjaan ini, saya senang menjadi perusahaan kecil yang mengerjakan proyek-proyek menarik dari klien di seluruh dunia.

Tujuannya adalah untuk membuat semua 3 pemangku kepentingan lebih akuntabel dan memperkenalkan mereka dengan kerugian lunak yang mendasari yang menimpa mereka melalui salah-kolaborasi. Jika tim pengembangan perangkat lunak ingin menghitung dan mengukur utang teknologi mereka secara akurat, mereka dapat mengikuti model proses yang ketat berdasarkan metodologi Agile, atau bahkan metodologi Waterfall. Ketika Anda mengikuti pendekatan disiplin itu, Anda akan dapat menandai sprint revisi & perbaikan tersebut secara terpisah dan pada akhir fase, Anda akan dapat menghitung dengan tepat berapa banyak dari mereka yang Anda butuhkan, dan dengan mudah turun ke alasan untuk itu.

Saya akan mengakhiri ini dengan kutipan penutup dari Samuel Beckett: