Semua orang ingin tahu berapa lama proyek akan berlangsung. Dalam artikel ini, kami akan menjelaskan cara memberikan perkiraan yang akurat dan tidak pasti kepada manajer dengan menggunakan waktu siklus dan menghitung cerita, serta saran kapan harus menghindari evaluasi sama sekali.

Celeste merasakan tekanan. Manajernya, Barry, ingin membuat ramalan timnya setiap triwulan. Tugas itu diperumit oleh fakta bahwa kelompok Celeste mengerjakan lebih dari satu produk: Barry ingin mendapatkan ramalan untuk tiga sekaligus. Masing-masing dari mereka adalah bagian dari proyek yang berbeda.

Programmer dari grup Celeste tidak memiliki cukup informasi untuk membuat setidaknya beberapa perkiraan, terutama untuk seluruh kuartal.

Celeste memutuskan untuk mengaku pada Barry dan melihat apa yang mereka lakukan. Dia membuat janji pada hari berikutnya dan mengumpulkan data.

Gadis itu tiba di kantor Barry tepat pukul 10 pagi. Ketika dia mengetuk pintu, Barry masih berbicara di telepon. Dia memberi isyarat padanya untuk masuk dan mengangkat satu jari untuk membuatnya jelas: dia akan siap dalam satu menit.

Dia duduk di kursi pengunjung di seberang mejanya.

Barry menutup telepon dan berbalik, "Baiklah, mari kita bahas waktu proyeknya, kan?"

Celeste mengangguk dan berkata, "Ya. Sepertinya itulah yang dapat dilakukan dalam situasi seperti itu. ”

Barry mengerutkan kening. "Sepertinya?" Saya perlu komitmen khusus. Tidak ada "sepertinya"! "

Celeste duduk dengan nyaman: "Barry, apakah Anda ditekan untuk melepaskan ketiga produk ini?"

"Bagaimana kamu tahu?" - Barry menggelengkan kepalanya. - Jika Anda mendengarkan orang-orang dari penjualan dan pemasaran, maka bencana akan terjadi jika kami tidak merilisnya sekarang. Saya tidak tahu harus menjawab apa, kecuali bahwa semuanya akan terjadi. "

"Tapi bulan lalu, Anda membahas portofolio proyek," kenang Celeste. "Saya pikir produk A adalah prioritas utama."

"Ya," katanya. "Dan produk B dan C juga menjadi prioritas utama."

Celeste memutar matanya, "Tapi tahukah Anda bahwa hanya ada satu prioritas utama, bukan?"

"Aku tahu itu, dan kau tahu," katanya. "Tapi kolega saya tidak tahu." Saya perlu ramalan apa yang dapat Anda lakukan - dengan baik, kewajiban - dan kemudian Anda dapat bernapas sedikit dengan tenang. "

"Produk apa yang harus kita kerjakan sejak awal?" Tanya Celeste.

"Produk A, tentu saja," katanya. "Dia yang paling dibayar kembali."

"Yah, itu yang akan kita lakukan," kata Celeste. "Kami tegang dan akan merilis A dalam waktu sebulan." Tugas Anda adalah membuat orang-orang baik ini menghadiri presentasi kami setiap minggu. Mereka harus melihat apa yang kita lakukan dalam seminggu. Jika mereka tidak datang ke demo, saya menolak untuk memberi mereka informasi. "

Barry bersandar, “Tunggu. Saya mengerti tentang demo. Dan bagaimana dengan dua bulan lainnya? Dan mengapa Anda tidak memberi mereka informasi? "

Celeste berkata: “Jika kami hanya mengerjakan satu produk, saya bisa menghitung peringkat berdasarkan siklus pengembangan kami. Untuk produk A, kami merilis tiga hingga empat lantai [kode untuk tugas khusus] per minggu. Tapi kami tidak tahu siklus pengembangan nyata untuk produk B dan C. "

Barry mengangguk: "Kenapa tidak?"

"Produk B dan C direncanakan dalam dua dan tiga bulan," kata Celeste. - Cukup jauh untuk pemasaran. Masalahnya adalah semakin jauh pekerjaan, semakin sedikit “waktu” departemen pemasaran bekerja dengan pemilik produk untuk mengklarifikasi cerita. Kami tidak tahu fungsi apa yang perlu diimplementasikan dalam dua dan tiga bulan. Kita harus membuat asumsi berbasis ilmiah dari awal (tebakan liar-ilmiah, SWAG). Ini normal, saya suka melakukan ini dengan teman-teman saya, tetapi kami perlu lebih spesifik. Yang mana tidak. "

"Jadi, mengapa kamu tidak memberi tahu mereka apa pun jika mereka tidak datang ke demonstrasi?" Tanya Barry.

"Jika tidak penting bagi mereka untuk mengamati kemajuan kita dan memberikan umpan balik, maka mereka tidak terlalu peduli soal waktu," kata Celeste. "Mereka ingin kita berkomitmen tanpa memberikan kewajiban sebagai imbalan." Mengapa saya harus menghabiskan waktu mengevaluasi jika mereka tidak ingin berkontribusi? "

Barry setuju untuk "menjual" kotak waktu "bulanan kepada manajer yang menekannya untuk menetapkan tenggat waktu. Celeste akan memastikan bahwa tim hanya berfokus pada produk A. Dan dia telah menjadwalkan pertemuan mingguan untuk demonstrasi sehingga tim akan menunjukkan pekerjaan mereka dan menerima umpan balik.

Apakah Anda akan tergoda untuk melakukan berbagai hal secara berbeda?

Estimasi istilah - pekerjaan non-sepele

Memperkirakan tenggat waktu juga berhasil. Banyak tim menempatkan rutinitas seperti itu dalam jadwal kerja reguler mereka. Namun, perkiraan kuartalan yang akurat seringkali membutuhkan lebih dari satu atau dua jam kerja.

Setidaknya ada dua masalah dalam menilai kinerja triwulanan. Terlalu sering, persyaratan tidak sepenuhnya ditentukan dan, seperti dengan tim Celeste, evaluasi memisahkan tim dari pekerjaan mendesak pada proyek.

Masalahnya adalah bahwa perencanaan pengembangan perangkat lunak tidak seperti merencanakan perjalanan. Jika kota Anda memiliki lebih dari satu lampu lalu lintas, maka Anda terbiasa dengan fluktuasi lalu lintas. Saya tinggal di pinggiran kota Boston, dari mana perjalanan ke bandara dapat memakan waktu 20 dan 90 menit. Paling sering dari 30 hingga 45 menit. Ini adalah variasi yang signifikan untuk perjalanan 13 km.

Dan tidak ada inovasi dalam perjalanan seperti itu. Saya pergi ke bandara berkali-kali dan saya tahu beberapa cara untuk sampai ke sana. Saya memiliki aplikasi seluler yang membantu saya menemukan rute tercepat bahkan di sepanjang jalan. Meskipun beberapa opsi sedikit lebih dapat diprediksi, tidak ada yang dapat menjamin bahwa perjalanan khusus ini akan berakhir dalam 20 menit.

Perjalanan ke bandara berlangsung pada rute yang telah ditentukan dan dengan rintangan yang dipahami dengan baik. Tetapi pengembangan produk adalah masalah yang berbeda. Ini inovasi. Dengan kata lain, kita belum pernah melakukan hal seperti ini sebelumnya. Jika sebaliknya, maka kita tidak perlu menulis aplikasi baru atau memperbarui sistem yang sudah usang - kita akan menggunakan yang lama.

Untuk penilaian yang masuk akal, kami memiliki beberapa opsi. Sebenarnya tiga:

• Anda dapat memperkirakan urutan besarnya. Saya pikir ini berguna untuk seluruh proyek. “Kami mengharapkan kerja lima hingga sembilan bulan. Kita akan lebih tahu ketika kita menjawab pertanyaan-pertanyaan ini dan menyelesaikan bagian dari pekerjaan yang rumit ini. ” SWAG sangat cocok untuk evaluasi semacam itu.
• Anda dapat mengumpulkan informasi yang cukup tentang persyaratan dan memberikan perkiraan yang masuk akal. Tim mungkin perlu bekerja dengan cerita pengguna untuk membuat perkiraan dengan sebaran waktu yang cukup kecil.
• Ada opsi untuk mengevaluasi pekerjaan untuk waktu yang singkat, misalnya, selama satu atau dua minggu. Mungkin ternyata perkiraan akhir tidak sepenuhnya benar. Tetapi biasanya hasilnya cukup dekat sehingga tidak mengecewakan orang yang diminta untuk melakukannya.

Prakiraan apa yang Anda butuhkan untuk seorang manajer?

Saya perhatikan bahwa manajer sering kali membutuhkan estimasi urutan besarnya. Dalam hal ini, tim dapat membuat perkiraan dan melaporkannya sebagai berikut:

“Kami percaya bahwa proyek ini akan memakan waktu lima bulan dengan kepercayaan 50% dalam akurasi perkiraan ini. Kami 80% percaya diri dalam penilaian delapan bulan. Sepuluh bulan adalah kepercayaan 90%. "

Ini membantu manajer memahami bahwa ada berbagai kepercayaan. Jika mereka menginginkan kepastian 100%, maka ini bisa memakan waktu lebih dari 14 bulan.

Anda dapat menggunakan metode spiral: “Kami fokus pada kuartal pertama tahun depan. Kami tidak tahu kapan tepatnya di kuartal pertama, tetapi kami pikir kami bisa mengatasinya. " Saat proyek berjalan, Anda menentukan: "Kami memperbarui perkiraan untuk suatu periode antara pertengahan Januari dan pertengahan Maret." Setelah belajar lebih banyak, katakan: "Di suatu tempat di bulan Februari, jika badai salju tidak terjadi." Kemudian pada bulan Januari Anda dapat mengatakan: "Minggu ketiga bulan Februari."

Saya juga akan merekomendasikan rentang tiga tanggal: “Tanggal optimis adalah Januari. Yang paling realistis adalah akhir Februari. Yang paling pesimistis adalah akhir April. ”

Bagaimanapun, jangan pernah memberikan penilaian yang jelas. Itu menggoda St Murphy (dari Hukum Murphy) untuk mengambil proyek Anda dan melakukan hal-hal buruk.

Dalam beberapa kasus dan dalam beberapa perintah, pelanggan mungkin memerlukan informasi tambahan. Di sini Anda dapat mendiskusikan dengannya fungsi-fungsi spesifik yang sedang dilaksanakan untuk memahami ketidakpastian.

Gunakan waktu siklus alih-alih evaluasi

Saya tidak suka perkiraan tentang masa implementasi proyek perangkat lunak atau proyek TI lainnya, terutama Agile. Sebaliknya, saya lebih suka tim untuk merilis cerita yang sangat kecil atau mengevaluasi pekerjaan dengan waktu siklus.

Jika Anda tidak terbiasa dengan terminologi:

• Kisah pengguna menggambarkan bagaimana pelanggan atau pengguna menggunakan produk untuk satu tujuan fungsional ("Saya ingin memesan tempat" atau "Saya perlu menerbitkan data kota pintar untuk memenuhi persyaratan transparansi"). Kisah berbeda dari kisah pengembang yang melihat suatu produk dalam hal basis data dan API.
• Waktu siklus mengacu pada total waktu yang dibutuhkan tim untuk merilis pekerjaan pada satu cerita. Ini termasuk waktu pengembangan aktif dan waktu henti ketika pekerjaan mengharapkan sesuatu.

Idenya adalah untuk memahami waktu rata-rata yang diperlukan untuk menghasilkan sesuatu yang berguna (sejarah).

Dalam kasus Celeste, dia tahu bahwa sebuah tim dapat menghasilkan tiga hingga empat lantai per minggu untuk produk A. Bagi banyak tim, penghitungan cerita berfungsi seperti metode penilaian lainnya.

Jika tim belum pernah mengerjakan produk yang serupa, maka waktu siklus sebelumnya tidak akan berlaku untuk produk baru ini. Tim mungkin tidak tahu bagaimana memperbaiki dan membagi cerita untuk menghasilkan beberapa minggu. Selain itu, ia mungkin tidak mengetahui status kode dan ketersediaan tes yang cukup. Jika tim Anda telah mengerjakan cerita selama lebih dari tiga hari, jangan repot-repot memprediksi. Hitung cerita dan jangan mencoba melakukan lebih dari biasanya.

Ketika sebuah tim mulai menangani cerita dalam satu atau dua hari, Anda juga tidak diharuskan membuat penilaian. Seringkali perhitungan sederhana lebih mudah dan lebih akurat.

Mengapa tidak menggunakan kecepatan?

Anda telah memperhatikan bahwa saya merekomendasikan waktu siklus dan penghitungan cerita, daripada kecepatan untuk memperkirakan waktu proyek. Karena kecepatan adalah pengganti.

Misalnya, saya berjalan setiap hari agar tetap bugar. Saya mengikuti rute yang sama setiap hari, melacak kecepatan relatif saya. Pada hari yang cerah dan indah, saya berjalan sekitar 5,6 km per jam. Pada hari hujan atau panas dan lembab, kecepatan turun menjadi 4 km / jam. Di salju atau es saya tidak bisa keluar sama sekali, dalam hal ini kecepatan saya adalah 0.

Saya pergi pada rute yang sama. (Ya, itu membosankan, tapi itu masalah saya). Meskipun saya menempuh jarak yang sama, perjalanan membutuhkan waktu yang berbeda tergantung kondisi. Di sini kondisinya mirip dengan basis kode dan tes tim Anda.

Jika ceritanya cukup kecil, kecepatannya sesuai dengan waktu siklus. Tetapi terlalu sering, manajer mencoba mengevaluasi proyek dengan cerita yang sangat besar. Menghitung akan lebih sederhana: “Kita bisa menyelesaikan satu atau dua cerita dalam satu siklus. Satu atau dua cerita mana yang ingin Anda pilih? "

Menolak untuk mengevaluasi bukanlah tipuan

Ketika Barry membahas masalah dengan kolega, salah satu dari mereka berkata: "Menolak untuk mengevaluasi tenggat waktu adalah penipuan!"

Barry menjawab: “Tidak benar. Anda ingin kami merilis produk, kan? "

Jawabannya adalah “Tentu saja. B dan C. "

"Masalahnya adalah bahwa mereka harus dilakukan pada gilirannya," jawab Barry. - Jika Anda benar-benar membutuhkan produk A, apa gunanya membuat perkiraan untuk sisanya? Kita bisa mulai bekerja dan menunjukkan kemajuan kita. Ketika kami telah melakukan cukup, kami akan mengulangi prosedur untuk B dan C. Selain itu, Anda akan memiliki waktu untuk mengklarifikasi persyaratan untuk B dan C untuk mempersiapkan kami cerita. "

Tim Celeste menyelesaikan sebagian besar Proyek A dalam satu bulan. Pelepasan produk B membutuhkan waktu lebih lama - mendekati dua bulan. Dan karena perusahaan menerima pendapatan yang cukup dari pelepasan produk A dan B, itu mengurangi tekanan pada pelepasan produk C.

Ketahui nilai yang dibutuhkan manajer Anda. Hadirkan dia sesuai kebutuhannya. Dan jika Anda punya sedikit waktu, mulai bekerja.

Evaluasi proyek TI: pelajaran

• Jangan sertakan angka atau tanggal tertentu. Sebagai gantinya, berikan urutan estimasi besarnya dengan keyakinan dalam rilis yang tepat waktu. Atau usulkan estimasi jangka pendek berdasarkan faktor-faktor di bawah kendali Anda.
• Bagilah tujuan proyek menjadi cerita pengguna yang menentukan fungsionalitas perangkat lunak. Kemudian buat estimasi Anda berdasarkan jumlah cerita pengguna yang dapat Anda proses.
• Pastikan Anda memahami persyaratan sebelum membuat komitmen.