Pengumpulan Keperluan yang Tidak Berubah di Tengah Pembinaan

Dua hari sebelum pelancaran. Papan pemuka sudah siap dibina, diuji, dan diatur untuk demo Isnin. Kemudian e-mel itu tiba: "Hei, boleh tambah satu lagi benda? Kita perlukan juga pecahan mengikut wilayah. Dan mungkin mengikut tempoh perkhidmatan. Oh, dan CFO tadi sebut mahu pandangan YoY." Anda menatap skrin. Anda telah menulis dokumen keperluan. Anda telah menjalankan kickoff. Anda telah menghantar nota mesyuarat. Tiada satu pun daripada itu menghalang permintaan ini, kerana tiada satu pun daripadanya adalah artifak yang mencegah perubahan skop.

Atas kertas, ini adalah kesalahan BA. Anda terlepas keperluan. Anda tidak bertanya soalan yang betul. Anda sepatutnya tahu CFO akan mengambil berat tentang YoY. Kejuruteraan membina semula carta yang sama untuk kali ketiga dalam dua minggu. Pihak berkepentingan secara senyap menurunkan darjat anda dari "rakan kongsi yang dipercayai" kepada "pemproses tiket." Anda mula menambah 40% pada setiap anggaran hanya untuk menyerap pergolakan yang tidak dapat dielakkan.

Penyelesaiannya bukan lebih banyak dokumentasi. Ia adalah dokumentasi yang berbeza, ditulis dalam 90 minit pertama, ditandatangani sebelum satu tiket pun dipotong. Satu halaman masuk, satu halaman keluar, bertarikh, bernama, dan di-e-mel kepada seseorang yang mempunyai kuasa untuk berkata ya. Segala-galanya yang lain adalah persembahan semata-mata.

Inilah Playbook yang saya jalankan pada setiap permintaan dalaman sekarang: papan pemuka, analitik, alat dalaman, analisis ad hoc. Ia mengambil masa 90 minit untuk dilakukan dengan betul. Ia menjimatkan 2 hingga 3 minggu pembinaan semula setiap projek. Matematiknya tidak halus.

Borang Permohonan: Satu Halaman, Lima Kotak

Borang permohonan adalah satu halaman. Bukan lima. Bukan lapan. Satu. Jika ia tumpah ke halaman kedua, anda membiarkan peminta menyembunyikan pemikiran yang kabur di sebalik dinding teks. Lima kotak. Jika mana-mana daripada lima itu kosong, projek tidak dimulakan. Itu bukan panduan. Itulah peraturannya.

Kotak 1: Masalah. Apa yang rosak sekarang? Bukan "kita perlukan papan pemuka." Itu adalah penyelesaian. Masalahnya ialah "ketua CS menghabiskan 4 jam setiap Isnin membina laporan kadar peralihan pelanggan dari tiga fail CSV dan angkanya bercanggah dengan Salesforce." Jika peminta menjawab "kita perlukan papan pemuka" lagi, tanya: apa yang papan pemuka itu membolehkan anda berhenti lakukan? Terus tanya sehingga kata kerjanya adalah dihapuskan, bukan ditambah.

Kotak 2: Keputusan yang Output Akan Maklumkan. Setiap papan pemuka, setiap laporan, setiap analisis wujud untuk memaklumkan sebuah keputusan. Tulis keputusan itu. "Sama ada perlu kembangkan pasukan SDR kepada 12 atau 8 wakil pada suku hadapan." "Sama ada perlu tamatkan pelan warisan." "Sama ada perlu alihkan bajet pemasaran dari media berbayar kepada acara." Jika peminta tidak dapat menamakan satu keputusan spesifik, permintaan itu adalah hiasan, bukan sokongan keputusan. Kotak 2 adalah pembunuh perluasan skop yang paling bersih dalam borang.

Kotak 3: Metrik Kejayaan. Bagaimana kita akan tahu ini berjaya, enam minggu dari sekarang? Bukan "orang menggunakannya." Bukan "ia berguna." Hasil yang boleh diukur: "Masa laporan CS Isnin turun dari 4 jam kepada bawah 30 minit." "Keputusan penamatan dibuat menjelang akhir Q2 dengan rasional yang didokumentasikan." "Memorandum pengagihan semula bajet pemasaran merujuk analisis ini." Kotak 3 adalah apa yang anda semak dalam pengesahan selepas penghantaran. Jika ia kabur di sini, ia tidak boleh diukur kemudian, dan projek secara senyap masuk ke perkuburan "adakah ini pernah penting?"

Kotak 4: Dalam Skop. Spesifik, berbullet, terhad. "Kadar peralihan pelanggan mengikut bulan, mengikut peringkat pelan, mengikut kohort pendaftaran. Ditapis untuk 12 bulan lepas. Dimuat semula setiap hari." Lima hingga lapan bullet maksimum. Jika anda mempunyai 14 bullet, anda bukan mengukur skop sebuah papan pemuka, anda mengukur skop sebuah platform.

Kotak 5: Luar Skop. Inilah kotak yang semua orang terlupa. Senaraikan, secara eksplisit, apa yang tidak anda bina. "Bukan pecahan mengikut wilayah. Bukan mengikut wakil jualan. Bukan sejarah melebihi 12 bulan. Bukan masa nyata. Bukan boleh dieksport ke Excel." Luar skop adalah satu kotak yang memberi pulangan sepuluh kali ganda. Apabila peminta kembali pada minggu ketiga meminta pecahan wilayah, anda menunjuk kepada Kotak 5. Mereka yang menamakannya. Mereka yang menandatanganinya. Perbualan itu singkat, berasas fakta, dan tidak emosional.

Jika mana-mana daripada lima kotak ini kosong atau tidak jelas, tolak projek itu. Dengan sopan. "Saya tidak dapat mulakan sehingga saya mendapat jawapan spesifik untuk Kotak 2. Keputusan apa yang ini akan maklumkan? Boleh kita tempah 30 minit untuk menyelesaikannya?" Menolak bukanlah kurang sopan. Memulakan permintaan yang kabur dan kemudian "terlepas" keperluan dua minggu kemudian adalah tidak sopan.

Soalan "Apa yang Akan Anda Lakukan dengan Jawapannya"

Ini adalah soalan paling berguna dalam kerja BA, dan hampir tiada sesiapa yang menanyakannya.

Senarionya: peminta mahukan papan pemuka yang menunjukkan skor kesihatan pelanggan. Anda bertanya, dengan tenang, "Jika skor untuk Pelanggan X ialah 72, apa yang akan anda lakukan? Bagaimana jika 45? Bagaimana jika 88?" Tiga perkara berlaku.

Jika mereka boleh menjawab dengan jelas ("Di atas 80, tiada tindakan. 60-80, CSM menempah semakan. Di bawah 60, ia pergi ke giliran pengekalan"), anda mempunyai keperluan yang sebenar. Angka-angka itu dipetakan kepada tindakan. Papan pemuka itu adalah sokongan keputusan.

Jika mereka ragu-ragu, kemudian berkata "kita akan melihat tren" atau "bergantung" atau "kita akan bincangkan dalam mesyuarat mingguan," anda mempunyai keperluan hiasan. Mereka mahu angka itu wujud, bukan kerana ia mengubah tingkah laku, tetapi kerana ia terasa bertanggungjawab untuk dijejaki. Keperluan hiasan adalah 60-70% daripada permintaan dalaman, berdasarkan pengalaman saya. Bina ia dan ia akan tersimpan tidak digunakan selama enam bulan.

Jika mereka melenting dan berkata "kita akan tahu apabila melihatnya," anda mempunyai keperluan berdasarkan perasaan. Lebih buruk daripada hiasan, kerana peminta percaya perasaan mereka adalah spesifikasi. Keperluan berdasarkan perasaan berubah setiap hari kerana ia tidak pernah menjadi spesifikasi dari awal.

Skrip untuk mengemukakan soalan tanpa kelihatan konfrontatif adalah penting. Jangan kata "adakah ini berguna?" Kata: "Saya ingin memastikan saya membina perkara yang betul. Ceritakan kepada saya apa yang akan anda lakukan pada suatu Isnin pagi jika anda membuka ini dan angkanya ialah [X]. Kemudian ceritakan perkara yang sama jika angkanya ialah [Y]." Anda membingkainya sebagai masalah anda ("Saya ingin membina perkara yang betul"), bukan sebagai soal siasat. Peminta biasanya menjawab dengan jujur kerana mereka tidak sedar bahawa mereka sedang mendedahkan sama ada keperluan itu sebenar atau hiasan.

Jika jawapannya adalah hiasan atau perasaan, anda mempunyai tiga pilihan. Pilihan satu: undur diri dengan sopan, dengan alasan kapasiti. Pilihan dua: bina versi yang lebih kecil dan lebih murah (query SQL yang boleh mereka jalankan, bukan papan pemuka penuh) dan semak semula dalam sebulan. Pilihan tiga: adakan perbualan terus terang tentang sama ada soalan yang lebih dalam adalah "kita belum tahu cara menguruskan perkara ini lagi," yang merupakan masalah penemuan, bukan masalah papan pemuka, dan mungkin memerlukan sejam dengan penganalisis, bukan satu sprint kejuruteraan.

Prototaip Dahulu Apabila Boleh

Sebelum mana-mana SQL ditulis. Sebelum mana-mana tiket dipotong. Lakarkan papan pemuka itu.

Figma berfungsi. Google Sheets sebenarnya lebih baik, kerana ia membolehkan anda memalsukan data dan peminta boleh melihatnya seperti mereka akan melihat perkara sebenar. PowerPoint dengan segi empat tepat berfungsi dalam keadaan terdesak. Tujuannya bukan alat. Tujuannya adalah untuk meletakkan gambar jawapan di hadapan peminta sebelum anda melibatkan mana-mana jam kejuruteraan.

Ujicuba 30 minit menghapuskan kira-kira 80% kerja semula yang sepatutnya berlaku semasa pembinaan. Angka itu tidak tepat. Itulah yang saya lihat merentasi mungkin 60 projek dalaman dalam beberapa tahun kebelakangan ini. Kadang-kala ia 95%. Kadang-kala 60%. Ia tidak pernah di bawah 50%.

Apa yang berlaku dalam semakan prototaip adalah peminta akhirnya melihat secara konkrit apa yang mereka minta dan menyedari salah satu daripada tiga perkara. (a) "Oh, saya sebenarnya perlukan baris diatur dengan cara lain." (b) "Saya fikir saya mahu carta bar tetapi carta garis dengan purata bergerak 4 minggu adalah apa yang sebenarnya saya cari." (c) "Ini tidak menjawab soalan saya. Saya perlu melihat pecahan mengikut [perkara yang tidak ada dalam permintaan asal]." Ketiga-tiga penemuan itu adalah percuma dalam mock Google Sheet. Ia mahal dalam papan pemuka yang telah siap dibina.

Prototaip dahulu tidak terpakai untuk semua perkara. Perubahan backend, kerja integrasi, pembersihan saluran data, migrasi skema: tiada mock berguna selama 30 minit untuk "kita perlu gabungkan dua jadual pelanggan." Apabila prototaip dahulu tidak terpakai, penggantinya adalah contoh output bertulis: "Inilah baris data yang anda akan dapat balik dari integrasi ini. Inilah empat medannya. Inilah maksud setiap medan dalam bahasa biasa." Contoh bertulis adalah setara prototaip untuk kerja backend. Tujuan yang sama: dedahkan salah faham dengan murah.

Pengesahan Keperluan: Bertulis, Bertarikh, Bernama

Ini adalah perenggan paling penting dalam seluruh Playbook ini.

Pengesahan adalah artifak. Bukan dokumen. Bukan mesyuarat. Bukan thread Slack. E-mel dengan ringkasan satu halaman dilampirkan, dihantar kepada peminta dan pengurus mereka, meminta balasan bertulis yang menyatakan "diluluskan." E-mel itu, dengan cap tarikh dan balasan tersebut, adalah satu-satunya perkara yang berdiri antara anda dan perluasan skop.

Mekanik: tulis ringkasan satu halaman lima kotak. Hantar melalui e-mel (bukan Slack, bukan Teams, bukan komen dalam Jira) kepada peminta dan pengurus langsung mereka. Badan e-mel berkata: "Berdasarkan perbualan permohonan kita pada [tarikh], inilah ringkasan apa yang kita bina, keputusan yang ia maklumkan, metrik kejayaan, apa yang dalam skop, dan apa yang secara eksplisit di luar skop. Sila balas 'diluluskan' untuk meneruskan. Kerja kejuruteraan bermula setelah kelulusan diterima."

Dua sebab untuk CC pengurus. Pertama, pengurus biasanya adalah orang yang mempunyai kuasa bajet dan orang yang akan ditanya "ke mana perginya jam kejuruteraan?" jika skop berubah. Mereka perlu melihat permintaan asal. Kedua, pengurus juga adalah orang yang paling mungkin menambah skop semasa pembinaan ("hei, sambil itu..."), dan mempunyai mereka dalam e-mel pengesahan asal memberikan anda artifak untuk menolak balik.

Ya verbal bukan ya. Thumbs-up Slack bukan ya. "Kedengaran bagus" dalam mesyuarat bukan ya. Balas-dengan-diluluskan dalam e-mel, bertarikh, dengan peminta dan pengurus dalam thread itu. Itulah ya. Saya telah kalah dalam hujah mengenai perluasan skop apabila saya mempunyai ya verbal dan tiada trail e-mel. Saya tidak pernah kalah satu pun apabila saya mempunyai e-mel itu.

Trail kertas bertarikh adalah satu-satunya pertahanan BA apabila skop berubah. Ayat itu tidak dramatik. Ia adalah sebab keseluruhan langkah ini wujud. Tanpanya, setiap perubahan skop yang dipertikaikan adalah pertandingan memori, dan BA sentiasa kalah pertandingan memori menentang peminta yang mempunyai pangkat organisasi yang lebih tinggi.

Menangani Perluasan Skop: Tiga Ya, Tujuh Tidak

Di tengah pembinaan, peminta mahu menambah sesuatu. Ini akan berlaku. Ia bukan tanda kegagalan. Ia adalah keadaan tetap kerja dalaman.

Terdapat tiga sebab yang sah untuk mengembangkan skop semasa pembinaan, dan tujuh yang tidak sah.

Tiga sebab yang sah (anda berkata ya, dengan garis masa baharu):

Perubahan peraturan. Keperluan pematuhan baharu telah tiba yang mempengaruhi output. Papan pemuka mesti menunjukkan medan baharu atau ia tidak boleh dihantar. Ya, dan inilah tarikh baharu.
Bug atau isu data yang menghalang. Semasa pembinaan, anda mendapati data asas adalah salah, hilang, atau bercanggah dengan cara yang menjadikan spesifikasi asal mustahil. Ya, dan kita perlu berhenti sebentar untuk membetulkan data; tarikh baharu ialah X.
Kejutan kebergantungan. Sistem hulu yang anda tidak tahu (atau yang baru sahaja berubah) bermakna pendekatan integrasi asal sudah tidak dapat digunakan. Ya, dan kita perlu reka bentuk semula bahagian itu; tarikh baharu ialah X.

Tujuh sebab yang tidak sah (anda berkata "ya, dan inilah garis masa baharu," tetapi garis masanya adalah rundingan):

"Sambil awak buat tu." Pihak berkepentingan terfikir tentang perkara baharu.
"[Orang Kanan] melihat prototaip dan mahu..." Semakan prototaip memunculkan permintaan baharu.
"Pemasaran juga mahu..." Peminta baharu sedang diselundupkan ke dalam projek asal.
"Ia akan berguna juga untuk melihat..." Perluasan hiasan.
"Kita telah tukar fikiran mengenai metrik." Kotak 3 sedang ditulis semula semasa penerbangan.
"Boleh buat ia dinamik?" Hardcoded kepada berparameter adalah pembinaan semula, bukan penyesuaian kecil.
"Satu benda kecil sahaja." Frasa ini hampir selalu merupakan petanda. Kecil untuk diminta, besar untuk dibina.

Perhatikan bahawa untuk kedua-dua yang sah dan tidak sah, jawapannya adalah "ya, dan." Jangan sekali-kali berkata "tidak." Perkataan tidak menjadikan anda seorang birokrat. Frasa "ya, dan inilah garis masa baharu" menjadikan anda rakan kongsi yang kebetulan jujur tentang kos.

Templat kawalan perubahan di bawah adalah yang menjadikan "ya, dan" boleh dikuatkuasakan. Tanpanya, "ya, dan" bertukar menjadi "ya," kerana tiada apa yang didokumentasikan dan tarikh baharu secara senyap kembali ke tarikh lama dalam fikiran peminta.

Templat Kawalan Perubahan

Lima medan. E-mel. Bertarikh. Ditandatangani.

SUBJEK: Permintaan perubahan: [nama projek] - [tarikh]

Tarikh pengesahan asal: [tarikh]
Projek: [nama]

1. APA YANG BERUBAH (satu ayat): _________________________________

2. MENGAPA (satu ayat: pautan kepada sebab yang sah atau, jika tidak, namakan pertukaran):
   _________________________________

3. KESAN TERHADAP GARIS MASA (tarikh hantar baharu dalam YYYY-MM-DD):
   Tarikh lama: _______
   Tarikh baharu: _______

4. KESAN TERHADAP PEMINTA LAIN (projek mana yang akan tertangguh, berapa lama):
   _________________________________

5. PENGESAHAN PEMINTA ATAS TARIKH BAHARU: Balas "diluluskan" untuk mengesahkan tarikh baharu.

Itulah sahaja. Lima medan. Hantar dalam masa sejam selepas permintaan perubahan skop. Peminta membalas "diluluskan" atau tidak. Jika tidak, skop asal dan tarikh asal dikekalkan.

Jangan verbal. Jangan tidak bertarikh. Jangan "kita akan serap sahaja." Menyerap skop tanpa mencatatnya adalah bagaimana BA akhirnya keletihan, dipersalahkan, dan tidak dapat menunjukkan satu saat pun apabila projek itu terkeluar dari landasan.

Pengesahan Selepas Penghantaran: Semakan Dua Minggu

Dua minggu selepas penghantaran, anda menempah 30 minit dengan peminta. Satu soalan: adakah metrik kejayaan dalam Kotak 3 benar-benar bergerak?

Jika ya, catatkan. Dua ayat dalam dokumen portfolio anda, pakej ulasan prestasi anda, penilaian diri akhir tahun anda. "Membina papan pemuka kadar peralihan pelanggan untuk pasukan CS. Masa laporan Isnin turun dari 4 jam kepada 22 minit dalam tiga minggu selepas pelancaran (sasaran: di bawah 30 minit). Keputusan: ketua CS menggunakan papan pemuka untuk mewajarkan pertambahan +2 CSM dalam perancangan Q3." Itulah jenis artifak yang mendapat kenaikan pangkat untuk BA. Bullet "hantar papan pemuka" yang kabur mendapat BA diperbaharui kontrak, bukan dinaikkan pangkat.

Jika tidak (dan inilah bahagian yang kebanyakan BA salah), itu bukan kegagalan yang perlu dikebumikan. Itu adalah penemuan kajian. Tulis laporan: "Membina papan pemuka. Dua minggu kemudian, ketua CS telah membukanya 3 kali. Masa laporan Isnin tidak berubah. Hipotesis: keputusan mendasar (CSM mana yang ditugaskan kepada akaun mana) dibuat berdasarkan hubungan, bukan data, dan papan pemuka tidak menangani kemacetan sebenar."

Laporan itu berharga. Ia adalah input kepada permohonan seterusnya. Ia adalah sebab permintaan seterusnya anda dari pasukan yang sama akan lebih tajam, kerana anda mempunyai data tentang apa yang tidak berfungsi kali lepas. Kegagalan yang dikebumikan adalah pembaziran. Kegagalan yang didedahkan terkumpul menjadi kepakaran.

Semakan dua minggu juga menutup gelung kepada peminta. Mereka berasa diikuti. Mereka lebih berkemungkinan membawa anda masalah sebenar yang seterusnya dan bukannya permintaan kabur seterusnya, kerana mereka telah belajar bahawa anda benar-benar mengambil berat tentang hasil, bukan sekadar hasil yang diserahkan.

Aliran Kerja dalam 90 Minit

Dari mula hingga akhir, kerja hadapan adalah sembilan puluh minit.

30 minit: panggilan permohonan. Telusuri lima kotak. Tanya soalan "apa yang akan anda lakukan dengan jawapannya." Catat keputusan dan metrik kejayaan.
30 minit: buat prototaip jawapan (Sheets, Figma, atau contoh output bertulis). Hantar kepada peminta. Tanya "adakah ini sesuatu yang akan anda lakukan dengan pada suatu Isnin pagi?"
30 minit: tulis e-mel pengesahan satu halaman. CC pengurus. Minta "balas dengan diluluskan." Tunggu balasan.

Jumlah: 90 minit. Selepas itu, kerja kejuruteraan bermula. Semasa pembinaan, sebarang permintaan perubahan skop mendapat borang kawalan perubahan lima medan dalam masa sejam. Dua minggu selepas penghantaran, anda menjalankan semakan pengesahan.

Sembilan puluh minit disiplin hadapan menggantikan dua hingga tiga minggu pergolakan pembinaan semula setiap projek. Ia juga menggantikan hakisan kepercayaan perlahan yang berlaku apabila pihak berkepentingan berasa setiap projek dihantar lambat dan sedikit tersasar. Kedua-dua kos adalah tidak kelihatan sehingga anda berhenti membayarnya. Sebaik sahaja anda berhenti, anda tidak akan kembali.

Dokumen itu bukan artifak. Mesyuarat itu bukan artifak. Thread Slack sudah pasti bukan artifak. E-mel bertarikh, bernama, disahkan adalah artifak. Bina keseluruhan amalan di sekitar mendapatkan satu e-mel itu, setiap kali, sebelum mana-mana kod ditulis.

Playbook Penganalisis Perniagaan