Seberapa pentingkah mengetahui fungsi sebelum pengkodean?

Saya bekerja untuk sebuah perusahaan pengembangan perangkat lunak di mana pekerjaan pengembangan telah ditunda untuk kami. Tim di darat menangani dukungan dan berbicara langsung dengan klien. Kami tidak pernah berbicara dengan klien secara langsung. Kami hanya berbicara dengan orang-orang dari tim darat, yang berbicara langsung dengan klien.

Ketika persyaratan datang, tim di darat berbicara dengan klien dan membuat dokumen persyaratan dan memberi tahu kami. Kami membuat dokumen desain setelah mempelajari persyaratan (kami mengikuti model air terjun tradisional).

Tetapi ada satu masalah dalam keseluruhan proses: tidak ada seorang pun di tim lepas pantai atau di darat yang memahami fungsi aplikasi sepenuhnya. Kami hanya tahu ini adalah aplikasi web kompleks besar yang menangani pemrosesan pesanan kompleks, manajemen katalog, manajemen kampanye, dan aktivitas lainnya. Kami berjuang dengan dokumen desain karena persyaratannya tidak jelas. Kemudian masuk ke serangkaian pertanyaan / jawaban bolak-balik antara tim on shore, tim off shore dan klien. Kita sering diberitahu untuk memahami fungsionalitas dari kode. Tapi itu biasanya tidak layak karena basis kode sangat besar dan bahkan memahami item menu sederhana butuh berhari-hari jika tidak berminggu-minggu. Kami mencoba memberi tahu klien untuk memberi kami transfer pengetahuantentang aplikasi tetapi tidak berhasil. Manajer kami akan sering memberi tahu kami untuk memulai pengkodean bahkan jika dokumen desain tidak lengkap atau persyaratan tidak jelas. Kita akan mulai dengan mengkode bagian dari persyaratan yang tampak jelas dan menunggu sisanya.

Ini biasanya akan menunda penyebaran sebulan. Dalam kasus ekstrim kami akan memiliki kesalahan sangat rendah dalam pengembangan dan produksi tetapi klien akan mengatakan itu bukan yang mereka tanyakan. Itu akan memulai permainan menyalahkan dan serangkaian permintaan perubahan dan kami akhirnya akan mengembangkan sesuatu yang sangat berbeda.

Pertanyaan saya adalah bagaimana Anda melakukan pengembangan jika Anda tidak mengetahui fungsionalitas aplikasi sepenuhnya?

MEMPERBARUI

Metodologi pengembangan itu bukan pilihan saya dan saya bukan pemimpin tim saya. Begitulah awalnya. Saya mencoba memberi tahu orang-orang tentang keuntungan gesit tetapi tidak berhasil. Selain itu saya tidak berpikir tim saya memiliki pola pikir yang diperlukan untuk bekerja di lingkungan yang gesit.

Versi pendek:

Mengetahui apa yang harus dilakukan ≠ mengenal pelanggan Anda.

Bayangkan ini: Anda adalah perusahaan yang terkait dengan pengembangan real estat. Anda meminta pasangan Anda untuk membangun kompleks besar. Pasangan itu mengatakan bahwa terlepas dari semua dokumen yang Anda berikan kepadanya, ia juga perlu berbicara langsung dengan orang-orang yang akan membeli apartemen di kompleks ini. Serius?

Versi panjang:

Selalu menyenangkan mengetahui bagaimana aplikasi tertentu akan digunakan, karena menyenangkan untuk mempelajari berbagai hal, tetapi itu tidak selalu mungkin pada proyek besar.

Beberapa domain terlalu rumit. Jika Anda hanya seorang pengembang dan Anda sedang mengerjakan beberapa aplikasi dari banyak domain, Anda tidak selalu dapat memahami apa yang dilakukan pengguna akhir , karena itu akan mengharuskan Anda menghabiskan lima tahun untuk belajar akuntansi, sepuluh tahun di sekolah kedokteran, enam tahun di sekolah hukum, dll.

Di sisi lain, produk perangkat lunak yang dibuat tanpa memahami domain spesifik akan menjadi yang terbaik, yah, sedikit tidak dapat digunakan .

Itu sebabnya persyaratan fungsional dan non fungsional harus ditulis oleh orang yang sepenuhnya memahami domain. Secara umum, pengumpulan persyaratan melibatkan sekaligus:

1. Teknisi (misalnya pengembang yang akan mengatakan bahwa fitur tertentu tidak mungkin, bahwa yang lain ini bisa jauh lebih baik jika dilakukan dengan cara ini, dan yang ini akan menelan biaya ribuan dolar sementara ada alternatif yang jauh lebih murah),

2. Orang-orang yang berspesialisasi dalam manajemen proyek,

3. Orang-orang berspesialisasi dalam domain pelanggan , yang memiliki pemahaman penuh tentang domain ini dan kebutuhan tepat pelanggan. Tentu saja, ini mungkin pelanggan itu sendiri.

Satu persyaratan fungsional dan non fungsional ditulis dan cukup tepat, Anda tidak perlu hal lain sebagai orang yang pekerjaannya menerjemahkan persyaratan tersebut ke dalam kode.

Adapun kasus spesifik Anda, Anda menggambarkan sendiri penyebab masalahnya:

Kami berjuang dengan dokumen desain karena persyaratannya tidak jelas.

Bukan kurangnya pengetahuan tentang pelanggan yang menyebabkan semua masalah , tetapi kualitas rendah dari persyaratan. Dalam proyek yang dikelola dengan benar, persyaratan fungsional dan non fungsional harus benar-benar jelas dan tidak ambigu. Jika dokumen persyaratan tidak jelas atau jika itu memberi tahu Anda bahwa "desain visual produk harus menarik" atau kebodohan lain seperti itu, itu karena itu ditulis oleh orang-orang yang tidak tahu cara menulisnya.

Mengetahui hal itu, Anda harus bertindak secara berbeda:

• Jika Anda tahu bahwa tim yang mengumpulkan persyaratan putus asa, dan tim Anda sendiri memiliki orang-orang yang terampil untuk persyaratan berkumpul, jelaskan situasinya kepada atasan Anda dan beri tahu bahwa tim lain harus diganti oleh seseorang yang kompeten , misalnya orang-orang dari Anda.

• Kalau tidak (yaitu jika mereka tidak putus asa), cobalah untuk menentukan penyebab internal mereka dari persyaratan rendah dan meyakinkan mereka bahwa melakukan pekerjaan mereka dengan benar hanya akan mengurangi biaya keseluruhan proyek . Menampilkan statistik tentang seberapa buruk persyaratan tertulis memengaruhi proyek dengan meningkatkan biaya (berapa?) Dan risiko tidak siap untuk tenggat waktu adalah ide yang bagus di sini.

Mungkin dokumen persyaratan tidak lengkap. Saya melihat ini sepanjang waktu: manajer proyek yang tidak berpengalaman hanya yakin bahwa dokumen satu halaman sudah cukup, dan tidak mengerti mengapa mereka akan menulis tiga hingga empat ratus halaman, bukannya satu. Jika demikian halnya di perusahaan Anda, tunjukkan bahwa menghabiskan lebih banyak waktu pada persyaratan akan mengurangi biaya.

Anda menggunakan metodologi pengembangan yang salah untuk masalah yang Anda hadapi.

Dengan menggunakan Air Terjun, Anda berkomitmen untuk:

1. Mendapatkan persyaratan yang tepat di muka - ini jelas tidak berfungsi
2. Menyandikan persyaratan menjauh dari pelanggan - Anda tidak dapat secara efektif memeriksa masalah dengan pelanggan karena Anda telah berkomitmen untuk mengembangkan persyaratan
3. Peluang pertama bagi pelanggan untuk melihat fungsionalitas mereka adalah selama pengujian - ini sudah sangat terlambat mengingat masalah yang Anda alami

Pertimbangkan untuk menggunakan, jika memungkinkan, cara berbeda dalam mengelola proyek. Pengembangan Perangkat Lunak Agile memiliki beberapa fitur yang dirancang untuk mengatasi masalah yang Anda hadapi.

Sebuah perbandingan yang layak dari Waterfall vs Agile ditulis beberapa waktu lalu, mari kita ambil beberapa kutipan darinya yang menyoroti masalah Anda:

Kehilangan Tanda:

Setelah tahap selesai dalam metode Air Terjun, tidak ada jalan untuk kembali, karena sebagian besar perangkat lunak yang dirancang dan diimplementasikan dengan metode air terjun sulit untuk diubah sesuai dengan waktu dan kebutuhan pengguna. Masalahnya hanya dapat diperbaiki dengan kembali dan merancang sistem yang sama sekali baru, metode yang sangat mahal dan tidak efisien.

Terikat...

Metode lincah memungkinkan untuk perubahan spesifikasi sesuai kebutuhan pengguna akhir, mengeja kepuasan pelanggan. Seperti yang telah disebutkan, ini tidak mungkin ketika metode air terjun digunakan, karena setiap perubahan yang dilakukan berarti proyek harus dimulai dari awal lagi.

... dan Tidak Dapat Memindahkan

Untuk menyelaraskan perbedaan antara keduanya, orang dapat mengatakan metode air terjun klasik adalah kepastian, sementara metodologi Agile mengeja kemampuan beradaptasi. Metode gesit pandai mengurangi biaya overhead, seperti, alasan, pembenaran, dokumentasi dan rapat, menjaganya serendah mungkin. Dan, itulah sebabnya metode Agile menguntungkan tim kecil dengan persyaratan yang terus berubah, lebih dari proyek yang lebih besar.

Di mana Anda berada sekarang adalah buruk; Anda tidak memenuhi persyaratan pelanggan, dan, jika Anda berada di pihak yang salah dalam pengembangan perangkat lunak, produktivitas akan hilang, ketidakpercayaan akan meningkat, dan hal-hal yang cenderung semakin buruk, tidak lebih baik.

Hubungan dengan pelanggan sangat penting ; di sini, sepertinya Anda tidak dapat secara efektif mengumpulkan masalah mereka dan beradaptasi dengan persyaratan mereka yang berubah dalam cara Anda saat ini bekerja; karena itu Anda perlu melihat cara mengubah itu.

Itu bukan cara kerjanya. Salah satu mata pelajaran pendidikan saya saat ini adalah analisis, dan hubungan dengan pelanggan. Penekanannya adalah pada definisi proyek yang jelas. Bayangkan ini:

• Anda memesan perusahaan bangunan untuk membangun rumah tetapi Anda tidak tahu bagaimana Anda ingin terlihat. Anda cukup menyesuaikan lantai pertama, sehingga tim membangun rumah hingga lantai pertama. Maka Anda ingin lantai dasar diletakkan berbeda. Ups ...

Kecuali Anda sangat yakin Anda dapat (sebagian) membuat fondasi yang benar untuk aplikasi tersebut, saya hanya akan memberi tahu klien bahwa tidak ada cara lain yang akan dilakukan selain dengan tujuan dan fungsi yang jelas. Karena jika Anda hanya menikam apa yang mungkin terjadi, Anda akan berisiko membuang banyak uang dan menghabiskan waktu.

Inilah beberapa hal yang akan membantu mengatasi masalah:

1. Tingkatkan komunikasi antara kedua tim. Minta tim lain untuk mengompres persyaratan menjadi 3 kata, dan kemudian programmer akan mengimplementasikan kata-kata itu dengan tepat. Kata-kata itu hanya perlu benar. Tidak ada yang akan dilaksanakan tanpa kata-kata itu. Setiap kata memberi Anda 2.000 baris kode. Implementasi dimulai ketika sebuah kata baru diketahui.
2. Jika sebuah kata tidak segera jelas bagi programmer Anda, mereka diizinkan untuk mengajukan satu pertanyaan . Pertanyaannya lagi harus benar. Itu membutuhkan jawaban segera - jawabannya tidak bisa menunggu bolak-balik dari sisi lain dunia, tetapi perlu diketahui sebelumnya. Implementasi dimulai segera setelah menerima jawaban dan jawaban akan diikuti surat itu.
3. Jika selama implementasi ada persyaratan yang tidak jelas atau kabur, cara untuk menyelesaikannya adalah dengan terlebih dahulu melihat 3 kata yang ada. Jika masih belum jelas, maka programmer membuat tebakan terbaik . Setiap keterlambatan dalam proses ini benar-benar dilarang; dan meminta bantuan dari tim lain bukanlah cara yang tepat untuk menyelesaikannya - mereka sudah memiliki kesempatan untuk mengubah persyaratan dengan memutuskan 3 kata yang benar.
4. Jika setelah semua ini, persyaratan masih belum jelas atau tidak mungkin untuk diterapkan, cara yang benar untuk menangani adalah dengan menolak 3 kata yang menyebabkan masalah, dan pindah ke kata berikutnya. Setiap kata yang ditolak akan dikumpulkan dan diteruskan ke tim lain, dan kata-kata tersebut harus dimodifikasi sebelum dimasukkan kembali ke dalam sistem. Menolak kata-kata selalu menggerakkan batas waktu dan implementasi perlu direncanakan lagi.
5. Tim perlu dievaluasi berdasarkan berapa banyak kata yang mereka tolak. Setelah persyaratan diterapkan, ini diperbaiki selamanya dan tidak dapat diubah lagi . Setiap upaya untuk mengubah fitur yang sudah diterapkan akan ditolak.
6. Masalah aktual dengan pertanyaan ini adalah mengasumsikan bahwa lebih banyak informasi membuat implementasi lebih mudah. Ini tidak benar. Semakin banyak kebebasan yang dimiliki oleh programmer Anda, semakin mudah implementasinya . Mengompresi persyaratan memungkinkan komunikasi sejumlah besar informasi tanpa terlalu membatasi apa yang boleh dilakukan oleh programmer.