🕺🏼 👨‍🍳 🚖 Peringkat. Hitung dan temui 🚿 ☣️ 👩🏾‍🤝‍👨🏼

Prediktabilitas tenggat waktu memainkan peran penting dalam pengembangan proyek TI. Dan karena kompleksitas proses yang tinggi, penilaian tugas merupakan masalah yang sulit, yang tidak memiliki algoritma eksplisit atau rencana sederhana. Ini diperparah oleh kenyataan bahwa dalam proses komunikasi tentang evaluasi, bisnis, manajemen proyek dan pengembangan dapat berbicara bahasa yang berbeda, tidak mengerti dan tidak ingin memahami masalah dan nilai masing-masing. Hasilnya adalah "berhenti berlangganan" di mana upaya dikeluarkan, tetapi mereka tidak membawa efek yang diperlukan.

Artikel ini akan bermanfaat bagi pengembang yang ingin meningkatkan dan membuat proses evaluasi lebih nyaman bagi diri mereka sendiri. Di dalamnya, saya akan membagikan pendekatan yang dikembangkan, yang memungkinkan kami untuk meningkatkan saling pengertian dengan unit lain, serta mengurangi tingkat upaya kami sendiri untuk evaluasi. Kami akan menganalisis mengapa kami memerlukan taksiran, cara mengevaluasi tugas besar dan subtugas yang diuraikan. Dan, yang paling penting, apa yang harus dilakukan untuk masuk ke penilaian ini.

Versi video dari presentasi tersedia di sini .

Nah, sekarang to the point.

Mengapa memberi nilai

Dalam kehidupan setiap pengembang, momen yang tidak menyenangkan itu datang ketika "mereka" mendatangi kami dan menuntut: "kapan itu akan siap?". "Mereka" adalah manajer, produk, pemimpin tim, bos ... Pertanyaannya adalah, mengapa "mereka" ini? Apa yang akan "mereka" lakukan dengan ini? Jika kita memahami ini, kita dapat memberi mereka apa yang mereka butuhkan dan menghemat waktu mereka. Ada beberapa opsi, dan inilah yang utama.

Manajer perlu mengevaluasi ruang lingkup pekerjaan (pengiriman, rilis, sprint): jadwal kalender dan total volume mereka. Dalam hal ini, penting untuk masuk ke penilaian keseluruhan, masuk ke setiap tugas tertentu tidak masalah (di suatu tempat menghabiskan lebih banyak, di suatu tempat kurang - umumnya disepakati). Di masa depan, pekerjaan departemen lain direncanakan untuk ini, dan indikator-indikator yang dikelola bisnis bergantung padanya. Dan bisnis membutuhkan prediktabilitas: untuk mengurangi risiko dan meningkatkan pengelolaan.
. , . /. , , (, , ) . : , - . , . .
( ). , . , : , . , /, , ( ), . (, , ), .

Nah, mengapa "mereka" ini dibongkar. Tetapi apakah kita membutuhkan ini? Bayangkan manajer Anda pergi berlibur. Selama-lamanya. Jadi Anda duduk, bekerja dengan tenang, sehari, dua, seminggu. Tidak ada yang butuh peringkat, hidup itu baik. Apakah Anda akan mengevaluasi diri sendiri?

Memberi mereka atau tidak adalah masalah pribadi, tetapi inilah argumen untuk itu.

Penilaian menunjukkan bagaimana menyelesaikan tugas. Otak manusia adalah hal yang mahal, dan seseorang tidak suka berpikir - itu sulit. Karena itu, keinginan alamiah untuk berpikir sesedikit mungkin. Tetapi bagaimana cara melakukannya? Anda dapat membagi aktivitas menjadi aktivitas yang lebih sempit. Kami berbagi perencanaan dan pelaksanaan: pertama-tama kami memikirkan metode (selama evaluasi), kemudian kami beralih ke eksekusi dan berpikir tentang eksekusi (dalam proses).
, «» . , — . , () ( ) , . , - .
— . — . , , . . , . 2 . 2 , - , . . , , — . , , — . ( /), . , , : « , !!». , , . ? . «», , . , , — - .
Efek psikologis. Jika tugasnya kompleks, itu berubah selama proses pengembangan atau pengetahuan kami tentang itu berubah. Jika kami tidak memberikan penilaian awal, tugas dalam proses itu dipenuhi dengan detail baru, dan akibatnya kami tidak sampai di sana - kami tidak ingat mengapa. Setelah beberapa iterasi seperti itu, efek penipu mengetuk kepala. Dan jika mereka telah memberikan penilaian awal, alasannya akan tetap: mereka berpikir bahwa 5 nuri dibutuhkan, tetapi ternyata 10. Mengapa ternyata itu menjadi pertanyaan kedua, mereka mengingatnya dengan baik. Dan alasannya tidak selalu ("Pengembang selalu tidak melakukan apa-apa" / "Produk-produk ini tidak dapat berpikir untuk selamanya, dan kemudian muncul").

Jadi, kami memutuskan: penilaian dibutuhkan oleh "kami" dan "mereka". Masuk akal untuk melanjutkan membaca artikel lebih lanjut.

Tujuan penilaian

Tidak ada gunanya menebak berapa lama tugas akan berlangsung. Anda tidak dapat menebak dengan tepat, dan jika Anda bisa, Anda tidak akan dapat mengatakan ini dengan andal sampai Anda melakukannya: jadi saya menebak atau tidak menebaknya. Dan pada tahap ini, tidak ada yang tertarik dengan penilaian.

Jadi, penilaian bukanlah upaya untuk menebak berapa lama tugas akan berlangsung. Evaluasi adalah kesepakatan antara pelanggan dan kontraktor tentang kerangka kerja dan (mungkin) cara tugas dilakukan .

Biasanya, bisnis yang memadai tidak memiliki tugas untuk dihancurkan dalam kerangka waktu tertentu, bisnis membutuhkan prediksi dan batasan risiko. Waktu tidak dicirikan oleh kecepatan kerja programmer, tetapi oleh jumlah pekerjaan yang ia lakukan. Dan Anda juga bisa menyapa rekan kerja: jika saya mendapat tugas dengan penilaian yang tidak memadai, ini adalah kesempatan bagi saya untuk berpikir, apakah metode kami persis sama? Mungkin dia melihat cara yang lebih mudah untuk diselesaikan? Atau mungkin sebaliknya, tidak melihat sesuatu yang besar? Bagaimanapun, alasan untuk memeriksa arloji.

Proses penilaian

Dasar dari proses penilaian adalah untuk melihat nilai dari tugas bisnis, serta risiko utama dari tugas dan jumlah rutin. Dan kemudian mengevaluasi mereka, melampirkan kerangka kerja: tidak diketahui persis apa itu, tetapi jelas lebih besar dari X dan kurang dari Y. Dan tentu saja, kami mengevaluasinya dengan akurasi yang diperlukan (karena perkiraan pastinya mahal, dan otak malas).

Komposisi Tugas:

- ( ). , . smoke-test . , , , « ». , ! — . , : « - , ».
, - , . «» -. , , ( , , , , ), — .
. - , , - . , ( ). : , , , (, . — - . : ( , , : , , , , ), , , , ( ) , , zero-tolerance , , , -, . , (//), (//).
Yang lainnya .

Prosedur untuk mengevaluasi epik

Skema ini lahir dari kenyataan bahwa tugas apa pun dapat dilakukan dalam jumlah waktu berapa pun . Pernyataan itu dilebih-lebihkan, tentu saja, tetapi secara keseluruhan mencerminkan esensi. Misalnya, seorang pelanggan mendatangi saya dan berkata: “Saya ingin facebook. Kapan akan siap? " Waktu minimum untuk menyelesaikan masalah seperti itu yang berhasil saya buat adalah 15 menit. Saya pergi ke facebook, mengambil screenshot, membuat halaman dengan gambar screenshot, meletakkannya di server saya. Memenuhi kondisi masalah. Anda bahkan dapat meningkatkan implementasinya: mengambil gambar, tetapi membuat iframe dengan facebook (meskipun, seperti yang saya harapkan, facebook sudah menangani ini) Karena evaluasi waktu menentukan cara untuk menyelesaikan tugas, Anda dapat mengurangi waktu untuk menyelesaikan tugas sebanyak 2-3 kali (kebetulan 5 kali). Sangat lucu bahwa hukum empiris ini terus-menerus ternyata diperiksa dalam praktik.

Kami menguraikan tugas menjadi subtugas. Ternyata sesuatu seperti gambar ini (kami menyebutnya "pohon Natal"): menilai tugas secara horizontal dalam waktu, secara vertikal - prioritas.
Kami mengurutkan subtugas berdasarkan prioritas (nilai bisnis pertama + "memuat", lalu berisiko, lalu sisanya sesuai urutan kepentingan).
Jika taksiran perlu dikurangi, kami pangkas masalahnya dari bawah. Mengapa kita bisa mengurangi: beberapa risiko berhasil dan pembengkakan atau nilai bisnis tidak persis sama dengan yang seharusnya - ini adalah hal-hal penting, dan tanpanya, tugas tidak dapat dilewati. Perlu untuk memperbaikinya. Kemudian kita akan dapat masuk ke penilaian dengan melakukan bagian utama dari tugas (tergantung pada kegagalan, bagian yang lebih besar atau lebih kecil dari tugas akan dilakukan).

Proses Evaluasi Tugas

Ok, epik itu terurai. Dan bagaimana cara mengevaluasi ukuran tugas tertentu?

Jika kita sudah melakukan tugas ini dengan tepat . Kami memiliki statistik di suatu tempat, berapa banyak waktu yang dihabiskan untuk tugas serupa. Jika kita tidak melakukannya, tetapi seorang kolega, maka kita dapat mengambil hasilnya dan mengalikannya dengan koefisien perbedaan antara dulu dan sekarang (tingkat pengembang, pengetahuan sistem, pengetahuan risiko). Kami naik ke statistik, berkembang biak - kami dapatkan.
. , . , 60%. , 60% , . , — , 1.5-2 .
. R&D. — , . — . (1, 2, 4 ), — . , , . , R&D, 1-2 , R&D . — R&D. - — , , . — N — - ( ). , — , . , , — .

, ( ) , , . , , .
Planning poker. , . : -, , , , -, , ,
(/ ), . . , . , , 70% .
PERT. , (-) 5 . .
min real max
<> 2 8 20 9

— , , — , ( ), — , , ( ).
:

	min	real	max
<>	2	8	20	9

Koefisien 4 dan 6 diambil, seperti yang saya mengerti, dari asumsi bahwa dalam kasus umum probabilitas risiko didistribusikan secara normal, dan ekor (min / maks) sama-sama kemungkinan.

Proses masuk ke nilai

Memberikan penilaian adalah setengah dari perjuangan. Hal yang paling berharga adalah mengikuti penilaian ini. Dan proses menyelesaikan tugas adalah proses aktif, pada partisipasi di mana hasil akhir lebih tergantung pada perkiraan yang berhasil ditebak di awal. Dan mematuhi tampilan yang sama di area yang sama sekali berbeda. Saya melihat banyak kasus ketika, setelah memberikan penilaian, pengembang mengambil posisi pasif "baik, ke mana harus pergi sekarang - apa pun yang terjadi", melipat kakinya dan mengikuti arus. Dan sekarang saatnya untuk bertindak.

Teknik yang berguna pada hit:

6. : . — , - , . /, . ( «» - ). , , - . — . . ? N.
«».
, (- + ) — , . 30%.
.
, ( ) . ( ) — , . — , . — , . .
( ). . , , , . , , . « » — 20-30%, 50. . ( ) , , , .

Dan sebagai permulaan, ada efek meluruskan tenggat waktu yang terkait dengan penilaian tugas. Ini dijelaskan secara lebih rinci, misalnya, di sini , dan karena itu saya tidak akan mengulanginya. Sebagaimana diterapkan pada evaluasi, itu memiliki konsekuensi bahwa perlu untuk mengevaluasi tugas dan memantau hit, jika penting bagi kita untuk menyelesaikan beberapa saat. Bahkan jika tugasnya kecil, dan ada banyak waktu sebelum pengirimannya (seperti dengan pengembang yang disebutkan sebelumnya, kewalahan dengan pekerjaan, yang tidak suka memberi peringkat). Dan jika kita tidak membayangkan apa sebenarnya stok itu (dan kita dibimbing oleh fakta bahwa itu besar dan “negara tidak akan menjadi miskin”), kita mendapatkan kelebihan persyaratan yang tidak terkendali. Dan tidak masalah buffer mana yang diletakkan: 2x, 5x, 100x - jika Anda tidak mengelolanya, itu akan dimakan semua sama.

Kesimpulan

Dengan menggunakan pendekatan ini, pengembang dapat merampingkan dan menyederhanakan proses penilaian. Dan kekuatan akan dihabiskan lebih sedikit, dan stres akan berkurang, dan hasil akhirnya akan lebih baik. Dan juga kita dapat menyajikan kejutan yang kurang menyenangkan untuk "mereka", dan kemudian kita akan menemukan bahwa "mereka" mulai berbicara bahasa yang sama dengan "kita".

gambar

Peringkat. Hitung dan temui