Bagaimana cara menghadapi perubahan persyaratan yang sering terjadi?

Saya sedang berhadapan dengan situasi yang cukup menegangkan (menurut saya) di tempat kerja saya saat ini.

Kami sudah mulai mengembangkan proyek baru, mendapatkan beberapa persyaratan, mengimplementasikannya dan kemudian menunjukkan kepada seseorang yang dapat Anda panggil sebagai 'penasihat bisnis' (orang yang mengetahui persyaratan bisnis tetapi tidak akan menggunakan program). Orang itu seharusnya mengevaluasi aplikasi dari sudut pandang pelanggan, mengujinya, dll.

Di sini bagaimana 'proses' terlihat:

1. penasihat bisnis berbicara di malam hari dengan bos saya selama satu atau dua jam di windows messenger
2. hari berikutnya saya menerima email dengan salinan percakapan itu. Saya seharusnya memilih tugas dari sana, memeriksa bug yang dilaporkan (yang seringkali bukan bug, hanya pengujian yang buruk dan melupakan perusahaan sebelumnya)
3. Saya menerapkan perubahan, implementasi diterima dan kemudian dalam satu atau dua minggu ternyata tidak ingin mereka inginkan (mereka berbicara dengan beberapa klien potensial yang telah melihat perangkat lunak selama 5 menit dan ia menyarankan perubahan) - Saya harus melakukan perubahan baru

Jangan salah paham, saya mengerti bahwa terkadang persyaratan berubah. Yang membuat saya kesal adalah seberapa sering perubahan terjadi di tempat kerja saya dan betapa mudahnya 'manajemen' memberikan dua persyaratan baru atau terkadang perubahan mendasar pada fitur yang ada.

Pada saat yang sama kami bekerja pada tenggat waktu yang ketat dan saya memiliki kesan bahwa alih-alih maju dengan perangkat lunak kami, kami menjalankan lingkaran.

Saya mencari saran dari Anda bagaimana menghadapi situasi ini? Apakah ini situasi normal dan saya hanya hipersensitif tentang hal itu?

Jika memungkinkan, lakukan percakapan yang Anda kirimi email dan ubah menjadi dokumen persyaratan. Buatlah daftar tugas yang bisa Anda dapatkan darinya dan pesan berdasarkan apa yang Anda anggap sebagai prioritas dan tetapkan estimasi untuk masing-masing. Kemudian tanyakan fitur mana yang mereka inginkan untuk rilis berikutnya.

Pada dasarnya, paksakan semacam umpan balik di mana manajemen tahu apa yang akan Anda bangun. Tulis dokumen persyaratan Anda sendiri sampai mereka menerima pesan.

Kartu Cerita

Saya pikir situasi Anda sangat cocok untuk memperkenalkan cerita pengguna . Mereka sangat membantu dalam menyediakan cara interaktif dan berkelanjutan bagi manajer Anda untuk menetapkan prioritas dan dia bahkan dapat membuangnya ketika dia kembali ke ide seminggu kemudian dan menyadari itu tidak bisa diterapkan.

Di dunia nyata, persyaratan berubah secara rutin. Di sisi positifnya, Anda mengetahuinya sebelum selesai membangun perangkat lunak dan mengirimkannya - Anda memiliki siklus umpan balik yang ketat dari pengguna langsung perangkat lunak, yang sebenarnya hebat.

Sepertinya masalah terbesar di sini adalah cara ad-hoc yang mengatur perubahan. Anda memiliki apa yang dianggap tangkas / Scrum sebagai "pemilik produk", yang memberikan umpan balik, tetapi prosesnya tidak terdokumentasi dengan baik, dan dipikirkan dengan buruk.

Anda mungkin ingin melihat model di Scrum , dan pandangan mereka tentang apa pemilik produk yang efektif , untuk membantu menginformasikan langkah Anda selanjutnya.

Jadi, alih-alih memiliki proses ad-hoc ini, bertujuan untuk pindah ke dunia di mana Anda memiliki hubungan yang lebih dekat dan lebih bermanfaat dengan "penasihat bisnis", dan di mana semua orang berada di halaman yang sama tentang hasil dari perubahan yang mereka diskusikan .

Proses Anda saat ini membuatnya terlalu mudah bagi orang-orang ini untuk hanya bertukar pikiran ide-ide tanpa perlu sumber daya dan uang yang akan dikonsumsi. Jika mereka menginginkan semua fitur ini, mereka perlu mendapatkan "skin in the game".

Ambil email percakapan itu dan masukkan ke dalam semacam aplikasi pelacakan fitur / bug meskipun itu hanya spreadsheet. Kirim tambahan baru kembali ke penasihat bisnis dan minta dia untuk menandatangani pada setiap item atau memberikan koreksi. Seiring dengan sign-off, mereka harus memprioritaskan (Yang mana yang Anda inginkan dulu?).

Setelah mereka menyetujui, kirim kembali jadwal Anda pada saat barang akan selesai untuk pengujian dan minta mereka untuk berkomitmen pada waktu untuk melakukan pengujian / persetujuan untuk penyelesaian.

Saya tahu membuat jenis dokumentasi ini bukan mengapa Anda menjadi seorang programmer, tetapi Anda bisa mengambil risiko membuang daftar-daftar ini atau terus membuang kode yang diperoleh dengan susah payah.

Menekan. Mereka yang bertanggung jawab perlu melihat berapa biaya permintaan ini.

Perubahan persyaratan tidak selalu buruk. Kuncinya adalah mengingat pelanggan Anda. Kemungkinan bos Anda adalah pelanggan Anda dalam hal ini. Anda perlu memberi tahu atasan Anda bahwa Anda menganggap perubahan persyaratan konstan ini membatasi kemampuan Anda untuk menghasilkan produk yang paling berguna baginya. Sangat mungkin bahwa bisnis mendapat manfaat dari Anda yang terus bereaksi terhadap perubahan. Jika demikian, itu adalah model bisnis mereka, dan Anda tidak melakukan kesalahan apa pun, meskipun saya sarankan berlari ke bukit dalam kasus itu!

Orang-orang yang frustrasi dengan perubahan kebutuhan sering dinilai dengan seberapa baik mereka mengelola setiap perubahan. Metrik "jumlah perubahan yang ditangani secara memadai" ini mungkin merupakan sumber masalah Anda yang sebenarnya. Pertimbangkan untuk mendiskusikan metrik yang lebih baik dengan atasan Anda. Ketika saya menghadapi persyaratan yang terus berubah, saya berusaha untuk menulis konten yang memungkinkan saya beradaptasi dengan persyaratan yang terus berubah. Alih-alih menjalankan simulasi dan menganalisis data setiap hari, saya akan menulis alat yang membuat proses menjalankan simulasi dan menganalisis data lebih murah, dan menuai hasilnya seiring waktu. Jika itu masih terlalu gila, saya bahkan mungkin menulis alat untuk menulis alat!

Proses Anda mungkin mendapat manfaat dari beberapa prinsip gesit, seperti terkunci di iterasi. Saya pikir seminggu masuk akal dengan perubahan cepat seperti yang Anda gambarkan. 2 minggu mungkin akan bekerja lebih baik pada akhirnya.

Setelah persyaratan yang cukup penting telah diidentifikasi, suruh orang yang Project Ownerberperan menandatangani dan menguncinya selama satu minggu sementara Anda membangunnya. Alokasikan pekerjaan yang cukup untuk diri Anda sendiri ke tempat Anda akan sibuk dan beri tahu kekuatan untuk mengetahui alokasi Anda. yaitu jika per minggu Anda dapat menghasilkan pekerjaan 16 poin, dan Anda memiliki 16 poin pekerjaan, maka Anda sepenuhnya digunakan untuk minggu itu. (Konsep poin berasal dari aliran kerja gesit)

Jika ada perubahan di pertengahan minggu, ucapkan kata-kata ajaib ini:

Saya dapat melakukan [fitur baru ini], [perubahan baru ini], [dll], tetapi apa yang tidak ingin Anda lakukan ?

Artinya, Anda adalah sumber daya yang terbatas, Anda hanya dapat menerima begitu banyak pekerjaan. Jika item pekerjaan baru masuk, Anda diizinkan menjadi sumber daya terbatas seperti Anda dan memberikan poin ke item baru dan menjatuhkan / mengubah item lain sebagai pengganti perubahan masuk baru ini. Prioritaskan kembali daftar iterasi Anda bersama dengan pemilik proyek dan Anda harus lebih baik dalam menghadapi perubahan.

Jika persyaratan berubah lebih sering dari itu, Anda mungkin perlu menegosiasikan stabilitas di lingkungan Anda.

Ungkapan "Perubahan persyaratan" terkadang disalahgunakan oleh orang-orang IT. Apa yang Anda uraikan memang perubahan persyaratan tetapi ini mungkin karena satu atau lebih dari yang berikut (Saya tidak cukup tahu tentang kasus Anda, jadi yang berikut mungkin atau mungkin tidak berlaku):

1. Ambisi manajemen untuk membuat pengguna akhir bahagia secepat mungkin dan menunjukkan kemajuan cepat.

2. Kurangnya analisis terperinci. Ingat bahwa Analis perlu mengajukan pertanyaan tentang mengapa tidak hanya apa. Analis perlu "berpikir" dengan pengguna akhir tentang "solusi" tidak hanya menerima pesanan.

3. Kurangnya proses formal untuk verifikasi dan konfirmasi persyaratan, diikuti oleh persetujuan.

4. Meminta orang yang salah untuk melakukan satu atau lebih peran yang belum tentu dilatih untuk mereka seperti Analis Bisnis atau Analis Sistem.

5. Pembuatan prototipe terbatas.

6. Anggapan / ketakutan bahwa itu harus dilakukan dengan cepat dan kalau bukan IT yang harus disalahkan.

Kecuali satu alamat semua di atas dengan benar, hubungan antara TI dan pengguna bisnis / akhir akan stres. Harap dicatat bahwa ini tidak menyiratkan bahwa poin di atas konklusif. Ada faktor-faktor lain yang mengarah pada situasi stres yang serupa dengan situasi Anda, tetapi saya pikir daftar ini harus membuat Anda maju.

Saya pikir Anda harus mendekati ini dari beberapa arah:

1. Mintalah semua pemegang pasak (termasuk seluruh tim pengembangan) bertemu (offline / online) dengan penasihat bisnis dan mencoba memahami domain, visi, dan kemudian bertukar pikiran tentang persyaratan bersama.

2. Formalisasi persyaratan / cerita pengguna, dengan penilaian masing-masing:
   a. Prioritas (urgensi / penting)
   b. Kedewasaan (seberapa didefinisikan dengan baik - dipahami dan disepakati oleh mayoritas pemegang saham *)
   c. Kompleksitas (perkiraan kasar)
   
   Saat memilih kebutuhan / penyimpanan pengguna mana yang akan digunakan berikutnya, memperhitungkan ketiga faktor tersebut. Jika persyaratan memiliki kematangan yang rendah, tambahkan misi penelitian sebelum itu, di mana Anda menghubungi semua pemegang saham, selidiki alasan di balik persyaratan tersebut dan tentukan lebih baik persyaratan tersebut (tulis kasing dan / atau buat kerangka kawat dan presentasikan) sebelum bertindak di atasnya.

3. Cobalah untuk memikirkan beberapa langkah ke depan sambil merancang sebelum setiap implementasi - desain arsitektur yang fleksibel yang memiliki ruang untuk mengakomodasi perubahan.

4. Cobalah untuk mengadaptasi proses pengembangan tangkas misalnya SCRUM atau Kanban - ini akan memberi Anda alat untuk mengembangkan produk dengan persyaratan yang berubah.

Anda juga harus mempertimbangkan meminta moderator untuk memindahkan pertanyaan ini ke PM.stackexchange.com (dengan menandai itu) karena meskipun pertanyaan ini cocok di sini, itu akan lebih cocok di sana.

(*) Pemegang pasak untuk persetujuan: bisnis, pemasaran, manajemen proyek, pengembangan dan QA.