Halo, Habr!
Hari ini kami ingin berbicara tentang bagaimana tim produk kami mendekati persiapan persyaratan fungsional untuk pengembang ketika membuat produk dan fitur baru.
Pada tahap pengembangan, banyak kejutan mungkin muncul, terutama jika tugas tersebut tidak dijelaskan dengan jelas. Anggota tim yang berbeda dapat memahami pengembangan dan berfungsinya fitur yang sama dengan cara yang berbeda, sehingga manajer produk bertanggung jawab untuk menciptakan produk mulai dari pengembangan konsep hingga rilis final. Dan bagian penting dari proses ini adalah persiapan persyaratan fungsional.
Pertanyaan tentang menggambarkan tugas untuk pengembang yang telah kita bahas dalam artikel
Cara Manajer Belajar Mengatur Tugas untuk Pengembang , tetapi di dalamnya kita berbicara lebih banyak tentang masalah administrasi, dan hari ini kita akan berbicara lebih banyak tentang masalah teknis. Ini adalah komponen yang sangat penting dari setiap bisnis yang penjualannya melalui Internet. Setiap perusahaan yang aktif berkembang di lingkungan internet, pada kenyataannya, berubah menjadi bisnis perangkat lunak. Tetapi meskipun demikian, kompetensi di bidang manajemen kebutuhan cenderung tumbuh sangat lambat.
Akibatnya, kita sering melihat gambaran yang sama: tugas-tugas dari berbagai departemen terus-menerus jatuh ke dalam departemen pengembangan, persyaratan dalam tugas-tugas ini dijelaskan secara samar-samar, dan segera setelah sesuatu dilaksanakan, segera kembali untuk revisi (karena direktur tidak sepenuhnya menggambarkan apa yang saya inginkan, dan pengembang melakukan sesuai keinginannya). Hasilnya jelas: tenggat waktu yang tidak dapat diprediksi untuk tugas-tugas yang dapat memakan waktu berbulan-bulan, tim yang terdemotivasi, ketegangan dalam tim, pelanggan yang tidak puas, tertinggal dari pesaing, dan sebagainya.
Dengan artikel ini kami ingin memberikan resep sederhana yang akan meletakkan dasar untuk menyelesaikan masalah seperti itu. Hal ini dapat direkomendasikan untuk dipelajari (apalagi, untuk tindakan) dengan aman bagi semua orang yang menetapkan tugas.
Perusahaan yang berbeda memiliki pendekatan yang berbeda untuk menulis persyaratan fungsional, tetapi di
Retail Rocket kami memilih opsi ini dan sejauh ini tidak menyesal.
Persyaratan fungsional: apa itu dan mengapa mereka dibutuhkan
Pertama, mari kita lihat persyaratan fungsional apa.
Persyaratan fungsional - ini adalah pernyataan masalah kepada pengembang. Segala sesuatu yang tidak ditunjukkan dalam persyaratan dilakukan atas kebijakan pengembang, yang sering menyimpang dari presentasi manajer produk tentang hasil yang diharapkan. Oleh karena itu, persyaratan harus berisi jawaban atas semua pertanyaan yang mungkin pada tugas tersebut.
Persyaratan fungsional biasanya terdiri dari:
- Kisah pengguna - menunjukkan apa yang Anda harapkan dari tim pengembangan
- Use cases - tampilkan skenario penggunaan
- Wireframes - alat visualisasi untuk ide Anda
Hari ini kita akan fokus pada kisah Pengguna dan kasus Penggunaan.
Kisah pengguna
Kisah pengguna menggambarkan apa yang dilakukan pengguna dalam peran tertentu untuk mencapai hasil, dan apa yang perlu dilakukan pengembang untuk menghidupkan tugas ini.
Biasanya, templat digunakan:
Sebagai <an Nama Peran>, saya ingin <Tujuan, Tindakan>, sehingga <Hasil yang Diharapkan>, untuk melakukan <Apa yang Harus Dilakukan Pengembang>Ada berbagai contoh penerapan metodologi ini. Misalnya, ini cara
kerjanya di Trello:
Di Retail Rocket, kami membuat Cerita Pengguna di Google Documents menggunakan tabel. Ini membantu menyederhanakan proses komunikasi antara tim yang berbeda, karena semua orang dapat meninggalkan komentar dan memberikan umpan balik.
Misalnya, seperti inilah tugas pelacakan NPS untuk toko online:
Berkat visualisasi interaksi tersebut, tugas pengguna dengan lancar dan logis masuk ke tugas untuk pengembang. Kemudian datang pergantian kasus penggunaan.
Gunakan kasing
Use cases menggambarkan perilaku pengguna langkah demi langkah ketika berinteraksi dengan produk yang dikembangkan.
Tugas pengguna adalah apa yang dilakukan pengguna untuk mencapai tujuan jangka pendek.
Jika pengguna memecahkan masalah pada halaman yang dikembangkan dalam beberapa cara, maka setiap solusi harus memiliki use case-nya sendiri tertulis. Misalnya, jika akses ke fungsionalitas yang terpengaruh terletak di beberapa halaman, Anda perlu menulis use case terpisah untuk setiap cara pengguna beralih ke fungsional.
Mari kita lihat contoh fitur kami yang baru dirilis -
Galeri gambar dan font untuk surat massal.
Tujuan pengguna adalah menyimpan gambar di platform kami dan menggunakannya untuk membuat kampanye email.
Tugas Pengguna:
- Unggah gambar
- Sematkan gambar dalam templat surat
- Hapus gambar
Untuk setiap tugas Anda perlu menulis kasus penggunaan Anda sendiri - deskripsi tentang bagaimana pengguna berinteraksi dengan antarmuka.
Contoh kasus penggunaan:Unggah gambar:
- Log Pemasar Email Ke Akun Rocket Eceran Pribadi Anda
- Pemasar Email Membuka Bagian Galeri
- Pemasar email mengunggah gambar melalui drag & drop atau dengan mengklik tombol “Select Files”
- Gambar diunggah
- Pengguna melihat pemberitahuan tentang keberhasilan unggahan gambar
Hapus gambar:
- Pengguna mengklik gambar
- Gambar menonjol
- Seleksi dapat dihapus dengan mengklik area di luar gambar yang dipilih.
- Pengguna mengklik ikon tiga titik
- Menu konteks muncul.
- Pengguna memilih tautan "Hapus file" di dalamnya. Jika beberapa gambar dipilih, maka semua akan dihapus.
- Gambar dihapus
Semua skenario penggunaan dilukis dengan cara yang sama, yang memberikan pengembangan pemahaman yang jelas tentang bagaimana interaksi pengguna dengan produk atau fitur terlihat, dan apa yang perlu dilakukan untuk ini.
Mengapa persyaratan fungsional sangat penting
Dengan menggunakan format persyaratan fungsional ini, Anda memberikan instruksi yang jelas kepada tim pengembangan. Selain itu, Anda dapat menunjukkan bagaimana antarmuka terlihat dari sisi klien dan bagaimana ia menyelesaikan tugasnya. Pendekatan ini membantu mempresentasikan ide Anda dan menghindari kesalahpahaman dalam tim.
Biasanya, perumusan masalah untuk pengembang memberi mereka banyak pertanyaan, jawaban yang tergantung pada kompleksitas dan waktu implementasi. Untuk memperjelas detailnya, mereka harus menghabiskan waktu untuk komunikasi alih-alih pekerjaan langsung mereka - menciptakan fitur-fitur keren dan meningkatkan produk. Dan bahkan dalam proses komunikasi, semua seluk-beluk tidak selalu diklarifikasi jika direktur tugas hanya menjawab pertanyaan yang muncul, tetapi pengguna tidak pergi jalan sendiri.
Ambil contoh galeri kami. Jika manajer produk baru saja datang dengan tugas membuat galeri, pada satu titik tentang penghapusan file, pengembang harus mengklarifikasi:
- Apakah saya perlu menghapus file sama sekali?
- Apakah ini akan menjadi penghapusan manual atau apakah file terlama akan secara otomatis dihapus ketika yang baru diunduh, jika batas penyimpanan terlampaui?
- adalah penghapusan dari daftar file atau Anda perlu membuka file
- Apakah file dihapus secara permanen atau ada keranjang untuk file di mana mereka disimpan selama beberapa waktu? jika Anda membutuhkan keranjang, berapa banyak file yang disimpan di dalamnya?
- haruskah ada penghapusan file batch atau hanya satu yang bisa dihapus?
- file dihapus menggunakan ikon terpisah (seperti apa ikon ini?) atau melalui item menu (apa namanya? di mana ia berada dalam daftar tindakan?)
- dll.
Lagi pula, ini hanyalah salah satu poin dari tugas ini, dan sudah ada begitu banyak pertanyaan. Dan mencari tahu masing-masing membutuhkan waktu dan usaha di kedua sisi.
Persyaratan fungsional membantu manajer produk untuk memikirkan dan merumuskan dengan jelas semua skenario interaksi pengguna dari antarmuka dalam tugas tersebut.
Semakin tepat tugas diajukan dan semakin banyak rincian yang dimiliki pengembang sebelum memulai pekerjaan, semakin efisien pekerjaan tersebut. Tidak ada waktu yang terbuang untuk komunikasi yang panjang dan terkadang tidak berarti. Dalam hal ini, semua pihak mendapat manfaat: pengembang mendapatkan pemahaman yang jelas tentang apa dan bagaimana melakukannya, dan pemberi tugas menyelesaikan pekerjaan persis dalam bentuk yang ia bayangkan.
Dan bagaimana Anda mendekati rumusan tugas untuk pengembang?
Direktur Produk Gulfiya Kurmangaleeva