Anda dapat menulis spesifikasi teknis yang sempurna, tetapi apa gunanya jika pengembang Anda menangis?

Pemilik produk berbentuk bola sedang bekerja di galaksi yang sangat jauh. Dia menulis catatan dengan lancar di atas serbet dan diam-diam memberikannya kepada pengembang. Dan segera dia menerima produk jadi yang 100% memenuhi harapannya. Meskipun produk ini merupakan layanan lintas platform yang kompleks dengan blackjack dan kemampuan beradaptasi.



Apakah ini mungkin dalam praktiknya?



“Tidak, Saudaraku, kamu tidak akan membodohi kami! Kerangka acuan harus ditulis panjang dan cermat, ”ucap para senior berambut abu-abu itu. "TK serius!" - Jun bermulut kuning menggemakan mereka. “Istri saya meninggalkan saya karena tugas teknis yang singkat,” seorang analis bisnis berpengalaman mengakui.



Biarkan saya tidak setuju.



Menulis TK tidak harus menyita waktu. Lagipula, kerangka acuan yang baik lebih mudah ditulis daripada yang buruk. Jika Anda mengetahui beberapa trik, tentu saja. Aku akan memberitahumu tentang ini hari ini. Namun, alih-alih serbet, saya tetap merekomendasikan penggunaan confluence .

Apa yang salah?

Saya telah menulis tugas untuk pengembang selama lebih dari 11 tahun. Aplikasi, game, layanan web, sistem CRM, platform pelatihan, dan produk lain dibuat berdasarkan mereka. Selama waktu ini, saya telah beralih dari menulis dokumen desain 200 halaman menjadi kerangka acuan singkat dalam beberapa langkah. Dan, tentu saja, dia mengisi semua kemungkinan gundukan.



Tahun demi tahun, di berbagai perusahaan, saya mengamati bagaimana produk, perancang game, dan pemasar menetapkan tugas. Dan apa konsekuensi dari berbagai "fitur" desain tugas ini. Bagaimana awal sprint bergeser seminggu, mencari tahu apa yang sebenarnya diinginkan pelanggan. Karena panik, mereka memperbaiki fungsionalitas yang baru saja dituangkan ke dalam produk. Seberapa cepat skor aplikasi turun karena kasus yang tidak terhitung. Bagaimana penjualan turun dan pengguna setia pergi. Bagaimana pengembang kelelahan ketika mereka harus mengutak-atik tugas yang bermasalah.



Saya mendapat kesan bahwa terlalu banyak dari mereka yang menetapkan tugas pengembangan tidak tahu bagaimana melakukannya dengan baik . Dan pertanyaan tentang kualitas TK itu sendiri tidak menjadi fokus perhatian: mereka mengatakan, mereka menulis tugas dan norma, mereka tidak akan memahaminya, atau apa? Selain itu, selalu ada hal yang lebih menarik untuk dilakukan: mendiskusikan hipotesis baru, rapat, rehat kopi. Akibatnya, semua orang menderita - pelanggan, pengembang, dan bisnis.

Ada dua ekstrem saat menulis TK

Semakin besar produk yang Anda kerjakan, semakin tinggi biaya kesalahan dan semakin penting kualitas spesifikasi teknisnya (terima kasih, cap!). Oleh karena itu, kedua opsi tersebut tidak cocok jika Anda melakukan sesuatu yang lebih serius daripada halaman arahan. Dalam produk yang besar dan kompetitif , penulisan TK harus cepat, cerdas, rock and roll . Mari kita lihat bagaimana menuju ke sana.

,

1. 
   
   – , , . , ( ).
2. 
   
   – , . , – , . .. , , . , – , .
3. PM-
   
   – , , . «», , .
4. QA
   
   – , . user journey . , , , .
5. TK harus menyenangkan ketua tim,
   
   artinya tidak memerlukan ritual dan penjelasan khusus untuk ditransfer ke pengembangan. Misalnya, jika suatu produk telah menyelesaikan tugas teknis dan ditabrak bus tepat di sana, tepat di kantor, ini seharusnya tidak mencegah tugas teknis dibuat dengan cara terbaik.

Apakah sulit untuk memenuhi semua persyaratan ini? Tidak semuanya.



Sebaliknya, jika Anda mengingatnya, maka Anda tidak akan bisa terus terang menulis TK yang buruk. Karena semua persyaratan ini intinya hanya satu hal - menjaga orang yang berinteraksi dengan TK ini.

Format TK saya

Format ini adalah campuran yang cukup longgar dari cerita pengguna + definisi selesai .



Itu muncul sebagai hasil evolusi bertahun-tahun: setiap kali saya melihat masalah sistematis, saya mengubah format TK saya sehingga masalah ini tidak akan muncul di masa mendatang. Hasilnya adalah format yang singkat dan bersih secara visual yang bahkan dapat dengan mudah diambil oleh bulan Juni. Plus, ini memenuhi persyaratan yang dijelaskan di atas.



Seperti inilah tipikal cerita di TK saya:







Dan betapapun besar dan kompleksnya produk yang kami kembangkan, TK mana pun akan terdiri dari cerita-cerita sederhana (jumlahnya hanya akan bertambah).





Penting: story tidak boleh mendeskripsikan fungsionalitas yang terlalu besar (misalnya, beberapa layar) atau terlalu kecil (misalnya, satu tombol). Biasanya, satu cerita adalah satu fitur atau mekanik produk. Misalnya, sebuah cerita dapat sepenuhnya menggambarkan pendaftaran pengguna baru. Untuk mengatur tugas tata letak halaman arahan baru, sebagai aturan, satu cerita juga cukup bagi saya.



Jika spesifikasi teknisnya besar dan signifikan, maka sebelum daftar cerita saya tulis secara singkat: mengapa kami melakukannya dan hasil apa yang ingin kami capai . Begitulah pengembang memiliki gambaran besar.

Secara umum, ternyata seperti ini:

Contoh

Oke, untuk memahami cara kerjanya - mari kita pecahkan produk menjadi cerita semacam itu. Misalnya, kami memutuskan untuk membuat aplikasi bernama "neural boot". Di dalamnya, neural network akan melakukan percakapan intim dengan produk yang belum sempat sehari (dan tidak punya teman).



Untuk mempermudah, kita asumsikan bahwa kita sudah memiliki jaringan saraf yang terlatih dan kita perlu membuat antarmuka untuk itu dalam bentuk aplikasi.



Kemungkinan, TK terdiri dari baris-baris berikut:

1. Otorisasi pengguna
2. Profil pengguna
3. Layar komunikasi dengan neuroboot
4. Layar "Katalog Neuroboot"
5. Profil dan layar pengaturan
6. Popup pembayaran
7. Koneksi Analytics

Tetap melukis setiap cerita (dalam format di atas) dan mengirimkannya ke pengembangan. Sudah kubilang itu akan mudah.

---

Peretasan hidup yang rumit

Ada sejumlah teknik yang membantu saya mengerjakan produk setiap hari. Berikut adalah yang berhubungan dengan menulis kerangka acuan.

Retasan hidup # 1: Detail secara berulang

Sekarang saya tidak menulis spesifikasi teknis sama sekali - mereka sendiri, di latar belakang, muncul dalam proses kerja. Saat tugas baru muncul, saya langsung mencari tahu: subtugas apa yang diperlukan untuk melakukan ini? Dan kemudian saya memperbaiki setiap subtugas dalam format cerita (hanya namanya, detailnya akan datang nanti).



Jadi, saya segera memiliki kerangka acuan umum yang siap. Tetap hanya untuk merinci ceritanya sejauh mungkin memberikan tugas teknis untuk pengembangan.



Detailing juga terjadi di latar belakang: saat saya meneliti dan memikirkan detailnya, saya segera membuat catatan di dalam baris yang sesuai. Alih-alih desain, saya memasukkan prototipe dari NinjaMock .



Pendekatan ini secara signifikan mempercepat pekerjaan. Plus, ini memungkinkan Anda untuk tidak melewatkan gambaran besar dan tidak menggali detail sebelumnya.

Retasan hidup # 2: Tidak bekerja dengan jin

Ada film lama di mana jin memenuhi keinginan dengan cara yang paling menyebalkan.



Tentu saja, pengembang yang waras tidak akan secara spesifik mencari peluang untuk menyakiti. Tapi terkadang orang tidak peduli apa yang mereka kerjakan. Kemudian mereka melakukan tugas "seperti yang tertulis", tidak benar-benar menyelidiki mengapa itu diperlukan. Secara berkala, ini akan menghasilkan file besar dan kecil. Ya, produksi meletakkan ... tetapi tidak ada yang menulis dalam tugas apa yang perlu diperiksa - apakah penerapan seperti itu akan merusak yang lainnya.



Saya tidak akan mengatakan tentang outsourcing, tetapi pendekatan ini tidak dapat diterima di produk. Pengembang yang baik sedang membangun kuil, bukan hanya memasang batu bata. Artinya, dia melihat gambaran besarnya dan menyelidiki apa yang terjadi. Orang-orang seperti itu sering menawarkan solusi alternatif dan memperingatkan tentang jebakan sendiri.



Oleh karena itu, jika Anda ingin TK Anda dilakukan dengan sebaik mungkin, maka terkadang Anda perlu meningkatkan bukan TK, tetapi budaya pengembangan dalam tim. Secara umum, ini adalah tugas PM, tetapi produk juga dapat mempengaruhi situasi. Terutama jika tim mempercayainya (misalnya, berkat spesifikasi teknis yang dirancang dengan baik dan cermat).

Lifehack # 3: Pisahkan TK dari dokumentasi

Kerangka acuan menjawab pertanyaan "apa yang perlu dilakukan?" Dan dokumentasi - untuk pertanyaan "bagaimana cara melakukannya / bagaimana cara kerjanya?" TK ditulis sebelum pelaksanaan tugas, dan dokumentasi ditulis setelahnya.



Jika saya perlu menata ulang kabinet, saya akan menulis tugas dengan semangat “mengatur ulang dari sini -> di sini”. Tetapi saya tidak akan menggambar denah arsitektur rumah yang memiliki lemari pakaian.



Adakalanya ada anggapan bahwa TK harus ditulis sedemikian rupa , pada saat yang sama, dan dokumentasi . Ini adalah teori yang merusak. Dokumentasi lengkap tetap tidak akan berfungsi, karena tidak diketahui sebelumnya bagaimana tepatnya kerangka acuan tersebut akan diterapkan. Selain itu, pengembang membutuhkan ruang untuk bermanuver, yang tidak disediakan oleh dokumentasi. Dan yang utama adalah menulis TK seperti itu berkali-kali lebih lama dan itu akan menjadi tidak praktis.



Ada produk berbeda dan startup berbeda. Seseorang dapat melakukannya tanpa dokumentasi sama sekali. Tetapi jika Anda masih membutuhkan dokumentasi, pekerjakan bulan Juni yang akan menjelaskan fungsionalitas secara detail setelah penerapannya. Anda tidak memerlukan keahlian khusus untuk mendeskripsikan fungsi yang ada, tetapi Anda akan menghemat waktu dan tenaga untuk karyawan yang terampil - pengembang dan pengembang produk.

Retasan hidup # 4: Belajar program

Pengamatan murni empiris: Produk yang mengetahui cara memprogram lebih baik dalam merumuskan tugas. Selain itu, tidak perlu menjadi operator backend senior, cukup menguasai bahasa pemrograman apa pun dan memahami esensi dari pemikiran algoritmik.



Pada suatu waktu saya masih membuat kode yang tidak terkendali pada Spectrum chthonic , dan di tahun-tahun murid saya, saya bahkan harus menulis driver di Assembler. Artinya, saya terbiasa dengan pemrograman secara langsung - dan ini, tentu saja, membantu menemukan bahasa yang sama dengan developer.

Retasan hidup # 5: Banyak berpikir, sedikit menulis

Masalah terbesar selalu muncul dengan tugas-tugas yang tidak sepenuhnya dipahami oleh pelanggan itu sendiri. Misalnya dia butuh report baru di admin area, tapi dia kurang paham bagaimana report ini akan dibuat. Seperti, Anda para programmer akan mengetahuinya. Tidak, tidak seperti itu.



Satu-satunya cara untuk menulis masalah bagus yang diselesaikan dengan benar adalah dengan memahami. Idealnya, cukup pahami masalahnya sehingga Anda bisa melakukannya sendiri ... jika Anda tahu cara membuat program.



Tetapi ketika Anda mengetahuinya - Anda tidak perlu membuang semua informasi yang ditemukan di TK. Ini hanyalah pemahaman mendalam tentang tugas yang memungkinkan Anda untuk membuang hal-hal yang tidak perlu dan hanya menulis yang penting.

---

PS TK adalah sarana, bukan tujuan. Oleh karena itu, terkadang TK terbaik adalah ketidakhadirannya. Suatu hari nanti saya akan memberi tahu Anda bagaimana saya meluncurkan beberapa produk tanpa spesifikasi teknis sama sekali.



PPS Jika Anda memiliki format kerangka acuan atau life hack Anda sendiri saat menulisnya - silakan bagikan di komentar.