Dalam sebuah diskusi tentang menjaga motivasi pengembang, seseorang berkata:

“Saya juga melakukan semua yang saya bisa untuk mengisolasi pengembang kami […] Dari permintaan perubahan yang tidak sesuai”

Berpegang teguh pada rencana pasti akan membuat pengembang dan manajer tetap berada dalam zona nyaman mereka. Proyek ini terus berjalan dan selesai tepat waktu. Tapi kami tidak peduli tentang pemenuhan tenggat waktu. Kami berkomitmen untuk membangun perangkat lunak yang memberikan nilai kepada pelanggan kami. Spesifikasi berubah seiring pelanggan mendapatkan wawasan baru tentang apa yang paling bernilai. Mereka akan berubah.

Secara tradisional, respons industri perangkat lunak adalah menghindari perubahan. Minta klien untuk menandatangani rencana tersebut, dan kemudian menaatinya. Buat mereka mengerti bahwa perubahan akan sangat merugikan mereka. Lindungi pengembang dari perubahan.

Dampaknya bersifat regresif: pelanggan, manajer, dan pengembang ditanamkan rasa takut akan perubahan. Ketika perubahan menjadi tak terelakkan setelah banyak perlawanan, tidak ada yang tahu bagaimana meresponsnya.

Mengetahui cara merespons perubahan dalam proyek perangkat lunak adalah keterampilan yang tiada duanya, baik itu pemfaktoran ulang atom, atau perubahan arsitektur besar, atau menulis pengujian otomatis yang membantu Anda tetap waras dalam prosesnya.

Seperti keterampilan apa pun, Anda dapat menguasainya melalui belajar dan berlatih. Mungkin cara terbaik untuk mempelajari cara menghadapi perubahan dalam pengembangan perangkat lunak adalah dengan memperkenalkan perubahan secara sengaja. Ini akan menjadi eksperimen yang menyenangkan: beri tahu pengembang Anda untuk mengubah sesuatu, agar mereka tetap waspada dan terlatih dalam seni perubahan. Saya tidak tahu apakah mereka akan menyatakan Anda gila, atau apakah mereka akan termotivasi oleh hal itu. Saya hanya tahu saya akan melakukannya.