Haruskah pengembang memahami domain bisnis atau apakah spesifikasinya memadai?

Saya bekerja untuk perusahaan yang domainnya benar-benar sulit untuk dipahami karena merupakan teknologi tinggi dalam elektronik, tetapi ini berlaku untuk setiap pengembangan perangkat lunak dalam domain yang kompleks.

Aplikasi yang saya kerjakan menampilkan banyak informasi, bagan, dan metrik yang sulit dipahami tanpa pengalaman dalam domain. Pengembang menggunakan spesifikasi untuk menggambarkan apa yang harus dilakukan perangkat lunak, seperti menentukan bahwa bagan tertentu harus menampilkan metrik jenis ini dan metrik ini adalah rumus aritmatika berikut.

Dengan cara ini, pengembang tidak benar-benar memahami bisnis dan apa / mengapa dia melakukan tugas ini. Ini bisa baik-baik saja jika spesifikasi benar-benar terperinci tetapi ketika tidak atau ketika penulis lupa menggunakan case, ini cukup sulit bagi pengembang untuk menemukan solusinya.

Di sisi lain, melatih setiap pengembang untuk semua aspek bisnis bisa sangat lama dan sulit.

Haruskah kita lebih mementingkan spesifikasi terperinci (tetapi seperti yang kita ketahui, spesifikasi sempurna tidak ada) atau haruskah kita melatih semua pengembang untuk memahami domain bisnis?

EDIT: ingatlah dalam jawaban Anda bahwa perusahaan dapat menggunakan pengembang eksternal dan bahwa formasi untuk semua domain bisa sekitar 2 minggu

Spesifikasi ini hampir tidak pernah memadai. Pengembang yang tidak memiliki pengetahuan domain tidak dapat menunjukkan ketika spesifikasi salah (sering terjadi di sebagian besar tempat) dan membuat pilihan desain yang buruk.

Dalam pengalaman saya, setelah bekerja di 3 industri yang sangat berbeda sekarang, Anda bisa mulai tidak tahu banyak tentang domain, tetapi Anda harus mempelajarinya pada akhirnya dan seseorang harus memahaminya secara lebih rinci.

Masalah mendasar adalah ke impedansi klien-pengembang: mereka menginginkan sesuatu tetapi hanya akan mengetahuinya ketika mereka melihatnya dan Anda ingin menyelesaikan masalah mereka tetapi tidak selalu bisa mendapatkan ide yang jelas tentang apa masalah itu. Semakin banyak pengetahuan domain dari industri (klien) mereka yang dapat Anda (pengembang) bawa, semakin mudah Anda menerjemahkan "keinginan" yang samar menjadi "masalah" konkret dan menyelesaikannya.

Sebagai contoh anekdotal, pekerjaan saya sebelumnya adalah di industri kimia yang melibatkan perangkat lunak manajemen pabrik. Saya mulai dengan nol pengetahuan domain secara efektif, tetapi mampu mengimplementasikan kode yang saya butuhkan untuk menyelesaikan sub-masalah yang disajikan kepada saya oleh pengembang senior dan klien. Seiring waktu, saya berusaha untuk mempelajari industri ini, sehingga saya dapat berkomunikasi lebih mudah di tingkat klien. Ketika saya memahami industri mereka, saya mulai memahami apa masalah sebenarnya. Ketika mereka mengatakan hal-hal seperti "kita perlu melacak semua nilai data pada modul ini" Saya dapat menerjemahkannya menjadi apa yang sebenarnya mereka maksudkan, yaitu "kita perlu menyimpan catatan historis dari setiap nilai yang dihasilkan oleh sensor ini, disimpan selama X hari retensi, tetapi selalu dievaluasi berdasarkan bacaan terbaru dari sensor itu. "

Jadi ya, seseorang membutuhkan pengetahuan domain, dan lebih disukai pengembang karena masalah domain bukan masalah kode dan menerjemahkan antara keduanya tidak sepele. Pada akhirnya, setiap pengembang yang layak disimpan di tim Anda harus mengambil domain, sehingga mereka dapat membuat pilihan lebih banyak informasi tentang nuansa kode mereka.

SESEORANG pada proyek perlu memiliki pengetahuan domain yang cukup lengkap. Orang itu mungkin atau mungkin bukan pengembang.

Dalam proyek Agile, pemilik proyek klien adalah orang itu, dan mereka bekerja secara kolaboratif dan erat dengan tim. Dalam proyek non-Agile, seseorang dalam tim perlu mendapatkan pengetahuan itu, tetapi biasanya tidak, yang merupakan salah satu alasan mengapa proyek non-Agile sangat rentan terhadap kegagalan.

Ada banyak jawaban bagus. Saya menambahkan sendiri karena setelah membacanya dan mencari saya menemukan bahwa tidak ada yang menyebutkan masalah utama: bug .

Jika tim tidak dilengkapi dengan cukup banyak orang dengan otoritas dan keahlian domain yang cukup, cepat atau lambat bug akan merayap masuk. Diberi pengetahuan tentang domain, ada nilai-nilai / hasil / hubungan yang tidak masuk akal, atau tidak sensasional. Orang bisa berharap bahwa spesifikasi secara eksplisit menunjukkan mereka tetapi pada kenyataannya yang terbaik yang dapat Anda capai adalah dengan menghindari yang paling jelas (beri tahu saya jika suku bunga menjadi negatif, atau hal-hal seperti itu - ini bisa atau bisa bukan kesalahan tetapi cukup aneh untuk diperhatikan).

Ini sangat terkait dengan memahami alasan untuk pilihan, dan dalam kasus terbaik itu juga mengarah ke perangkat lunak yang lebih baik (karena jika seseorang benar-benar tahu alasan di balik permintaan, dapat memikirkannya, daripada harus menerimanya sebagai suatu pemberian ).

Ingat bahwa Einstein berkata, "Tetapi pemikiran dan gagasan, bukan formula, adalah awal dari setiap teori fisik." , Yaitu bahwa orang berpikir bukan dalam hal rumus abstrak tetapi gagasan ...

Jika Anda menempatkan orang yang hanya tahu bahasa Inggris dan orang yang hanya tahu bahasa Jepang di sebuah ruangan, mereka tidak akan bisa menerjemahkan dari bahasa Jepang ke bahasa Inggris, terlepas dari menjadi ahli bahasa masing-masing. Untuk alasan yang sama, bahkan programmer ahli tanpa pengetahuan domain tidak berdaya dalam mencari tahu apa yang mereka butuhkan untuk membangun, bahkan ketika mereka memiliki akses 24x7 ke pakar domain terbaik yang tidak juga ahli dalam pengembangan perangkat lunak.

Spek adalah upaya menerjemahkan "bahasa Jepang" dari persyaratan domain ke "Bahasa Inggris" dari persyaratan pemrograman. Ketika Anda mendapatkan kualitas terjemahan yang sebanding dengan terjemahan Google, itu adalah hari keberuntungan Anda; sebagian besar waktu, kualitasnya tidak ada, sehingga Anda tidak memiliki jalan lain untuk mendapatkan setidaknya beberapa pengetahuan domain. Dengan ketekunan, itu membuat Anda menjadi "penerjemah" yang layak pada akhir proyek, sehingga nilai Anda untuk perusahaan Anda tumbuh secara signifikan. Sebagian besar waktu, Anda juga bersenang-senang dalam prosesnya, jadi ini adalah situasi yang saling menguntungkan.

Tanpa beberapa aspek pengetahuan bisnis Anda berakhir dengan pengembang yang tidak mengajukan pertanyaan dan tanpa berpikir kode apa yang dikatakan spesifikasi. Saya percaya dibutuhkan "Pemikir" untuk membuat perangkat lunak yang bagus, bukan hanya orang yang dapat menggunakan keyboard. Memahami tidak hanya "Apa" yang Anda lakukan tetapi "Mengapa" dan bagaimana itu cocok dengan gambaran yang lebih besar membantu memberikan kepuasan yang lebih besar bagi tim pengembangan.

Saya pikir Anda harus mencoba untuk mendapatkan pengetahuan domain. Spesifikasi adalah daftar periksa yang mengatakan apa yang harus dilakukan produk akhir dan diperlukan untuk validasi produk Anda. Sebagai pengembang Anda harus selalu berusaha memahami apa masalah sebenarnya yang Anda coba selesaikan. Mendapatkan pengetahuan domain akan membantu Anda memahami hal itu.

Ini akan membantu Anda mendesain dan kode dengan mudah karena Anda akan mengerti apa yang mengubah bagian (katakanlah aturan ditetapkan) dan menempatkannya secara terpisah. Anda tidak perlu menjadi ahli dalam hal itu tetapi akan dapat berbicara dengan pengguna akhir dalam bahasa mereka .

Anda dapat mengendarai mobil dengan pengetahuan dasar tentangnya; tetapi jika Anda ingin menikmati perjalanan Anda perlu belajar lebih banyak tentang cara menggunakannya dengan tepat. Seperti halnya perdagangan lainnya, tidak wajib untuk memahami domain, tetapi menyenangkan ketika Anda melakukannya .

Saya pikir seorang pengembang yang mengetahui bisnis ini sepadan dengan emas.

Dalam skenario "tradisional" di mana bisnis memiliki beberapa persyaratan dan beberapa analis bisnis menerjemahkannya ke dalam persyaratan teknis maka pengembang bekerja dari mereka yang pasti memiliki dua hal yang dapat terjadi:

1. Anda memiliki banyak titik kegagalan. Analis bisnis mungkin tidak mendapatkan semua persyaratan bisnis yang diterjemahkan dengan sempurna dan / atau pengembang mungkin tidak menerjemahkannya ke dalam spesifikasi teknis dengan sempurna. Varian pada skenario "rahasia di sekitar ruangan". Hanya urgensi komunikasi.

2. Salah satu atau semua pemilik bisnis, analis bisnis atau pengembang cukup baru bagi organisasi untuk kehilangan item-item utama yang tidak akan mereka pikirkan secara normal. Pengembang berpengalaman yang mengenal bisnis dengan baik dapat membantu mendidik orang-orang dalam peran-peran lain untuk membuat produk lebih lengkap.

Hampir selalu ada trade-off yang dibuat antara nilai setiap fitur dalam spesifikasi, seberapa dekat spesifikasi harus diterapkan untuk bernilai, dan biaya pertemuan setiap kombinasi fitur spesifikasi. Seringkali pertukaran yang baik hanya dapat dilakukan ketika pengetahuan untuk melakukan semua hal di atas ada dalam satu orang, atau tim yang bekerja erat, termasuk arsitek dan / atau pembuat kode perangkat lunak yang sebenarnya.

Tanpa pengetahuan yang sangat terlokalisasi dan bahkan mungkin perasaan, hasilnya dapat dengan mudah berakhir sebagai produk yang sangat mahal dan hampir tidak berguna yang sangat dekat dengan spesifikasi tertulis.

Biaya membuat spek yang tidak memiliki masalah di atas sering kali lebih besar daripada melatih arsitek dan / atau pembuat kode untuk memiliki pengetahuan domain yang cukup untuk bekerja dengan spek yang kurang terperinci (dengan asumsi legalitas dan kontrak bisnis memungkinkan ini).

Ya, pengembang perlu mengetahui bisnisnya sampai tingkat tertentu. Mereka tidak harus mengetahui detail setiap menit, tetapi mereka harus memiliki pemahaman dasar tentang apa yang digunakan untuk laporan X dan bagaimana laporan itu digunakan dalam proses bisnis. Semakin pengembang Anda memahami tentang bisnis, semakin baik solusi yang dapat mereka berikan.

Berdasarkan pengalaman saya *, satu individu dengan pengetahuan yang baik tentang domain masalah dan pengetahuan yang baik tentang pengembangan perangkat lunak lebih mungkin untuk menemukan solusi optimal untuk masalah daripada dua individu, satu dengan pengetahuan yang sangat baik tentang domain masalah dan satu dengan pengetahuan yang sangat baik pengembangan perangkat lunak, bekerja bersama.

Saya pikir sampai pada fakta sederhana bahwa komunikasi yang terjadi di otak seorang individu jauh lebih cepat dan lebih baik daripada komunikasi antar individu.

* Pengalaman utama yang saya gambar untuk menjawab pertanyaan ini adalah 10+ tahun dihabiskan untuk mengembangkan paket perangkat lunak akuntansi (dari awal hingga 'mode pemeliharaan'). Meskipun pengetahuan saya tentang pengembangan perangkat lunak cukup baik, dibandingkan dengan rekan-rekan saya, saya sering merasa terhalang oleh kurangnya pemahaman tentang domain masalah.

Saya ingin menjawab sebagai seseorang yang datang dari sisi bisnis, yang bekerja dengan pengembang yang menunjukkan sedikit minat dalam mempelajari dasar-dasar perdagangan, kadang-kadang bahkan tampaknya bangga tidak harus tahu tentang dasar-dasar itu: Masalahnya adalah bahwa pengembang tidak akan dapat melihat kesalahan dalam hasil pada pandangan pertama (hasil tidak masuk akal, tanda-tanda yang salah dan sebagainya), yang membutuhkan kasus uji rinci (yang kami tidak kembangkan sampai saat ini), atau pengawasan terus-menerus terhadap hasilnya. Sejauh saya bersedia mempelajari dasar-dasar pengembangan perangkat lunak untuk memudahkan komunikasi, saya ingin mendorong pengembang untuk melakukan hal yang sama.

Anda tidak harus melakukannya, tetapi mengapa Anda tidak mau?

Saya akan khawatir tentang setiap programmer yang enggan dan terutama tidak dapat mempelajari domain sampai tingkat tertentu. Sangat penting untuk keluar dari "menara kode gading" sesekali.

Menulis kode tanpa tahu bagaimana menggunakannya dan untuk tujuan apa kedengarannya seperti pekerjaan yang mengerikan. Siapa yang mau menghancurkan batu bata saat Anda bisa membangun katedral?

Semakin terlibat pengembang dan semakin senior dalam bisnis, semakin penting memiliki setidaknya pengetahuan domain tingkat menengah atau area yang lebih bernuansa industri yang mungkin kritis tidak akan dipahami oleh tim pengembang.

Namun spesifikasi harus memadai untuk tugas-tugas tingkat bawah. Singkatnya, yang terbaik adalah melatih tenaga kerja Anda ke tingkat yang lebih rendah. Mereka mungkin menjadi programmer polyglot terbaik di dunia, tetapi jika mereka tidak dapat memahami masalah ini dengan cukup dalam, mereka selalu mengalami kegagalan atau pemrograman pawai kematian.

Seharusnya selalu ada beberapa spesifikasi - Anda tidak dapat mengharapkan semua pengembang menjadi pakar domain. Pada saat yang sama, jika pengembang secara membabi buta mengikuti spesifikasi tanpa benar-benar memahami untuk apa itu, hasilnya mungkin tidak benar-benar seperti yang diinginkan klien. Sering terjadi bahwa ketika pengembang bahkan memiliki tingkat pemahaman yang agak baik (tetapi tidak ahli), mereka dapat menangkap kesalahan dan kelalaian dalam spesifikasi. Mereka juga dapat berkontribusi dan memberikan umpan balik kepada proses yang dapat membuat produk akhir jauh lebih baik.

Mungkin layak mempekerjakan beberapa ahli domain yang tugasnya adalah untuk menjalin hubungan antara klien dan pengembang untuk membantu memberikan pengembang pemahaman yang lebih baik dan juga untuk membantu menulis spesifikasi.

Saya pikir ini sulit untuk memberikan jawaban.

Sulit untuk melihat bagaimana, katakanlah, seorang pengembang lepas dapat memahami bisnis (atau ilmu) di balik setiap aplikasi yang mereka kembangkan. Dalam situasi ini, saya pikir lebih penting bahwa pengembang tahu untuk mengajukan pertanyaan yang tepat tentang spesifikasi atau model bisnis daripada benar-benar memahami bisnis itu sendiri.

Sebaliknya, seorang pengembang perusahaan, dengan asumsi mereka telah berada dalam bisnis yang sama untuk waktu yang sama, harus benar-benar belajar bagaimana bisnis berjalan setelah beberapa bulan (atau mungkin bertahun-tahun). Dalam tim besar, Anda mungkin juga memiliki arsitek yang memahami bisnis lebih jelas daripada pengembang.

Dalam UKM dengan pengembang tunggal, penting bahwa pengembang sering berdiskusi dengan pemilik / manajer untuk menghindari pergi dan menerapkan hal yang salah.

Jadi ada banyak cara berpikir yang mungkin tentang hal ini, tetapi kuncinya adalah sama dalam semua kasus: komunikasi .

Pengembangan perangkat lunak adalah satu-satunya profesi yang saya tahu yang mengharuskan Anda untuk tidak hanya menjadi mahir dalam profesi Anda sendiri tetapi memiliki pemahaman dasar tentang profesi yang sedang Anda tangani. Penting untuk memiliki pemahaman yang cukup tentang domain untuk berkomunikasi dengan klien dan pengembang lain dalam bahasa klien. Sebagai pengembang, Anda tidak selalu bisa mengandalkan orang lain untuk melatih Anda. Kadang-kadang Anda harus meningkatkan diri sendiri dengan penelitian pribadi, sering kali di luar jam kerja biasa.

Saya benar-benar mengerti apa yang Anda maksudkan di sini karena kami, sebagai perusahaan dalam industri pariwisata, menghadapi masalah yang sama. Ketika saya adalah pengembang junior, saya juga belajar pariwisata di sebuah perguruan tinggi. Jadi, Anda bisa menebak bahwa saya tidak berasal dari latar belakang ilmu komputer tetapi pengetahuan pariwisata saya tinggi.

Kami membangun produk dalam kaitannya dengan perusahaan perangkat lunak lain saat itu, tetapi pengetahuan khusus domain masih kurang. Seperti yang Anda jelaskan, sangat sulit untuk memperbaikinya jika Anda membangun produk di industri pariwisata karena ada banyak masalah lintas sektoral, dll.

Jadi, gerakan ini memberi banyak hasil buruk dalam jangka panjang. Kemudian, kami mengambil langkah besar ke depan, dan saya mulai fokus hanya pada pengembangan daripada bagian bisnis proyek. Karena saya memiliki pengetahuan industri dan pengetahuan pemrograman, proyek tumbuh lebih efisien dari sebelumnya. Belum lagi, kita kemudian dapat membuat keputusan lebih cepat karena saya memiliki pengalaman di kedua sisi mata uang.

Sebagai jawaban konkret untuk pertanyaan Anda, sudah pasti ya menurut pendapat pribadi saya. Jika proyek yang sedang dikerjakan oleh tim Anda adalah proyek jangka panjang, maka ambil jalan yang sulit dan latih staf Anda tentang dasar-dasar dan perincian spesifik domain.

Jika pengembang tetap di perusahaan / industri dalam jangka waktu yang lama, mereka akan perlahan-lahan tetapi pasti akan belajar "bisnis".

Beberapa perusahaan mengakui dan memberikan pelatihan dalam "bisnis". Perusahaan keuangan adalah contoh yang baik untuk ini.

Semakin banyak Anda mempelajari bisnis, semakin mudah untuk berbicara dengan pengguna Anda. Mereka akan merasa lebih percaya diri pada Anda. Anda akan lebih mudah memahami keanehan di mana suatu sistem mungkin salah jika itu tidak cukup seperti yang diharapkan bagi pengguna.

Untuk menjawab pertanyaan Anda, spesifikasinya tidak pernah memadai dalam pengalaman saya. Masalah umum adalah mereka sering tidak mengandung informasi yang cukup, dan keluar dari tanggal dengan cepat.

Pengalaman domain bisnis dapat menjadi kewajiban bagi beberapa perusahaan. Mereka mencari pengembang dengan pengalaman di domain saat merekrut. Beberapa perusahaan bahkan menempatkan ini lebih tinggi daripada keterampilan teknologi yang sebenarnya. (Tidak ada pengalaman finansial, tidak ada wawancara yang sangat umum, tentunya di Inggris).

Dari pengalaman pribadi, spesifikasinya cukup selama Anda memiliki seseorang di tim yang bekerja dengan Anda yang memiliki pengetahuan domain.

Saya bekerja di industri yang sangat terspesialisasi: kami membuat perangkat lunak untuk media penyiaran. Saya hampir tidak tahu apa-apa tentang penyiaran, tapi saya tahu kode dan saya tahu data, dan saya punya orang-orang baik di tim manajemen proyek yang mengerti penyiaran. Formula itu sudah cukup baik selama beberapa tahun terakhir bagi saya untuk menghasilkan fungsionalitas yang baik yang disukai klien.