Mengapa dan kapan Anda harus memilih FFF? Mari kita lihat.
1. Tiga kombinasi
Setiap pendekatan manajemen proyek pada dasarnya berbeda karena memperbaiki atau tidak memperbaiki nilai-nilai berikut: anggaran, ruang lingkup pekerjaan, tenggat waktu dan kualitas internal sistem.
Kombinasi spesifik menciptakan kondisi kerja tertentu, memiliki pro dan kontra:
- Harga tetap
- Tiga poin dari segitiga proyek ditetapkan: waktu, uang, dan jumlah pekerjaan.
- Risiko utama ditanggung oleh kontraktor dan akibatnya, risiko ini tercermin dalam penilaian. Selain itu, risiko diciptakan untuk pelanggan, saya menulis tentang masalah ini di artikel 12 saat mengerjakan tugas teknis dalam produk IT .
- Nilai tambah yang besar dari pendekatan ini adalah parameter proyek yang telah ditentukan sebelumnya sebelum memulai pekerjaan. Seringkali bisnis / pemerintah perlu menentukan jangka waktu, uang dan jumlah pekerjaan dalam kontrak.
- . , . , .
- .
- Time and Materials (T&M)
- , - .
- .
- , .
- , . , , .
- .
- ( , Product Owner'), , , , .
- Fix Time and Budget, Flex Scope (FFF)
- : , .
- .
- , , .
- , .
- , , . .
- : , / , .
- , .. . , , , , , , .
– , . , «», , , . . , , SonarQube. Podlodka.
2.
Mengapa ketiga kombinasi ini terbentuk? Mengapa kita tidak bisa memperbaiki semuanya? Bagaimanapun, hal yang paling sederhana adalah memperbaiki anggaran, ruang lingkup pekerjaan, tanggal rilis dan kualitas internal sistem, menandatangani perjanjian (jika pelanggan internal, kemudian melalui prosedur persetujuan dengan pemangku kepentingan) dan melakukan pekerjaan dengan ketepatan yang akurat di keempat nilai. Tetapi, seperti yang ditunjukkan oleh latihan, ada masalah mendasar yang tidak membuatnya mudah untuk melalui jalan ini tanpa distorsi.
Tidak ada yang bermasalah dengan penghitungan anggaran, cukup mudah untuk menghitung tanggal rilis dan ada banyak metrik dan daftar periksa untuk menetapkan tingkat kualitas tertentu untuk suatu produk TI. Semuanya sederhana jika Anda dapat memperkirakan ruang lingkup pekerjaan secara akurat. Dengan kata lain, jika ada daftar tugas yang terperinci dan perkiraan yang akurat dari jumlah pekerjaan ini, maka tiga nilai lainnya dapat dengan mudah dihitung. Sebaliknya, jika tidak ada perkiraan pasti, nilai-nilai lainnya juga tidak akurat, karena didasarkan pada perkiraan jumlah pekerjaan.
Memperkirakan ruang lingkup pekerjaan selalu menjadi masalah, karena tidak ada metodologi estimasi tunggal yang dapat bekerja dengan akurasi yang dapat diterima. Semua metode didasarkan pada pengalaman tim sebelumnya yang melakukan hal serupa, yang pada akhirnya berarti ketidakakuratan, karena orang-orang tidak akurat: emosional, optimis, pelupa. Kurangnya metodologi penilaian yang akurat adalah faktor pertama yang menghalangi kita untuk masuk ke dalam penilaian jumlah pekerjaan.
Saya menulis lebih banyak tentang masalah ini di artikel Kepuasan Pelanggan untuk Pemrogram: Semua Pemrogram Optimis . Ada link ke report 36 dari Vadim Makishvili, di mana ia menyarankan agar skor dikalikan dengan 3. Menggunakan metafora meletakkan dan berjalan di rute, tertulis di artikel Mengapa proyek TI membutuhkan waktu 2-3 kali lebih lama dari yang direncanakan? ...
Dalam proses kerja pada produk TI, perubahan berikut: daftar tugas yang harus dilakukan, kedalaman elaborasi mereka, pendekatan desain sistem. Ini terjadi di bawah pengaruh lingkungan eksternal: perubahan pasar, perubahan strategi perusahaan, perubahan kebijakan dalam perusahaan, umpan balik dari pengguna, perkenalan baru dari mereka yang diam pada tahap analitik, dan kemudian memutuskan untuk berbicara, dll. Ketidakmampuan kita untuk mempengaruhi pengaruh eksternal adalah faktor kedua yang mencegah kita untuk melakukan penilaian terlebih dahulu.
Faktor ketiga adalah tidak adanya kriteria untuk menentukan pencapaian ketuntasan saat mendeskripsikan ruang lingkup pekerjaan. Penulisan TK tidak bisa diselesaikan, hanya bisa dihentikan. Saya menulis tentang ini secara rinci di artikel Kapan saatnya berhenti menulis Kerangka Acuan .
Saya harus membuat reservasi bahwa semua ini benar jika Anda bekerja di area yang agak kompleks: menurut kerangka kerja Cynefin, ini adalah area Kompleks dan Rumit. Jika proyek Anda menjadi Jelas dan pada saat yang sama agak pendek, maka kemungkinan besar Anda akan memperkirakan jumlah pekerjaan dengan sangat akurat.
Secara total, kami memiliki bahwa akar masalahnya terletak pada perkiraan yang tidak akurat dari ruang lingkup pekerjaan dan ketidakmungkinan praktis untuk membuat perkiraan ini akurat, oleh karena itu:
- Proyek harga tetap mengorbankan kualitas internal sistem, karena hampir tidak mungkin untuk mendapatkan perkiraan dengan tiga puncak tetap. Atau, dalam proyek harga tetap yang sama, mereka menganggarkan ulang begitu banyak risiko untuk menutupi ketidakakuratan dalam penilaian sama sekali, yang mana tidak efektif.
- T&M , . Product Owner'.
- FFF , , « » , T&M.
3. ?
Jika tidak mungkin untuk memperkirakan ruang lingkup pekerjaan dengan cukup akurat, mungkin tidak sama sekali? Ada gerakan #NoEstimates seperti itu. Singkatnya, kami mengatur proses pengembangan sedemikian rupa untuk melaksanakan tugas seefisien mungkin dari tahap ide hingga peluncuran ke produksi dan pada saat yang sama menjaga kualitas internal yang tinggi. Mereka menawarkan untuk mengatur proses menggunakan Kanban dengan metrik pemrosesan aliran pelacakan dan perhatian khusus untuk meningkatkan proses penyampaian fitur baru. Evaluasi dini dianggap berbahaya, mengevaluasi dan merawat backlog hanya membuang-buang waktu.
Tempat mempelajari lebih lanjut tentang #NoEstimates:
- David Anderson berbicara banyak tentang ini, misalnya, dalam ceramahnya Jalan Alternatif Menuju Agility Perusahaan .
- Askhat Urazbayev berbicara di AgileDays dalam pidatonya #NoEstimates: Pengembangan non-evaluatif .
- Ron Jeffries menulis tentang ini di artikel Some Thoughts on Estimation .
- Denis Stebunov menulis tentang ini di Habré dalam artikel Tentang Perkiraan Persyaratan dalam Pengembangan Perangkat Lunak .
Saya baik untuk pendekatan ini. Saya suka dia sebagai seorang insinyur dan sebagai pemimpin. Tetapi kehidupan diatur sedemikian rupa sehingga pemilik anggaran membutuhkan perkiraan, setidaknya pada tahap pertama pekerjaan, setidaknya satu perkiraan. Di Byndyusoft, kami terkadang beralih ke #NoEstimates, tetapi hanya setelah hubungan yang cukup lama dengan pelanggan dan ini tidak selalu terjadi.
4. FFF - keseimbangan antara fleksibilitas dan prediktabilitas
Meskipun nilai merusak kehidupan dan membuang-buang waktu, sulit untuk memulai tanpa nilai. Namun, jelaslah bahwa tidak ada perkiraan yang akurat. Ternyata, opsi terbaik adalah memperbaiki tenggat waktu dan anggaran sehingga bisnis dapat hidup dengannya, dan membiarkan volume pekerjaan mengambang. Selain itu, pelanggan dan kontraktor harus setuju bahwa pada setiap saat tim hanya terlibat dalam tugas yang paling penting dan perlu, dan pelanggan menyediakan waktu untuk memantau dinamika pilihan prioritas.
Pertama kali saya melihat deskripsi FFF adalah di Getting Real by 37signals di bab Fix Time and Budget, Flex Scope . Saat ini, di perusahaan saya, ini adalah pendekatan yang paling populer untuk bekerja, baik pelanggan maupun kami puas dengannya.
5. Kualitas internal sistem
Seperti yang saya tulis di atas, mengerjakan FFF dimungkinkan jika perusahaan memiliki pengembang yang kompeten yang dapat memastikan kualitas internal sistem yang tinggi. Ini biasanya dicapai dengan mengotomatiskan semua dan semua orang, membuat daftar periksa dengan praktik terbaik, terus-menerus meninjau kode dan arsitektur, semua jenis pengujian, dan yang terpenting, merekrut orang yang tepat ke tim.
Mengapa tidak melupakan kualitas internal, tulis blog Martin Fowler, Apakah Perangkat Lunak Berkualitas Tinggi Sepadan dengan Biayanya? ... Saya menulis tentang ini di artikel Menentukan kegagalan proyek TI... Singkatnya, dengan FFF, diasumsikan adanya perubahan arah pengembangan produk, dan hal ini menunjukkan fleksibilitas sistem yang memadai. Jika kualitas sistem rendah, maka setiap "giliran" akan memperlambat pengembangan dan meningkatkan biayanya, hingga penghentian proyek sepenuhnya.
Jika Anda ingin bekerja sesuai FFF, maka masukkan kriteria kualitas ke dalam kontrak untuk memperbaikinya dengan pasti.
6. Motivasi pelanggan dan kontraktor
Pekerjaan FFF memberikan motivasi yang tepat dari pihak pelanggan dan kontraktor. Tidak seperti Harga Tetap, di mana pelanggan dan kontraktor berkomunikasi melalui antarmuka kontrak, dan tidak seperti T&M, di mana pelanggan dapat kehilangan batasan dan membelanjakan lebih dari yang diperlukan; di FFF, setiap orang harus berinvestasi dalam komunikasi dan "hidup" dalam proyek untuk melakukan hal yang paling penting dan pada saat yang sama memenuhi persyaratan kontrak.
7. Pilih FFF
Harga tetap dan T&M memiliki kelebihan dalam konteks tertentu:
- Jika Anda berpartisipasi dalam tender dan berkomitmen untuk menyelesaikan pekerjaan tertentu dalam waktu dan uang yang telah disepakati, sementara komunikasi sebagian besar dibangun melalui kontrak, harga Tetap kemungkinan besar merupakan pilihan terbaik.
- Jika pelanggan tahu persis apa yang dia butuhkan dan tahu bagaimana membangun proses kerja secara efektif, maka dia hanya perlu membeli sumber daya T&M dan membuangnya atas kebijaksanaannya sendiri.
Namun, jika hal lain dianggap sama, kami mencoba memilih FFF. Pendekatan ini tampaknya paling seimbang: ini mengurangi risiko pelanggan dan kontraktor, menciptakan motivasi yang diperlukan di kedua sisi dan menjaga kualitas internal sistem.
Tautan:
- Bagaimana dan kerangka acuan apa yang harus ditulis saat mengerjakan Agile .
- Prinsip manajemen proyek di biro desain Artyom Gorbunov.