Produk dan Penyerahan Hasil · Usaha dan Kekayaan
Usaha dan Kekayaan · Produk dan Penyerahan Hasil
5 refleksi
《Sebelum menggambar prototipe, jelaskan cara penggunaan》 Mengapa semakin awal halaman digambar, proyek kadang justru semakin banyak diubah?
Langsung menggambar halaman saat proyek dimulai mudah membuat semua merasa pekerjaan bergerak. Tombol, warna, tata letak sudah ada dan mudah dibahas. Namun halaman dapat tergambar lengkap sementara apa yang hendak diselesaikan penggunanya tetap belum jelas.
Menurut saya beberapa pertanyaan perlu dijelaskan dahulu: siapa menggunakan, kapan, ke mana setelah langkah ini? Nama fitur hanya daftar isi; bagaimana fitur tersambung menentukan apakah sistem dapat digunakan. Jika pemahaman penggunaan berbeda, semakin rinci gambar, mungkin semakin banyak bagian harus dibongkar kelak.
Saat siap mendesain, jalani satu skenario konkret dahulu. Jelaskan apa yang tiap orang perlu berikan, dapat lihat, dan akhirnya peroleh. Catat ketidaksamaan pemahaman saat itu. Setelah pertanyaan kunci dipastikan, ubah menjadi halaman agar komunikasi memiliki dasar bersama.
Tentu beberapa gagasan baru terlihat setelah digambar. Saat itu buat draf kasar untuk menemukan masalah, jangan tergesa menganggapnya final. Tingkat persiapan bergantung pada masalah langkah berikutnya. Menggunakan desain untuk mengonfirmasi kebutuhan berbeda dampak dari menjadikan desain belum terkonfirmasi sebagai perintah pengembangan.
《Jangan langsung mengubah program, bedakan masalah dahulu》 Apakah keluhan sulit digunakan berarti program harus segera diubah?
‘Sulit digunakan’ dapat berarti banyak hal. Ada yang tidak tahu operasi, menemui kesalahan program, merasa alur tak lancar, atau ingin fitur baru. Jika semua dimasukkan ke satu daftar perubahan, tim segera sibuk tetapi belum tentu menyelesaikan jenis masalah sama.
Saat masalah muncul, saya cenderung membedakannya dahulu. Kurang akrab penggunaan memerlukan penjelasan atau pelatihan; fitur yang dijanjikan tak berjalan perlu diperbaiki; proses penggunaan tak masuk akal perlu pemeriksaan desain; gagasan baru memerlukan pembahasan kebutuhan ulang. Penanganan berbeda, orang terlibat dan standar selesai berbeda.
Saat mengajukan masalah, jelaskan sedapat mungkin apa yang dilakukan, diharapkan, dan sungguh terjadi. Simpan gejala yang dapat diulang, lalu minta pihak terkait mengonfirmasi. Diskusi pun bergerak dari mudah-tidaknya menuju lokasi masalah konkret, dan lebih mudah menilai apakah perubahan memengaruhi penggunaan awal.
Klasifikasi tidak menggantikan perbaikan atau menjadi alasan menunda. Kerjakan masalah yang jelas, segera periksa bagian belum jelas. Terutama jangan menyebut semua masalah sebagai pengguna tidak tahu memakai; itu hanya menghilangkan umpan balik produk. Membedakan masalah bertujuan mengurangi jalan memutar sekaligus menangani hal yang sungguh perlu diselesaikan.
《Uji sepanjang alur bisnis》 Jika setiap tombol dapat diklik, mengapa penggunaan nyata tetap bermasalah?
Fitur tunggal tampak normal, seluruh urusan tetap mungkin tak terselesaikan. Bisa mengirim data tidak berarti orang berikut menerimanya; bisa membuat pesanan tidak berarti penanganan sesudahnya tersedia. Pengujian per halaman mudah melewatkan masalah antarlaman, antarorang, dan antarstatus.
Karena itu saya lebih memperhatikan bagaimana bisnis berjalan lengkap. Dari posisi pengguna nyata, gunakan data mendekati kenyataan dan jalani awal, proses, hingga akhir. Siapa mengoperasikan, menunggu, menangani masalah, semuanya dilihat dalam satu alur. Keberadaan fitur dan penyelesaian bisnis perlu dikonfirmasi terpisah.
Pengujian juga dapat mengikuti kemajuan pengembangan. Periksa bagian selesai, sambungkan alur yang sudah dapat tersambung, catat serta sampaikan masalah. Jika baru mencoba setelah semuanya selesai, kesalahpahaman awal menumpuk di akhir; hal yang semula dapat disesuaikan tepat waktu menjadi tergesa.
Ini tidak berarti versi tak lengkap langsung boleh digunakan semua orang. Jika belum siap, gunakan data contoh dalam cakupan jelas, ketahui langkah yang belum dapat selesai. Pengujian bertahap membantu menemukan masalah lebih awal; penerimaan akhir tetap harus kembali ke kegunaan lengkap yang disepakati. Kurangi menilai dari antarmuka, perbanyak mengikuti jalannya urusan.
《Mengurangi satu fitur kadang mendekatkan peluncuran》 Mengapa kebutuhan makin lengkap tetapi proyek makin jauh dari dapat digunakan?
Saat membahas produk, gagasan sering bertambah. Setiap orang dapat menambah fitur masuk akal yang tidak tampak berlebihan dalam daftar. Namun saat dikerjakan, desain, pengembangan, pengujian, dan pemeliharaan memerlukan penanggung. Semuanya bertumpuk dan produk mungkin terus berada pada tahap kurang sedikit lagi.
Menurut saya, kembali pada masalah sekarang. Tanpa fitur ini, apakah alur utama masih dapat selesai? Apakah ia menyelesaikan masalah yang sudah muncul atau hanya yang dibayangkan mungkin muncul? Jika kegunaan utama tetap selesai tanpanya, catat dahulu dan nilai lagi setelah ada umpan balik penggunaan jelas.
Pengurangan juga harus beralasan. Beri tahu peserta apa dipertahankan, ditunda, dan mengapa. Untuk bagian selesai, daftarkan perbaikan; untuk bagian belum dibuat, daftarkan fitur yang sungguh kurang. Pisahkan keduanya agar tim tahu apakah berikutnya memperbaiki produk atau terus memperluas cakupan.
Mengerjakan lebih sedikit tidak berarti menurunkan kualitas dasar, terlebih membenarkan alur kunci tak selesai demi jadwal. Kelengkapan yang diperlukan tahap kini tetap dijaga. Memusatkan tenaga pada hal yang memengaruhi penggunaan nyata kadang lebih dekat pada hasil yang dapat diserahkan daripada terus menambah fitur yang tampak kaya.
《Memperbarui produk dimulai dari perubahan bisnis sendiri》 Jika pesaing menambah fitur, haruskah kita mengikutinya?
Melihat pesaing membuat fitur baru, mempelajarinya perlu. Namun mengapa mereka membuatnya, pengguna siapa dihadapi, bisnis apa hendak didukung belum tentu kita tahu. Jika hanya melihat tombol baru lalu tergesa menambahkannya, produk sendiri mungkin semakin menyerupai rangkuman fitur pesaing.
Menurut saya pembaruan dimulai dari proses penggunaan sendiri. Apakah bisnis berubah, masalah apa terus diajukan pelanggan, di mana alur kini tersendat? Baru lihat bagaimana produk luar menangani masalah serupa. Hasilnya adalah cara yang dapat dibandingkan, bukan nama yang wajib diikuti.
Saat membahas fitur baru, periksa hubungan dengan alur yang ada. Siapa memakai, bahan apa diperlukan, siapa terdampak setelah selesai? Jika ini belum jelas, jumlah fitur bertambah bersama kesulitan penggunaan. Memperjelas kebutuhan operasional nyata memberi arah pembaruan teknologi yang lebih stabil.
Inovasi luar tentu dapat mengingatkan kebutuhan yang belum terlihat. Coba pahami dalam skenario konkret, lalu nilai kelayakan adopsinya. Perhatikan pesaing sekaligus pertahankan pilihan sendiri. Produk perlu terus berubah, tetapi setiap perubahan sebaiknya menjawab urusan pengguna mana yang dibuat lebih baik.