Bagaimana orang non-teknis dapat belajar menulis spec untuk proyek kecil?

Bagaimana orang non-teknis dapat belajar menulis spesifikasi untuk proyek kecil?

Seorang teman saya mencoba melakukan outsourcing pengembangan di proyek statistik.

Secara khusus, dia melakukan banyak pekerjaan di excel, dan ingin melakukan outsourcing pembuatan skrip untuk melakukan apa yang dia lakukan sekarang dengan tangan.

Namun, teman saya sangat tidak teknis. Dia miskin dalam menulis spesifikasi teknis.

Ketika dia menulis spec, itu ditulis dengan cara Anda menggambarkan melakukan sesuatu di excel (pergi ke sel ini dan kemudian salin nilai ke sel itu). Itu juga terlalu bertele-tele, dan melakukan contoh beberapa kali. Saya tidak yakin apakah dia benar menggambarkan kasus sudut.

Proyek pertama yang dia outsourcing adalah kegagalan. Saya pikir dia mendeskripsikan beberapa detail, tetapi kasus sudut kurang jelas. Itu dan / atau pembuat kode yang dipekerjakannya tidak memikirkan kasus sudut dan mengajukan pertanyaan yang sesuai. Saya tidak yakin. Saya menggunakan IM dengannya dan butuh setengah jam untuk menggali deskripsi yang seharusnya membutuhkan waktu lima menit atau kurang untuk menggambarkannya. Saya menulis skrip untuknya di akhir, tetapi tidak memeriksa mengapa prosesnya dengan coder gagal.

Dia telah meminta bantuan saya. Namun, saya menolak untuk terlibat, karena mengambil specnya dan menerjemahkannya ke dalam persyaratan yang jelas adalah 10x lebih banyak pekerjaan daripada mengeksekusi pada spec yang ditulis dengan jelas.

Apa cara yang benar baginya untuk belajar? Apakah ada sumber daya yang bisa dia gunakan? Adakah cara dia bisa belajar dari proyek praktik kecil dan tekanan rendah dengan coders?

Sebagian besar skripnya berorientasi pada statistik dan pemrosesan data. misalnya ambil kolom ini dan jalankan rata-rata di atasnya. Hapus baris ini dalam kondisi ini. Jadi tantangannya berbeda dari spec'ing aplikasi web.

Saya melihat dua pendekatan yang baik untuk masalah ini. Namun, penting untuk menyadari dua hal. Pertama, persyaratan rekayasa adalah kerja keras - mengubah ide menjadi spesifikasi formal yang cukup untuk membangun sistem membutuhkan banyak waktu, upaya, dan praktik. Kedua, jika Anda memiliki persyaratan yang baik (dalam format apa pun, dari spesifikasi formal hingga cerita pengguna yang kurang formal dan kasus penggunaan), itu akan jauh lebih mudah, lebih murah, dan lebih cepat untuk benar-benar membangun perangkat lunak (dan membangunnya lebih awal).

Jika teman Anda akan meminta banyak perangkat lunak untuk dibangun atau bermaksud mengontrakkannya, ia harus belajar bagaimana menulis persyaratan perangkat lunak, setidaknya pada level tujuan bisnis dan konsep operasi. Dua buku terkemuka tentang rekayasa persyaratan perangkat lunak adalah oleh Karl Wiegers - Persyaratan Perangkat Lunak (Edisi ke-2) dan Lebih Banyak Lagi Tentang Persyaratan Perangkat Lunak: Masalah Duri dan Saran Praktis . Saya berharap sebagian besar orang yang akan dipekerjakannya menginginkan semacam dokumen yang menggambarkan sistem, setidaknya pada tingkat tujuan bisnis atau konsep operasi, dan buku-buku ini membahasnya. Mereka juga membahas bagaimana dan mengapa aspek-aspek lain dari persyaratan teknik yang saya curigai akan dikembangkan oleh pengembang yang baik di awal proyek.

Opsi kedua adalah mempekerjakan seseorang yang berpengalaman dalam pengembangan perangkat lunak dan rekayasa persyaratan (dan mungkin bahkan semacam rekayasa sistem atau arsitektur sistem) untuk memahami ruang masalah dan menentukan di mana solusi perangkat lunak diperlukan dan di mana solusi perangkat lunak tidak akan bermanfaat, menulis dokumen, dan bahkan mungkin mengawasi atau melakukan upaya pengembangan. Namun, ini mungkin akan lebih mahal dan jumlah untuk menyewa pengembang perangkat lunak penuh waktu untuk jangka waktu yang lama untuk mengembangkan tidak hanya sistem yang diminta, tetapi persyaratan dan arsitektur yang dibutuhkan juga.

Sejujurnya, saya tidak berpikir apa yang teman Anda alami adalah hal yang tidak biasa bagi seseorang yang tidak memahami proses pengembangan perangkat lunak. Saya juga tidak berpikir kesalahan sepenuhnya terletak pada dirinya. Jika proyek perangkat lunak pertama tidak memiliki persyaratan yang baik, pengembang yang di-outsourcing-kan seharusnya menjelaskan, memperbaiki, dan mendokumentasikan persyaratan tersebut. Terus terang, saya tidak yakin bahwa Anda adalah orang yang tepat untuk terlibat, baik, jika Anda tidak mau meluangkan waktu atau upaya untuk bekerja dengan pengguna / pelanggan non-teknis dan mengembangkan spesifikasi teknis yang baik (ini adalah peran kunci siapa pun yang melakukan rekayasa persyaratan dalam disiplin ilmu teknik apa pun).

Saya pikir solusi optimal adalah kombinasi dari dua opsi saya. Saya pikir teman Anda (dan mungkin Anda juga) harus belajar tentang apa yang terlibat dalam rekayasa persyaratan dan manfaat yang memiliki persyaratan kuat dapat membawa ke proyek. Anda, sebagai pengembang perangkat lunak, juga harus lebih terbiasa dengan rekayasa persyaratan dan cara memperoleh, mendokumentasikan, menganalisis, dan mengelola persyaratan yang sesuai untuk proyek perangkat lunak - ini benar-benar keterampilan yang berharga bagi siapa pun yang melakukan pekerjaan di bagian mana pun dalam siklus hidup perangkat lunak.

Ketika saya membutuhkan spesifikasi dari klien non-teknis, saya biasanya meminta mereka untuk menulis dalam bahasa sederhana apa sebenarnya yang ingin mereka capai. Seperti pada "aplikasi harus melakukan A ke B ketika saya menekan C, tetapi hanya jika D". Bonus tambahan untuk "karena D berarti ...".

Bahkan "ambil kolom ini dan jalankan rata-rata di atasnya." adalah langkah ke arah yang benar. Penjelasan yang lebih baik adalah "Tabel berisi ini dan itu" (jika strukturnya sudah ditentukan sebelumnya); "Dapatkan rata-rata X". Pada dasarnya, cara paling tidak teknis mungkin tanpa kehilangan detailnya.

Dengan kata lain, jelaskan idenya, bukan implementasinya.

Kemudian seorang programmer yang peduli harus dapat memahami tujuan sebenarnya dari apa yang dia perintahkan untuk lakukan dan memilih langkah-langkah yang benar sendiri, mengajukan pertanyaan untuk apa pun yang tidak jelas.

Jika tidak ada orang yang cukup peduli dan memahami prosesnya, proyek akan gagal dalam hal apa pun.

Dia dapat mencoba menggunakan pendekatan storyboard .

Mintalah dia menuliskan daftar hal-hal ( cerita ) yang harus dilakukan aplikasi dan di dalam daftar itu, lebih jauh uraikan fungsi masing-masing cerita.

Dia dapat menggunakan alat seperti Asana untuk menyempurnakan ruang lingkup dan fungsi proyek, dan bahkan berinteraksi dengan pengembangnya.

Menerjemahkannya ke dalam persyaratan yang jelas adalah 10x lebih banyak pekerjaan daripada mengeksekusi pada spesifikasi yang ditulis dengan jelas.

Amin. Itu juga menjelaskan mengapa:

pembuat kode yang dipekerjakannya tidak memikirkan kasus-kasus sudut dan mengajukan pertanyaan yang sesuai.

Memahami persyaratan adalah bagian tersulit (dan paling mahal) dari sebagian besar proyek pemrograman. Ketika orang non-teknis menulis persyaratan, mereka seringkali hanya mendokumentasikan penyelesaian yang ingin mereka ganti ("buka Excel, klik pada sel B3 ..."). Yang terbaik yang bisa mereka harapkan adalah duplikat persis dari kesulitan mereka saat ini!

Cara paling produktif yang saya tahu untuk mengatasi ini adalah untuk mendorong orang ini untuk menulis Use Cases ("gunakan" berima dengan "longgar"). Alih-alih menulis persyaratan, jelaskan bagaimana sistem akan digunakan. Ini membuat pengembang sedikit goyah untuk menyarankan solusi yang lebih baik daripada apa yang dilakukan pengguna sekarang.

Sepertinya masalah ini diperburuk oleh kemampuan komunikasi tertulis yang buruk dari teman Anda. Dia harus memasukkan pekerjaan ke dalam mengkomunikasikan ide-ide mereka secara efektif, atau membayar programmer untuk memancing informasi dari mereka. Entah proses yang menyakitkan dan memakan waktu, tetapi melakukannya sendiri lebih murah daripada membayar seseorang untuk melakukannya dengan Anda.

Bagaimanapun, ini adalah kesulitan yang umum dan membuat frustrasi di mana orang-orang kreatif memiliki ide yang tidak lengkap, atau tidak mampu menggambarkannya dalam waktu kurang dari satu juta kata. Orang ini harus berusaha menemukan programmer yang sangat sabar dan berwawasan luas yang bersedia memahami apa yang sebenarnya mereka coba lakukan dan mewujudkannya.

pembuat kode yang dia sewa tidak ... mengajukan pertanyaan yang sesuai

Itu resep untuk bencana. Itu, dan juga harapan bahwa coder akan bertanya. Coders suka kode, bukan untuk berkomunikasi, mengharapkan mereka untuk menghentikan kebiasaan mereka tanpa insentif sangat tidak realistis.

Jika teman Anda ingin menyelesaikan pekerjaan, mereka lebih baik membuat proses yang melibatkan komunikasi berkelanjutan dengan coder - dan teman Anda yang harus memainkan peran aktif dalam hal itu, bukan coder. "Tunjukkan padaku apa yang dilakukan setiap hari Senin dan siapkan dua jam untuk membahas ini setiap hari Selasa", hal-hal seperti itu.

• Sebagai pengantar, berikan mereka ikhtisar ringan tentang metodologi pengembangan Agile dan iterasi (artikel Wikipedia akan melakukannya), sehingga mereka bisa merasakan bagaimana seharusnya.
   
• Untuk membantu mereka memahami kegagalan di masa lalu, berikan mereka ikhtisar ringan Waterfall / Big Design Up Front (yang termasuk kritik - sekali lagi, artikel Wikipedia akan melakukannya) - ini biasanya melakukan pekerjaan yang cukup baik menjelaskan bagaimana biasanya sulit untuk menentukan hal-hal yang benar di muka.

Dalam pengalaman saya, cara yang paling dapat diandalkan untuk mendapatkan pekerjaan perangkat lunak seperti yang diinginkan dengan pelanggan non-teknis adalah berkomunikasi secara permanen dan mengulangi deskripsi fitur, tidak mencoba untuk menentukannya sampai mati dalam satu kesempatan.

Sebagian besar skripnya berorientasi pada statistik dan pemrosesan data. misalnya ambil kolom ini dan jalankan rata-rata di atasnya. Hapus baris ini dalam kondisi ini. Jadi tantangannya berbeda dari spec'ing aplikasi web.

Ini berbeda - sepertinya jauh lebih sederhana daripada menentukan aplikasi web. Ini proses yang logis. Ini hal yang mudah.

Teman Anda hanya perlu menuliskan langkah-langkah yang ia ambil saat melakukan proses ini. Dia dapat melakukannya bagaimanapun yang dia inginkan tetapi hal-hal utama yang menjadi fokus adalah akurasi, keringkasan, dan kejelasan. Tidak ada alasan bahwa itu tidak dapat dilakukan murni dalam teks seperti naskah; itu akan mendapat manfaat dari beberapa divisi logis dari komponen atau tugas, dan mungkin akan berfungsi dengan baik sebagai diagram alur atau diagram.

Sekarang teman Anda harus mencari analis / pengembang yang kompeten dan menggunakan layanan mereka satu per satu. Dia perlu menjabarkan harapannya - setiap hari atau setidaknya beberapa kali per minggu teman Anda harus bertemu dengan pengembang dan melihat langsung demonstrasi kemajuan. Teman Anda akan membayar pengembang untuk waktunya selama demonstrasi ini, tetapi akan sepadan untuk memastikan bahwa proyek sedang berjalan sesuai spesifikasi. Setiap perubahan pada spesifikasi - yaitu hal-hal yang dihilangkan teman Anda - perlu dinegosiasikan dan mungkin ditambahkan ke harga yang dikutip.

Perhatikan bahwa saya mengatakan 'kompeten' - ini tidak sama dengan 'rata-rata', karena ada banyak pengembang 'rata-rata' yang tidak kompeten. Jika teman Anda hanya mendapatkan pembuat kode termurah, atau hanya menemukan seseorang daring, ia akan mengalami masalah. Bukan untuk menyarankan bahwa orang yang menemukan pekerjaan online tidak baik, tetapi Anda tidak akan mempekerjakan seseorang tanpa rekomendasi.

Teman Anda harus menemukan orang yang tepat. Dalam setiap proyek perangkat lunak ada kebutuhan untuk analis, programer, administrator sistem, penguji, dan manajer proyek. Semakin banyak peran yang teman Anda ingin 'outsourcing', semakin banyak penyedia yang terampil dan semakin banyak teman Anda harus membayar.

Maaf menjadi orang yang memecah ini untuk Anda, tetapi itu bukan pekerjaan orang non-teknis untuk belajar bagaimana menulis spesifikasi formal. Adalah tugas pengembang untuk mewawancarai orang non-teknis, mencoba menyaring apa yang dikatakan orang tersebut kepada Anda tentang apa yang mereka kejar, menentukan apa yang benar-benar diinginkan klien (bukan apa yang mereka pikir mereka inginkan, yang tidak selalu hal yang sama), membangun dokumen persyaratan yang relatif informal (yang terstruktur dengan baik tetapi mencoba menghindari jargon yang tidak akan dipahami klien) dan meninjau dokumen itu dengan klien.

Setelah klien puas dengan dokumen persyaratan informal, Anda dapat menggunakannya sebagai dasar untuk menyusun spesifikasi persyaratan yang lebih formal yang mulai membahas detail teknis lebih lanjut tentang apa yang dibutuhkan.

Seluruh proses ini dikenal sebagai "persyaratan penangkapan" dan membentuk langkah pertama dalam proses rekayasa perangkat lunak. Sebenarnya menulis perangkat lunak hanya sebagian kecil dari rekayasa perangkat lunak, fakta yang sayangnya banyak pengembang perangkat lunak lupa. Hal lain yang tampaknya mereka lupakan adalah bahwa ada kebutuhan yang kuat untuk berkomunikasi dengan klien dan tetap berdialog dengan mereka selama seluruh proses untuk memastikan bahwa semuanya tetap pada jalurnya.

Sedangkan untuk berkomunikasi dengan orang-orang non-teknis, sangat penting Anda mencoba menghindari menggunakan jargon komputer dan pengembangan perangkat lunak ketika berbicara dengan mereka. Jika mereka menggunakan istilah jargon dari bidang mereka sendiri maka penting untuk memahami apa arti istilah ini sehingga Anda mungkin ingin menyusun glosari proyek untuk mendapatkan definisi formal untuk istilah ini. Bagaimanapun, Anda bekerja untuk mereka, jadi penting untuk memahami dari mana mereka berasal.

alih-alih jargon, Anda harus mencoba menggunakan cara tidak mengintimidasi untuk berkomunikasi dengan klien Anda, dokumen yang ditulis dalam bahasa Inggris sederhana adalah bantuan, tetapi banyak orang dalam bisnis perangkat lunak yang digunakan untuk menulis untuk komputer daripada manusia sehingga dapat menemukan ini sulit. Selain itu, klien tidak suka membaca tumpukan kertas besar, tidak peduli seberapa sederhana bahasa mereka, jadi Anda mungkin ingin menggunakan alat bantu visual. Diagram, gambar rangka, dan papan cerita adalah alat yang berguna di sini.

Tetapi singkatnya, intinya adalah itu bukan tugas klien Anda untuk belajar bahasa Anda, itu milik Anda untuk belajar bahasa mereka.