Pengembangan perangkat lunak dianggap sebagai proses yang tidak dapat diukur, dan tampaknya untuk mengelolanya secara efektif, Anda memerlukan bakat khusus. Dan jika intuisi dengan kecerdasan emosional tidak terlalu berkembang, maka syaratnya pasti akan berubah, kualitas produk akan turun dan kecepatan pengiriman akan turun.
Sergei Semenov percaya bahwa ini terjadi terutama karena dua alasan.
- Tidak ada alat dan standar untuk mengevaluasi pekerjaan programmer. Manajer harus menggunakan penilaian subyektif, yang pada gilirannya menyebabkan kesalahan.
- Tidak ada cara kontrol otomatis dari proses dalam tim yang digunakan. Tanpa kontrol yang tepat, proses dalam tim pengembangan berhenti untuk memenuhi fungsi mereka, karena mereka mulai dieksekusi sebagian atau hanya diabaikan.
Dan ia menawarkan pendekatan untuk penilaian dan pengendalian proses berdasarkan data objektif.
Di bawah ini adalah versi video dan teks dari laporan Sergey, yang, menurut hasil pemungutan suara pemirsa, menempati posisi kedua di
Saint TeamLead Conf .
Tentang pembicara: Sergey Semenov ( sss0791 ) telah bekerja di IT selama 9 tahun, adalah pengembang, pemimpin tim, manajer produk, sekarang CEO GitLean. GitLean adalah produk analitis untuk manajer, direktur teknis, dan pemimpin tim, yang dirancang untuk membuat keputusan manajemen yang objektif. Sebagian besar contoh dalam cerita ini didasarkan tidak hanya pada pengalaman pribadi, tetapi juga pada pengalaman perusahaan klien dengan staf pengembangan dari 6 hingga 200 orang.Sudah dengan kolega saya Alexander Kiselev kami berbicara tentang
evaluasi pengembang pada bulan Februari di TeamLead Conf sebelumnya. Saya tidak akan membahas hal ini secara terperinci, tetapi akan merujuk pada artikel tentang beberapa metrik. Hari ini kita akan berbicara tentang proses dan bagaimana mengontrol dan mengukurnya.
Sumber data
Jika kita berbicara tentang pengukuran, alangkah baiknya untuk memahami di mana mendapatkan data. Pertama-tama, kami memiliki:
- Git dengan informasi kode;
- Jira atau pelacak tugas lainnya dengan informasi tentang tugas;
- GitHub , Bitbucket, Gitlab dengan informasi ulasan kode.
Selain itu, ada mekanisme keren seperti mengumpulkan berbagai penilaian subjektif. Saya akan membuat reservasi bahwa itu harus digunakan secara sistematis jika kita ingin mengandalkan data ini.
Tentu saja, kotoran dan rasa sakit menunggu Anda dalam data - tidak ada yang dapat Anda lakukan tentang hal itu, tetapi ini tidak begitu menakutkan. Hal yang paling tidak menyenangkan adalah mungkin tidak ada data tentang pekerjaan proses Anda dalam sumber-sumber ini. Ini mungkin karena proses dibangun sehingga mereka tidak meninggalkan artefak dalam data.
Aturan pertama yang kami sarankan untuk diikuti saat merancang dan membangun proses adalah membuatnya sehingga mereka meninggalkan artefak dalam data. Anda harus membangun bukan hanya Agile, tetapi juga membuatnya
Agile Measurable.
Saya akan menceritakan kepada Anda kisah horor yang kami temui dengan salah satu pelanggan yang datang kepada kami dengan permintaan untuk meningkatkan kualitas produk. Untuk membuat Anda memahami skalanya, sekitar 30-40 bug dari produksi terbang ke tim yang terdiri dari 15 pengembang seminggu. Mereka mulai memahami alasannya, dan mendapati bahwa 30% tugas tidak masuk dalam status "pengujian". Pada awalnya, kami pikir itu hanya kesalahan data, atau penguji tidak memperbarui status tugas. Tetapi ternyata benar-benar 30% dari tugas tidak diuji. Pernah ada masalah dalam infrastruktur, karena itu 1-2 tugas dalam iterasi tidak termasuk dalam pengujian. Lalu semua orang lupa tentang masalah ini, penguji berhenti membicarakannya, dan seiring waktu itu tumbuh menjadi 30%. Akibatnya, ini menyebabkan lebih banyak masalah global.
Oleh karena itu, metrik penting pertama untuk setiap proses adalah bahwa ia meninggalkan data. Pastikan untuk mengikuti ini.
Terkadang, demi terukur, Anda harus mengorbankan sebagian dari prinsip Agile dan, misalnya, di suatu tempat lebih suka komunikasi tertulis daripada lisan.
Latihan tanggal jatuh tempo, yang kami terapkan di beberapa tim untuk meningkatkan kemampuan prediksi, terbukti sangat baik. Esensinya adalah sebagai berikut: ketika pengembang mengambil tugas dan menyeretnya ke "sedang berlangsung", ia harus menetapkan tanggal tenggat saat tugas akan dirilis atau siap untuk dirilis. Praktek ini mengajarkan pengembang untuk menjadi manajer proyek mikro bersyarat dari tugasnya sendiri, yaitu, memperhitungkan ketergantungan eksternal dan memahami bahwa tugas tersebut hanya siap ketika klien dapat menggunakan hasilnya.
Agar pelatihan dapat berlangsung, setelah batas waktu, pengembang harus pergi ke Jira dan menetapkan batas waktu yang baru dan meninggalkan komentar dalam bentuk yang diberikan secara khusus, mengapa hal ini terjadi. Tampaknya mengapa birokrasi seperti itu diperlukan. Namun faktanya, setelah dua minggu latihan ini, kami membongkar semua komentar seperti itu dari Jira dengan skrip sederhana dan melakukan retrospektif dengan tekstur ini. Ternyata banyak wawasan tentang mengapa tenggat waktu terputus. Ini bekerja sangat keren, saya sarankan menggunakannya.
Pendekatan Masalah
Dalam pengukuran proses, kami menganut pendekatan berikut: kita perlu melanjutkan dari masalah. Kami membayangkan beberapa praktik dan proses yang ideal, dan kemudian kami kreatif dalam hal apa yang mungkin tidak berhasil.
Penting untuk memantau pelanggaran proses , dan bukan bagaimana kita mengikuti beberapa praktik. Proses seringkali tidak berhasil, bukan karena orang jahat melanggarnya, tetapi karena pengembang dan manajer tidak memiliki cukup kontrol dan memori untuk mengikuti semuanya. Melacak pelanggaran peraturan, kami dapat secara otomatis mengingatkan orang tentang apa yang perlu dilakukan, dan kami mendapatkan kontrol otomatis.
Untuk memahami proses dan praktik apa yang perlu Anda terapkan, Anda perlu memahami mengapa melakukan ini dalam tim pengembangan, apa yang dibutuhkan bisnis dari pengembangan. Semua orang mengerti bahwa tidak terlalu dibutuhkan:
- bahwa produk dikirim untuk periode perkiraan yang memadai;
- bahwa produk itu berkualitas baik, belum tentu sempurna;
- sehingga semua ini cukup cepat.
Artinya,
prediktabilitas, kualitas dan kecepatan itu penting. Oleh karena itu, kami akan melihat semua masalah dan metrik dengan tepat memperhitungkan bagaimana mereka memengaruhi prediktabilitas dan kualitas. Kami hampir tidak akan membahas kecepatan, karena dari hampir 50 tim kami bekerja dengan satu atau lain cara, hanya dua yang bisa bekerja dengan kecepatan. Untuk meningkatkan kecepatan, Anda harus dapat mengukurnya, dan sehingga setidaknya dapat diprediksi, dan ini adalah kemampuan prediksi dan kualitas.
Selain prediktabilitas dan kualitas, kami memperkenalkan arah seperti
disiplin . Kami akan menyebut disiplin segala sesuatu yang memastikan fungsi dasar proses dan pengumpulan data, berdasarkan pada analisis masalah yang dapat diprediksi dan kualitas.
Idealnya, kami ingin membangun skema kerja berikut: sehingga kami memiliki pengumpulan data otomatis; dari data ini kita dapat membuat metrik; Menggunakan metrik untuk menemukan masalah Laporkan masalah langsung ke pengembang, pemimpin tim atau tim. Maka semua orang akan dapat menanggapi mereka secara tepat waktu dan mengatasi masalah yang ditemukan. Saya harus mengatakan segera bahwa itu tidak selalu mungkin untuk mendapatkan sinyal yang dapat dimengerti. Terkadang metrik akan tetap hanya metrik yang harus dianalisis, lihat nilai, tren, dan sebagainya. Bahkan dengan data, kadang-kadang akan ada masalah, kadang-kadang mereka tidak dapat dikumpulkan secara otomatis dan Anda harus melakukannya dengan tangan (saya akan mengklarifikasi kasus tersebut secara terpisah).
Selanjutnya, kami mempertimbangkan 4 tahap kehidupan fitur:
Dan kami akan menganalisis masalah disiplin, prediktabilitas, dan kualitas apa yang dapat terjadi pada setiap tahap ini.
Masalah dengan disiplin pada tahap perencanaan
Ada banyak informasi, tetapi saya memperhatikan poin paling mendasar. Mereka mungkin terlihat cukup sederhana, tetapi mereka dihadapkan dengan sejumlah besar tim.
Masalah pertama yang sering muncul selama perencanaan adalah
masalah organisasi basi - tidak semua orang yang seharusnya ada di pertemuan perencanaan.
Contoh: tim mengeluh bahwa tester menguji sesuatu yang salah. Ternyata penguji dalam tim ini tidak pernah merencanakan sama sekali. Atau alih-alih duduk dan merencanakan sesuatu, tim dengan panik mencari tempat untuk duduk karena mereka lupa memesan ruang rapat.
Metrik dan sinyal tidak perlu dikonfigurasi, harap pastikan Anda tidak memiliki masalah ini. Pertemuan itu ditandai pada kalender, semua orang diundang ke sana, tempat diambil. Tidak peduli betapa lucu kedengarannya, ini ditemui di tim yang berbeda.
Sekarang kita akan membahas situasi di mana sinyal dan metrik diperlukan. Pada tahap perencanaan, sebagian besar sinyal yang akan saya bicarakan harus dikirim ke tim sekitar satu jam setelah akhir pertemuan perencanaan, agar tidak mengganggu tim dalam proses, tetapi tetap mempertahankan fokus.
Masalah disiplin pertama adalah
bahwa tugas-tugas tidak memiliki deskripsi, atau mereka tidak dijelaskan dengan baik. Ini dikendalikan secara elemen. Ada format yang harus sesuai dengan tugas - kami memeriksa apakah ini benar. Misalnya, kami mengikuti bahwa kriteria penerimaan ditetapkan, atau untuk tugas-tugas front-end ada tautan ke tata letak. Anda juga perlu melacak komponen yang ditempatkan, karena format deskripsi sering dikaitkan dengan komponen. Untuk tugas backend, satu deskripsi relevan, untuk tugas frontend, yang lain.
Masalah umum berikutnya adalah bahwa
prioritas diucapkan secara lisan atau tidak sama sekali dan tidak tercermin dalam data . Akibatnya, pada akhir iterasi, ternyata tugas yang paling penting belum selesai. Penting untuk memastikan bahwa tim menggunakan prioritas dan menggunakannya secara memadai. Jika tim memiliki 90% tugas dalam iterasi memiliki prioritas tinggi, itu sama dengan tidak ada prioritas sama sekali.
Kami mencoba melakukan distribusi seperti itu: 20% tugas prioritas tinggi (Anda tidak dapat membantu tetapi menurunkannya); 60% - prioritas menengah; 20% - prioritas rendah (tidak menakutkan jika kami tidak merilisnya). Kami menggantung sinyal pada semua ini.
Masalah terakhir dengan disiplin, yang terjadi pada tahap perencanaan -
tidak ada cukup data , termasuk untuk metrik selanjutnya. Dasar: tugas tidak memiliki peringkat (sinyal harus dibuat) atau jenis tugas tidak memadai. Artinya, bug dimulai sebagai tugas, dan tugas utang teknis tidak dapat dilacak sama sekali. Sayangnya, tidak mungkin untuk secara otomatis mengontrol jenis masalah kedua. Kami menyarankan hanya sekali setiap dua bulan, terutama jika Anda CTO dan Anda memiliki beberapa tim, memeriksa backlog dan memastikan bahwa orang mulai bug seperti bug, cerita seperti cerita, tugas utang teknis seperti utang teknis.
Masalah prediktabilitas pada tahap perencanaan
Kami beralih ke masalah dengan prediktabilitas.
Masalah dasarnya adalah
bahwa kami tidak termasuk dalam tenggat waktu dan perkiraan , kami salah
mengevaluasi . Sayangnya, tidak mungkin menemukan semacam sinyal atau metrik ajaib yang akan menyelesaikan masalah ini. Satu-satunya cara adalah mendorong tim untuk belajar lebih baik, menganalisis penyebab kesalahan dengan satu atau lain penilaian menggunakan contoh. Dan proses pembelajaran ini dapat difasilitasi dengan cara otomatis.
Hal pertama yang bisa dilakukan adalah berurusan dengan tugas yang jelas bermasalah dengan perkiraan waktu eksekusi yang tinggi. Kami menggantung SLA dan mengontrol bahwa semua tugas sudah cukup terurai. Kami merekomendasikan maksimum dua hari untuk memulai, dan kemudian Anda dapat beralih ke satu hari.
Paragraf berikutnya dapat memfasilitasi pengumpulan artefak, di mana dimungkinkan untuk melakukan pelatihan dan menganalisis dengan tim mengapa terjadi kesalahan dengan penilaian. Kami menyarankan untuk menggunakan praktik Tanggal jatuh tempo untuk ini. Dia membuktikan dirinya sangat keren di sini.
Cara lain adalah metrik yang disebut kode Churn sebagai bagian dari tugas. Esensinya adalah bahwa kita melihat persentase kode dalam kerangka tugas yang ditulis, tetapi tidak sesuai dengan rilis (lebih banyak dalam
laporan terakhir). Metrik ini menunjukkan seberapa baik tugas yang dipikirkan dengan matang. Oleh karena itu, alangkah baiknya memperhatikan masalah dengan lompatan Churn dan memahaminya, apa yang tidak kami perhitungkan dan mengapa kami melakukan kesalahan dalam penilaian.
Kisah berikut ini standar: tim merencanakan sesuatu, sprint diisi, tetapi pada akhirnya
tidak sama sekali dengan apa yang telah direncanakan . Anda dapat mengonfigurasi sinyal untuk isian, mengubah prioritas, tetapi untuk sebagian besar tim yang kami gunakan, mereka tidak relevan. Seringkali ini adalah operasi legal oleh manajer produk untuk melemparkan sesuatu ke dalam sprint, mengubah prioritas, sehingga akan ada banyak kesalahan positif.
Apa yang bisa dilakukan di sini? Hitung metrik dasar standar yang cukup: penutupan scout sprint awal, jumlah lemparan ke dalam sprint, penutupan lemparan itu sendiri, perubahan prioritas, lihat struktur lemparan. Setelah itu, evaluasi berapa banyak tugas dan bug yang biasanya Anda masukkan ke dalam iterasi. Selanjutnya, menggunakan sinyal untuk mengontrol bahwa Anda
meletakkan kuota ini pada tahap perencanaan .
Masalah kualitas pada tahap perencanaan
Masalah pertama:
tim tidak memikirkan fungsionalitas fitur yang dirilis . Saya akan berbicara tentang kualitas dalam arti umum - masalah kualitas adalah jika klien mengatakan itu ada. Ini bisa jadi semacam kekurangan bahan makanan, atau bisa juga hal teknis.
Mengenai kekurangan makanan, metrik seperti
churn 3 minggu bekerja dengan baik , mengungkapkan bahwa 3 minggu setelah rilis tugas churn berada di atas normal. Intinya sederhana: tugas itu tidak dirilis, dan kemudian dalam waktu tiga minggu persentase kode yang cukup tinggi dihapus. Rupanya, tugas itu tidak dilaksanakan dengan sangat baik. Kami menangkap dan menganalisis kasus-kasus tersebut dengan tim.
Metrik kedua diperlukan untuk tim yang memiliki masalah dengan bug, kerusakan, dan kualitas. Kami mengusulkan untuk membuat
grafik keseimbangan bug dan kerusakan: berapa banyak bug yang ada saat ini, berapa banyak yang tiba kemarin, berapa yang kemarin. Anda dapat menggantung
Monitor Real Time seperti itu tepat di depan tim sehingga dia melihatnya setiap hari. Ini hebat memfokuskan tim pada masalah kualitas. Kedua tim dan saya melakukan ini, dan mereka benar-benar mulai memikirkan tugas dengan lebih baik.
Masalah standar berikutnya adalah
tim tidak punya waktu untuk hutang teknis . Kisah ini mudah dipantau jika Anda mengikuti pekerjaan dengan tipe, yaitu, tugas utang teknis dievaluasi dan dimulai di Jira sebagai tugas utang teknis. Kita dapat menghitung kuota alokasi waktu apa yang diberikan kepada tim utang teknis selama kuartal tersebut. Jika kami setuju dengan bisnis bahwa itu adalah 20%, dan hanya menghabiskan 10%, ini dapat diperhitungkan dan pada kuartal berikutnya untuk mencurahkan lebih banyak waktu untuk utang teknis.
Masalah dengan disiplin dalam pengembangan
Sekarang mari kita beralih ke tahap pengembangan. Apa masalah dengan disiplin?
Sayangnya, kebetulan
pengembang tidak melakukan apa-apa, atau kami tidak dapat memahami jika mereka melakukan sesuatu. Mudah untuk melacak ini dengan dua tanda dangkal:
- frekuensi komitmen - setidaknya sekali sehari;
- setidaknya satu tugas aktif di Jira.
Jika tidak, maka itu bukan fakta bahwa Anda harus mengalahkan pengembang, tetapi Anda perlu mengetahuinya.
Masalah kedua yang dapat merobohkan bahkan orang yang paling kuat dan bahkan otak pengembang yang sangat keren adalah
pemrosesan konstan . Alangkah baiknya jika Anda, sebagai pemimpin tim, tahu bahwa seseorang memproses: menulis kode atau melakukan tinjauan kode setelah jam.
Berbagai aturan Git juga
dapat dilanggar . Hal pertama yang kami mendesak semua perintah untuk mengikuti adalah untuk menentukan awalan tugas dari pelacak dalam pesan komit, karena hanya dalam hal ini kita dapat menautkan tugas dan kode untuk itu. Di sini lebih baik tidak membangun sinyal, tetapi langsung mengkonfigurasi git hook. Untuk aturan git tambahan apa pun yang Anda miliki, misalnya, Anda tidak dapat melakukan dalam master, kami juga mengonfigurasi kait git.
Hal yang sama berlaku untuk praktik yang disepakati. Pada tahap pengembangan, ada banyak praktik yang harus diikuti pengembang. Misalnya, dalam hal Tanggal jatuh tempo, akan ada tiga sinyal:
- tugas yang batas waktunya tidak ditentukan;
- tugas yang telah jatuh tempo;
- tugas yang batas waktunya telah diubah tetapi tidak ada komentar.
Sinyal disetel untuk semua ini. Hal serupa juga dapat diatur untuk latihan lainnya.
Masalah prediktabilitas pada tahap pengembangan
Banyak hal yang bisa salah dalam perkiraan pada tahap pengembangan.
Sebuah tugas bisa bertahan dalam pengembangan untuk waktu yang lama. Kami telah mencoba menyelesaikan masalah ini pada tahap perencanaan - uraikan tugas dengan cukup baik. Sayangnya, ini tidak selalu membantu, dan
ada tugas yang membeku . Sebagai permulaan, kami sarankan untuk mengatur SLA menjadi "sedang berlangsung" sehingga ada sinyal bahwa SLA ini dilanggar. Ini tidak akan memungkinkan Anda untuk mulai melepaskan tugas lebih cepat sekarang, tetapi itu lagi akan memungkinkan Anda untuk mengumpulkan faktur, menanggapi ini dan mendiskusikan dengan tim apa yang terjadi, mengapa tugas itu hang untuk waktu yang lama.
Prediktabilitas dapat menurun jika
ada terlalu banyak tugas pada satu pengembang . Dianjurkan untuk memeriksa jumlah tugas paralel yang dilakukan pengembang berdasarkan kode, dan bukan oleh Jira, karena Jira tidak selalu mencerminkan informasi yang relevan. Kita semua adalah manusia, dan jika kita melakukan banyak tugas paralel, maka risiko bahwa ada sesuatu yang salah akan meningkat.
Pengembang mungkin memiliki beberapa masalah yang tidak dibicarakannya, tetapi yang mudah diidentifikasi berdasarkan data. Misalnya, kemarin pengembang memiliki sedikit aktivitas kode. Ini tidak berarti bahwa ada masalah, tetapi Anda, sebagai pemimpin tim, dapat muncul dan mencari tahu. Dia mungkin macet dan butuh bantuan, tetapi dia malu untuk bertanya padanya.
Contoh lain, pengembang, sebaliknya, memiliki semacam tugas besar yang terus tumbuh dan berkembang dalam kode. Ini juga dapat dideteksi dan kemungkinan didekomposisi sehingga pada akhirnya tidak ada masalah pada tinjauan kode atau tahap pengujian.
, . , , . .
. , , .
.
«» : , ; «»; «»; , bug fix. , , , , , — « ».
, , , , . , - , .
, , ,
, «» . , . ,
Legacy Refactoring , , , .
, —
SLA high-priority- . , . , , : high-priority critical .
, —
. -, . -, , . , .
-
Code review. ? , , — pull requests. -, pull request, . , , «in review», , Jira. , . , 2-3 , .
, , , pull request, . — , pull request ticket Jira .
, , , . pull requests, . , , : «, , - ». , . pull requests , , Jira.
pull request, , — , , - , - , , . .
, , — , , , , . : , « , ». , .
, , linter. , , - linter, - - , .
-
, SLA , , . , , .
SLA , "
- " — . , -. pull request .
,
- , . , CTO , , , . -. - , 6 50% - . , , 50%, CTO . , CTO - , 100%.
, — , - . :
, -.
-
, -. , .
100 . - 10 , - 1-2 . , .
— , , . , , , .
, , , , .
—
, - , . — churn -, .. pull request , .
,
- , , , . , commit, , -.
, - ( pull request ), - . , commit, . , .
. , — Jira. Jira. , «testing». task-tracker. , , - .
SLA . SLA , .
-, , , — . . , , ,
.
pipeline test- — , , , . build' , , — , . , 1-2 , , . , .
— . , . , , «» , , , , , .
, , ,
. . , , , , . , , , . : , , , .
, «» , , . , , , .
Cerita lain yang memengaruhi kualitas fase pengujian adalah ping-pong yang konstan antara pengujian dan pengembangan . Penguji hanya mengembalikan tugas ke pengembang, dan dia, pada gilirannya, tanpa mengubah apa pun, mengembalikannya ke penguji. Anda dapat melihatnya sebagai metrik, atau mengonfigurasi sinyal untuk tugas tersebut dan melihat dengan cermat apa yang terjadi di sana dan jika ada masalah.Metodologi Metrik
Kami berbicara tentang metrik, dan sekarang pertanyaannya adalah - bagaimana cara mengatasi semua ini? Saya hanya mengatakan hal-hal yang paling mendasar, tetapi bahkan banyak dari mereka. Apa yang harus dilakukan dengan semua ini dan bagaimana menggunakannya?
Kami menyarankan Anda untuk mengotomatiskan proses ini secara maksimal dan mengirimkan semua sinyal ke tim melalui bot dalam pesan instan. Kami mencoba berbagai saluran komunikasi: baik surel maupun dasbor - tidak berfungsi dengan baik. Bot telah membuktikan sendiri yang terbaik. Anda dapat menulis bot sendiri, Anda dapat mengambil OpenSource dari seseorang, Anda dapat membeli dari kami.
Intinya di sini sangat sederhana: tim bereaksi lebih tenang terhadap sinyal dari bot daripada kepada manajer, yang menunjukkan masalah. Jika memungkinkan, kirim sebagian besar sinyal langsung ke pengembang terlebih dahulu, lalu ke tim, jika pengembang tidak merespons, misalnya, dalam satu atau dua hari.
Tidak perlu mencoba membangun semua sinyal sekaligus. Sebagian besar dari mereka tidak akan berfungsi, karena Anda tidak akan memiliki data, karena masalah sepele dengan disiplin. Karena itu, pertama-tama kita membangun disiplin dan memberikan sinyal untuk praktik-praktik disipliner. Menurut pengalaman tim yang kami ajak bicara, butuh satu setengah tahun untuk sekadar membangun disiplin dalam tim pengembangan tanpa otomatisasi. Dengan otomatisasi, dengan bantuan sinyal konstan, tim mulai bekerja secara normal dengan cara yang disiplin di suatu tempat setelah beberapa bulan, yaitu, jauh lebih cepat.
Sinyal apa pun yang Anda buat publik, atau langsung langsung ke pengembang, tidak dapat Anda ambil dan nyalakan. Pertama, Anda perlu mengoordinasikan ini dengan pengembang, berbicara dengannya dan tim. Dianjurkan untuk memasukkan semua nilai ambang batas dalam Perjanjian Tim secara tertulis, alasan mengapa Anda melakukan ini, apa langkah selanjutnya, dan seterusnya.
Harus diingat bahwa semua proses memiliki pengecualian, dan memperhitungkan ini pada tahap desain.
Kami tidak membangun kamp konsentrasi untuk pengembang di mana tidak mungkin untuk mengambil langkah ke kanan, langkah ke kiri. Semua proses memiliki pengecualian, kami hanya ingin tahu tentang mereka. Jika bot terus-menerus bersumpah tentang beberapa tugas yang benar-benar tidak dapat diuraikan, dan yang membutuhkan waktu 5 hari untuk bekerja, Anda perlu memberi tanda "tidak ada pelacakan" sehingga bot memperhitungkannya. Anda, sebagai manajer, dapat secara terpisah memantau jumlah tugas "tanpa pelacakan" tersebut, dan dengan demikian memahami seberapa baik proses dan sinyal yang Anda buat. Jika jumlah tugas yang berlabel “tidak ada pelacakan” tumbuh dengan mantap, maka, sayangnya, ini berarti bahwa sinyal dan proses yang Anda temukan sulit bagi tim, itu tidak dapat mengikuti mereka, dan lebih mudah untuk mengatasinya.
Kontrol manual masih tetap ada . Tidak akan berhasil menyalakan bot dan meninggalkan suatu tempat di Bali - Anda masih harus berurusan dengan setiap situasi. Anda mendapat semacam sinyal, orang itu tidak menanggapinya - Anda harus mengetahui alasannya dalam satu atau dua hari, membicarakan masalahnya dan mencari solusinya.
Untuk mengoptimalkan proses ini, kami menyarankan untuk memperkenalkan praktik seperti
petugas proses . Ini adalah posisi transisi seseorang (seminggu sekali) yang memahami masalah yang ditandakan bot. Dan Anda, sebagai pemimpin tim, membantu petugas menangani masalah-masalah ini, yaitu, awasi dia. Dengan demikian, pengembang meningkatkan motivasi untuk bekerja dengan produk ini. Dia memahami manfaatnya, karena dia melihat bagaimana masalah ini dapat diselesaikan dan bagaimana bereaksi terhadapnya. Dengan demikian, Anda mengurangi keunikan Anda ke tim dan
membawa lebih dekat saat ketika tim menjadi otonom , dan Anda masih bisa pergi ke Bali.
KesimpulanKumpulkan data. Bangun proses sehingga Anda memiliki data yang dikumpulkan. Bahkan jika Anda tidak ingin membangun metrik dan sinyal sekarang, Anda dapat melakukan analisis retrospektif yang keren di masa mendatang jika Anda mulai mengumpulkannya sekarang.
Secara otomatis mengontrol proses. Saat merancang proses, selalu pikirkan tentang bagaimana Anda bisa meretasnya, dan bagaimana Anda bisa mengenali peretasan seperti itu dari data.
Ketika sinyal sedikit selama beberapa minggu - bagus sekali! Kami dihadapkan dengan fakta bahwa ketika tim melihat bahwa ada lebih sedikit sinyal, dan tampaknya situasinya membaik, ia mulai dengan panik melakukan beberapa praktik lain, mulai menerapkan sesuatu untuk melihat paket sinyal ini lagi. Ini tidak selalu diperlukan, mungkin jika ada lebih sedikit sinyal - semuanya baik-baik saja dengan Anda, tim mulai bekerja seperti yang Anda inginkan sejak awal, dan Anda selesai :)
Ayo bagikan temuan Timlid Anda di TeamLead Conf . Konferensi Februari akan diadakan di Moskow dan Call for Papers sudah terbuka .
Apakah Anda ingin mengalami pengalaman orang lain? Mendaftarlah untuk buletin manajemen kami untuk menerima berita tentang program ini dan jangan lewatkan waktu untuk menawar tiket konferensi.