Cara Meningkatkan Peluang Sukses

Proyek pengembangan perangkat lunak terkenal memiliki tingkat kegagalan yang tinggi. Dalam konteks makalah ini, “kegagalan” didefinisikan sebagai, “tidak memenuhi harapan dan/atau persyaratan yang dinyatakan sponsor proyek”. Ini akan mencakup hal-hal seperti kegagalan berfungsi dengan cara yang dimaksudkan seperti yang didefinisikan dalam dokumen persyaratan, tidak memperoleh standar kinerja yang diperlukan, melampaui anggaran sehingga proyek dibatalkan, atau menimbulkan begitu banyak bug sehingga pengguna akhir melihat sistem Jasa Pembuatan Perusahaan sebagai tidak dapat digunakan.

Saya mulai memprogram aplikasi bisnis dua puluh sembilan tahun yang lalu. Saat itu saya bekerja sebagai insinyur pendukung sistem, pengembang, arsitek solusi, direktur pengembangan, konsultan, pelatih, dan CEO sebuah perusahaan perangkat lunak. Apa yang saya pelajari dari pengalaman bertahun-tahun ini adalah bahwa proyek gagal berulang kali karena daftar alasan yang sangat singkat. Makalah ini akan mengidentifikasi poin-poin kunci kegagalan tersebut dan menawarkan panduan sederhana tentang cara menghindarinya – saya katakan sederhana karena untuk mencakup semua cara memecahkan masalah pengembangan perangkat lunak secara memadai membutuhkan banyak buku.

1 – Persyaratan

Banyak, jika bukan sebagian besar, perusahaan memiliki sejarah alami dalam migrasi penyimpanan data, alur kerja, dan proses pelaporan mereka. Jalur transformasi yang khas adalah beralih dari kertas, ke spreadsheet, ke database, ke aplikasi bisnis yang canggih. Selama transformasi ini, yang sering terjadi selama bertahun-tahun, terminologi dan proses alur kerja yang digunakan ketika bisnis dioperasikan di atas kertas sering terbawa ke spreadsheet. Jargon dan proses bisnis ditetapkan seputar bagaimana bisnis perlu beroperasi di bawah sistem berbasis kertas dan berlanjut setelah perusahaan bermigrasi ke sistem berbasis spreadsheet. Ini berulang lagi ketika mengadopsi sistem berbasis database, dan seterusnya.

Masalah dengan ini adalah bahwa setelah perusahaan akhirnya matang untuk menggunakan aplikasi bisnis yang sepenuhnya mampu untuk merampingkan proses alur kerja, memperluas kemampuan bisnis untuk menganalisis dan melaporkan data bisnis, kemampuan penuh sistem itu jarang direalisasikan. Ini bukan karena ketidakmampuan teknologi atau pemrogram yang membuatnya, biasanya karena bisnis tidak dianalisis dengan benar saat menyiapkan persyaratan.

Terlalu sering, sponsor internal proyek, pengguna akhir, analis bisnis, dan pakar domain lainnya, sering kali berada dalam batasan waktu yang terlalu lama untuk memenuhi pencapaian yang ditetapkan oleh Manajer Proyek atau Manajer Bisnis. Demikian; proyek kehilangan peluang emas yang sesungguhnya untuk mewujudkan ROI yang jauh lebih tinggi pada sistem, peningkatan produktivitas yang lebih besar, masa pakai sistem yang lebih lama, dan kesesuaian yang lebih baik untuk cara bisnis saat ini beroperasi.

Inilah cara Anda menyelesaikan masalah:

Menyarankan/mencerahkan PM : Biarkan PM dan pemangku kepentingan proyek mengetahui konsekuensi dari tidak mengevaluasi proses alur kerja dan terminologi domain secara memadai.

Dokumentasikan biaya yang diperlukan untuk menulis ulang sistem : Penulisan ulang hanya dalam beberapa tahun, atau lebih buruk, tidak pernah meluncurkan sistem sama sekali, dibandingkan dengan waktu ekstra untuk melakukan analisis yang tepat perlu ditinjau selama perencanaan awal proyek. Libatkan analis bisnis dan/atau arsitek untuk membantu proses ini sedini mungkin.

Pertanyaan terminologi konvensional . Buat kamus “Bahasa Ubiquitous” domain. Tantang setiap istilah dan artinya kepada setiap pemangku kepentingan, sponsor, atau pengguna akhir. Dengan kata lain, pengumpulan persyaratan lebih dari sekadar mengumpulkan kata benda dan kata kerja.

Bekerja dengan Pakar Domain : Pakar domain – versus pengguna akhir sehari-hari – dapat menganalisis proses bisnis yang perlu ditingkatkan dan bagaimana sistem dapat mengakomodasi hal itu. Jangan hanya berasumsi bahwa kumpulan data menceritakan keseluruhan cerita tentang bagaimana data itu digunakan. Analis bisnis, atau pakar domain, harus memiliki pemahaman yang kuat tentang bisnis Anda, bukan teknologi yang akan digunakan untuk melayaninya. Sekali lagi, ini harus dilakukan bekerja sama dengan arsitek.

Buat cerita pengguna yang mudah dipahami : Cerita pengguna yang baik singkat, tepat, dan terbatas pada tindakan tunggal. Mereka harus dengan jelas menyatakan siapa, apa, dan mengapa untuk setiap tindakan yang perlu dilakukan oleh pengguna akhir atau sistem. Jangan membuat dokumen persyaratan rumit yang mengaburkan maksud persyaratan – itu adalah pepatah lama, “tidak dapat melihat hutan melalui pepohonan”.
2 – Penerjemahan Persyaratan ke Spesifikasi Teknis

“Hattrick” terbesar dalam mengembangkan perangkat lunak adalah mengambil konsep bisnis, yang seringkali bersifat abstrak, dan kemudian mengubahnya menjadi spesifikasi teknis yang sangat literal dan konkret. Sering kali konteks proses bisnis tidak dipahami oleh pemrogram atau, tidak secara akurat diterjemahkan ke dalam spesifikasi teknis dan akhirnya ke dalam kode sistem.

Masalah dengan ini adalah bahwa Anda memiliki pebisnis yang memproduksi persyaratan dan orang teknis yang membuat terjemahan itu. Kecuali orang teknis memiliki pemahaman yang benar tentang bisnis Anda dan, konsep bisnisnya, maka terjemahannya akan sering salah. Tidak seperti menerjemahkan dua bahasa dengan Google translate, di mana seseorang dapat menebak arti kata-kata yang tidak diterjemahkan dengan benar dalam konteks percakapan tertentu, aplikasi komputer tidak bisa. Konsep, proses, tindakan semuanya harus sangat spesifik agar komputer dapat memprosesnya.

Banyak perusahaan pengembang menugaskan tugas membuat terjemahan ini kepada pemrogram. Ini secara inheren cacat karena programmer berurusan dengan detail pengkodean terbaik daripada tingkat yang lebih tinggi, abstraksi yang ditemukan dalam bisnis. Menjembatani kesenjangan dalam konsep dan tingkat detail ini hampir tidak mungkin dilakukan dengan baik dan, sering kali waktu menghasilkan bencana kegagalan dalam proyek.

Ini dibuktikan dengan mengamati kode dan membandingkannya dengan cerita pengguna. Seringkali kode menggabungkan beberapa cerita pengguna yang tidak terkait ke dalam file yang sama, membuat semuanya mustahil untuk dipahami, dimodifikasi, diperluas, diverifikasi, atau dipelihara.

Pengamatan lain adalah bahwa kode akan kehilangan konsep lengkap yang berasal dari pakar domain dan akan diakomodasi oleh sedikit kode panjang yang bekerja di sekitar konsep daripada mengartikulasikannya. Contohnya adalah di mana ada istilah umum bisnis yang digunakan dengan baik, yang berhubungan dengan data spesifik atau proses spesifik yang merupakan hal dunia nyata dalam domain bisnis tertentu. Saat meninjau kode, biasanya tidak ada istilah yang digunakan, tetapi sebaliknya, diganti dengan jargon teknis, singkatan arbitrer, atau lebih buruk lagi, huruf tunggal. Hal ini membuat sulit untuk mengetahui apakah kode tersebut benar-benar cocok dengan persyaratan. Bahkan jika fungsionalitas pengguna akhir tampaknya ada dan berfungsi, itu tidak berarti kode dibuat dengan benar. Apa yang dapat menyebabkan – dan hampir selalu terjadi – adalah bahwa ada kemungkinan besar bahwa sementara iterasi pertama dari sistem mungkin tampak berfungsi dengan baik, ketika bisnis ingin memperluas kemampuan fitur atau, menambahkan fitur baru, fondasi kode tidak akan mendukungnya. Saya tidak dapat menghitung berapa kali saya atau teknolog lain harus menasihati klien, “Diperlukan penulisan ulang”.

Sebagian besar perusahaan berusaha memecahkan masalah ini dengan memasukkan analis bisnis dan/atau arsitek solusi ke dalam tim.

Tanggung jawab analis bisnis adalah menjadi pakar domain dan mengetahui cara mendokumentasikan persyaratan sistem dengan benar dengan cara yang dapat dipahami oleh orang teknis.

Peran arsitek adalah untuk mengambil persyaratan dan model sistem dengan cara yang menggambarkan pemahaman yang jelas tentang persyaratan untuk pemangku kepentingan proyek dan kerangka teknis yang jelas untuk bekerja di dalam untuk programmer – dengan demikian, “hattrick”.

Masalah dengan ini adalah bahwa sebagian besar perusahaan menganggap Arsitek Solusi sebagai orang yang telah menjadi programmer senior atau pemimpin tim teknis yang, karena umur panjang (pengalaman) perlu dipromosikan menjadi arsitek sebagai langkah logis berikutnya. Namun, ini hanya berarti bahwa kita kembali ke awal masalah dengan seorang programmer, meskipun sangat berpengalaman, membuat terjemahan. Kecuali jika analis bisnis melakukan pekerjaan yang luar biasa dalam mengartikulasikan persyaratan dengan cara yang mudah dipahami oleh programmer, kemungkinan masih ada kesenjangan dalam konsep dan pemahaman.

Jarang teknolog senior memiliki pemahaman yang mendalam tentang konsep bisnis, dan sama halnya, analis bisnis memiliki pemahaman yang mendalam tentang pemrograman. Apa yang lebih bermasalah adalah bahwa programmer hampir tidak pernah berpengalaman dalam domain yang cukup untuk menawarkan wawasan atau saran tentang bagaimana meningkatkan proses bisnis saat ini atau cara data bisnis diatur. Mereka hanya mengandalkan detail persyaratan dan biasanya tidak “berpikir di luar kebiasaan”. Ini sangat umum terjadi pada perusahaan pengembangan lepas pantai.