Cara tradisional untuk mengukur tugas di industri kami adalah jam tangan. Mari kita hitung berapa banyak metrik dalam jam yang kita gunakan.
Jam pertama dan terpenting adalah jam yang kami pasang di klien. Bergantung pada situasinya, kami menyetujui jam di muka, atau mengatur fakta - berapa banyak yang dihabiskan programmer.
Jam kedua adalah jam yang disebut programmer, menjawab pertanyaan "berapa banyak waktu yang Anda butuhkan untuk menyelesaikan masalah?". Jika kami setuju dengan klien sebelumnya, maka jam tangan ini disiapkan untuk penjualan. Jika pembayaran dilakukan setelah fakta, maka kami meminta programmer untuk evaluasi untuk tujuan perencanaan.
Jam ketiga - berapa banyak yang dihabiskan programmer untuk memecahkan masalah sebenarnya. Arloji ini bertepatan sangat jarang dengan nomor yang direncanakan, yang dia panggil sendiri, dan ini normal - tidak ada yang tahu bagaimana merencanakan waktunya dengan tepat, karena banyak kekuatan dari lingkungan bertindak atas pekerjaan programmer - dia terganggu, dia tidak dalam mood, dia dihadapkan dengan kesulitan yang tidak terduga, dll.
Ada juga jam keempat - saat kami menetapkan jumlah yang berbeda dari yang disepakati sebelumnya. Tentu saja, jika kondisi kerja sama kita memungkinkan kita untuk melakukannya.
Dan sekarang perhatian, pertanyaannya adalah: di mana Anda bisa bekerja dengan efisiensi? Atau dengan cara lain: efektivitas apa yang akan kita tingkatkan?
Seseorang dapat menjawab dengan samar: efisiensi pemrogram. Nah, bagaimana, dan apa yang akan kita ukur? Di hadapan kami, saya ingatkan Anda, tiga atau empat jenis jam tangan.
Coba beri tahu programmer: kami ingin Anda menghasilkan lebih banyak jam. Apa yang akan dia jawab? Si programmer adalah orang yang cerdas, ia belajar di institut, dan ia segera mengingat metrik kelima - jumlah jam dalam sehari. Dan dengan berani memberi tahu Anda tentang hal itu - saya tidak bisa bekerja lebih dari 24 jam sehari, takut akan Tuhan.
Dia juga akan mengingat teori relativitas. Bahkan jika itu tidak secara detail, itu pasti menyebutkan ketidakmungkinan waktu kompresi - apakah kita tidak bergerak dengan kecepatan mendekati cahaya?
Jika arloji tidak menyusut, lalu bagaimana cara meningkatkan efisiensi? Bagaimana Anda bisa membicarakannya? Bagaimana Anda bisa menghitungnya? Berapa jam per jam yang dihabiskan programmer? Menghabiskan setengah jam untuk satu jam kerja? Bagaimana cara membuat formula? Tanpa formula, Anda tidak akan membuat perhitungan apa pun, dan Anda tidak akan menetapkan tujuan.
Mari kita pergi ke sisi lain. Bayangkan bukan seorang programmer, tetapi seorang pekerja pabrik. Di sini dia, orang yang malang, seluruh giliran di mesin dan menghasilkan bagian. Bagaimana pekerjaannya direncanakan? Misalkan seratus bagian per shift. Perubahan itu berlangsung delapan jam, ternyata 4,8 menit untuk satu bagian.
Sekarang bayangkan: kita, dengan pendekatan kita untuk mengukur pekerjaan, telah datang untuk memimpin pekerja ini. Kami tidak lagi memberitahunya “lakukan 100 bagian”, kami senang mengukur dalam hitungan jam, sehingga rencana kerja baru akan terdengar seperti “lakukan 8 jam per shift”.
Dia, tentu saja, pada awalnya akan menganggap kita idiot. Dia bertanya - tetapi berapa banyak detail yang harus dilakukan? Tidak masalah, kami menjawab. Yang utama adalah arloji. Kami memahami bahwa ada variasi, Anda pergi ke sana untuk merokok, mengobrol dengan teman, tetapi kami membayangkan tagihan rata-rata - 4,8 menit per detail. Karena itu, lakukan kami 100 kali selama 4,8 menit pekerjaan Anda.
Pada awalnya, tentu saja, dia akan mencoba mengikuti rencana lama, tetapi ketika dia melihat perhitungannya, nilai-nilai hidupnya akan berubah - itu akan mengatakan "begitu banyak yang telah dihitung dalam 20 shift 8 jam." Apa gunanya dia sekarang secara umum untuk melakukan rincian, jika hanya waktu yang dihabiskan di mesin dibayar?
Jika pada saat itu mereka belum mengusir kami keluar dari pabrik, maka kami akan mengubah sistem penjualan. Kami tidak akan menjual suku cadang kepada pelanggan - faktur akan menunjukkan jam yang dihabiskan oleh pekerja kami. Klien meminta 100 bagian, kami pergi untuk berpikir, lalu kami mengirim faktur - 8 jam kerja spesialis. Klien terkejut, tetapi setuju, dan membayar tagihan. Dan setelah beberapa hari dia mendapat "peningkatan" lain - beberapa jam. Apa yang terjadi? Pekerja tidak bisa bertahan dalam 8 jam.
Pelanggan mulai membenci - jam berapa, jam tangan macam apa? Kami membutuhkan detailnya! Berkeping-keping, kotak, palet, gerobak - tidak masalah. Bagi kami tidak ada bedanya berapa jam yang dibutuhkan untuk memproduksinya!
Di sini, saya pikir, mereka pasti akan mengusir kita. Pengembalian akuntansi dalam potongan - baik internal maupun eksternal, untuk pelanggan. Dan akan terlibat dalam efisiensi.
Di mana efisiensi di sini, apa rumusnya? Jawabannya jelas: semakin banyak bagian per unit waktu pekerja, atau bengkel, atau seluruh pabrik menghasilkan, semakin baik. Tentu saja, tergantung pada teknologi, kualitas yang layak dan tidak ada stocking.
Tetapi formula untuk efisiensi jelas - potongan per jam. Dan arahan untuk penerapan upaya manajemen jelas, untuk meningkatkan efisiensi.
Kami, sedih, kembali ke programmer kami. Dan kami juga menginginkan formula sederhana dan mudah dipahami untuk menghitung efektivitas. Apa yang kita punya di sana? Arloji, arloji, sekitar - arloji.
Sekarang Anda sudah mengerti apa yang salah dengan jam. Jam mengukur waktu - fenomena fisik di luar kendali Anda yang telah terjadi, sedang terjadi dan akan selalu terjadi. Tidak masalah apakah Anda bekerja atau tidak, apakah perusahaan Anda ada atau telah ditutup, apakah Anda memiliki klien atau tidak - waktu akan berlalu, dan itu akan diukur dalam hitungan jam.
Yang dapat Anda lakukan adalah mengelola aktivitas Anda selama jam yang diberikan kepada Anda oleh Kode Tenaga Kerja, yaitu menghasilkan sesuatu, dan entah bagaimana mengukur apa yang Anda hasilkan.
Dalam kasus pabrik, semuanya jelas - ada pengukuran dalam satuan fisik. Potongan, liter, linier, persegi atau meter kubik. Dan bersama kami, programmer, apa yang harus dilakukan? Dalam hal apa mengukur tugas kita, kecuali berjam-jam?
Hal pertama yang terlintas dalam pikiran adalah potongan-potongan. Tetapi pemikiran seperti itu tidak mungkin - variasi antara tugas terlalu tinggi.
Bahkan, jawabannya sudah lama ditemukan dalam apa yang disebut. metodologi pengembangan yang fleksibel, seperti scrum. Metode ini disebut "Perencanaan Poker."
Dalam unit apa tugas perencanaan poker diukur? Jawabannya tidak biasa - dalam hal apa pun. Panggil mereka apa yang Anda inginkan. Anjing, burung beo, tinja, titik, kacamata - tidak masalah. Nama yang paling umum adalah poin cerita (poin cerita, poin cerita). Secara pribadi, saya suka poin yang lebih sederhana dan lebih ringkas. Saya akan menggunakannya dalam penjelasan lebih lanjut. Anda, tentu saja, dapat memilih yang lain.
Fitur utama dari poin adalah relativitas mereka. Ini bukan unit ukuran dari beberapa classifier, tetapi skala unik untuk setiap perusahaan, atau bahkan tim. Tugas yang sama, dalam dua tim yang berbeda, dapat dievaluasi secara berbeda. Di suatu tempat - lima poin, di suatu tempat - tiga belas, dll.
Jumlah poin - ini adalah ukuran sebenarnya dari tugas tersebut. Penilaian yang sangat kami miliki.
Teknik perencanaan poker merekomendasikan penggunaan estimasi dari seri Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34, dll. poin, di mana setiap elemen berikutnya sama dengan jumlah dari dua sebelumnya. Alasannya sederhana: harus ada perbedaan yang signifikan antara peringkat. Agak sulit untuk memilih peringkat antara, misalnya, 5 dan 6 poin. Jauh lebih mudah - antara 5 dan 8, atau 8 dan 13.
Metodologi merekomendasikan untuk mengevaluasi tim sebagai berikut. Semua anggota tim harus diberi kartu dengan tanda yang tertulis padanya (dari seri Fibonacci). Anda dapat membeli kartu khusus untuk perencanaan poker, jika Anda menginginkan kecantikan, tetapi untuk kesederhanaan cukup untuk mengambil potongan kertas kecil biasa untuk catatan, seperti stiker, hanya tanpa strip perekat.
Jadi, tim berkumpul, masing-masing memegang kartu. Sebuah tugas diumumkan, fitur-fiturnya dan detailnya terdaftar sehingga semua orang mengerti apa yang perlu dilakukan. Setelah itu, setiap peserta membuat penilaian sendiri - memilih salah satu kartu - dan meletakkannya di atas meja (sehingga penilaian tidak terlihat).
Ketika semua orang telah mengevaluasi, kartunya dibalik, dan pemeriksaan kunci dilakukan - tidak boleh ada perkiraan yang terpisah satu sama lain oleh lebih dari satu elemen dari seri Fibonacci.
Misalnya, nilai 5 dan 8 normal, dan nilai 3 dan 8 tidak baik. Terlalu banyak overshoot dalam perkiraan menunjukkan bahwa seseorang tidak mengerti sesuatu. Mereka yang memberi peringkat rendah tahu terlalu banyak (misalnya, sudah menyelesaikan masalah seperti itu), atau belum mengerti apa-apa dan terlalu optimis.
Demikian juga, skor tinggi dapat mengindikasikan kesalahpahaman tentang tugas. Sebagai contoh, seorang programmer tidak pernah memecahkan masalah seperti itu, atau mereka terhubung dengan mekanisme platform yang tidak diketahui olehnya, dan dia, kalau-kalau, sebagai cadangan, memberikan nilai tinggi.
Dalam kasus apa pun, jika perkiraannya sangat berbeda, diperlukan diskusi kedua - untuk memperjelas rinciannya, membahas seluk-beluknya, dan memberikan informasi maksimal. Ketika diskusi diadakan, evaluasi diulang. Jika perlu, berulang-ulang, hingga taksiran dipisahkan satu sama lain oleh tidak lebih dari satu elemen seri.
Terkadang berguna untuk mengecualikan salah satu anggota tim dari penilaian tugas tertentu. Misalnya, jika ada peserta magang di tim, maka setidaknya jelaskan kepadanya, setidaknya jangan jelaskan kepadanya - dia tidak akan mengerti apa kesulitannya atau, sebaliknya, kesederhanaan tugas. Pada akhirnya, dia hanya setuju dan menempatkan peringkat yang diinginkan agar tidak menunda tim.
Hasil seperti itu tidak memiliki nilai, karena mengubah perencanaan poker menjadi formalitas kosong. Oleh karena itu, saya merekomendasikan aturan sederhana: hanya orang yang memahami sesuatu dalam tugas yang berpartisipasi dalam penilaian tugas. Anda tidak mengerti - hanya duduk dan mendengarkan.
Tentu saja, kadang-kadang terjadi bahwa hanya satu orang yang mengerti tugas itu. Misalnya, jika itu milik bidang ilmu yang sangat spesifik dan jarang digunakan. Tidak apa-apa, biarlah ada satu penilaian.
Ada kasus ekstrem - tidak ada yang mengerti bagaimana menyelesaikan masalah. Tidak apa-apa - kita mengatur apa yang terjadi, lalu kita akan mencari tahu.
Ketika nilai ditetapkan, rata-rata aritmatika dipertimbangkan - ini akan menjadi nilai akhir tugas. Dalam metodologi yang fleksibel, mereka menuliskannya di stiker dan menggantungnya di papan tulis, tapi saya sarankan hanya menambahkannya ke sistem informasi Anda, di mana Anda menuliskan tugas. Tentu saja, Anda harus terlebih dahulu menambahkan bidang yang sesuai.
Algoritma evaluasi lain adalah tanpa menggunakan perintah. Misalnya, poin dapat diberikan oleh pemimpin, atau pemimpin, atau programmer paling cerdas. Biasanya, mereka beralih ke algoritma ini setelah bermain tim poker selama beberapa minggu atau bulan.
Alasannya sederhana: perlu bahwa semua anggota tim terbiasa dengan sistem penilaian. Mereka menembusnya, belajar cara mengevaluasi tugas dengan cepat, dan tidak melihat poin, seperti seekor domba jantan di gerbang baru. Ketika kebiasaan telah berkembang, satu orang dapat dievaluasi. Tentu saja, meninggalkan tim hak untuk mengekspresikan pendapat mereka - tidak ada yang sempurna, dan pemimpin mungkin salah dalam perkiraan.
Terkadang tim mengalami kesulitan di awal pekerjaan dengan poin - tidak ada yang tahu apa yang harus dipilih untuk titik referensi. Saya sarankan memilih beberapa jangkar - tugas khas yang Anda selesaikan secara berkala.
Jangkar pertama adalah tugas termudah. Sebagai aturan, sejauh yang saya tahu, waktu yang dihabiskan oleh programmer dibebankan beberapa 15 menit. Tugas apa yang biasanya Anda selesaikan dalam 15 menit? Laporan sederhana? Menambahkan pengguna ke basis data? Mengisi classifier alamat?
Tugas ini harus diberi skor 1 poin. Di masa depan, Anda akan dibimbing olehnya.
Anda dapat menambahkan beberapa jangkar lagi, tergantung pada spesifikasi Anda. Misalnya, laporan eksternal sederhana pada satu register residu, tanpa bel dan peluit, tanpa kode dalam formulir dan modul - biarlah 3 poin. Tambahkan syarat ke dokumen dan tampilkan pada formulir, tanpa memproses input dan cek - biarkan 2 poin. Dll
Penting bahwa tim itu sendiri memilih jangkar ini, setuju dengan mereka dan menggunakannya di masa depan. Estimasi relatif, dan jangkar akan memainkan peran sebagai titik awal.
Sekarang semua tugas kita diukur dalam satuan fisik - poin. Kita tahu berapa banyak poin yang diselesaikan dalam seminggu, sebulan, setahun, dll. Kami tahu berapa banyak poin yang dihasilkan oleh setiap programmer. Kami melihat dengan jelas berapa banyak poin yang "menimbang" tugas yang tidak terselesaikan.
Tetapi yang paling penting, kita tahu efektivitas sebagai rasio poin terhadap jam. Tentu saja, lebih mudah untuk menghitung poin per hari.
Satu programmer menghasilkan 4 poin sehari, yang lain - 8, yang ketiga - 2. Minggu lalu kami menghasilkan 50 poin, minggu ini - 80, yang berarti efisiensi kami meningkat.
Tujuan peningkatan efisiensi juga menjadi jelas: kita harus belajar menghasilkan lebih banyak poin per unit waktu. Waktu, seperti yang kita tahu, tidak tunduk pada pengaruh kita, tetapi jumlah poin yang diselesaikan masih bagaimana. Sebenarnya, inilah yang akan kami terus pelajari.
Poin adalah sistem koordinat utama yang akan digunakan dalam presentasi lebih lanjut. Ini adalah bagian yang harus dimiliki yang tidak dapat dilewati. Tidak masuk akal untuk memperkenalkan beberapa metode lain sampai poin dihitung. Apakah kamu mengerti mengapa?
Karena Anda tidak dapat mengevaluasi efektivitas metode yang diterapkan. Bagaimana cara memahami, lebih baik atau lebih buruk, tidak memiliki nomor? Tidak mungkin, hanya fantasi yang tersisa. Manajemen yang didasarkan pada fantasi dan ilusi tentu saja sangat luas, tetapi tidak cocok untuk meningkatkan efisiensi.
Saya akan memberi tahu Anda sedikit rahasia: dengan menerapkan sistem untuk menilai tugas dalam poin, Anda sudah dapat meningkatkan efisiensi tim pemrogram. Terkadang bahkan dua kali, saya menguji hipotesis ini beberapa kali.
Alasannya sederhana - ada transparansi nyata. Ilusi menghilang, angka telanjang tetap ada. Bersama dengan jam yang dibayarkan oleh klien, Anda mendapatkan sistem yang cukup kuat untuk melacak kinerja. Orang-orang, setelah melihat angka-angka mereka, diri mereka sendiri akan mulai bekerja lebih baik, karena mereka tidak akan lagi dapat bersembunyi di belakang jam.
Karena itu, tanpa penundaan, buat catatan tugas di sistem Anda dalam poin. Ini tidak sulit sama sekali, terutama jika Anda menggunakan sistem pada platform 1C - cukup tambahkan bidang angka ke objek metadata yang menyimpan tugas Anda. Nah, tulis beberapa laporan tentang sistem poin - berapa banyak masalah yang telah dipecahkan, oleh siapa, kapan, berapa banyak yang belum diterima dalam pekerjaan, berapa banyak yang menunggu penerimaan oleh pelanggan, dll.
Ringkasan
- Mengukur tugas hanya dalam hitungan jam membuat Anda tidak memiliki kesempatan untuk meningkatkan efisiensi;
- Lebih baik mengukur tugas dalam unit fisik - poin;
- Lebih baik mulai menerapkan poin dengan perencanaan poker tim;
- Ketika sistem penilaian menjadi jelas bagi tim, satu orang dapat dievaluasi;
- Penilaian memberikan pemahaman tentang efektivitas;
- Poin harus otomatis.