Pemilikan Hujung ke Hujung: Dari Masalah hingga Hantar hingga Pelajari

Anda menghabiskan tiga minggu pada reka semula daftar keluar. Fail Figma itu bersih. Demo prototaip mendapat anggukan dari PM dan ketua jurutera. Anda menanda tiket "sedia untuk pembangunan" pada hari Khamis, melambai selamat tinggal dalam standup pagi Jumaat, dan beralih kepada ringkasan seterusnya.

Dua belas minggu kemudian anda membuka produksi untuk menunjukkan kepada rakan aliran baharu. Separuh spesifikasi anda tiada. Keadaan kosong yang anda perjuangkan dipotong pada hari ketiga sprint. Pengesahan borang berkelakuan tidak seperti prototaip. Penukaran turun 4%. Tiada siapa yang memberitahu anda, kerana setakat yang diketahui oleh pasukan, kerja anda berakhir semasa penyerahan (handoff).

Kisah itu adalah cara pereka junior menghantar. Pereka kanan tidak menghilang semasa penyerahan (handoff), kerana mereka tahu penyerahan (handoff) adalah kira-kira titik pertengahan kerja, bukan penghujungnya.

Mengapa pemilikan hujung ke hujung adalah bar pengambilan baharu

Sepuluh tahun lalu portfolio bingkai Figma yang berkilat boleh mendapatkan anda peranan kanan. Gelung pengambilan telah berubah. Baca mana-mana perihalan kerja semasa untuk Pereka Produk Kanan atau Staf dan anda akan melihat perkataan yang sama berulang: hasil. Hasil tidak tinggal dalam Figma. Mereka tinggal dalam analitik produksi, dalam jumlah tiket sokongan, dalam keluk pengekalan tiga bulan selepas pelancaran.

"Saya mereka bentuknya" adalah kisah junior. "Saya menghantar dan inilah yang kami pelajari" adalah kisah staf. Jurang antara dua ayat itulah yang dibincangkan oleh playbook ini.

JD Pereka Produk rakan menyenaraikan pemilikan hujung ke hujung sebagai kecekapan peringkat kanan atas sebab. Ia adalah tingkah laku tunggal yang memisahkan pereka yang mendapat kenaikan pangkat dari pereka yang tersangkut.

Kitaran pemilikan

Kitaran ciri sebenar mempunyai enam peringkat, dan pereka yang memiliki kerja hadir untuk semua peringkat tersebut. Kebanyakan pereka yang pernah saya temui hadir untuk dua setengah peringkat.

Inilah kitarannya, dengan artifak yang menutup setiap peringkat:

Tambahkan kesemuanya. Kitaran ciri sebenar adalah 4-8 minggu, kadang-kadang 10. Sesiapa yang memberitahu anda sebuah ciri boleh direka dan dihantar dalam seminggu sama ada berbohong tentang skop atau melangkau peringkat. Biasanya kedua-duanya.

Dua peringkat yang paling kerap dilangkau oleh pereka adalah yang pertama dan yang terakhir. Pembingkaian masalah diserahkan kepada PM. Pembelajaran digugurkan kerana ringkasan seterusnya sudah dimuatkan. Beginilah cara anda mendapat portfolio ciri yang tidak boleh anda katakan secara jujur bahawa ia berkesan.

Ringkasan masalah

Satu halaman. Siapa penggunanya, apa yang mereka cuba lakukan, apa yang menghalang mereka, seperti apa kejayaan dalam bahasa biasa. Jika anda tidak dapat menulis ringkasan masalah tanpa memetik tiket Linear PM, anda belum memahami masalah itu. Pergi tanya tiga pengguna.

Sintesis penyelidikan

Tiga hingga lima cerapan konkrit, setiap satunya dikaitkan dengan bukti. Bukan "pengguna mahu ia lebih mudah." Itu adalah harapan, bukan cerapan. "Pengguna meninggalkan pada langkah 3 kerana autolengkap alamat gagal untuk kod pos bukan AS" adalah cerapan. Ia memberitahu anda apa yang perlu direka bentuk.

Prototaip dan spesifikasi

Aliran boleh diklik beserta peraturan yang diperlukan oleh kejuruteraan untuk membinanya. Kes pinggir, keadaan ralat, keadaan kosong, keadaan pemuatan. Spesifikasi adalah tempat pereka peringkat pertengahan memotong jalan pintas dan pereka kanan mendapat gelaran mereka.

Nota keluaran dan pengesahan QA

Anda menelusuri build staging. Anda memfailkan pepijat yang anda lihat. Anda mengesahkan secara bertulis. Anda tidak hanya berkata "kelihatan bagus" dalam Slack dan bergerak.

Papan pemuka

Metrik yang anda komitkan dalam dokumen kickoff, dipetakan terhadap garis dasar, dipantau sekurang-kurangnya dua minggu selepas pelancaran. Bonus: tangkapan skrin dalam Notion anda supaya anda mempunyai resit semasa masa kenaikan pangkat.

Dokumen retro

Apa yang kami hantar berbanding spesifikasi. Apa yang berubah semasa pembinaan. Apa yang kami lakukan berbeza. Dua puluh minit menulis yang menjadi artifak paling berharga dalam kerjaya anda.

Dokumen kickoff

Kebanyakan creep skop berakar pada satu perkara: pasukan tidak pernah bersetuju tentang apa yang mereka bina sebelum mereka mula. Dokumen kickoff membaiki ini. Ia mengambil masa 90 minit untuk ditulis dan menjimatkan anda tiga minggu berhujah tentang ulasan Figma.

Dokumen kickoff yang berfungsi mempunyai lima bahagian.

1. Masalah dalam satu perenggan. Bahasa biasa, tiada jargon, ditulis supaya pekerja baharu boleh membacanya dalam 30 saat dan tahu apa yang cuba anda selesaikan.

2. RACI. Siapa yang Bertanggungjawab (melakukan kerja), Akauntabel (memutuskan), Dirujuk (mendapat input), Dimaklumkan (mendapat kemaskini). Untuk ciri tipikal:

Jika dua orang berdua-duanya fikir mereka adalah A untuk keputusan yang sama, anda akan kehilangan dua minggu untuk pertengkaran wilayah pada minggu keenam. Buangkan kekaburan itu sekarang.

3. Metrik kejayaan. Pilih satu atau dua. Tuliskan dengan nombor dan arah. "Kadar penyelesaian tugas +15% dalam masa 30 hari selepas pelancaran." "Tiket sokongan yang ditag 'daftar keluar' turun 20% dalam masa 60 hari." Jika pasukan tidak dapat bersetuju pada metrik, itu bermakna mereka tidak bersetuju tentang masalah. Jangan teruskan sehingga anda bersetuju.

4. Potongan skop yang jelas. Satu senarai, mengikut nama, perkara yang anda tidak lakukan. "Kami tidak mereka semula halaman troli dalam projek ini. Kami tidak membina edit pukal. Kami tidak menyokong Apple Pay dalam v1." Tanpa senarai ini, setiap mesyuarat menjadi mesyuarat senarai keinginan.

5. Garis masa. Tarikh kasar untuk setiap enam peringkat. Jika garis masa anda tidak termasuk "ukur" dan "pelajari," anda berkomitmen kepada projek yang tidak lengkap pada hari pertama.

Dapatkan dokumen yang diluluskan oleh PM dan ketua teknikal sebelum anda membuka Figma. Cetaknya, tampalkan ke dinding anda, rujuknya bila-bila masa seseorang cuba menambah skop.

Kekal dalam standup jurutera

Lima belas minit sehari yang memisahkan pereka yang menghantar dari pereka yang menyerah.

Anda tidak perlu berada dalam standup setiap hari selama-lamanya. Anda perlu berada dalam standup semasa sprint pembinaan untuk ciri anda. Itu biasanya dua hingga empat minggu. Hadir, dengar, pergi. Kebanyakan hari anda tidak akan berkata apa-apa.

Apa yang perlu didengar:

• "Kami tidak boleh lakukan X, jadi kami akan buat Y." Ini adalah saat spesifikasi anda berubah secara senyap. Bersuara. Jika Y baik, katakan begitu. Jika Y memusnahkan matlamat pengguna, tolak balik sekarang, bukan dalam QA.
• "Kami akan buat bahagian itu kemudian." Kemudian bermakna tidak pernah. Jika "kemudian" adalah keadaan kosong, keadaan ralat, atau keadaan pemuatan, itu adalah pengalaman untuk separuh pengguna anda. Jangan biarkan ia terlepas.
• Kes pinggir yang tiada siapa tanya anda. "Apa yang berlaku jika pengguna tidak mempunyai item?" "Bagaimana jika API tamat masa?" Jika jurutera bertanya kepada bilik, bilik sepatutnya bertanya kepada anda. Hadirlah di situ.
• Anggaran yang berganda. Jika tugas 3 hari kini menjadi tugas 8 hari, sesuatu berubah dalam spesifikasi atau pelaksanaan. Cari tahu yang mana, kerana jika ia spesifikasi, anda mungkin boleh memudahkannya.

Bila untuk diam: skop kerja orang lain, perincian pelaksanaan teknikal yang tidak menjejaskan UX, upacara perancangan sprint yang bukan tentang ciri anda. Jangan jadi pereka yang mengganggu standup.

Sikap yang berguna: fikirkan diri anda sebagai wakil pengguna dalam bilik. Jurutera menyelesaikan masalah pembinaan. PM menyelesaikan masalah keutamaan. Tiada orang lain menyelesaikan masalah pengguna melainkan anda berbuat demikian.

Semakan selepas pelancaran

Dua minggu selepas pelancaran, jalankan semakan 30 minit. Bukan tiga bulan. Bukan "apabila ada masa." Dua minggu. Sekat jemputan kalendar pada hari anda menghantar.

Tiga lajur pada dokumen:

Bawa pasukan melaluinya. Jujurlah. Jika keadaan kosong dipotong dan anda menyesal, katakan begitu. Jika metrik bergerak kurang dari yang diharapkan, namakannya. Tujuannya bukan untuk menyalahkan. Tujuannya untuk memastikan pasukan belajar pelajaran yang sama pada masa yang sama.

Kemudian kongsi dokumen itu secara terbuka dalam saluran reka bentuk. Ya, secara terbuka. Dua sebab. Pertama, rakan sejawat anda belajar dari kerja anda. Kedua, ia memaksa tahap kejujuran intelektual yang tidak pernah dicapai oleh dokumen peribadi. Pereka yang menulis retro secara terbuka mendapat kenaikan pangkat lebih cepat, kerana seluruh organisasi mula melihat mereka sebagai seseorang yang berfikir dengan teliti tentang kraf mereka.

Perangkap "reka bentuk selesai semasa penyerahan (handoff)"

Namakan diagnosis: jurang penyerahan (handoff). Ia adalah ruang antara eksport Figma dan penerapan produksi di mana kira-kira 40% niat reka bentuk secara senyap hilang. Keadaan kosong dipotong untuk masa. Animasi digugurkan untuk prestasi. Salinan ditulis semula oleh seseorang yang tidak membaca spesifikasi. Kes pinggir dihantar dengan tingkah laku lalai kerana spesifikasi tidak menutupnya dengan cukup jelas.

Gejala anda terperangkap dalam perangkap:

• Anda tidak dapat memberitahu, dengan melihat produksi, versi spesifikasi mana yang sebenarnya dihantar
• Anda mendengar tentang isu UX dari sokongan sebelum anda menyedarinya sendiri
• Tangkapan skrin portfolio anda adalah fail Figma, bukan rakaman skrin produksi
• Anda beralih dari ciri ke ciri tanpa metrik yang dikaitkan dengan nama anda

Punca utama: pasukan menganggap penyerahan (handoff) sebagai pemindahan pemilikan. Fail berpindah dari pereka ke jurutera, dan pemilikan ikut serta. Ini salah. Penyerahan (handoff) adalah pemindahan pelaksanaan. Pemilikan kekal dengan anda.

Pembetulan: tulis semula definisi selesai anda sendiri. Selesai bukan "Figma diluluskan." Selesai adalah "metrik dalam dokumen kickoff mempunyai bacaan 14 hari selepas pelancaran dan retro diterbitkan." Definisi itu secara semula jadi menarik anda melalui sprint pembinaan, pengesahan QA, dan peringkat ukur-dan-pelajari.

Beritahu pengurus anda. Beritahu PM anda. Beritahu ketua teknikal anda. Kali pertama anda berkata "saya akan menutup gelung dua minggu selepas pelancaran," anda akan berasa janggal. Menjelang ciri ketiga ia akan menjadi reputasi anda.

Menjejak kadar penghantaran anda sendiri

Bina hamparan peribadi. Lima lajur sudah cukup.

Semak setiap suku. Tiga perkara untuk dilihat:

Kadar penghantaran. Berapa banyak ciri yang anda mulakan berbanding berapa banyak yang sebenarnya dihantar. Jika anda memulakan enam dan menghantar dua, itu adalah masalah dalam skop atau kickoff, bukan dalam kemahiran reka bentuk anda. Bawa ke 1:1 anda.

Kadar digunakan. Berapa banyak ciri yang dihantar sebenarnya menggerakkan metrik yang anda komitkan. Jika anda menghantar enam dan tiga menggerakkan metrik, itu adalah tahun yang kukuh. Jika anda menghantar enam dan sifar menggerakkan metrik, soalan yang perlu ditanya adalah sama ada anda memilih masalah yang salah atau mereka bentuk penyelesaian yang salah.

Kadar pembelajaran. Berapa banyak daripada ciri-ciri ini menjana cerapan yang didokumentasikan yang boleh anda bawa ke yang seterusnya. Ini adalah faedah berganda kerjaya reka bentuk. Dua cerapan suku tahun selama sepuluh tahun adalah apa yang dibawa oleh Pereka Staf ke meja.

Hamparan ini adalah pakej kenaikan pangkat anda. Apabila pengurus anda bertanya mengapa anda patut dinaikkan pangkat, anda tidak berkata "saya bekerja keras." Anda buka lembaran. Anda telusuri ciri-cirinya. Anda tunjuk metrik. Anda namakan cerapan yang memaklumkan kerja anda seterusnya. Kenaikan pangkat menjadi perbualan tentang bukti, bukan perdebatan tentang persepsi.

Perangkap biasa

Melangkau dokumen kickoff kerana ia terasa seperti beban kerja. Dokumen itu mengambil masa 90 minit. Creep skop yang anda elakkan mengambil berminggu-minggu. Sentiasa buat dokumen.

Menghilang semasa pembinaan jurutera kerana standup terasa membosankan. Ia memang membosankan kebanyakan hari. Dua hari setiap sprint di mana ia tidak membosankan adalah hari ciri anda secara senyap direka semula tanpa anda. Hadirlah.

Mengira bingkai Figma sebagai "dihantar." Sesebuah ciri tidak dihantar sehingga ia berada dalam produksi dan pengguna sebenar telah menyentuhnya. Mock bukan penghantaran.

Menganggap semakan selepas pelancaran sebagai pilihan. Ia adalah perkara termurah yang akan anda lakukan sepanjang suku dan yang paling tinggi leveragennya. Pilihan bermakna ia tidak pernah berlaku. Jadualkannya pada hari anda melancarkan.

Mengelirukan aktiviti dengan hasil. Merekodkan 40 jam masa Figma bukan kemajuan jika metrik tidak bergerak. Pereka kanan menjejak hasil, bukan aktiviti.

Templat dan alat

Gunakan ini sebagai titik permulaan. Sesuaikan dengan pasukan anda.

Templat dokumen kickoff: Perenggan masalah, jadual RACI, metrik kejayaan dengan nombor dan tarikh, senarai potongan skop yang jelas, garis masa enam peringkat. Satu halaman. Jangan terlalu kompleks.

Senarai semak mendengar standup jurutera: Mutasi spesifikasi, penangguhan "kemudian", kes pinggir tanpa pemilik, anggaran yang berganda. Empat poin, lihat sebelum setiap standup.

Templat semakan selepas pelancaran: Tiga lajur (dihantar vs berubah vs akan buat berbeza), mesyuarat 30 minit, diterbitkan dalam saluran reka bentuk dalam masa 48 jam.

Penjejak kadar penghantaran: Lima lajur (ciri, tarikh kickoff, tarikh hantar, digunakan, dipelajari), disemak setiap suku bersama pengurus anda, dibawa ke setiap perbualan kenaikan pangkat.

Peralihan dalam pemikiran anda

Kerja pereka produk bukan untuk menghasilkan fail reka bentuk. Kerjanya adalah untuk mengubah sesuatu dalam produksi untuk pengguna, dan mengetahui sama ada perubahan itu berkesan.

Apabila itulah kerjanya, penyerahan (handoff) berhenti menjadi garisan penamat dan menjadi titik pertengahan. Standup jurutera berhenti menjadi mesyuarat orang lain dan menjadi tempat kerja anda sama ada bertahan atau secara senyap mati. Semakan selepas pelancaran berhenti menjadi sesuatu yang bagus untuk ada dan menjadi saat anda mengubah satu ciri menjadi pembelajaran yang menambah baik sepuluh seterusnya.

Portfolio anda berhenti menjadi tangkapan skrin dan menjadi senarai metrik yang bergerak.

Itulah kerjanya. Mulakan dengan ciri seterusnya yang anda ambil. Tulis dokumen kickoff pada hari pertama. Jadualkan semakan selepas pelancaran pada hari anda menghantar. Pantau kadar penghantaran meningkat selama empat suku. Perbualan kenaikan pangkat akan mengikuti sendiri.

Ketahui Lebih Lanjut

• JD Rakan: Pereka Produk
• Sehari dalam Kehidupan Pereka Produk
• Kerja Penerokaan sebagai Pereka Produk
• Metrik Reka Bentuk Produk: Kadar Penghantaran, Impak Selepas Pelancaran, Kualiti