Saat menghitung jangka waktu proyek, kami secara tradisional mengevaluasi durasi langkah-langkah perantara, kemudian merangkumnya dan menambahkan penyangga untuk semua jenis kecelakaan. Kemudian kepemimpinan memotong kita periode ini menjadi dua. Sebagai bagian dari catatan ini, penulis akan tertarik pada perhitungan kami, karena bahkan seorang manajer proyek dengan pengalaman luas sering memahami bahwa periode yang dihitung terlalu pendek dan banyak, kadang-kadang, bertentangan dengan penilaian ahli pribadinya. Ya, ia akan mengoreksi estimasi persyaratan proyek dan langkah-langkah perantara ke penilaian ahli dan, dengan penguasaan yang benar dengan beberapa pemrosesan, akan memenuhi tenggat waktu dengan akurasi 15%, tetapi sedimen akan tetap ada.
Catatan ini menjelaskan alasan perbedaan antara perkiraan ahli dan perkiraan teoritis. Hal ini juga dianggap mengapa penilaian pakar “berlebihan” biasanya dianggap remeh jika tidak dilakukan berdasarkan statistik pada implementasi proyek serupa. Pada akhirnya, terungkap bagaimana cara menghitung dengan benar jangka waktu proyek dan menjelaskan situasinya kepada pihak yang berkepentingan sebelum dimulainya proyek atau selama proyek.
Akar kesalahan
Ketika kami mengevaluasi periode implementasi suatu karya, kami menentukan angka yang paling mungkin. Ini bisa berupa penilaian ahli pada satu poin atau tiga poin, seperti dalam PERT. Dalam proyek yang kompleks, ini bisa menjadi pemodelan parametrik. Dalam semua kasus, kami melakukan kesalahan yang sama. Faktanya adalah bahwa dalam semua metode estimasi klasik diasumsikan bahwa kita memiliki distribusi normal dari nilai estimasi - menurut Gauss. Para ahli teori sangat menyukai distribusi ini.
Distribusi normal berarti bahwa proyek dengan perkiraan durasi 6 bulan dengan benar kemungkinan besar akan selesai dalam 9 bulan atau 3 bulan. Pada jarak yang sama dari pusat distribusi, probabilitas penyelesaian proyek adalah sama - ini adalah fitur dari kurva Gauss. Di sisi lain, dalam praktiknya, hanya sedikit yang melihat proyek TI yang diselesaikan dua kali lebih cepat (setelah 3 bulan), tetapi proyek yang tertunda satu setengah kali lipat (9 bulan) yang kita lihat secara teratur. Selain itu, dengan distribusi normal, setengah dari proyek kami akan berakhir sebelum perkiraan waktu, dan setengah setelahnya. Tetapi ini tidak diamati dalam praktik juga. Ini menunjukkan bahwa distribusi normal untuk memperkirakan tenggat waktu tidak berlaku. Artinya, kami tidak memiliki distribusi normal, tetapi beberapa yang lain, dengan probabilitas penyelesaian yang berbeda sebelum tanggal dan setelah yang paling mungkin.
Pertimbangkan distribusi lognormal sebagai contoh distribusi tersebut. Ini akan menunjukkan kepada kita fitur-fitur dari kelas distribusi ini. Untuk distribusi lognormal, harapan median dan matematika secara signifikan melampaui puncak:
Dalam grafik yang disajikan, puncak menunjukkan probabilitas terbesar dari tanggal penyelesaian proyek.Gambar ini biasanya termasuk angka ini ditambah margin tertentu. Median menunjukkan titik pemisahan di mana setengah dari proyek akan diselesaikan sebelum batas waktu ini, dan setengah setelahnya. Ekspektasi matematis menunjukkan nilai rata-rata dari durasi proyek. Untuk fragmen kerja, distribusi akan memiliki fitur yang sama: perbedaan besar antara periode waktu yang paling diharapkan untuk implementasi fragmen kerja (rencana secara tradisional didasarkan padanya) dan nilai rata-rata dari istilah tersebut.
Untuk memprediksi durasi proyek, kami menentukan rantai waktu terpanjang dan menambahkan durasi fragmen-fragmennya. Jika kita menambahkan bersama nilai yang didistribusikan menurut Gauss, maka rata-rata istilah akhir yang benar harus diperoleh. Memang, setengah dari fragmen pekerjaan akan selesai lebih cepat dari jadwal, setengah kemudian dan heterogenitas ini akan membatalkan satu sama lain. Semakin banyak fragmen, semakin akurat ketidakhomogenan dikompensasi. Plus, kita dapat menghitung kesalahan dan sedikit menggeser tenggat waktu dengan satu atau dua sigma, tergantung pada konsekuensi tenggat waktu.
Tetapi kami tidak memiliki distribusi Gaussian. Di negara kita, memperpanjang waktu eksekusi dari setiap karya jauh lebih mungkin daripada memperpendeknya dengan jumlah yang sama. Akibatnya, jika kita menambahkan tenggat waktu untuk penyelesaian pekerjaan yang paling memungkinkan, maka heterogenitas dalam hal penyelesaian tidak dikompensasi, tetapi diperkuat. Selain itu, mereka mengintensifkan ke arah perpanjangan jangka waktu rata-rata nyata proyek dibandingkan dengan perkiraan. Apa yang kita amati dalam kehidupan nyata: jika istilah pertama sudah lewat, maka semua istilah lainnya akan terlambat, sementara penundaan hanya akan tumbuh. Hanya dengan menerapkan upaya tambahan maka kelambatan proyek dapat dihentikan.
Ciri metode perhitungan ini adalah fakta yang sudah diketahui: semakin kecil fragmentasi pekerjaan untuk menilai durasi proyek, semakin tidak akurat perkiraannya. Meskipun secara teori seharusnya justru sebaliknya. Alasan untuk ini adalah bahwa penilaian ahli kami untuk seluruh pekerjaan dan untuk bagian-bagiannya diambil dari pengalaman. Pengalaman mengevaluasi setiap elemen secara independen, dan tidak didasarkan pada aritmatika, yang menurutnya durasi pekerjaan harus merupakan jumlah dari durasi bagian-bagian penyusunnya. Aritmatika tidak bekerja di sini, karena jumlah tenggat waktu yang paling mungkin untuk menyelesaikan bagian tidak memberikan tenggat waktu yang paling mungkin untuk menyelesaikan semua pekerjaan - hanya harapan matematika yang dapat dijumlahkan dengan benar.
Jika kami mencoba untuk menggeser perkiraan jangka waktu untuk seluruh proyek atau bagian-bagiannya dengan satu atau dua sigma, mengingat distribusi menjadi normal, maka ini tidak banyak membantu, karena ekor distribusi jauh lebih tebal daripada kurva Gaussian. Akibatnya, karena peningkatan dalam estimasi istilah, seseorang bahkan tidak dapat mencapai median, belum lagi nilai rata-rata durasi proyek dalam bentuk harapan matematika.
Apa yang harus dilakukan
Di satu sisi, harapan matematika harus ditambahkan. Di sisi lain, kita bukan ahli matematika. Kami berasal dari kehidupan nyata dan kami memahami masalah menghitung parameter grafik bahkan ketika ada waktu untuk ini dan beberapa statistik yang terkumpul. Tetapi ada cara lain. Pada akhirnya, masalah menilai waktu lebih dari selusin tahun, dan praktiknya telah belajar untuk mengatasinya.
Metode Brooks : kami mempertimbangkan periode implementasi program "head-on" (pengguna adalah programmer itu sendiri) dan mengalikannya dengan 3 untuk produk perangkat lunak (pengguna adalah lingkaran orang yang tidak terbatas) atau kompleks perangkat lunak (dalam realitas saat ini - satu set layanan Microsoft) dan 9 untuk produk perangkat lunak sistem ( dalam realitas saat ini, satu set komponen infrastruktur terkait). Dari mana koefisien-koefisien ini berasal secara teoretis dapat dibenarkan dalam bab pertama buku Brooks "Mythical Man-Month" dan deskripsi tahun 1975 ini bergeser dengan baik ke realitas saat ini.
Metode scrum : kami memperkenalkan unit perantara abstrak dari kompleksitas implementasi fungsional, kami melihat statistik implementasi fungsional yang diukur dalam unit fungsional yang diberikan, kami meminta tim untuk mengevaluasi kompleksitas tugas proyek, menerjemahkan unit ke dalam iterasi Scrum (sprint) yang diketahui panjang dan mendapatkan estimasi persyaratan untuk tim pengembangan ini. Karena kami bekerja dengan statistik yang benar-benar dikumpulkan dan tim bertanggung jawab atas perkiraan kerumitannya, pengikatan durasi ke unit kerja adalah ekspektasi matematis dan karenanya separuh dari sprint akan berakhir sedikit lebih awal, setengah sedikit kemudian. Dalam praktiknya, di setengah dari iterasi Scrum, tim harus mengambil bagian dari tugas, dan setengahnya menambahkan yang tidak direncanakan, sehingga panjang sprint tetap konstan.
Tugas mentransfer Evaluasi Scrum dari satu tim ke tim lain adalah seni. Mereka tidak dapat dibawa dengan hanya memperkenalkan faktor konversi untuk unit kerja dari satu tim ke unit kerja dari tim lain. Faktanya adalah bahwa satu tim memiliki front-end yang baik dalam komposisinya, tetapi tidak memiliki spesialis basis yang baik, dan tim lain memiliki spesialis basis yang baik, tetapi tugas-tugas garis depan untuk itu adalah peningkatan kompleksitas. Perbedaan dalam spesialisasi pengembang akan mengarah pada fakta bahwa sehubungan dengan tugas-tugas backend, satu tim akan memiliki kelebihan dalam kompleksitas terhadap tugas-tugas pada database, dan yang lainnya di bagian depan. Selain itu, tim itu sendiri menentukan tingkat yang diperlukan dari kualitas internal produk dan tim yang berbeda menentukannya dengan cara yang sedikit berbeda dari tim tetangga, yang juga membuat sulit untuk menghitung ulang unit tenaga kerja. Artinya, adalah mungkin untuk menerjemahkan unit perantara dari satu tim ke unit perantara dari tim lain dengan membandingkan perkiraan tugas serupa, tetapi tugas ini harus diambil dari berbagai jenis kegiatan, dengan mempertimbangkan kekuatan dan kelemahan tim dan mempertimbangkan kekhasan pengaturan Scrum mereka.
Metode elemen fungsional : kami memperkenalkan unit perantara input tenaga kerja, menyusun daftar elemen fungsional (layar di browser, layanan mikro, elemen infrastruktur kustom, dll.), Memperkirakan kesulitan kerja pada setiap elemen fungsional di unit perantara. Setelah itu, berdasarkan pengalaman ahli kami bekerja dengan tim pengembangan spesifik, kami mengevaluasi faktor konversi unit perantara dari waktu ke waktu. Secara pribadi, saya masih secara independen mengevaluasi faktor konversi untuk berbagai jenis kegiatan: analitik, perancangan, penulisan pernyataan tugas, penulisan kode, tata letak, pengujian, integrasi, dll. Setelah ini, urutan operasi, karakteristik waktu tunda antara selesainya operasi sebelumnya dan awal yang baru harus diperhitungkan dan durasi proyek harus ditentukan oleh metode jalur kritis.
Sejauh ini, kami telah bekerja dengan faktor-faktor internal proyek. Tetapi kami juga memiliki yang eksternal: kontraktor eksternal, departemen terkait, pemasok, dan klien. Masalah dengan mereka persis sama: mereka melakukan respons dua kali atau lebih cepat atau kurang dari satu setengah kali lebih lama dari nilai yang paling mungkin. Artinya, juga tidak ada distribusi waktu normal. Ini juga harus diletakkan dan diperhitungkan berdasarkan statistik pada pekerjaan dengan klien, kontraktor dan unit terkait dan, jika mungkin, dilindungi dengan bantuan penalti.
Pembenaran waktu
Jadi, kami memperkirakan durasi proyek yang diproyeksikan. Bagaimana menjustifikasi istilah yang diterima? Berdasarkan perhitungan yang dilakukan. Sebagai contoh, penulis catatan untuk proyek non-Scrum biasanya membuat tabel visual multi-garis besar di Google Sheets dengan perhitungan terperinci dengan metode elemen fungsional. Perhitungan didasarkan pada praktik, semua koefisien dan parameter bersifat visual, dan praktik untuk pihak yang berkepentingan biasanya merupakan argumen yang kuat dan baik, bahkan jika itu ternyata merupakan periode yang tidak nyaman bagi individu tertentu. Terutama praktiknya adalah visual dan diperoleh dalam kerangka perusahaan saat ini.
Akankah para pemangku kepentingan, seperti manajemen, setuju dengan penilaian garis waktu yang dilakukan dengan baik dan terinformasi dengan baik? Tidak selalu, bahkan jika pihak yang berkepentingan sepenuhnya memahami dan menyadari bahwa penilaian itu benar. Kadang-kadang penilaian tidak dapat diterima karena alasan eksternal, tetapi ini sudah merepotkan bagi pihak yang berkepentingan, yang mengakibatkan keputusan yang sulit oleh manajemen pada waktunya. Namun demikian, melihat perhitungan berdasarkan pengalaman, manajemen dan pihak-pihak lain yang berkepentingan memiliki peluang untuk mempengaruhi jangka waktu proyek yang diprediksi dengan mengalokasikan sumber daya dan kekuatan tambahan. Terkadang manajemen yang memahami situasi waktu akan terus memotong tenggat waktu tanpa mengalokasikan sumber daya dan otoritas tambahan. Cara hidup dengan ini adalah topik dari catatan terpisah.