Mengapa tujuan dibutuhkan? Bagaimana seharusnya mereka diformulasikan? Masalah apa yang bisa muncul? Pada kesempatan Y. Subbotnik Pro, saya menyiapkan laporan berdasarkan pengalaman beberapa tahun dalam menetapkan tujuan untuk tim di Yandex.
- Saya akan ceritakan sedikit tentang diri saya, dalam konteks mengapa Anda harus mendengarkan laporan saya. Saya memimpin tim yang sekarang disebut manajemen. Saya telah bekerja di sini untuk waktu yang lama, saya telah melihat banyak hal - keseluruhan evolusi tentang bagaimana manajemen diatur di perusahaan besar, bagaimana kita memimpin tujuan.
Saya juga menyukai alat dan metodologi, dari pengembangan hingga seluruh perusahaan. Dan baru-baru ini, saya, antara lain, mengepalai departemen yang terlibat dalam pembuatan alat internal kami.
Penafian: Apa yang tidak akan saya bahas dalam pembicaraan saya? Saya tidak akan memberi tahu Anda semua jenis definisi ensiklopedis - apa itu SMART, OKR, KPI. Semua ini telah dinyatakan ratusan kali di Wikipedia. Anda mungkin pernah mendengar semua hal ini sendiri. Jika tidak, pencarian cepat dengan mesin pencari favorit Anda akan memberikan jawabannya. Ini penuh dengan artikel yang sangat bagus. Aku memeriksanya malam ini.
Apa yang ingin saya ceritakan? Saya akan mencoba membagikan kepada Anda pengalaman yang agak pribadi. Dan pengalaman yang kami miliki di Yandex tentang penetapan tujuan. Saya akan menunjukkan kepada Anda sejumlah contoh yang baik dan mencoba untuk memberikan peringatan - hal-hal apa, menurut saya, harus dipertimbangkan dan penggaruk apa yang tidak boleh diinjak.
Ini adalah pembicaraan eksperimental di area yang tidak biasa bagi saya. Oleh karena itu, jika Anda mengajukan pertanyaan, saya mungkin dapat memberi tahu lebih banyak dan lebih substansial apa yang Anda butuhkan.
Mengapa memimpin tujuan?
Apa hubungannya ini dengan Anda? Pertama, saya berharap ada orang di antara Anda yang menetapkan tujuan sendiri. Dan saya pikir akan bermanfaat bagi Anda untuk mendengar tentang pengalaman tersebut untuk menetapkan tujuan dengan lebih baik. Kedua, meskipun Anda sendiri tidak menentukan tujuan saat ini, tetapi hanya mencapainya, pemahaman umum tentang metodologi dan prinsip akan membantu Anda mencapainya dengan lebih baik.
Kemungkinan besar, penonton yang hadir menentukan tujuan dan pencapaian. Saya sendiri termasuk orang-orang seperti itu. Biasanya orang di posisi tengah terlibat dalam kedua utas. Jadi saya harap ini menarik dan bermanfaat untuk semua orang.
Mari kita bicara sedikit tentang mengapa menetapkan tujuan. Saya memiliki beberapa kutipan yang saya dengar pada waktu yang berbeda dari kolega dan kenalan yang berbeda: mereka berkata, semua ini adalah birokrasi, alih-alih menetapkan beberapa tujuan dan tugas menulis, lakukan saja secara normal, dan semuanya akan berjalan dengan baik. Tidak perlu menemukan apa pun, tidak perlu membuang waktu untuk ini.
Kebijaksanaan populer kedua adalah Anda hanya perlu bekerja sangat, sangat keras, mengambil lebih banyak dan membuang, jangan lupa untuk beristirahat. Kerja keras seperti itu akan menyelesaikan segalanya, dan tidak peduli apa tujuan Anda. Ini semua, tentu saja, benar. Tapi hanya sebagian.
Bahkan jika Anda adalah pengembang yang sangat baik dan Anda bekerja dengan sangat baik, masih akan ada saatnya ketika Anda tidak memiliki cukup tangan untuk melakukan semuanya. Dan Anda harus menjawab pertanyaan: apa yang harus dilakukan di tempat pertama, apa yang harus dilakukan sekarang? Saya memiliki potongan waktu yang terbatas, dan masih banyak lagi yang harus dilakukan. Kami membutuhkan prioritas.
Kedua, jika Anda seorang pemimpin, maka sebuah masalah akan muncul - satu hal yang sama dapat dilakukan dengan berbagai cara yang berbeda. Dan Anda perlu memahami bagaimana meninjau apa yang telah dilakukan bawahan Anda.
Saya berbicara tentang sistem ulasan kami. Di sana saya berbicara lebih detail tentang cara kerja RPG internal kami: dengan level, level-up, peringkat, dll.
Perhatikan laporannya
Lingkaran kehidupan
Mari kita bicara tentang siklus hidup. Sebenarnya, saya akan meneruskan ke eksposisi tentang cara kerjanya di negara kita.
Saya mengambil foto-foto seperti itu. Apa yang kita lihat di sini? Tentunya banyak yang akrab dengan tahapan siklus hidup hampir semua hal - kami membidik, menembak, melihat ke mana kami memukul. Biasanya, di dunia Agile, ini seperti perencanaan sprint. Atau retro, atau demo - siapa yang bisa melakukannya.
Tapi saya suka merancang proses sehingga hal-hal rumit dapat diekspresikan melalui rumus dan prinsip sederhana dan diskalakan secara fraktal. Gambar dengan petunjuk fraktal Mandelbrot kepada kita tentang ini.
Apa yang kita punya Bagian yang berbeda dari proses fraktal kami. Ada interval peninjauan karyawan enam bulan.
Setiap tiga bulan - midreview, di mana kami merangkum hasil sementara dari periode review.
Sekali sebulan, ada lampu hijau di mana tim memberi tahu tim terkait apa yang terjadi pada target. Ini diperlukan agar perintah disinkronkan satu sama lain.
Dan sprint dua minggu itu.
Seperti yang Anda lihat, hasilnya adalah gambaran fraktal, sangat mirip dengan metodologi yang Anda perlukan untuk membidik terlebih dahulu, memahami apa sebenarnya yang akan Anda lakukan, melakukannya, dan kemudian lihat hasilnya.
Hal ini sangat penting karena para pemberi nasehat dari kearifan rakyat di atas tertutup di tengah gambar. Mereka baru saja menembak. Plus atau minus mereka tidak membidik, plus atau minus mereka tidak melihat ke mana mereka memukul. Dan ini memberikan proses yang jauh lebih tidak dapat diprediksi dan dikendalikan daripada jika Anda mengikuti tiga tahap sederhana seperti itu.
Sepertinya setiap laporan harus memiliki pendahuluan, isi, dan kesimpulan. Demikian pula, setiap tindakan yang memiliki tujuan harus memiliki penetapan tujuan, pelaksanaan, dan kesimpulan.
Supaya hasil tersebut bisa dirangkum, sehingga bisa juga dilakukan penetapan tujuan, agar bisa membidik dengan benar dibutuhkan property yang penting seperti terukurnya.
Dalam cerita tentang keterukuran, saya akan memberi contoh anti. Saya memiliki konsep bersayap (dalam Yandex) - tujuan "kotak centang".
Tujuan kotak centang
Ini adalah anti pola. Sasaran Anda kemungkinan besar tidak terlalu bagus jika terdengar seperti "buat versi baru komponen X", "mulai layanan Y", atau "refactor Z". Mengapa itu buruk?
- , , . . , , , - : , , , , . , .
«», — X? ? - , . , , . — « X», - .
- Penilaian hasilnya menjadi lebih rumit. Misalnya, Anda perlu mengevaluasi dua tim. Tanpa proses peninjauan dan kalibrasi, Anda tidak akan dapat menemukan bahwa satu tim telah melakukan kesalahan, gaya MVP, dan yang kedua telah melakukan semuanya dengan baik, selama berabad-abad dan dengan sangat rinci.
Oleh karena itu, rekomendasi saya adalah mencoba untuk menghindari tujuan "checkboxing", mencoba menerjemahkannya ke dalam bidang yang lebih terukur.
Membuat metrik dan menentukan target adalah bagian dari mengerjakan tujuan
Mungkin timbul pertanyaan bahwa ada sesuatu yang sangat sulit diukur. Dan terkadang Anda harus mulai berlari. Sudah jelas bahwa Anda perlu melakukan layanan X atau pemfaktoran ulang Y, tetapi masih belum ada metrik yang memungkinkan Anda untuk mengukurnya. Kami tidak mengerti target apa yang ingin kami tentukan sendiri sebagai gambar target. Bagaimana menjadi?
Kami menggunakan pola bahwa proses membuat metrik dan menentukan target sudah menjadi bagian dari pekerjaan untuk mencapai tujuan. Tidak perlu memblokir awal pekerjaan pada tujuan jika Anda belum merumuskannya sepenuhnya.
Saya akan memberi Anda beberapa contoh dari tujuan dunia nyata kita. Yandex memiliki tim yang menangani apa yang disebut Beauty of the Sickle, membuatnya lebih cantik. Saat dia muncul, hanya ada ide umum. Di sini Anda banyak orang, lakukanlah.
Tim bahkan tidak tahu apa itu kecantikan dan berapa persen dari kecantikan yang tidak diketahui itu yang bisa diubah. Namun, mereka mulai bekerja secara paralel. Ada pendapat intuitif bahwa beberapa hal lebih indah, dan mari kita lakukan ini. Dan secara paralel, mereka mulai menemukan sistem yang akan mengukur keindahan ini. Dan hasilnya, kami mendapatkan sistem, metrik, yang diceritakan Anton Vinogradov dalam laporannya "Yandex Beauty: Design for Millions":
Perhatikan laporannya
Inti dari sistem: kami membuat perbandingan versi lama dan versi baru secara berdampingan. Kemudian kami menghitung jumlah perubahan positif dari setiap implementasi kami selama periode waktu tertentu.
Pada semester pertama pengerjaan tujuan ini, kami merumuskan metrik. Kami membuat pemandangan sebagai persentase - sedikit dari langit-langit. Di semester berikutnya, berdasarkan seberapa baik kami melakukannya, kami sudah memahami bagaimana metrik ini bergerak, penerapan apa yang mempengaruhinya, apa yang mungkin Anda inginkan di sana.
Contoh kedua dalam konteks mengerjakan metrik adalah salah satu kontur tertua kami, tim yang menangani kecepatan antarmuka.
Saat itu dimulai, ada juga pesan umum: tolong buat sabit memuat lebih cepat. Tapi bagaimana mengukur cepat atau tidak? Ada keluhan seperti: "Saya membukanya di ponsel, sepertinya ada yang lambat bagi saya. Mesin pencari pesaing lebih cepat! " Untuk mulai melakukan pekerjaan ini, tidak perlu merumuskan metrik secara tepat. Kami tahu hal-hal umum: jika Anda mengirim banyak byte melalui jaringan, menjalankan banyak kode di JS, itu akan memakan waktu lama. Mari mulai melakukan sesuatu, dan di sepanjang jalan mengumpulkan metrik nyata, pahami bagaimana kami akan mengukurnya.
Ada juga laporan tentang ini. Andrey Prokopyuk menceritakan tentang semua detail kami tentang bagaimana kecepatan diukur pada pengguna nyata dan pada pengukuran sintetis di dalamnya:
Perhatikan laporannya
Pada saat yang sama, orang-orang itu bekerja untuk mencapai tujuan yang berarti - untuk mengurangi byte yang sama ini.
Ukur yang tak terukur
Pertanyaan berikutnya yang mungkin muncul: baik, kami ingin mengukur dan lebih atau kurang jelas pada kecepatan frontend - ada penggaris yang memungkinkan kami mendeteksi byte. Tetapi bagaimana Anda bisa mengukur sesuatu yang umumnya tidak dapat diukur? Dengan keindahan Anda tampil berdampingan, bagaimana jika tidak ada apa-apa? Misalnya, Anda perlu mengukur kebahagiaan pengguna dalam pengembangan internal.
Pertama, perlu dipikirkan lagi. Seperti yang saya katakan, dengan keindahan yang sama yang tampak subjektif, kami dapat memperoleh metrik yang lebih terukur.
Kedua, Anda dapat memikirkan tentang metrik proxy. Di sini saya juga akan mengirim Anda ke mesin pencari favorit Anda: Anda dapat menemukan banyak artikel tentang apa itu metrik proxy dan bagaimana memilihnya. Singkatnya, metrik proxy memungkinkan Anda secara tidak langsung memperkirakan keadaan Anda yang sebenarnya, untuk membuat asumsi seperti: "Jika kami terus digunakan, antarmuka kami mungkin tidak terlalu buruk."
Jelas bahwa ini akan memiliki beberapa tingkat kesalahan dan izin. Tetapi jika Anda memaksakan jumlah metrik proxy yang memadai, pada akhirnya Anda bisa mendapatkan perkiraan yang cukup baik, yang tidak memerlukan pembuatan metrik kompleks yang besar.
Yang terakhir ini disarankan dalam komentar pada laporan saya sebelumnya: selalu mungkin bagi subjek yang sangat beragam untuk mengumpulkan juri pengguna atau pakar dan meminta mereka untuk menilai mereka dalam skala. Lakukan ini secara teratur dan dapatkan sistem koordinat, metrik yang dapat direproduksi yang akan memungkinkan Anda memahami jika Anda maju dengan benar. Bahkan metrik ini masih akan lebih baik daripada sasaran "kotak centang" tersebut. Seperti Porthos: "Saya bertarung hanya karena saya bertarung!"
Beberapa kata kunci untuk membantu survei pengguna: csi nps. Tapi saya pikir idenya jelas.
Metrik anti-bug
Contoh lainnya adalah tentang metrik antibug. Kami memiliki proses khusus yang memungkinkan kami meningkatkan kualitas antarmuka kami dan mengurangi bug.
Sekarang saya akan memberi tahu Anda cara kerjanya. Beberapa poin dapat diilustrasikan di atasnya.
Pertama, kami telah membuat grafik ringkasan jumlah bug tertimbang untuk tim. Artinya, kami menghitung jumlah bug yang muncul di jendela mengambang dan menetapkan bobotnya sesuai dengan prioritasnya. Kami memiliki anak di bawah umur, trivials, normals, kritikus dan blocker yang berbeda satu sama lain dalam urutan besarnya. Minor dan trivial memiliki bobot 1, normal memiliki 10, kritikus memiliki 100, dan pemblokir memiliki 1000. Hasilnya adalah grafik yang mencerminkan berapa banyak bug yang saat ini ada di layanan, dengan mempertimbangkan prioritas mereka.
Kedua, kami mulai membuat grafik semacam itu secara terpisah untuk bug yang ditemukan oleh tim itu sendiri dan penguji tim, dan untuk yang dilaporkan oleh pengguna eksternal. Kemudian kami menangguhkan komponen target, melaksanakan target. Di dalam diri kita, proses ini disebut kebijakan nol bug. Tetapi jelas bahwa nol adalah cita-cita yang tidak dapat dicapai, dan setiap tim mungkin memiliki angka nol yang berbeda pada waktu tertentu. Ada batasan yang ditentukan - bahwa beratnya tidak lebih dari 50 atau 100.
Jika sebuah tim baru mulai mengerjakan antibug, kami katakan bahwa itu harus dikurangi 20% setiap bulan. Ada enam bulan dalam satu semester, lima bulan untuk penurunan 20%, ditambah satu bulan lagi untuk mempertahankan hasil ini. Dengan demikian, dimungkinkan untuk satu semester mencapai nilai target dan memiliki sedikit bug.
Metrik antibug adalah 20% berdasarkan prinsip bahwa seharusnya ada lebih banyak bug yang ditemukan sendiri daripada bug pengguna. Artinya, pengujian pada proyek akan bekerja lebih baik, dan pengguna seharusnya menemukan lebih sedikit bug daripada kami.
Kriteria terakhir adalah kepatuhan dengan SLA penutup. Meskipun Anda tidak memiliki banyak bug, tetapi bug tersebut telah bertahan lama, hal ini dapat mengganggu pengguna: jumlah orang yang terpengaruh oleh bug dalam produksi bertambah setiap hari hingga bug ini sembuh.
Dan inilah dua poin. Selain metodologi cara kami mengukur, memperkirakan bobot ini, dan jumlah bug, ada contoh lain tentang cara menggabungkan beberapa kriteria berbeda ke dalam satu metrik.
Anda cukup meletakkan bobot dan persentase pada kriteria ini dan mengatakan bahwa satu memengaruhi 40%, 20% kedua, 40% ketiga. Berikut ini contohnya, dan metrik ini memungkinkan pekerjaan yang lebih atau kurang terpadu pada antibug untuk didistribusikan di antara lusinan tim di Yandex.
Kami kembali ke kata kunci "keseimbangan". Anda harus mencoba menemukannya. Saya akan memberi tahu Anda tentang beberapa saldo yang perlu Anda ingat ketika Anda melakukan proses penetapan tujuan.
Yang pertama adalah keseimbangan antara "terlalu sedikit tujuan" dan "terlalu banyak tujuan". Gol seharusnya tidak terlalu sedikit, karena itu tidak akan cukup ambisius untuk tim. Anda hanya tidak akan memanfaatkan potensi penuh Anda. Terlalu banyak juga buruk: memulai dari titik tertentu, overhead dalam mengenali dan mempertahankan tujuan akan menjadi terlalu besar. Mereka akan menumpuk secara total dan akan mengganggu Anda.
Kami memiliki beberapa contoh seperti itu. Misalnya ada tim yang terdiri dari delapan orang. Mereka memiliki sekitar enam gol. Mereka berkata: “Sebagai sebuah tim, kami tidak dapat melacak enam target sekaligus. Kami perlu melacaknya di lampu hijau, terus-menerus memahami apakah masing-masing berkembang dengan baik bersama kami. Mari kita bagi menjadi dua tim beranggotakan empat orang dan mendistribusikan tiga gol ini ke satu tim, tiga lainnya ke tim lainnya. Ini adalah metode kerja yang pada akhirnya memungkinkan Anda untuk memfokuskan orang sedikit lebih sempit pada tujuan tertentu.
Keseimbangan berikutnya adalah keseimbangan antara keinginan dan kemampuan kita. Jika tidak ada keseimbangan dalam tim yang terlibat dalam penetapan tujuan, maka sangat sering terjadi bias di satu arah atau yang lain. Misalkan Anda memiliki manajemen puncak yang kuat dan dia memberi tahu Anda: "Kami pasti perlu melakukan ini." Dan semua tujuan ditetapkan dari keinginan kami - kami ingin ini terjadi, dan apa pun yang Anda inginkan, "keluarkan dan letakkan". Situasi seperti itu mungkin penuh dengan fakta bahwa keinginan ini tidak akan sejalan dengan kenyataan dan tidak akan terpenuhi.
Selain itu, ketimpangan terjadi jika para pelaut merebut kekuasaan di kapal tersebut. Kemudian tim akan berusaha merumuskan gol sedemikian rupa sehingga semuanya akurat dan terjamin. Seperti yang saya katakan, ini penuh dengan potensi Anda yang kurang dimanfaatkan. Harus selalu ada tantangan, jalan keluar dari zona nyaman Anda, titik di mana Anda mencapainya. Melalui ketegangan, evolusi terjadi. Penting bahwa ketegangan ini tidak membuat ligamen Anda robek. Ini harus berkembang. Dan keseimbangan ini harus diupayakan.
Ada juga keseimbangan antara yang disebut lebar dan kedalaman. Selalu ada pilihan, mana yang lebih baik - untuk menyusun tujuan secara rinci, tetapi hanya satu, atau untuk mendapatkan banyak tujuan, tetapi pada akhirnya tidak punya waktu untuk mengerjakan masing-masing setidaknya sampai batas tertentu. Tidak ada nasihat universal di sini, karena situasi kehidupan sangat berbeda. Beberapa utas sangat penting untuk mendukung setidaknya entah bagaimana, dan dalam pengertian ini lebar diperlukan. Misalnya, menyikat gigi, makan, berolahraga, bekerja adalah hal yang sama pentingnya. Di sini tidak mungkin untuk mengatakan - izinkan saya menyikat gigi dengan sangat baik untuk bulan pertama, tiga kali sehari, bulan depan saya akan sangat pandai berolahraga, dll.
Tetapi ada juga situasi yang berlawanan, ketika penting bagi kita untuk menyelesaikannya sampai akhir, adalah baik untuk menutup beberapa masalah dan kemudian melanjutkan. Dan jangan memulai dua perbaikan pada saat bersamaan. Jika memungkinkan, pertama-tama Anda dapat melakukan satu hal, berinvestasi dengan baik, mengikutinya, dan kemudian melakukan hal lain.
Kita membutuhkan keseimbangan antara dua formulasi: "reorientasi pada waktunya ke realitas yang berubah" dan "menyerah pada kesulitan pertama." Terkadang Anda dapat mulai melakukan sesuatu dan menemukan bahwa tugasnya lebih sulit dari yang diharapkan. Atau faktor eksternal telah terjadi, seperti virus corona atau yang lainnya. Sangat menggoda, dipandu oleh prinsip Agile, untuk secara fleksibel beradaptasi dengan realitas yang berubah dan, misalnya, meremehkan KPI Anda, melepaskan beberapa tujuan atau sesuatu yang lain. Di sini kita menemukan diri kita dalam situasi yang sama seperti dalam penetapan tujuan awal, hanya dalam dinamika.
Pastikan bahwa Anda tidak menyerah pada kesulitan pertama, bahkan dalam dinamika, ketika Anda terus mengubah distribusi bobot gol, tetapi juga jangan membenturkan kepala ke dinding saat ini tidak lagi memberikan hasil apa pun.
Hal terakhir yang ingin saya bicarakan dalam slide ini adalah keseimbangan antara berbagai tujuan. Terkadang tujuan mulai bertentangan satu sama lain.
Di tempat khusus ini, kami memiliki metodologi yang jelas untuk menukar satu sama lain. Tetapi penting juga untuk menilai sisanya, tujuan yang saling bertentangan yang sama dari jarak yang cukup. Dalam bentuk apa seseorang dapat menukar yang satu dengan yang lain?
Dan beberapa analogi dan gambar tentang keseimbangan. Itu, dalam bentuk yang saya rumuskan untuk diri saya sendiri, ada dua jenis:
- « ». — , , - — , .
, . : « , ». , , . , : . - «». , , . . , : - . , , . , , .
Pada akhirnya, saya ingin mereproduksi semua yang saya katakan dan menunjukkan slide itu lagi kepada Anda. Tetapi jumlah mereka tidak begitu banyak, dan tampaknya kurang lebih bisa dimengerti.
Ringkasan singkat dari keseluruhan laporan: Menetapkan tujuan itu sulit. Anda mungkin mendapati bahwa penetapan tujuan itu sendiri membutuhkan banyak waktu. Tapi itu sepadan! Setidaknya ini adalah penilaian nilai saya berdasarkan pengalaman pribadi saya.
Saya sangat senang bahwa kami secara umum telah mencapai sistem dengan tujuan dan terus berkembang dan memperbaikinya. Semua upaya ini, menurut saya, membuahkan hasil.
Mungkin ada iklan untuk alat kami atau salah satu alat Anda, karena memberi atau menerima alat apa pun untuk melakukan tugas atau tujuan dapat digunakan. Cukup telusuri mesin pencari favorit Anda untuk [nama alat, spasi, target]. Anda pasti akan menemukan artikel yang menjelaskan dengan tepat bagaimana melakukan ini. Terima kasih atas perhatian Anda. Saya berharap Anda semua sama sukses memukul seperti di gif ini.
