Ini bukan tentang metodologi, tetapi tentang komunikasi dengan pelanggan.
Saya memiliki banyak situasi di mana pelanggan ingin terus-menerus menambahkan fitur baru ke proyek yang belum selesai, dan terkejut mengapa hal itu akan meningkatkan keseluruhan biaya dan penundaan. Konteks dan kepribadian para pelanggan itu berbeda, itu membutuhkan pendekatan yang berbeda, tetapi saya dapat mencoba untuk mengisolasi beberapa pedoman dan saran:
- Pastikan bahwa pelanggan memiliki akses ke informasi umum yang diperlukan untuk memahami mengapa perubahan persyaratan dapat berdampak pada biaya dan keterlambatan . Dengan kata lain, terbitkan beberapa artikel tentang hal-hal itu, menjelaskan apa yang orang non-teknis mungkin tidak tahu sama sekali.
Misalnya, bagi kebanyakan orang, benar-benar aneh bahwa perubahan yang mereka anggap kecil mungkin berdampak besar pada proyek dan menjadi sangat mahal (lihat contoh dalam pertanyaan saya ). Jika mereka meminta untuk melakukan beberapa perubahan, dan setiap kali Anda memberi tahu mereka, tanpa menjelaskan apa pun, bahwa mereka harus membayar ribuan dolar ketika mereka mengharapkannya secara gratis atau untuk beberapa puluh dolar, mereka mungkin akan berpikir Anda hanya mencuri uang mereka. Ini terutama benar karena beberapa programmer dan perusahaan perangkat lunak yang tidak etis mengembangkan produk yang tidak dapat dipertahankan (jadi Anda tidak dapat meminta untuk mengubahnya nanti oleh pengembang normal), kemudian meminta Anda membayar terlalu banyak untuk setiap modifikasi.
- Pastikan bahwa pelanggan telah memahami mengapa perubahan spesifik yang diinginkannya berdampak pada biaya . Untuk itu, Anda dapat memberinya tautan ke artikel Anda (lihat poin sebelumnya), atau hanya meringkas, dengan cara non-teknis, apa yang diperlukan untuk membuat perubahan yang diminta.
Penjelasan seperti itu juga merupakan ide yang bagus karena memungkinkan pelanggan Anda untuk memiliki pemahaman yang lebih baik tentang produk dan perubahannya. Dalam beberapa kasus, beberapa pelanggan saya berakhir dengan mengatakan bahwa perubahan yang mereka inginkan tidak terlalu pintar, dan bahwa mereka akan melakukannya dengan cara lain. Anda juga dapat menyarankan beberapa hal. Ini sangat dihargai oleh beberapa pelanggan (peringatan: beberapa lainnya membencinya), dan menunjukkan bahwa Anda tahu apa yang Anda bicarakan (dengan membandingkannya dengan kode monyet yang hanya menerjemahkan persyaratan ke dalam kode, tanpa terlalu memikirkan pendekatan yang mungkin) .
- Pastikan bahwa pelanggan tidak dapat melakukan apa pun yang dia inginkan, kecuali dia benar-benar yakin. Bagi sebagian orang, satu-satunya cara adalah mengunci persyaratan secara definitif sebelum mulai kode . Kalau tidak, itu adalah bencana, dan proyek tidak akan pernah berakhir . Bagi yang lain, itu adalah ide yang baik untuk tidak pernah melihat proyek yang tidak terintimidasi (secara umum pelanggan saya memiliki akses langsung ke produk yang tidak terintervasi sejak dini, sehingga mereka dapat membuat komentar / penyesuaian lebih awal juga).
Misalnya, saya memiliki pelanggan yang, setelah mengirim persyaratan "final", mengirim, rata-rata, sepuluh surat per hari dengan sepuluh perubahan persyaratan, pergi dari modifikasi kecil ("Bisakah Anda mengubah lebar perbatasan zona tengah di halaman beranda?) dari tiga hingga enam piksel? ") hingga perubahan yang memengaruhi seluruh proyek (setelah dua bulan pengembangan, satu minggu sebelum rilis:" Akhirnya, saya pikir ASP.NET adalah ide yang buruk. Bisakah Anda beralih ke PHP? " ).
Jadi untuk pelanggan itu , kami terpaksa mengunci semua persyaratan sebelum menulis kode. Itu tertulis dalam kontrak. Tidak ada perubahan yang diterima sebelum rilis final.
Itu tidak terlalu buruk, akhirnya, karena anehnya kami diizinkan untuk sangat terorganisir: proyek dirilis, sesuai dengan persyaratan lama, dan kemudian, beberapa hari kemudian, kami memulai versi berikutnya dari awal dengan set yang sama sekali berbeda persyaratan.