Pada bagian pertama dari laporan ini, kami menguraikan bagaimana mengukur kualitas dokumentasi dan efektivitas pengembangannya. Sekarang selami rincian penghitungan metrik.
Kata Yuri Nikulin, kepala layanan pengembangan dokumentasi teknis.
Untuk memulai, mari kita tentukan apa itu kinerja. Dalam pengertian klasik, ini adalah waktu yang diambil untuk menghasilkan unit output atau jumlah output yang diproduksi per unit waktu .
Misalnya, ini adalah jumlah ponsel yang diproduksi per bulan atau jumlah waktu yang diperlukan untuk menghasilkan ribuan ponsel. Timbul pertanyaan bagaimana mengukur kerja intelektual yang dilakukan departemen kami.
Jika kita menerapkan pendekatan klasik untuk mengevaluasi produktivitas, kita dapat menghitung berapa banyak dokumen, halaman, atau kata-kata yang ditulis per hari, minggu dan bulan. Ini akan membantu memperkirakan waktu potensial untuk produksi dokumentasi di masa depan, tetapi tidak akan menjawab pertanyaan tentang produktivitas. Lagi pula, kami jelas tidak tertarik untuk mengevaluasi keefektifan penulis dengan jumlah kata yang ditulis oleh mereka. Karenanya, kami memutuskan bahwa kami harus mulai dengan persyaratan untuk metrik yang kami rencanakan untuk dihitung.
Kami telah mengidentifikasi beberapa kriteria untuk memilih metrik:
- Transparansi Pendekatan untuk menghitung metrik dan menafsirkan hasil harus jelas tidak hanya bagi kami, tetapi juga bagi pelanggan.
- Ketersediaan data. Termasuk data untuk setiap periode terakhir untuk mengajukan hipotesis dan mencoba mengonfirmasinya dengan data historis.
- Kemampuan untuk mengotomatisasi penghitungan. Kami pasti tidak ingin menghitung metrik dengan tangan.
Akibatnya, kami menyadari bahwa objek ideal untuk menghitung metrik kinerja adalah tugas di Pelacak. Itu memenuhi semua persyaratan yang kami tetapkan untuk metrik.
Sumber data untuk kami adalah Yandex.Tracker. Ini cukup fleksibel dan mudah disesuaikan untuk tugas kita. Sudah memiliki semua data yang diperlukan, karena kami menggunakan alat ini setiap hari. Dan Pelacak juga memiliki API, yang berarti Anda dapat menggunakan informasi ini dan mengotomatiskan proses.
Jadi kami punya rencana untuk melanjutkan.
Siapkan antrian dan tugas
Anda harus mulai dengan memilih antrian, hierarki tugas, jenis dan statusnya.
Ini dijelaskan secara rinci oleh Katya Kunenko dalam laporan " Alat untuk persiapan dokumentasi pengguna ". Kami akan secara singkat berbicara tentang antrian dan tugas, yang kami gunakan sendiri.
Antrian
Kami memiliki tiga baris, yang intinya mencerminkan target pemirsa kami.
Hirarki tugas
Tugas kami memiliki struktur dua tingkat:
- di tingkat atas, tugas sesuai dengan dokumen yang diterbitkan,
- di tingkat bawah, tugas-tugas sesuai dengan pekerjaan pada dokumen.
Jenis dan status tugas
Jenis dan status tugas tidak hanya memungkinkan kami untuk mengklasifikasikan jenis pekerjaan dan statusnya saat ini, tetapi juga mempertimbangkan metrik kami dengan bagian.
Garis waktu untuk menyelesaikan tugas. Garis biru adalah waktu produksi rata-rata dokumen, oranye adalah waktu untuk memperbaiki bug, hijau adalah waktu rata-rata untuk menyelesaikan tugas semua jenis.
Kami akan memberi tahu contoh grafik. Misalnya, bug diperbaiki dalam 1-5 hari, dan dibutuhkan 30-40 untuk menulis dokumen baru. Pada saat yang sama, kami jarang menulis dokumen baru daripada menambah yang lama atau memperbaiki kesalahan. Oleh karena itu, waktu eksekusi rata-rata dari tugas apa pun (garis hijau) terlalu lama untuk bug dan terlalu pendek untuk dokumen baru. Dengan bantuannya, kami hanya mendapatkan gagasan rata-rata tentang kecepatan penyelesaian masalah.
Karena kami mempertimbangkan metrik untuk mengoptimalkan proses, kami perlu melihat irisan yang lebih tepat: misalnya, berapa lama kami telah menyelesaikan masalah "bug" atau "dokumen baru". Dan rata-rata untuk semua jenis dapat dilihat untuk melacak tren secara keseluruhan.
Kami menggunakan serangkaian jenis tugas.
Ada lebih banyak status daripada tipe, karena alur kerja memerlukan ini.
Lebih mudah untuk bekerja dengan jenis dan status jika tidak ambigu dan jumlahnya tidak terlalu banyak. Jika tidak, para pemain mungkin bingung.
Cara mempertimbangkan metrik kinerja
Pada bagian terakhir, kami mengatakan bahwa kami melakukan penelitian dan memilih 20 metrik dokumentasi dari 136. Enam di antaranya adalah metrik kinerja.
Ada dua aspek untuk menghitung metrik.
- Menghitung metrik yang diiris. Di atas, kami memberi tahu apa itu dan mengapa itu penting bagi kami.
- Menghitung nilai rata-rata.
Pendekatan klasik menghitung nilai rata-rata adalah merangkum semua indikator dan membaginya dengan angka mereka. Pendekatan ini tidak selalu berhasil dengan baik karena memperhitungkan kasus yang merosot. Misalnya, kita tahu bahwa sebagian besar bug yang kita perbaiki dalam sehari. Tetapi ada kasus yang merosot - misalnya, tiket hilang atau karyawan berhenti - maka dibutuhkan lebih banyak waktu untuk memperbaikinya. Misalkan kita memiliki enam bug untuk periode yang sedang ditinjau. Kami memutuskan lima dalam sehari, dan satu dari 115. Ternyata perbaikan bug rata-rata adalah 20 hari. Tetapi angka ini tidak mencerminkan kenyataan: kami hampir selalu memperbaiki kesalahan untuk hari itu, dan satu tiket panjang mempengaruhi indikator ini secara signifikan.
Dalam kasus seperti itu, persentil datang untuk menyelamatkan. Ini adalah nilai maksimum (dalam kasus kami, metrik), yang sesuai dengan persentase objek yang ditentukan. Misalnya, persentil ke-80 adalah nilai yang tidak melebihi 80% dari objek dalam sampel. Dalam kasus kami, nilai seperti itu akan menjadi nilai 1, karena 83% objek tidak melebihi itu.
Di sini bidang ketiga muncul - waktu kami menghitung metrik. Hampir semua metrik kami dihitung dalam 30 hari.
Kami menganggap metrik dengan pemotongan sebagai berikut:
- pertama semua baris bersama,
- lalu kami memotong secara bergiliran
- kemudian kami detail: kami membuat antrian dengan potongan untuk semua jenis tugas.
Setiap bagian selanjutnya dari metrik menyempurnakan yang sebelumnya. Nilai rata-rata untuk semua antrian, jenis dan status tugas memberikan gagasan umum. Kami kemudian mempertimbangkan nilai untuk masing-masing antrian untuk memahami bagaimana segala sesuatunya dengan dokumentasi teknis, pengguna, atau internal. Pada level terakhir, yang paling terperinci, kami sedang mengerjakan baris "antrian + jenis dan status".
Lebih lanjut kami akan memberi tahu bagaimana kami mempertimbangkan metrik kinerja.
Jumlah tugas tertutup
Seperti yang kami pertimbangkan: sesuai dengan jumlah tugas yang ditutup dalam interval [31 hari yang lalu; kemarin].
Jumlah tugas yang dilakukan
Seperti yang kita pertimbangkan: sesuai dengan jumlah tugas yang dimulainya pekerjaan dalam interval [31 hari yang lalu; kemarin].
Jumlah hari sebelum merekrut
Seperti yang kita pertimbangkan:
- Untuk setiap tugas yang diambil untuk bekerja dalam periode waktu yang ditentukan (tanggal mulai dalam Pelacak dalam interval [31 hari yang lalu; kemarin]), kami mempertimbangkan jumlah hari penuh yang berlalu antara pernyataan (tanggal pembuatan lapangan) dan awal tugas (tanggal mulai lapangan) .
- Kami merangkum semua nilai yang diperoleh pada langkah pertama.
- Kami membagi jumlah yang diterima dengan jumlah tugas yang kami lakukan pada item pertama.
Untuk persentil, item 3 dihilangkan, nilai-nilai diurutkan dalam urutan naik, dan nilai yang sesuai dengan persentil yang diberikan dipilih.
Jumlah hari yang harus diselesaikan
Seperti yang kita pertimbangkan.
- Untuk setiap tugas yang diselesaikan dalam periode waktu yang ditentukan (tanggal akhir dalam Pelacak dalam interval [31 hari yang lalu; kemarin]), kami mempertimbangkan jumlah hari penuh yang berlalu antara awal pekerjaan (tanggal mulai bidang) dan tugas (tanggal akhir bidang).
- Kami merangkum semua nilai yang diperoleh pada langkah pertama.
- Kami membagi jumlah yang diterima dengan jumlah tugas yang kami lakukan pada item pertama.
Untuk persentil, item 3 dihilangkan, nilai-nilai diurutkan dalam urutan naik, dan nilai yang sesuai dengan persentil yang diberikan dipilih.
Jumlah tugas tanpa reaksi lebih dari 14 hari
Seperti yang kami yakini: berdasarkan jumlah tugas yang tidak ada yang terjadi selama lebih dari 14 hari. Itu ditentukan oleh bidang yang diperbarui dalam Pelacak: nilai bidang harus kurang dari "kemarin - 14 hari".
Utang teknis
Seperti yang kami pertimbangkan: berdasarkan jumlah tugas yang status Backlog diatur dalam Pelacak.
Implementasi teknis dari perhitungan metrik kinerja
Di tingkat atas, sistem penghitungan metrik terdiri dari komponen dan tautan informasi berikut.
Program penghitungan metrik terjadwal
Kami menggunakan Nirvana , platform komputasi universal. Ini secara formal menggambarkan urutan proses diluncurkan. Bersama dengan internal scheduler (scheduler) Nirvana menggantikan kita dengan satu set skrip bash dan cron.
Program yang ditulis dengan Python berjalan secara teratur dan meminta data yang diperlukan untuk menghitung metrik.
Sistem pengaturan tugas
Data untuk menghitung metrik dalam kasus kami disimpan di Yandex.Tracker. Sebagai antarmuka ke data, kami menggunakan Yandex.Tracker Python API - ini adalah pembungkus pada HTTP API, yang memungkinkan lebih cepat dan lebih mudah untuk menerima informasi dalam struktur data yang cocok untuk diproses lebih lanjut.
Anda dapat memilih sistem yang nyaman dengan API yang sesuai, misalnya, Jira.
Sistem Persiapan Grafik
Setelah menghitung metrik berdasarkan data dari Yandex.Tracker, program kami menghasilkan file JSON dan mentransfernya ke layanan internal Yandex.Statistics untuk menggambar grafik.
Anda dapat menggunakan beberapa jenis pustaka JS yang dapat membuat grafik. Gambaran umum dari beberapa solusi serupa ada di Habré:
15 perpustakaan JavaScript terbaik
Pada bagian selanjutnya, kami akan menjelaskan bagaimana kami mempertimbangkan metrik kualitas dokumentasi pengguna.