Cara mengevaluasi kinerja tim

Sebuah startup keren di awal perjalanannya mirip dengan Sapsan. Sebuah tim kecil dengan cepat mendapatkan momentum dan bergegas ke masa depan, membawa banyak tugas untuk produksi. Jika proyek tersebut ternyata menjanjikan, seperti Skyeng, maka dalam beberapa tahun akan ada lebih banyak tim, dan ada kemungkinan bahwa di antara mereka akan ada lokomotif uap di mana Anda perlu terus-menerus melemparkan kayu bakar ke dalam tungku sehingga setidaknya ada sesuatu yang menjangkau pengguna.


Periksa atau baca pembicaraan Alexey Kataev di Saint TeamLead Conf jika Anda tidak tahu kriteria formal apa yang menentukan apakah tim Anda hebat . Jika Anda ingin dapat mengukur utang teknis dalam hitungan jam, daripada beroperasi dengan kategori "cukup sedikit", "berapa banyak", "sangat banyak". Jika manajer produk Anda percaya bahwa tim yang terdiri dari tiga orang dalam sebulan akan melakukan 60 tugas - tunjukkan padanya artikel ini. Jika manajer Anda menutup pengembangan dengan metrik dan menyarankan agar Anda mengambil tindakan berdasarkan hasil seperti: "34% berpikir bahwa tim memiliki masalah dengan perencanaan," laporan ini cocok untuk Anda.



Tentang pembicara: Alexei Kataev ( deusdeorum ) telah terlibat dalam pengembangan web selama 15 tahun. Berhasil bekerja sebagai backend, frontend, fullstack-developer dan pemimpin tim. Saat ini terlibat dalam perampingan proses pengembangan di Skyeng . Mungkin tidak asing bagi pemimpin tim dalam berbicara tentang pekerjaan tim yang didistribusikan.

Sekarang akhirnya kami melewati lantai ke pembicara. Mari kita mulai dengan konteksnya dan secara bertahap beralih ke masalah utama.



Saya bergabung dengan Skyeng pada 2015 dan merupakan satu dari lima pengembang - mereka semua adalah pengembang di perusahaan itu.

Sedikit lebih dari tiga tahun telah berlalu, dan sekarang kami memiliki 15 tim - ini adalah 68 pengembang .



Semua pengembang bekerja dari jarak jauh , mereka tersebar di seluruh dunia.

Mari kita lihat masalah-masalah yang mau tidak mau muncul saat meningkatkan skala perusahaan dari 5 menjadi 68 karyawan.

Dalam gambar, Sergey adalah manajer pengembangan.


Pernah kami memiliki satu tim, dan Sapsan, yang bergegas ke masa depan dan membawa banyak tugas dalam produksi. Tapi tidak hanya tugas, tetapi sedikit hutang teknis. Kemudian pada suatu titik, tanpa diduga bagi kami, ada lebih banyak tim.

Pertanyaan pertama yang dihadapi Sergey adalah apakah semua tim kami adalah Sapsans , atau apakah ada mesin uap di antara kami di mana Anda perlu membuang kayu bakar ke dalam kotak api.


Pertanyaan ini penting karena situasi seperti itu dapat muncul: seorang manajer produk atau perwakilan bisnis akan datang ke Sergey dan mengatakan bahwa kita tidak punya waktu, timnya bekerja dengan buruk. Namun faktanya, masalahnya bisa tidak hanya di tim. Masalahnya mungkin dalam hubungan antara tim dan bisnis atau dalam bisnis itu sendiri - mungkin tidak menetapkan tujuan dengan baik atau memiliki rencana yang terlalu optimis.

Anda perlu memahami apakah tim itu keren .


Pertanyaan kedua adalah sumber daya tim : berapa banyak tugas yang dapat kita ambil untuk produk. Masalah ini penting karena produk selalu memiliki banyak rencana untuk waktu dekat. Penting untuk memahami apakah tim akan mengatasi rencana ini, atau apakah Anda perlu membuang setengah dari tugas. Atau mungkin ada baiknya mempekerjakan beberapa orang lagi untuk merealisasikan semua tugas.


Pertanyaan ketiga adalah berapa banyak hutang teknis yang kita bawa? Ini adalah pertanyaan kritis, karena jika jumlahnya melebihi nilai batas, maka pada akhirnya kereta kami tidak akan bisa pergi ke mana pun. Kami harus mengabaikan tim, memulai proyek dari awal, dan kami tidak ingin mengizinkan ini.


Akhirnya - bagaimana kita memastikan bahwa semua tim adalah Sapsan dan bukan kereta?

1. Kami menentukan seberapa keren tim kami.

Tentu saja, hal pertama yang terlintas dalam pikiran adalah mengukur beberapa metrik! Sekarang saya akan bercerita tentang pengalaman kami dan bagaimana kami keliru berulang kali.


Pertama-tama, kami mencoba memantau kecepatan - berapa banyak tugas yang kami jalankan untuk sprint. Tetapi ternyata setengah dari tim kami tidak memiliki sprint sama sekali, mereka memiliki Kanban. Dan di mana ada sprint, tugas dinilai dalam jam atau poin cerita. Masih ada beberapa tim yang hanya melakukan tugas - mereka tidak memiliki Kanban, mereka tidak tahu apa itu Scrum.

Ini adalah inkonsistensi data. Kami mencoba menghitung satu angka pada data yang sangat berbeda. Pada saat yang sama, membuat sprint di mana-mana sehingga semua tim identik akan sangat mahal. Untuk menghitung satu metrik, seseorang harus mengubah proses.

Kami berpikir, mencoba beberapa opsi lagi dan sampai pada metrik sederhana - implementasi rencana . Ini juga mahal, tetapi hanya rencana produk yang harus dibuat identik, konsisten. Seseorang menuntun mereka ke Jira, seseorang di Google Spreadsheets, seseorang membuat grafik - mengonversi ke satu format jauh lebih murah daripada mengubah proses dalam tim.

Setiap kuartal, kita melihat apakah tim memenuhi persyaratan bisnis, berapa banyak tugas yang direncanakan telah selesai.


Menghitung jumlah insiden juga gagal.

Kami mencatat setiap kegagalan peluncuran atau bug yang menyebabkan kerusakan pada perusahaan, dan post-mortem. Sergei mendatangi saya sebagai pemimpin tim dan berkata: “Tim Anda mengakui paling banyak jatuh. Kenapa begitu? ” Kami berpikir, melihat, dan ternyata tim kami yang paling bertanggung jawab dan satu-satunya yang mencatat semua kesalahan. Sisanya bertindak berdasarkan prinsip cepat diangkat, tidak dianggap telah jatuh.

Masalahnya lagi adalah inkonsistensi data dan pengambilan sampel yang tidak memadai. Kami memiliki tim yang baru saja mendarat - tidak pernah mogok sama sekali. Kami tidak dapat mengatakan bahwa tim ini lebih baik, karena ia memiliki proyek yang lebih stabil.

Yang kedua - topik favorit saya - adalah distorsi kognitif . Kemudahan kognitif adalah ketika kita membuat kesimpulan yang tampaknya sederhana bagi kita, dan segera mulai memercayainya. Kami tidak memasukkan pemikiran kritis: jika ada banyak jatuh, itu berarti tim yang buruk.

Kami sampai pada metrik yang sama persis dengan jumlah insiden, tetapi hanya merevisi implementasinya. Kami membuat proses di mana semua jatuh dicatat . Pada akhir setiap bulan, kami meminta orang-orang yang tidak tertarik menyembunyikan insiden - ini adalah QA dan produk, apakah ini daftar lengkap masalah yang terjadi karena kesalahan tim. Mereka ingat ketika kita menjatuhkan sesuatu, dan melengkapi daftar ini.


Ada juga masalah dengan polling. Tampaknya alat super universal - kami akan mewawancarai semua orang (produk, pemimpin tim, pelanggan) masalah apa yang kami miliki dalam tim. Menurut jawaban mereka, kami akan membuat grafik, dan kami akan mencari tahu segalanya. Tetapi ada banyak masalah.

Pertama, jika Anda mengajukan pertanyaan tertutup, maka tidak ada kesimpulan yang dapat diambil dari data ini. Sebagai contoh, kami bertanya: "Apakah tim memiliki masalah dengan perencanaan?" dan 34% mengatakan bahwa ada - dan apa yang harus dilakukan? Jika Anda mengajukan pertanyaan terbuka: "Apa masalah dalam tim dengan infrastruktur?" - Anda akan mendapatkan jawaban kosong, karena semua orang terlalu malas untuk menulis apa pun. Tidak ada kesimpulan yang dapat diambil dari data ini .

Kami mengembangkan ide ini - pertama kami melakukan survei sebagai penyaringan, dan kemudian wawancara untuk memahami apa sebenarnya masalahnya. Kami akan berbicara tentang wawancara nanti.

Saya memberi tiga contoh, sebenarnya kami mencoba puluhan metrik .

Sekarang kami hanya menggunakan:

• Pemenuhan rencana.
• Jumlah insiden.
• Polling + wawancara.

Saya menipu jika saya mengatakan bahwa kita bahkan mengukur hal-hal sederhana ini di semua tim, karena hal yang paling mahal adalah implementasi . Terutama ketika ada 15 tim yang berbeda, ketika produk mengatakan: "Ya, kami sama sekali tidak membutuhkannya! Kami harus menjalankan tugas kami, sekarang tidak lagi sanggup! ” Sangat sulit untuk membuatnya sehingga untuk mengukur satu angka di semua tim.

Wawancara

Mari kita menyimpang singkat tentang wawancara dengan pengembang . Saya membaca beberapa artikel, mengikuti kursus belanjaan. Ada banyak hal tentang riset pengguna dan pengembangan pelanggan. Saya mengambil beberapa praktik dari sana, dan mereka sangat berkomunikasi dengan pengembang.

Jika tujuan Anda adalah untuk mengetahui masalah apa yang dimiliki tim, maka pertama-tama Anda harus menulis pertanyaan yang ditargetkan yang akan Anda cari jawabannya. Artinya, Anda tidak hanya melemparkan 30 pertanyaan, Anda memilih 2-3 pertanyaan yang Anda cari jawabannya. Misalnya: apakah tim memiliki masalah infrastruktur; bagaimana komunikasi antara bisnis dan tim dibentuk.

Dalam hal ini, pertanyaannya harus:

• Buka Jawaban atas pertanyaan: "Apakah ada masalah?" "Ya!" "Dia tidak akan memberitahumu apa-apa."
• Netral Pertanyaan tentang masalah adalah pertanyaan yang buruk. Lebih baik bertanya: "Ceritakan tentang proses perencanaan di tim Anda." Seseorang berbicara tentang prosesnya, dan Anda sudah mulai mengajukan pertanyaan yang lebih mendalam kepadanya.

Pendekatan lain yang sangat bagus adalah penentuan prioritas . Anda memiliki berbagai aspek kehidupan tim. Anda bertanya kepada karyawan yang mana, menurut pendapatnya, adalah yang paling keren dan harus tetap sama, dan yang, mungkin, harus ditingkatkan.

Ada pendekatan lain yang saya ambil dari bab wawancara di buku “Who. Selesaikan masalah nomor satu Anda "- ajukan pertanyaan seperti ini:" Jika saya bertanya suatu produk, bagaimana menurut Anda, masalah apa yang akan ia sebutkan? " Ini memaksa pengembang untuk melihat gambaran besar, dan bukan dari posisi mereka, untuk melihat semua masalah.

2. Mengevaluasi sumber daya

Sekarang mari kita bicara tentang penilaian sumber daya .

Mari kita mulai dengan pendekatan produk - karena ia biasanya mengevaluasi sumber daya timnya. Ada 3 orang, 20 hari kerja dalam sebulan - kami mengalikan orang dengan hari, kami mendapatkan 60 tugas.



Tentu saja, saya melebih-lebihkan, produk normal akan menggandakan ini sebagai 60 hari pengembangan. Tapi ini juga salah, tidak ada yang akan menggelar tugas yang dinilai selama 60 hari dalam 60 hari. Bahkan Scrum menyarankan Anda untuk mempertimbangkan faktor fokus dan mengalikannya dengan angka ajaib tertentu, misalnya 0,2. Bahkan, dari iterasi ke iterasi kami akan meluncurkan 12, lalu 17, lalu 10 tugas. Saya pikir ini penilaian yang sangat kasar.

Saya memiliki pendekatan sendiri untuk menilai sumber daya. Untuk memulainya, kami mempertimbangkan total sumber daya tim dalam jam kerja. Kami memperbanyak jam dengan pengembang, kami mengambil liburan dan hari libur. Misalkan Anda mendapat 750. Tapi tidak semua pengembangan adalah pengembangan itu sendiri.


Di atas adalah data nyata menggunakan salah satu perintah sebagai contoh:

• 36,9% waktu yang dihabiskan untuk komunikasi adalah rapat, diskusi, ulasan teknis, ulasan kode, dll.
• 63.1% - langsung memecahkan masalah.

Bisakah produk ini mengandalkan 63,1% ini? Tidak, tidak bisa, karena tugas produk hanya sebagian. Masih ada kuota (sekitar 20%) untuk memperbaiki bug dan refactoring . Inilah yang timlid distribusikan, dan produk tidak lagi diperhitungkan saat ini.


Dari tugas-tugas produk, juga, tidak semua tugas adalah yang telah direncanakan oleh produk. Ada tugas produk dari tim lain yang meminta bantuan darurat karena rilis. Kami memperkirakan sekitar 8–10% dari tugas yang datang dari tim lain .


Dan sekarang kita punya 287 jam! Semuanya akan keren jika kita selalu cocok dengan nilai kita. Tetapi dalam tim ini, kelebihan rata-rata dihitung - 1,51, yaitu, rata-rata, tugas itu memakan waktu satu setengah kali lebih banyak dari yang diperkirakan.


Total 750 tetap 189 jam untuk menyelesaikan tugas utama . Tentu saja, ini merupakan perkiraan, tetapi rumus ini memiliki variabel yang dapat diubah. Misalnya, jika Anda menghabiskan satu bulan untuk refactoring, Anda dapat mengganti nilai ini dan mencari tahu apa yang dapat Anda andalkan.

Saya mencurahkan sepanjang hari untuk ini - saya mengambil tugas, di Excel saya menghitung waktu rata-rata, menganalisisnya - saya menghabiskan banyak waktu dan memutuskan bahwa saya tidak akan pernah melakukannya lagi. Saya perlu pendekatan cepat untuk ini, agar tidak melakukannya dengan tangan saya setiap waktu.

Saya disarankan plugin untuk Jira dan EazyBI . Ini adalah alat yang sangat rumit, atau saya tidak memiliki keterampilan yang cukup, tetapi di tengah saya menyerah.

Saya menemukan cara untuk membuat laporan dengan cepat.


Unggah data dari pelacak tugas Anda ke DBMS yang Anda kenal (PostgreSQL untuk kami), lalu minta analis untuk menghitung semuanya. Kami memilikinya Dima, dan dia menghitung semuanya dalam 2 jam.


Pada saat yang sama, ia memberikan banyak data tambahan - lembur untuk pengembang, lembur untuk jenis tugas, beberapa koefisien, memberi tahu kami tentang wawasan dan hipotesis barunya - menyenangkan dan dapat diukur: Anda dapat menggunakannya segera di semua tim.

Cara menambah sumber daya

Sekarang tentang bagaimana Anda dapat mempercepat tim - tingkatkan sumber dayanya tanpa menambah jumlah pengembang.

Pertama-tama, untuk mempercepat sesuatu, Anda harus terlebih dahulu mengukurnya. Kami biasanya menghitung dua metrik:

1. Ringkasan penilaian awal tugas untuk iterasi dalam hitungan jam. Misalnya, kami menjalankan tugas selama 100 jam dalam seminggu.
   
2. Dan kadang-kadang waktu bergulir rata-rata adalah waktu dari saat tugas dikembangkan, sebelum diproduksi. Ini adalah metrik bisnis yang lebih dan menarik untuk produk, bukan pengembang.
   

Saya tidak akan bosan memberi tahu bot Arseny, yang saya tulis selama akhir pekan. Setiap minggu dia memposting intisari - berapa banyak tugas yang kami lakukan.



Ada dua hal menarik di sini:

1. Apa yang saya sebut efek pengamat - mengevaluasi beberapa indikator, kami sudah mengubahnya. Segera setelah kami mulai menggunakan bot ini, kami meningkatkan jumlah tugas yang kami lakukan selama iterasi.
   
2. Metrik harus memotivasi . Saya mulai dengan menunjukkan seberapa jauh kita tidak punya waktu untuk berlari. Ternyata kami tidak tepat waktu sebesar 10%, sebesar 20%. Ini tidak memotivasi sama sekali, tidak akan ada efek pengamat.
   

Kecepatan adalah metrik lagging, kita tidak bisa langsung mempengaruhinya. Ini menunjukkan sesuatu, tetapi ada metrik, yang memengaruhi, kita dapat memengaruhi kecepatan. Menurut saya, ada dua yang utama:

1. Keakuratan tugas penilaian.
Di sini kami sekali lagi dibantu oleh analis kami, Dima, yang menghitung waktu sebenarnya dari tugas itu, tergantung pada penilaian awal.


Ini adalah data nyata. Di atas adalah grafik waktu aktual untuk menyelesaikan tugas, dan di bawah ini adalah perkiraan kami.

Joel Spolsky mengklaim bahwa 16 jam per tugas adalah batasnya. Bagi kami jelas bahwa setelah 12 jam penilaian tidak masuk akal, variansnya terlalu besar. Kami benar-benar memperkenalkan soft-limit dan mencoba untuk tidak mengevaluasi tugas, lebih dari 12 jam. Setelah itu, baik dekomposisi atau riset tambahan.

2. Buang-buang waktu, yaitu, ketika pengembang menghabiskan waktu untuk sesuatu yang mereka mungkin tidak menghabiskannya.
Di salah satu tim kami, hingga 50% dari waktu dihabiskan untuk komunikasi. Kami mulai menganalisis dan memahami apa alasannya. Ternyata masalahnya ada dalam proses: semua pelanggan menulis langsung ke pengembang, mengajukan pertanyaan. Kami mengubah proses sedikit, mengurangi waktu ini dan meningkatkan indikator kecepatan.

Dalam kasus Anda, ini tidak harus berupa komunikasi, misalnya, mungkin sudah saatnya untuk penyebaran atau infrastruktur. Tetapi prasyarat untuk ini adalah bahwa semua pengembang Anda harus mencatat waktu. Jika tidak ada yang mencatat waktu Anda di Jira, maka jelas akan sangat mahal untuk mengimplementasikannya.

3. Berurusan dengan utang teknis

Ketika saya mengatakan "tugas teknis", saya memvisualisasikannya sebagai sesuatu yang kabur - tidak jelas bagaimana hal itu dapat diukur?


Jika saya memberi tahu Anda bahwa kami memiliki tepat 648 jam tugas teknis di salah satu tim, Anda tidak akan percaya. Tapi saya akan memberi tahu Anda algoritma yang digunakan untuk mengukurnya.


Kami mengumpulkan sekali seperempat tim secara keseluruhan (kami menyebutnya pertemuan refactoring) dan menghasilkan kartu: apa yang dilihat oleh kruk (milik kami dan orang lain) dalam kode, keputusan yang meragukan, dan hal-hal buruk lainnya, misalnya, versi perpustakaan lama - apa saja. Setelah kami membuat banyak kartu ini, untuk masing-masing kami menulis resolusi - apa yang harus dilakukan dengannya. Mungkin tidak melakukan apa-apa, karena itu bukan tugas teknis sama sekali, atau Anda perlu memperbarui versi perpustakaan, refactor, dll. Selanjutnya, kami membuat tiket di Jira, tempat kami menulis: "Ini masalahnya - ini solusinya."

Dan di sini kita memiliki 150 tiket di Jira - apa yang harus dilakukan dengan mereka?



Setelah itu, kami melakukan survei yang memakan waktu 10 menit untuk satu pengembang. Setiap pengembang memberikan peringkat dari 1 hingga 5, di mana 1 - "Suatu hari nanti akan kita lakukan di kehidupan berikutnya", dan 5 - "Kita perlu lakukan sekarang, itu banyak memperlambat kita." Kami menambahkan peringkat ini langsung ke tiket di Jira. Kami membuat bidang khusus, menyebutnya "Prioritas Refactoring", dan dengan itu kami mendapatkan daftar prioritas utang teknis dan masalah kami. Setelah mengevaluasi 10-20 pertama, dan kemudian mengalikan ekor dengan peringkat rata-rata (kami terlalu malas untuk mengevaluasi semua 150 tiket), kami mendapatkan utang teknis dalam hitungan jam .

Mengapa kita membutuhkan ini? Kami melakukan penilaian ini sekali dalam seperempat. Jika kita memiliki 700 jam pada kuartal pertama, dan kemudian menjadi, misalnya, 800, maka semuanya beres. Dan jika menjadi 1400, itu berarti ada ancaman dan perlu untuk meningkatkan kuota untuk refactoring - setuju dengan bisnis yang sekarang kita akan refactor sebulan penuh atau 40% sepanjang masa.

Nah, kami menyelesaikan masalah utang teknis, itu sedang dikunci.


Tetapi mari kita bicara tentang alasan yang menyebabkannya terjadi. Ini paling sering merupakan tinjauan kode yang buruk.

Ulasan kode salah

Salah satu alasan utama untuk tinjauan kode yang buruk adalah faktor bus. Kami telah belajar memformalkan faktor-bus . Kami mengambil tim, menulis daftar bidang yang relevan untuk tim ini, misalnya, untuk tim platform itu adalah: komunikasi video, sinkronisasi latihan, alat. Setiap pengembang memberikan peringkat 1 hingga 3:

• 1 - "Saya tidak mengerti apa itu, saya mendengar beberapa kali."
• 2 - "Saya bisa melakukan tugas dari area ini."
• 3 - "Saya seorang ahli super di bidang ini."

Menariknya, untuk beberapa bidang tidak ada satu pun pakar dalam tim, tidak ada yang tahu bagaimana ini bekerja.

Bagaimana kami mengatasi masalah dengan faktor bus ?

Selanjutnya, kami menghitung nilai tengah untuk setiap area, dan melakukan serangkaian laporan pada pertemuan tim reguler di mana para ahli memberi tahu seluruh tim tentang area tersebut. Tentu saja, metode ini tidak skala dengan sangat baik, tetapi, pertama, ada video dari laporan ini, dan kedua, ini adalah cara yang sangat cepat. Seluruh tim sekarang kurang lebih tahu cara kerja panggilan video. Untuk beberapa area, kami belum menulis dokumentasi, tetapi telah melakukan tugas menulis dokumentasi. Suatu hari nanti kita akan menulis.


Sekarang tentang ulasan kode ketika tidak ada cukup waktu. , review code review. pull requests, code review . , , - , review. - — , — , code review .

. — , .

4.

. , , cross review . -, : , , , . , . , .

, Google Suite : , , , .

— - .


-, . , , Continuous Integration ..

- — , . — , . , , , , , , . -.

:

• , , .
• - .
• , .
• .

, .

• QA- — 10 , .
• , - Skyeng - . — , , .
• open source, , .

Telegram (@ax8080) facebook , .

Saya mengingatkan Anda bahwa Call for Papers di konferensi TeamLead Conf 2019 untuk para pemimpin tim, yang akan diadakan pada 25-26 Februari di Moskow, sudah terbuka. Berikut ini ringkasan cara mengirim laporan, dan ketentuan untuk berpartisipasi, ini adalah tautan ke formulir aplikasi.

Dan tetap bersama kami! Kami akan terus memposting artikel dan video tentang mengelola tim pengembangan, dan dalam buletin kami akan mengumpulkan bahan-bahan pilihan selama beberapa minggu dan menulis tentang berita konferensi.