Beberapa menemukan jalan keluar, beberapa tidak melihatnya bahkan jika mereka menemukannya, dan banyak yang bahkan tidak mencarinya.
Dari Alice in Wonderland
Artikel ini memunculkan pertanyaan-pertanyaan berikut.
- Tentang ketidakkonsistenan komponen formula outsourcing 'Scrum + Fixed Price'.
- Satu kemungkinan kesalahan (akar penyebab) sebelum pilihan yang salah dari alat Scrum.
- Tentang satu situasi di mana benar-benar ada masalah menggabungkan Scrum dan Harga Tetap, yang membutuhkan analisis mendalam dan pertukaran untuk menyelesaikannya.
Artikel ini menyentuh titik yang sangat kontroversial yang tidak memiliki sudut pandang yang jelas dan merupakan subjek diskusi tanpa akhir. Oleh karena itu, ketika membaca, harap diingat bahwa pendapat Anda mungkin tidak sesuai dengan yang disajikan, tetapi ini tidak berarti sama sekali bahwa salah satu dari kita benar-benar benar serta fakta bahwa seseorang benar-benar salah.
Seperti disebutkan dalam artikel "Bagaimana memulai pseudo-Scrum dalam outsourcing" , dalam sejumlah besar proyek outsourcing, tim yang menggabungkan (atau mungkin angan-angan) Scrum dan Harga Tetap, siklus hidup proyek (LC) tidak diidentifikasi dengan benar. Itu kesalahan dibuat dalam memilih antara siklus hidup inkremental iteratif atau fleksibel. Dan, sebagai hasilnya, alat manajemen yang salah dipilih - kerangka kerja Scrum. Dan sudah konsekuensi dari pilihan ini adalah munculnya sejumlah masalah, kesimpulan yang salah tentang Agile, Scrum dan upaya (dari kata "siksaan"?) Untuk menggabungkan dua konsep yang saling eksklusif ini.
Saling eksklusif ?!
Sekarang saya berdebat.
Diasumsikan bahwa pembaca lebih akrab dengan bahan-bahan artikel di atas.
Scrum + Fixed Price – , ?
, , .Ketika menyimpulkan kontrak untuk penyediaan layanan outsourcing, klien hampir selalu menekankan Harga Tetap (skema turnkey). Keinginannya adalah untuk memperbaiki Lingkup Produk (atau jumlah pekerjaan), melihat anggaran, tenggat waktu. Dia ingin melihat apa yang dia "beli." Pelanggan jarang setuju dengan Waktu & Bahan.
“ ”
Dengan demikian, poin utama: kebutuhan klien harus diperbaiki dalam kontrak, dan penyedia layanan perlu memenuhi kewajiban berdasarkan kontrak dan memastikan bahwa parameter akan tetap tidak berubah dengan kesalahan yang dapat diprediksi (karena beberapa tingkat ketidakpastian dan risiko pada tahap penjualan dan kesimpulan kontrak) setelah dimulainya pengembangan. Masalah mengurangi tingkat ketidakpastian dan risiko adalah masalah kelayakan dan kualitas fase Penemuan (Pra-penjualan, diagnostik) dalam kaitannya dengan Lingkup Produk.
Sangat jelas bahwa jika kita memperbaiki sesuatu (kita menjamin kepada klien berdasarkan kontrak), maka kita harus merencanakan dan mengelolanya sedemikian rupa untuk memastikan pemenuhan kewajiban kita. Itu mengelola rencana (atau karakteristik tetap dari segitiga proyek).
Harga Tetap hanya mengharuskan kita untuk memprioritaskan manajemen rencana. Kalau tidak, mengapa kita harus memperbaiki sesuatu, mengetahui sebelumnya bahwa itu akan berubah, dan kita tidak benar-benar berencana untuk mengelolanya? Untuk hanya menandatangani kontrak? Kesalahan kritis dalam proses penjualan yang mapan: kami memperbaikinya, mengetahui sebelumnya bahwa kami akan berubah, hanya untuk menandatangani kontrak!
Mengapa kita harus berubah? Karena Scrum selalu tentang ketidakpastian dan hasilnya - berubah. Ini tentang prioritas manajemen perubahan. Dan mungkin saja mereka muncul setelah sprint pertama. Mengapa?
Penyimpangan tentang kemungkinan alasan untuk perubahan
Apa yang bisa menjadi alasan untuk perubahan? Misalnya, mungkin dalam fase Penemuan (pra-penjualan, diagnostik) yang dilakukan dengan buruk dalam situasi di mana Lingkup Produk dapat didefinisikan sampai batas tertentu (misalnya, lihat paragraf 3 dari Studi Kasus dalam artikel ), tetapi untuk apa untuk beberapa alasan ini belum dilakukan. Dalam hal ini, ini adalah masalah fase dan proses internal, dan bukan alasan untuk memilih Scrum untuk kontrak Harga Tetap, siklus hidup yang fleksibel dan bukan siklus berulang untuk mengkompensasi kesalahan yang dibuat.
Meskipun, dalam keadilan, saya perhatikan bahwa dalam penjualan (Pra-penjualan-kegiatan analis bisnis) dalam outsourcing (salah satu fase paling bermasalah dari sudut pandang Lingkup Produk!), Tidak semuanya sesederhana di toko ketika produk jadi dengan properti tertentu dibeli (Kegunaan). Dan fase Discovery adalah aktivitas yang sulit untuk dijual oleh para analis dan tim bisnis. Tetapi meminimalkan ketidakpastian sampai taraf tertentu dan menilai risiko adalah salah satu tugas utama dari proses penjualan yang dibangun dengan baik. Serta pembentukan pemahaman di klien tentang perlunya dan pentingnya kegiatan ini (bisa sangat sulit!). Tetapi untuk ini ada sejumlah teknik dan alat yang memadai. Dan itu bermuara pada masalah kualitas layanan yang diberikan, dan bukan penjualan "babi di ladang".
Alasan lain mungkin ketidakmampuan untuk menentukan Lingkup & Visi Produk pada saat ini (misalnya, lihat hal. 2 dari Studi Kasus dalam artikel ). Dan ini memang situasi yang sangat sulit dan tidak menguntungkan bagi kedua belah pihak, ketika timbul kontradiksi serius dan pertanyaan tentang penggabungan Scrum dan Harga Tetap dalam penyediaan layanan outsourcing ditingkatkan. Dibutuhkan analisis yang cermat, tindakan tambahan untuk membentuk pemahaman komprehensif tentang klien (seringkali secara teknis dan ideologis jauh dari kenyataan proses pengembangan) tentang kemungkinan kesulitan dan risiko, dan pencarian solusi kompromi.
Jadi mengapa Scrum dipilih? Untuk mengelola perubahan yang, misalnya, muncul sebagai akibat dari fase Penemuan yang dilakukan secara tidak benar (Pra-penjualan, diagnostik) atau ketika Lingkup Produk tidak dapat ditentukan pada fase ini? Dalam kasus pertama, menurut saya, ini salah. Dalam kasus kedua, sulit untuk diterapkan dengan Harga Tetap.
Opsi ketiga yang mungkin untuk memilih Scrum sebagai alat Agile, siklus hidup yang fleksibel alih-alih yang berulang dalam situasi di mana Lingkup Produk dikerjakan dan diperbaiki pada fase Penemuan (Pra-penjualan, diagnostik), dan dalam kontrak - Harga Tetap, juga tidak rasional menurut saya: mengapa memilih alat untuk mengelola perubahan (tidak fokus jelas merupakan hal yang lebih prioritas - rencana), kapan kemungkinannya diminimalkan?
Kembali ke ide utama artikel.
Tapi katakanlah Scrum dipilih. Sekali lagi, Scrum adalah alat manajemen perubahan, ketika tingkat ketidakpastian dapat dikurangi hanya dalam proses dan hanya ketika menggunakan pendekatan yang tepat. Dan penurunan ini adalah hasil dari proses ini.
Tetapi kontrak Harga Tetap memberikan prioritas untuk mengelola rencana!
Dengan demikian, 'formula' 'Scrum + Harga Tetap' diubah menjadi 'manajemen perubahan + manajemen rencana secara bersamaan'. Tugas manajer adalah mengelola, hingga tingkat yang berbeda-beda, baik rencana maupun perubahannya, tetapi hanya ada satu prioritas: rencana atau perubahannya.
Entah manajemen rencana atau manajemen perubahan adalah semacam aksioma yang melekat pada dasar-dasar manajemen dan analisis bisnis. Ini tercermin dalam manual dasar (dan tidak hanya) untuk manajer (PMBOK) dan analis bisnis (BABOK). Dan klasifikasi siklus hidup (dan identifikasi mereka dalam kaitannya dengan proyek tertentu) bergantung padanya: ada siklus hidup yang dirancang untuk mengelola rencana (misalnya, Waterfall, iterative incremental (IID)) dan fleksibel, Agile untuk manajemen perubahan. Pilihan siklus hidup (dan selanjutnya alat) didasarkan pada apa yang diberikan prioritas dalam manajemen.
Siklus hidup fleksibel adalah semacam siklus hidup inkremental berulang untuk proyek-proyek dengan fitur / karakteristik dominan tertentu (daftar pertanyaan cek diberikan dalam artikel di atas), memungkinkan Anda untuk mengidentifikasinya sebagai siklus hidup yang terpisah dan "mengarahkan semua upaya" untuk mengubah manajemen. Fitur-fitur ini dapat dikaitkan: ketidakmungkinan "di sini dan sekarang" untuk mencapai tingkat kepastian tertentu dari Lingkup Produk (yang paling penting!), Pencarian solusi bisnis (atau pengiriman cepat ke bisnis untuk menghasilkan umpan balik) yang akan "menembak", pembentukan daftar fungsi utama produk (Fitur Utama), iterasi pendek, variabilitas, percobaan, peningkatan fungsionalitas secara bertahap, retrospektif, peningkatan tidak hanya produk, tetapi juga proses untuk mendapatkan versi terbaik dari produk. Apakah mungkin dalam kondisi seperti itu untuk mendapatkan perkiraan anggaran dan persyaratan yang memadai?
Iblis hanya dalam satu detail, atau ... ini semua tentang Lingkup Produk
Semuanya memiliki moralitasnya sendiri, Anda hanya perlu dapat menemukannya!
Dari Alice in Wonderland
Apa yang dapat Anda katakan tentang kepastian (kemampuan untuk menetapkannya) dalam kaitannya dengan Lingkup & Visi Produk pada tahap penjualan, fase Penemuan, pada awal proyek outsourcing?
Jika Lingkup Produk tidak dapat didefinisikan, dievaluasi, ditetapkan karena alasan keunikan produk, gagasan tentang permulaan, ketidakpastian mengenai efektivitas keputusan bisnis yang dibuat (kebutuhan untuk menemukannya) dan sulitnya menentukan fungsi-fungsi utama produk, keberadaan hipotesis yang memerlukan verifikasi, dll. ... (lihat lagi poin 2 dari Studi Kasus di sini ), maka, tentu saja, kerangka kerja Scrum adalah alat yang paling cocok.
Namun, untuk outsourcing, situasi ini secara signifikan diperumit oleh keinginan klien untuk menggunakan skema Harga Tetap ketika menyelesaikan kontrak dan muncul dalam cahaya yang tidak menguntungkan bagi kedua belah pihak. Hingga taraf tertentu, dengan beberapa asumsi, kompromi dapat dicapai dalam mengontrak dan mengelola proyek semacam itu. Penting untuk membentuk pemahaman yang benar dan harapan yang benar dari klien (investor), menilai risiko, mempertimbangkan, jika mungkin, skema interaksi keuangan lainnya, dan dalam proses implementasi proyek, terus-menerus bekerja dengan loyalitas klien, dll. Saya tidak akan membahas pertanyaan itu, karena itu berada di luar cakupan artikel.
Dalam outsourcing, paling sering pertanyaannya terutama terletak pada perilaku kompeten dari fase Penemuan (pra-penjualan, diagnostik) dalam kaitannya dengan Lingkup Produk dan pilihan siklus hidup yang tepat. Dan jika Agile dan Scrum dipilih dalam situasi di mana Lingkup Produk dapat diperbaiki (dan bahkan lebih lagi ketika ini tidak dilakukan untuk beberapa alasan tepat waktu, dengan harapan / asumsi perkembangannya di masa depan), dan pada saat yang sama dalam kontrak - Harga Tetap, menurut pendapat saya, telah terjadi kesalahan yang meragukan hasil positif dari proyek ini.
Terima kasih atas perhatian anda!