Kebetulan belakangan ini saya telah melakukan banyak pekerjaan dengan persyaratan produk dari "pelanggan internal", termasuk kolega dari berbagai departemen dan tim teknis (di dalam perusahaan). Dan orang-orang terus-menerus mendatangi saya sehingga tim kami akan mengimplementasikan fitur tertentu, mengulang sesuatu, menambah, menghapus.
Dalam artikel ini saya ingin memberi tahu bagaimana Anda dapat bekerja dengan semua kekacauan yang masuk ini.
Artikel ini ditulis berdasarkan praktik kerja, dan tidak bermaksud membahas seluruh topik manajemen proyek, persyaratan, tim, kualitas implementasi selanjutnya dari persyaratan oleh pengembang, topik analisis hasil implementasi, dll.
Tapi itu hanya mencakup bagian kecil yang sempit antara "Wishlist" dan "implementasi", yang tepatnya tentang persyaratan itu sendiri: Wishlist sewenang-wenang / persyaratan / keinginan / masalah, dll. Terbang ke kami, dan kami bekerja dengan mereka dan pada akhirnya kami mendapatkan apa yang cocok untuk pengembangan.Mencari tahu masalah sebenarnya
Ketika seseorang menemukan masalah, permintaan, ide untuk fitur baru, dll. maka itu tidak selalu membawa kita siap pakai ini, cocok untuk implementasi. Sebagai aturan, ini atau semacam "kosmos" adalah sesuatu yang sangat besar, melumpuhkan, tidak realistis, mengharuskan untuk mengulang semuanya untuk menyelesaikan masalah kecil, yang relevansinya tidak diketahui. Atau hanya persyaratan "mentah", tidak dapat dipahami, dan tidak spesifik.
Misalnya, seseorang menyarankan untuk menambahkan fitur baru. Dan lakukan dengan cara ini, menawarkan semacam implementasi teknis. Dalam hal ini, tidak tahu apa yang diatur dan bagaimana hal itu bisa dilaksanakan. Jelas, seseorang tidak bisa hanya mengambil persyaratan seperti itu dan menerapkannya. Jika mereka melakukannya, dunia akan jatuh ke dalam kekacauan dan kegelapan dunia bawah lama.
Untuk sedikit mendorong kekacauan dan kegelapan dunia bawah, kita perlu memahami apa yang ada di balik gagasan dan proposal ini. Masalah apa yang benar-benar ingin diselesaikan oleh orang yang datang kepada Anda, masalah apa yang harus ditutup?
Ini jauh dari selalu jelas dan segera jelas. Seringkali Anda harus melewati, menanyakan pertanyaan yang sama berkali-kali. Atau pertanyaan berbeda. Sampai akhirnya menjadi jelas apa yang salah pada intinya, pada intinya masalah, dan bagaimana dalam pemahaman seseorang harus ada “begitu”. Dan pemahaman ini, sebagai suatu peraturan, sangat berbeda dari pernyataan asli dari tugas / masalah. Tetapi tanpa menerimanya, mustahil untuk melanjutkan ke langkah selanjutnya dan memenuhi kebutuhan.
Memahami apa yang
benar-benar dibutuhkan seseorang adalah keseluruhan seni, yang didedikasikan untuk seluruh perumpamaan (misalnya, "Vladimir Tarasov - Lebih dekat dengan rusa"), buku (misalnya, "Rob Fitzpatrick - Tanyakan ibumu") dan intensitas praktis (misalnya, tentang pengembangan kebiasaan).
Sepeda tua tentang pembeli bor
Seorang pria datang ke toko dan membeli bor di sana. Tetapi pada kenyataannya, dia tidak membutuhkan bor, dia membutuhkan lubang di dinding yang ingin dia bor. Karena itu, ia membeli bor.
Tapi itu belum semuanya. Lubang tidak diperlukan sendiri. Dia diperlukan untuk menggantung gambar indah yang besar dalam bingkai yang berat. Dan pahlawan ini ingin menggantung gambar untuk menyenangkan ibu mertuanya, yang telah lama memintanya untuk menggantung gambar, tetapi dia masih tidak melakukan ini.
Tampaknya bagi kami bahwa kami telah menemukan masalah mendasar. Tapi tidak.
Bahkan, dalam satu hari akan ada pertandingan sepak bola, yang benar-benar ingin dilihat pahlawan kita. Dan agar ibu mertuanya tidak punya alasan untuk mengganggunya, ia mengatur agar dirinya memiliki hak untuk menonton sepak bola - ia melakukan apa yang telah lama diminta - ia menggantungkan gambar.
Artinya, membeli latihan, ia benar-benar ingin menonton sepak bola dengan tenang.
Di sini harus dicatat bahwa situasi ketika seseorang muncul dengan aneh, tidak dapat dipahami, dirumuskan dengan bengkok atau, dari sudut pandang Anda, persyaratan yang salah, adalah
normal . Bagi orang-orang pada umumnya, adalah wajar bahwa mereka menginginkan sesuatu, tetapi mereka tidak selalu dapat mengartikulasikan dengan tepat dan benar apa yang mereka inginkan. Orang-orang, pada dasarnya, memang seperti itu - ini wajar. Maksudnya, intinya bukan bahwa seseorang itu salah, tetapi bagaimana Anda tahu bagaimana bekerja dengan situasi seperti itu.
Pada momen khusus ini, bekerja dengan pelanggan internal tidak jauh berbeda dari bekerja dengan pelanggan eksternal.
Persyaratan untuk fitur yang sudah ada
Sepeda mata-mata.
Entah bagaimana mereka mengirim mata-mata ke satu kota untuk mencari tahu di mana pabrik kartrid itu berada. Mereka memberikan informasi untuk membantu bahwa ada sebuah gereja di kota itu, dan jika Anda berjalan lurus dan pergi di sepanjang jalan, maka di suatu tempat di arah itu akan ada sebuah pabrik.
Di sinilah mata-mata di kota. Dia bertemu nenek dan bertanya:
- Katakan padaku, bagaimana menuju ke gereja?
- Tapi Anda melihat pabrik kartrid? Dari dia langsung dan kemudian ke kanan. Akan ada gereja.
Kasus paling sederhana, ketika ternyata apa yang diinginkan seseorang, sudah kita miliki. Mungkin tidak cukup dalam bentuk yang diharapkan, diasumsikan, dibayangkan seseorang. Hanya saja orang tersebut tidak tahu apakah itu, atau tidak tahu cara menggunakannya, atau dia memiliki informasi yang salah tentang cara kerjanya. Atau Anda hanya perlu mengkonfigurasi / mengaktifkan sesuatu untuk mendapatkan apa yang Anda butuhkan.
Ketika semuanya begitu sederhana, yang tersisa adalah memberikan instruksi kepada orang tersebut tentang bagaimana mendapatkan hasil yang dia butuhkan menggunakan peluang yang ada.
Selesai
Persyaratan Gandakan
Sering terjadi bahwa persyaratannya serupa, mereka hanya berbeda dalam nuansa pengaturan (potensial) atau tentang hal yang sama, tetapi dengan kata-kata yang sedikit berbeda. Persyaratan tersebut dapat digabungkan untuk memahami seberapa banyak dan di tempat mana fleksibilitas diperlukan (atau akan dibutuhkan di masa depan) dan di mana tidak diperlukan. Apa saja fitur utamanya? Untuk membuat satu sistem atau bagian dari fungsi sekaligus yang akan memenuhi semua kebutuhan ini sekaligus. Mungkin dengan pengaturan atau variasi yang berbeda, tetapi masing-masing tidak perlu melakukan hal yang sama secara terpisah beberapa kali.
Contoh:
Perwakilan dari beberapa departemen berbeda mendatangi Anda (biasanya secara independen satu sama lain dan pada waktu yang berbeda) dan mengatakan bahwa seseorang perlu mengirim laporan ke email ke klien dari daftar, yang lain - pemberitahuan ke lingkaran alamat tertentu yang beberapa sistem teknis tidak bekerja. Yang ketiga datang dan inginkan, sesuai dengan hasil pemrosesan data klien ini dan itu, sebuah surat dengan hasil pemrosesan dikirim ke klien.
Jelas di sini bahwa dalam semua kasus, sistem untuk mengirim surat diperlukan, dan tugas untuk mengirim berasal dari tempat yang berbeda dalam keadaan yang berbeda.
Oleh karena itu, sistem pengiriman surat terpadu tertentu muncul. Di mana tugas dapat berasal dari sistem yang berbeda. Dan jika semua peristiwa di atas (yang dengannya mereka yang ingin mengirim surat kepada kami) datang untuk terjadi dalam sistem yang sama, maka lebih baik lagi: itu berarti bahwa sistem tersebut dapat dibuat lebih seragam dan lebih sederhana.
Jika kita tidak bekerja dengan persyaratan yang masuk dengan cara ini, dan mereka datang ke pengembangan segera dalam bentuk mentah, maka setelah beberapa waktu kita akan menemukan sistem kita dengan beberapa pengirim surat yang berbeda, masing-masing bekerja sesuai dengan logikanya sendiri, memiliki implementasi khusus sendiri, pengaturan, fungsi. Dan untuk mengubah sepotong kecil logika di ketiganya, atau menambahkan fungsi dari yang lain ke salah satu pengirim ini, Anda perlu menyalin-tempel kode, atau menulis ulang bagian yang cukup besar dan refactor setelah implementasi dan operasi. Meskipun, pada prinsipnya, orang bisa mengerti sebelumnya bahwa semuanya akan terjadi.
Persyaratan yang saling bertentangan
Kebetulan bahwa dua persyaratan tertentu atau lebih saling bertentangan. Terkadang "sepenuhnya", yang tidak dapat digabungkan dengan cara apa pun. Namun, kadang-kadang, "mode yang berbeda" dapat dipertimbangkan, di mana masing-masing satu persyaratan terpenuhi, sementara yang lain tidak tersedia. Atau selesaikan salah satu masalah dengan cara lain - maka kontradiksi akan hilang.
Untuk bergerak menuju solusi, Anda harus mulai membuka rantai “mengapa / mengapa”. Untuk setiap persyaratan (seperti yang dijelaskan di bagian pertama artikel). Artinya, kita harus memahami sedalam mungkin dari apa sebenarnya persyaratan tersebut muncul, dan bahwa orang yang datang dengan persyaratan ini ingin "sungguh".
Kemudian kita memiliki kesempatan untuk menemukan solusi lain untuk "masalah nyata" ini, atau untuk memahami bagaimana persyaratan yang saling bertentangan ini dapat digabungkan.
Misalnya, jika satu persyaratan sebenarnya diperlukan hanya dalam beberapa kondisi sempit tertentu, dan lain dalam kondisi sempit tertentu lainnya. Kemudian ternyata mereka tidak berpotongan. Atau tugas yang menciptakan persyaratan seperti itu dapat diselesaikan dengan cara yang sangat berbeda, bahkan mungkin lebih sederhana dan efektif. Dan kemudian salah satu persyaratan menghilang (atau berubah menjadi yang sama sekali berbeda - yang tidak ada hubungannya dengan yang kedua), dan yang kedua tetap. Dan tidak ada kontradiksi.
Atau pahami: persyaratan ini tidak dapat digabungkan dengan cara apa pun, dan Anda harus memilih satu. Tapi, untungnya, ini masih sangat jarang.
Semua ini dimungkinkan karena hampir setiap tugas dapat diselesaikan dengan beberapa cara. Dan jika kita naik lebih tinggi dan lebih tinggi dari formulasi awal, mentah, mungkin semi-teknis tertentu, dalam memahami apa tugasnya, pada prinsipnya, maka ada semakin banyak pilihan solusi. Termasuk solusi non-teknis (tingkat pengaturan, proses, organisasi, dll). Dan semakin luas pilihan opsi, semakin mudah untuk memilih dua opsi untuk menyelesaikan dua masalah yang tidak saling mengganggu, dan bahkan, mungkin, membantu, jika memungkinkan.
Persyaratan boiler
Idenya adalah bahwa pada awalnya semua persyaratan yang berbeda dari semua sumber harus bergabung menjadi satu tumpukan, menjadi satu boiler. Kemudian Anda dapat membongkar mereka, menganalisisnya untuk opsi di atas - "berulang" atau "kontradiktif", untuk memberikan yang sudah disiapkan: persyaratan yang tidak berulang dan konsisten yang dapat "diambil dan dilakukan" dalam urutan yang benar.
Artinya, idenya adalah untuk melihat keseluruhan gambar. Untuk semua yang ada sekarang dan yang ingin mereka tambahkan, ubah. Dan berdasarkan seluruh gambaran ini, sudah diputuskan: apa, bagaimana, dan kapan melakukannya.
Dalam konteks ini, semua persyaratan yang masuk adalah bahan baku untuk bersiap-siap untuk tugas pengembangan di output. Selain itu, tugas-tugas pada output tidak akan selalu bertepatan satu-ke-satu dengan beberapa kebutuhan yang masuk. Satu tugas dapat memenuhi beberapa kebutuhan sekaligus atau menutup seluruh kelas persyaratan. Atau hanya menjadi bagian dari beberapa cerita besar.
Ringkasan
Ini adalah bagaimana kekacauan yang masuk berubah menjadi sesuatu yang indah, bermanfaat, dan dapat dimengerti oleh pengembang untuk tugas dan fungsi sistem Anda yang menyenangkan kolega Anda.