Metrik - indikator kesehatan proyek

Dalam TI, proyek yang sehat adalah sistem atau layanan yang, di satu sisi, berkualitas tinggi, yaitu, memenuhi persyaratan dan pengguna menyukainya. Di sisi lain, ini menghasilkan keuntungan, karena bisnis selalu benar-benar ingin menghasilkan uang. Tanpa bundel kualitas dan bisnis, tidak ada hal baik yang akan terjadi.



Di bawah potongan, Ruslan Ostropolsky akan memberi tahu Anda semua tentang metrik yang merupakan indikator kesehatan sistem TI. Dia akan menganalisis metrik apa, bagaimana mereka berubah saat proyek berkembang, mana yang paling baik digunakan dalam proyek mana. Menjelaskan bagaimana kualitas dan bisnis saling membantu dalam hal metrik dan mengapa kolaborasi ini diperlukan.


Tentang pembicara dan perusahaan: Ruslan Ostropolsky di bidang TI sejak 2010, bidang utama yang diminati adalah jaminan kualitas. Selama 5 tahun terakhir ia telah bekerja di DocDoc, sebuah perusahaan yang mengembangkan layanan Internet medis. Produk utama adalah penunjukan online dengan dokter, lebih dari 2 juta pasien telah mendaftar untuk dokter melalui DocDoc, ada juga garis diagnostik, telemedicine dan asuransi VHI.

Ketika kualitas dan bisnis bukan teman

Tanpa jaminan kualitas, akan sulit bagi bisnis untuk menghasilkan uang dalam jangka panjang. Butuh banyak kualitas dan bisnis. Jika tidak, maka situasi berikut mungkin terjadi.

Pertama, ada kualitas demi kualitas : ketika semua jenis pengujian yang dikenal digunakan dalam satu startup kecil. Anda dapat langsung berpikir tentang otomatisasi dan pengujian di bawah beban, tetapi jika Anda berlebihan, produk mungkin masih belum mencapai produksi. Karena itu, Anda perlu:

• Memahami bisnis - apa yang relevan saat ini: menghasilkan uang, memasuki pasar atau skala dengan cepat. Tugas bisnis adalah untuk mentransfer tujuan-tujuan ini ke departemen teknis.
• Kualitas di tempat yang tepat dan dalam jumlah yang tepat. Kadang-kadang, Anda dapat merilis rilis dengan bug, tetapi memahami risikonya, dan karenanya, pertimbangkan ini.

Kedua, ada kasus lain - bisnis tanpa kualitas . Sebuah perusahaan IT bahkan mungkin memiliki departemen pengujian, tetapi jika QA ringan atau ada dalam bentuk pengujian monyet, yang hanya menghapus regresi dan berhenti di sana, maka ini tidak akan banyak membaik.

NB: QA tidak benar-benar menguji, tetapi pendekatan tingkat perusahaan umum untuk bagaimana Anda membuat produk yang baik.

Bagaimana memahami apakah Anda sedang mengembangkan yang berkualitas tinggi atau tidak?


Penilaian obyektif membutuhkan metrik yang menunjukkan:

• Fakta masalah. Bahwa pada dasarnya Anda memiliki masalah, dan jika tidak ada masalah, Anda perlu mencarinya dengan lebih cermat. Kemungkinan besar, mereka ada di suatu tempat, hanya saja Anda masih tidak melihatnya.
• Fakta hasilnya. Proyek dibuat untuk menghasilkan uang, memasuki pasar, meningkatkan konversi. Hasil ini perlu dilacak.
• Kondisi saat ini. Di mana Anda dalam perjalanan menuju sasaran Anda, berapa banyak bug yang Anda miliki saat ini, apakah Anda berhasil berlari, seberapa cepat Anda bergerak.

Cara memilih metrik

Anda dapat memilih metrik berdasarkan tiga prinsip.

Dimana itu sakit. Jika suatu insiden terjadi, perlu dibongkar, ditimbang dengan metrik dan lihat rasa sakitnya: bagaimana perawatannya, dinamika apa, apakah bug diperbaiki.


Dengan pendekatan yang ditargetkan, kami jelas fokus pada tujuan, misalnya, akselerasi dan otomatisasi. Sebelumnya, pengujian otomatis kami memakan waktu dua jam. Kami menetapkan sasaran dalam 10 menit dan melihat metrik untuk melihat apakah kami mendekati nilai ini.


Tetapi tidak mungkin untuk mendapatkan proyek yang sehat jika metrik tidak memiliki koneksi dengan bisnis, mereka hanya teknis, dan bisnis tidak mendapatkan hasil. Sebaliknya, jika tidak ada bug, dan bisnis kehilangan uang, maka sesuatu yang aneh sedang terjadi.


Penting untuk diingat bahwa ada berbagai bisnis dan tahapan proyek yang berbeda. Startup, perusahaan yang sedang berkembang, atau proyek ekspansi membutuhkan metrik yang berbeda. Ini seperti penyakit - jika Anda hanya batuk, Anda bisa mengukur suhunya, minum asam askorbat, dan semuanya akan berlalu. Jika Anda memiliki kecurigaan pneumonia, Anda perlu mengambil gambar, pergi untuk pemeriksaan dan diperlakukan berbeda.

Metrik pada berbagai tahap proyek

Saya akan memberi tahu Anda metrik apa yang kami ukur saat kami startup, dan kemudian mulai tumbuh dan berkembang.

Startup

Pada tahap ini, produk hanya dalam masa pertumbuhan, Anda menguji hipotesis, menyelidiki apakah orang membutuhkannya.


Pada tahap startup untuk bisnis, penting bahwa ide-ide dikirimkan kepada pengguna secepat mungkin, dan mereka dapat diverifikasi. Artinya, Anda perlu mengukur waktu-ke-pasar - kecepatan pengiriman ide kepada pengguna (yaitu untuk produksi, dan bukan hanya untuk melepaskan) dan jumlah pelanggan .

Di bagian QA, kami hanya memiliki 3-5 metrik:

• jumlah bug dari pertempuran;
• jumlah bug yang mencapai rilis;
• kekritisan bug.

Jawaban atas pertanyaan tentang cara mengumpulkan metrik sederhana: ada tangan dan ada Excel. Sekitar sebulan sekali, letakkan tangan Anda di tabel data, ini sudah cukup.

Sedang tumbuh

Pada tahap selanjutnya, kita sudah belajar berdiri di atas kaki kita, kita berjalan sedikit.


Kebutuhan bisnis berkembang, menjadi penting untuk diukur:

• Lalu lintas Ketika menjadi jelas bahwa pengguna membutuhkan produk, lalu lintas sebanyak mungkin dihasilkan, misalnya, program afiliasi muncul.
• Penskalaan - sebisa mungkin tumbuh baik dari sisi produk, dan dari sisi pengembangan.

QA sudah semakin besar: 10-15 metrik. Jika dalam startup kami membuat produk sesuai dengan perasaan kami, misalnya, pendiri berkata: "Saya ingin tombol biru," dan semua orang melakukannya, sekarang ada statistik pertama. Anda dapat melewati fitur melalui tes A / B dan ingat untuk mengukur hasilnya.

Otomasi muncul. Pengujian monyet tidak lagi cukup, dan masuk akal untuk berinvestasi dalam ekstensi. Pada titik ini, pengujian otomatis muncul, yang seharusnya membantu membuat pengujian regresi lebih cepat. Dengan demikian, kecepatan pengujian rilis diukur : seberapa banyak otomatisasi dibenarkan. Sungguh menyedihkan ketika otomasi memakan waktu enam bulan, dan untuk beberapa alasan rilis tidak mempercepat.

Volume rilis juga diukur untuk melihat apakah, misalnya, alih-alih 5 pengembang, menjadi 15, tetapi karena beberapa alasan volume rilis belum bertambah.

Untuk mengumpulkan metrik pada tahap pertumbuhan, selain tangan dan Excel, sistem khusus muncul. Sistem adalah alat yang membantu menciptakan suatu produk. Jika sebelumnya kasus uji yang sama ditulis dalam Google docs, mereka muncul di sini:

• manajer sistem, misalnya, TestRail;
• Google Analytics untuk mengumpulkan data pengguna;
• Laporkan portal, Daya pikat untuk otomatisasi.

Sistem itu sendiri membangun metrik dan laporan tambahan.

Gendut

Kita tumbuh lebih jauh, “tumbuh terlalu tinggi dengan lemak” - kita tidak masuk ke kantor tempat kita duduk, dan kita mulai bergerak secara berkala.


Apa yang penting untuk bisnis?

• LTV. Perlu mempertahankan pelanggan. Jika sebelumnya klien mencatat sekali dan pergi, sekarang, jelas, perlu untuk mempertahankannya, untuk membangun layanan pengguna.
• Merek / Reputasi. Jika sebelumnya orang yang menghubungi DocDoc dapat berpikir bahwa ini adalah klinik, sekarang mereka tahu bahwa mereka berada dalam layanan yang membantu mereka.
• SLA Ketika orang mulai menggunakan layanan secara terus-menerus, ketersediaan layanan menjadi kritis, karena setiap waktu henti secara langsung memengaruhi uang.
• Data Data pertama muncul, baik produk dan teknis dan pengguna, yang harus dapat memproses dan menyimpan. Ada pertanyaan keamanan.
• Konversi Pada tahap penskalaan, produk yang secara fundamental baru tidak dibuat, tetapi yang dibuat membaik.

QA sudah mencakup sekitar 30-50 metrik. Kami mengukur:

• Load: backend, server dan depan, dan dalam irisan yang berbeda.
• Keamanan
• Tingkat rilis.
• Kecepatan otomasi.
• Stabilitas otomasi: kecepatan dan stabilitas otomasi secara langsung memengaruhi kecepatan pelepasan, karena regresi manual bukanlah tempat pada tahap ini dalam pengembangan proyek.
• Cakupan Otomatisasi.

Kami mengumpulkan data seperti sebelumnya, tetapi ada lebih banyak sistem yang digunakan.

Kesulitan

Semuanya tidak terjadi dengan lancar, dan kami tidak terkecuali. Saya akan memberi tahu Anda kesulitan apa yang kami temui ketika proyek telah cukup berkembang.


Ada banyak sistem , ada kebutuhan untuk mengelolanya entah bagaimana. Melihat masing-masing sistem setidaknya banyak waktu.

Jumlah arah , baik bahan makanan dan teknis, telah bertambah . Selain itu, setiap arah berkembang secara berbeda, beberapa di antaranya diluncurkan sebagai startup, dan akan salah jika menempatkan metrik dan jaminan kualitas pada mereka semua.

Proses menjadi lebih rumit : jika sebelumnya 5 orang bekerja di proyek, mudah untuk menyetujui dan bertindak sesuai, sekarang kita perlu memantau prosesnya. Sebagai contoh, orang-orang baru perlu diperkenalkan secara bertahap, jika tidak maka akan sulit bagi mereka untuk memahami akumulasi jumlah sistem.

Data dan laporan unik dalam layanan ini. Ini mengikuti dari kenyataan bahwa ada banyak sistem, dan Anda perlu memperhatikan semuanya. Setiap layanan menghasilkan laporannya sendiri, dan Anda harus mengikuti semuanya. Selain itu, semakin sulit untuk mengonfigurasinya sendiri: Anda perlu menghubungi dukungan teknis untuk laporan baru, atau mencoba mengonfigurasinya sendiri menggunakan skrip.

Dan jika ada banyak data, maka Excel tidak membantu . Terutama jika lusinan orang mulai mengerjakan satu file di mana semuanya diatur pada formula - seseorang mengubah sesuatu, semuanya rusak - mereka melihatnya dalam seminggu.

Mungkin ini adalah bagaimana analis muncul di perusahaan - orang-orang khusus yang mengumpulkan dan memelihara statistik dan data, karena terlalu banyak waktu untuk digabungkan.

Dan tentu saja, menjadi jauh lebih sulit untuk menganalisis informasi karena fakta bahwa sekali lagi ada banyak sistem, data yang berbeda yang ingin Anda hubungkan satu sama lain.

Perlakukan kesedihan

Anda bisa pergi ke laut, bersantai, kembali dan melihat pengalaman perusahaan lain.


Solusi logisnya adalah menyatukan semuanya dalam hal data dan mengubahnya menjadi metrik.

Kami merumuskan kriteria berikut:

• Mengumpulkan secara otomatis sehingga tidak ada tangan memuat apa pun di mana saja.
• Menerapkan berbagai representasi data.
• Harus ada banyak sistem: jika setengah dari data diambil dari Jira, setengah dari TestRail, mereka harus jatuh ke dalam satu celengan, dari mana kemudian laporan unik akan diperoleh.
• Semuanya harus dikelola dan mudah dirawat. Ini berarti bahwa orang itu sendiri dapat membangun laporan yang diperlukan berdasarkan sistem dan mendukungnya sendiri.

Dasbor

Kami memiliki banyak dasbor, hanya teknis yang aktif sekarang sekitar 30, dan totalnya sekitar 100.



Data untuk dasbor dikumpulkan secara umum dari mana-mana. Ternyata kanvas besar dari mana Anda dapat menghasilkan laporan yang diperlukan. Di bawah ini adalah beberapa contoh.

Kerusakan Bug Kritis



Di sini kami mengukur dan menampilkan jumlah bug untuk periode tertentu dan seberapa kritisnya bug tersebut. Data diambil dari Jira. Jira sendiri, mungkin, dapat membuat laporan seperti itu, tetapi tidak dalam bentuk yang sangat nyaman.

Kerusakan bug berdasarkan bidangnya sendiri

Di Jira, Anda bisa mengemas bidang khusus apa pun, dan bidang ini bisa berupa analitik, yang juga dimuat ke sistem umum. Sebagai contoh, di bawah ini adalah bug komponen.



Ada potongan yang sama untuk tim, orang, arah. Ini memungkinkan Anda untuk menonton berbagai irisan.

Rasio bug baru dan tertutup

Jika kita membuat 20 bug, dan hanya menutup 5, maka pada titik tertentu kita akan berkubang di dalamnya. Karena itu, Anda harus mengikuti angka-angka dan mengusahakan agar rasio menjadi sama dengan 1.



Tren bug untuk periode tersebut

Sistem praktis yang kami perkenalkan adalah kami mengunggah semua data historis dan dapat melihat dinamika.



Di Jira, ini agak rumit. Semuanya bekerja untuk kami secara otomatis, dan Anda dapat memilih periode apa pun dan melihat apakah Anda berhasil meningkatkan sesuatu, dan apakah proses dan gagasan yang diperkenalkan berhasil.

Tahapan menemukan bug

Jika sebelumnya kami hanya mengukur bug dalam pertempuran, sekarang kami berusaha untuk memastikan bahwa tidak ada bug dalam pertempuran sama sekali, dan kami membuat irisan pada tahap yang berbeda: pertempuran, rilis, pengujian, otomatisasi, ulasan, persyaratan.



Dasbor Otomasi

Untuk pengujian otomatis, ada juga dashboard. Ini sangat besar, jadi di bawah ini adalah dua fragmen terpisah.



Ini menampilkan jumlah bug yang terlewatkan. Jika Anda memiliki cakupan 90%, tetapi sebenarnya setengah dari bug hanya dikomentari atau dilewati, maka ini sangat penting, karena pada kenyataannya hanya 50% dari fungsionalitas yang berfungsi dengan benar.

Hal yang sama dengan gagal: berapa banyak tes crash. Kami biasanya menemukan penyebab crash yang berbeda: crash sistem, bug crash, fungsionalitas telah berubah. Secara terpisah, kami berbagi kerusakan yang tergantung pada sistem dan lingkungan, dan yang murni berdasarkan pada tes. Yang pertama adalah pekerjaan tim operasi, yang kedua adalah otomatisasi.

Kami juga melihat cakupan otomatisasi. Kami mengambil semua suite dari TestRial, dan kami juga dapat menyelami blok fungsionalitas dan menentukan, misalnya, bahwa pencariannya tertutup 30%.



Selain itu, data tentang pemotongan status tercermin di sini:

• Baru - fungsionalitas baru.
• Perlu koreksi - Anda harus memperbarui kasing.
• Tidak perlu - tidak ingin menutup otomatisasi.
• Selesai - Ditutupi.

Kritikalitas juga memiliki potongannya sendiri.

Kinerja Dasbor

Kami sedang membangun dasbor ini di Grafana, dan kami memuat metrik secara terpisah oleh API, frontend, backend, dan sisi server. Ada blok yang menunjukkan potongan saat ini dari rilis terbaru. Dengan demikian, Anda dapat masuk ke setiap metrik dan melihat dinamika.



Semuanya tumpang tindih dengan fungsionalitas yang berbeda, halaman situs yang berbeda.

Terbang terus

Tampaknya sekarang semuanya baik-baik saja: ia mengumpulkan dirinya sendiri dan di satu tempat, sekelompok metrik. Anda dapat dengan aman melanjutkan.

Namun ada masalah baru di sepanjang jalan. Ada terlalu banyak grafik, dan karenanya mereka lebih jarang ditonton. Ketika ada 5 jadwal, mereka mudah diperiksa setiap hari. Dengan peningkatan jumlah mereka, rejimen sekali seminggu diperoleh - juga baik. Dan tiba-tiba 3 hari yang lalu ada seorang fakap, yang tidak ada yang memperhatikan. Karenanya, reaksinya menjadi panjang, dan metrik serta dasbor berhasil menjadi usang. Ada berbagai alasan untuk ini, yang juga harus bisa dilawan.

Kita perlu membuat grafik teragregasi : dari 10 kita membuat grafik yang akan menunjukkan status 10. Ini. Selain itu, kita menarik indikator utama ke atas. Anda membuka dasbor dan segera melihat nilai yang diinginkan, dan kemudian segala sesuatu yang lain, yang mengungkapkan metrik lebih terinci.

Kami berbagi: metrik bisnis, metrik proses, metrik QA (Web / Ponsel, Manual / Otomasi, Kinerja).

Beginilah tampilan grafik gabungan (NPS, CSAT).



Di atas adalah nilai dan delta dibandingkan dengan periode sebelumnya. Dalam hal ini, jika panah berwarna merah, maka Anda perlu melakukan sesuatu, setidaknya lihat grafik secara lebih rinci. Jika panah berwarna hijau, maka semuanya baik-baik saja dan Anda tidak dapat bereaksi.

Juga, grafik memiliki kemampuan untuk jatuh ke level yang lebih rendah , tanpa ke mana-mana.



Bug terkait dengan orang-orang yang mengizinkannya (penguji atau pengembang). Jika Anda mengklik secara terpisah pada beberapa tester, sebuah tabel terpisah akan terbuka di atasnya - sepotong untuk tugas.

Langkah selanjutnya adalah memecahkan masalah bahwa grafik jarang dikendalikan. Yaitu, kami akan memperluas skema bekerja dengan data dan metrik: menambahkan pemberitahuan ke metrik yang diperlukan.

Lansiran

Kami menggunakan banyak lansiran. Saya akan memberikan contoh kategori dan situasi khusus:

• Performa
• Tes otomatis. Misalnya, jika persentase bug yang terlewat terlalu tinggi, atau jika terlalu banyak fungsi baru tidak tercakup oleh pengujian.
• Bug yang masuk. Di perusahaan kami, siapa pun bisa mendapatkan bug dalam sistem tiket. Sebelumnya, ini disertai dengan pesan di PM, dan sekarang ada saluran untuk peringatan tentang bug baru, apalagi, bug secara otomatis ditugaskan ke pelaksana secara bergantian. Orang yang ditunjuk harus mengurai bug, jika tidak bot akan mengingatkannya setiap 15 menit.
• Tes Kecepatan / Tes Menunggu. Jika jelas bahwa seseorang telah mengubur dirinya dalam suatu tugas - itu tidak masalah, dia menyandikannya, melakukan peninjauan, mengujinya - peringatan harus masuk: "Anda sudah melakukan tiga tugas, mungkin Anda sudah dikuburkan, minta bantuan."
• Cacat pada tugas / tim.
• Ulasan kasus uji. Ini hanya otomatisasi proses, agar tidak melakukannya dengan tangan.

Contoh Peringatan

Untuk tugas yang terbakar, bot menulis nomor tugas, status, prioritas, berapa lama tugas tersebut sudah diuji dan siapa yang mengujinya.



Pemberitahuan, dibuat dalam bentuk ringkasan, datang ke seorang individu yang melihat masalah apa yang dia miliki. Berikut adalah contoh peringatan untuk test case yang dikirim TestRial.



Ini menunjukkan kasus mana yang ditugaskan kepada siapa, dengan status apa dan siapa yang perlu diawasi.

Contoh lain adalah bot Yabeda, yang memonitor proses.



Ini diperlukan untuk mengonfigurasi proses menghubungkan bug dan tugas. Pengembang, menganalisis bug, harus menemukan tugas di mana kami melewatkan bug ini, untuk analisis lebih lanjut, untuk mengetahui mengapa kami melewatkan bug. Ini semacam analisis insiden, tetapi dengan penundaan.

Berapa banyak peringatan yang Anda butuhkan dan seberapa sering?

Jika akan ada banyak peringatan, maka akan ada banyak stres dari mereka. Karena itu, kami telah menetapkan aturan manajemen waspada untuk diri kami sendiri.

Terlalu banyak lansiran - berhenti merespons. 500 peringatan per hari, Anda pasti akan berhenti untuk menjelajah, yang berarti Anda dapat melewati yang penting.

Terlalu sedikit - tidak ada masalah. Jika ada terlalu sedikit pesan, misalnya, hanya membuang separuh, Anda mungkin tidak melihat masalah.

Tidak ada masalah - ringkasan fakta. Dengan tidak adanya masalah, peringatan juga harus dikirim, tetapi dalam bentuk ringkasan: apa yang terjadi pada siang hari, apa yang berhasil, tugas apa, apa yang terjadi. Jika Anda tidak membuat ringkasan, Anda mungkin berpikir bahwa semuanya rusak dan Anda perlu mencari peringatan apa yang telah jatuh.

: , . , , - , . , :

• — , .
• — , , . , , . .
• — , , , , .

, :

• — , , .
• / . , , .
• . , .
• . , . , . , , .

. , . . , , , , . , , : , .


, :

• . , , , . .

• . , , , . , 10 — .
• . , .

, , . . -, , , , , 15 , . -, , . . -, . , , , , , .

Online

. , . , . , .

QA

, QA .

: , , .

: , , .

:



— , X ( ), () (). , - , ( ) : , . , . , , . , , .

: — , , ( , , ).

: « ». , , , , . - . .

, , . , , . .

-

: , , . , .

: , , , .

, 10 , 500, . , .

. , , .



, , , . , , . «5 », .

, , , .

Ringkasan

— , . , . , . , , , — , .


:

• ;
• , ;
• , .

. , , , . .

— . , . , , - .

. , .

:

• ~ 50 QA 100 .
• ~ 30 .
• — , .
• .
• .
• QA must have.

Konferensi kami, yang menggabungkan semua aspek pengembangan produk berkualitas tinggi, akan dilahirkan kembali tahun depan, akan terbang keluar dari RIT ++ dan menjadi acara berskala besar yang independen, TechLead Conf. Kami akan segera mengumumkan tanggal dan tempat di saluran telegram , tetapi jika Anda telah melihat dari pengalaman Anda sendiri bahwa proses pengembangan bukanlah serangkaian batu bata yang tidak terhubung, dan ingin berbagi solusi untuk proses rekayasa bangunan, mengajukan permohonan laporan tanpa menunggu pengumuman.