Pertanyaan tentang bagaimana mengevaluasi keefektifan proses pengembangan ada seperti halnya pengembangan itu sendiri. Seringkali pengembang dapat mematuhi gagasan bahwa Anda hanya perlu menulis kode kualitas, tetapi semua optimisasi, aksi unjuk rasa ini, pelacakan aktivitas, dan sebagainya adalah kemauan manajerial. Para pemimpin, pada gilirannya, percaya bahwa di atas segalanya adalah produk dan kami sebenarnya memiliki bisnis di sini, bukan klub yang diminati: jadi tidak mungkin dilakukan tanpa metrik. Tetapi seberapa pentingkah metrik sama sekali?

Pada awal September, kami mengadakan pertemuan untuk para manajer pengembangan dan membicarakannya dengan orang-orang dari
Plesk, Avito, Dodo Pizza, Tinkov, Agima, CIAN, Yandex. Vertikal, DocDoc - yah, kami tidak melupakan diri kami sendiri. Di bawah ini adalah perasan dari apa yang dibicarakan tamu kami.
Dalam tim kecil, metrik tidak begitu penting
Ketika Anda mengelola tim yang terdiri dari lima hingga sepuluh orang, Anda menjadi unit tempur yang disepakati, sebuah kolektif di mana setiap orang mengenal semua orang. Pengembang menghabiskan waktu bersama, bekerja bahu membahu, dan sering berkomunikasi di luar pekerjaan. Tidak sulit untuk bergabung dengan tim STO ini: pemimpin menjadi anggota penuh tim dan memiliki kesempatan untuk berkomunikasi langsung dengan setiap orang. Semua konflik, masalah, atau kesulitan yang mungkin dihadapi suatu tim terlihat jelas, dan praktis tidak ada hambatan administratif antara stasiun layanan dan bawahannya.
Mengelola tim yang kompak dalam hal mengevaluasi efektivitasnya jauh lebih sederhana: karena tidak banyak peserta dalam alur kerja, solusi atau metode yang tidak efektif segera terlihat. Dan pengembang dengan mudah melakukan kontak dengan seniornya, karena mereka berkomunikasi dengannya setiap hari.
Dengan seratus pengembang, semuanya jauh lebih rumit
Begitu ukuran tim meningkat beberapa kali dan bukan 5-10, tetapi 50-100 orang, situasinya berubah secara dramatis. Sekarang pemimpin tidak dapat berkomunikasi secara pribadi dengan semua orang, dan kami membutuhkan metrik yang jelas dan efektif.
Solusi pertama dan paling jelas adalah manajer tugas dan analisis jumlah tugas tertutup. JIRA dan alat-alat serupa dapat menyediakan serangkaian data bermanfaat yang spesifik. Misalnya, analisis tugas tertutup akan mengungkapkan adanya beberapa masalah tanpa komunikasi pribadi dengan pengembang.
Misalnya, ketika metrik dibentuk di DocDoc, mereka awalnya berhenti sebanyak tujuh indikator, tetapi pada akhirnya hanya ada tiga:
- kenyamanan / kesenangan dari pekerjaan ;
- rasio yang dijanjikan dan waktu yang dihabiskan untuk tugas itu;
- waktu siklus hidup tugas.
Metrik pertama adalah subyektif dan menandai situasi di tim dan iklim mikro secara keseluruhan. Yang kedua dan ketiga - terkait langsung dengan pengembangan dan mencerminkan parameter penting pada waktu itu: banyak tim memiliki masalah dengan memenuhi tenggat waktu.
Saluran lain untuk mendapatkan informasi adalah kuesioner, yang juga tidak boleh dihindari. Misalnya, seluruh tim pengembangan Skyeng terdiri dari karyawan terdistribusi, dan karena perbedaan zona waktu, sulit untuk berbicara satu sama lain secara pribadi secara fisik. Bagi kami, jajak pendapat berkala dalam format online adalah jalan keluarnya. Mereka tidak membutuhkan banyak waktu, seorang karyawan dapat melewati mereka ketika itu nyaman baginya, dan untuk ini Anda tidak perlu memesan slot di kalender atau ruang pertemuan di kantor Moskow.
Masalahnya adalah bahwa pengembang tidak selalu berbicara tentang apa yang membuat mereka khawatir pada waktunya. Informasi ini hanya dapat diperoleh melalui komunikasi pribadi, sehingga CTO yang baik harus memiliki "jam buka", atau bahkan percakapan harus direncanakan dengan semua pemimpin tim dan pengembang dalam penyerahan.
Setiap pengembang harus memiliki hak untuk membuat janji temu dengan manajer yang lebih tinggi, melewati pemimpin tim mereka sendiri . Jika tidak, Anda akan menghadapi kekekalan masalah dan kesunyiannya.
Komunikasi dengan pelanggan
Tidak masalah jika Anda bekerja di perusahaan grosir atau outsourcing. Setiap pengembangan selalu memiliki pelanggan: internal atau eksternal. Di beberapa perusahaan itu dinyatakan secara eksplisit, di beberapa - tidak, tetapi selalu ada pelanggan.
Umpan balik pelanggan adalah informasi yang cukup penting, karena dapat mengungkapkan masalah yang tidak terlihat dari dalam dan melihat proses pengembangan dari luar. Jika klien benar-benar puas dan tidak dapat berkomentar tentang interaksinya dengan pengembang, maka di depan ini semuanya berjalan lebih atau kurang berhasil dan masalah internal tidak meluas dari kolektif.
Di sisi lain, sebuah skenario dimungkinkan di mana, tampaknya, perkembangannya bergerak, tetapi menurut penarikan kembali pelanggan itu lebih seperti kekacauan daripada produk: kegagalan untuk memenuhi tenggat waktu, masalah komunikasi, interpretasi TK yang salah. Setiap komentar ini adalah alasan serius untuk menyelidiki proses tim dan mencari tahu apakah semuanya benar-benar demikian. Jika kata-kata pelanggan dikonfirmasi, maka Anda perlu mencari apa yang menyebabkan masalah.
Hasil tes mungkin tidak terduga. Jadi, misalnya, beberapa pertanyaan muncul karena motivasi karyawan yang tidak memadai: sulit bagi siapa pun untuk memberikan yang terbaik setiap hari dan tidak mendapatkan insentif untuk pekerjaan mereka. Dan dalam hal ini, jangan bingung antara "dorongan" dengan "kompensasi" (yang kedua adalah gaji). Dalam hal ini, baik insentif material maupun non-material cocok: bonus, bonus, beberapa acara perusahaan dan chip untuk karyawan. Bahkan mengganti peralatan atau
memenuhi permintaan "opsional" dari bawahan dapat menunjukkan kepada pengembang bahwa pekerjaan mereka bernilai dan diperhatikan. Dan ini, pada gilirannya, akan meningkatkan "moral" dan produktivitas.
Terutama yang berhati-hati dalam situasi ini adalah memperlakukan karyawan "pendukung" yang, karena upaya gila mereka sendiri, menutup para anggota tim lainnya. Ada orang-orang seperti itu di tim mana pun, dan bahkan jika tim secara keseluruhan baik-baik saja, Anda tidak boleh lupa tentang kontribusi karyawan tersebut. Karena jika mereka "terbakar", maka semuanya akan terbang ke jurang.
Intinya: metrik tidak berguna tanpa berbicara dengan orang
Gagasan utama dari semua pidato tentang topik metrik: kebenaran hanya dapat dicapai dalam percakapan langsung. Metrik memungkinkan Anda mengidentifikasi masalah di tingkat statistik, tetapi penting untuk diingat bahwa mereka hanya menunjukkan konsekuensinya.
- Metrik tidak akan memberi tahu Anda bahwa troll telah dimulai di tim yang meracuni situasi di tim, atau bahwa mereka menempatkan orang hijau di tim, yang membayangkan dirinya sebagai pemimpin tim terbaik yang pernah hidup di planet ini.
- Metrik tidak akan memberi tahu Anda bahwa alat yang baru saja diperkenalkan ini tidak hanya menyakiti semua pengembang, tetapi setelah pembaruan terakhir, alat ini juga merupakan sepotong kode byd seseorang yang tidak efektif dalam segala hal.
- Metrik tidak akan memberi tahu Anda bahwa pada tahap komunikasi dengan klien dan diskusi tentang TK, kekacauan seperti itu terjadi sehingga tim alih-alih menggunakan "trem" bersyarat mulai membuat "bus troli dari sepotong roti".
Metrik hanya dapat menunjukkan fakta masalah.Tapi apa esensinya - Anda perlu memahami di lapangan. Memahami melalui percakapan, pertemuan, jajak pendapat, yaitu melalui interaksi langsung dengan orang yang hidup. Dan metrik akan menunjukkan kepada Anda di mana, kapan dan dengan siapa Anda perlu bicara, tetapi tidak lebih.
ps Di mitap, mereka berbagi pandangan:
* Sergey Lystsev (Plesk);
* Egor Tolstoy (Avito);
* Alexander Andronov (Dodo Pizza);
* Andrey Shelyokhin (Tinkov);
* Alexey Parshukov (Skyeng, ex-DocDoc);
* Andrey Ryzhkin (Agima);
* Alexey Chekanov (TsIAN);
* Danila Shtan (Yandex. Vertikal, ex-Tochka)
Terima kasih banyak
pps Jika Anda tertarik untuk mendengarkan / menonton versi lengkap dari mitap (ini juga mencakup pertanyaan tentang motivasi finansial, perekrutan, tingkat pencelupan CTO dalam teknologi, dll.) - tulis secara pribadi. Rekor itu ternyata tidak terlalu berkualitas tinggi, jadi kami tidak mulai mempublikasikannya: tetapi kami selalu siap untuk membagikannya kepada mereka yang benar-benar membutuhkannya.