Bagaimana meyakinkan klien non-teknis bahwa spesifikasi aplikasi mereka perlu disederhanakan?

Sering kali saya dihadapkan dengan situasi di mana klien baru datang kepada saya dengan aplikasi yang memiliki 100-an fitur yang tidak perlu dan cukup jelas bahwa hal-hal perlu disederhanakan secara drastis agar proyek memiliki peluang untuk berhasil. Bagaimana Anda meyakinkan klien untuk mengambil pendekatan Minimum Viable Product (MVP) dan menyederhanakan?

edit:

Jadi jawaban teratas saat ini adalah untuk memberikan perkiraan waktu / biaya kepada klien untuk aplikasi besar. Saya tidak terlalu menyukai jawaban ini karena tidak membahas masalah sebenarnya dengan situasi ini. Dan itu - ini adalah praktik yang buruk untuk menentukan aplikasi besar dan kemudian mencoba dan membangunnya sejak awal. Awalnya saya merasa jauh lebih nyaman membangun fondasi MVP yang kecil dan sederhana. Dan kemudian menambahkan fitur kecil ke fondasi itu satu per satu. Jadi, bagaimana saya meyakinkan klien untuk mendekati membangun perangkat lunak dengan cara ini?

Dengan memperkirakan berapa banyak uang / waktu akan diperlukan untuk melakukan ratusan fitur dengan kualitas tinggi. Sangat, sangat sedikit klien akan menaruh uang mereka di mulut mereka.

Dua kata: Kisah Pengguna.

Saya telah belajar bahwa cara tercepat untuk membantu klien Get A Clue® adalah meminta mereka membacakan cerita pengguna untuk setiap fitur atau halaman yang mereka inginkan. Beberapa hal terjadi, termasuk:

1. Mereka harus berpikir tentang apa yang sebenarnya harus dilakukan oleh halaman / fitur tersebut.
2. Ketika Anda meminta lebih banyak dan lebih detail ("dan ​​kemudian? ... dan kemudian? ...") mereka mulai memahami bahwa semuanya tidak akan terjadi dengan meminta Magic Space Monkeys ™ terbang dan melakukan selama akhir pekan.
3. Mereka menjadi mitra sejati dalam proses penciptaan. Yang berarti bahwa mereka akan mengerti mengapa mengubah pikiran mereka tentang sesuatu yang sudah 80% selesai akan menyebabkan a) penundaan jadwal, dan b) kenaikan biaya.

Serius. Kisah Pengguna oleh pemilik adalah salah satu alat terbaik yang saya tahu untuk membawa setidaknya beberapa kewarasan untuk proses tersebut.

Saat membahas aspek biaya dan waktu untuk produksi, mintalah peringkat persyaratan ("harus ada", "harus sudah", dan "baik untuk dimiliki") sehingga serangkaian fitur produk yang layak dan minimum yang penting adalah "must have" dalam versi 1, lalu masukkan sisa persyaratan ke dalam set backlog yang dapat diselesaikan sebagai sprint setelah versi pertama. Semoga yang "esensial untuk memiliki" yang tidak penting akan pergi ke bagian belakang paket dan pada saat Anda mendapatkan sprint yang baru yang lebih penting (dari pengalaman aktual dengan produk) akan melayang ke atas.

Klien harus menghargai bahwa Anda mempertimbangkan biaya bisnis mereka dan pentingnya mendapatkan produk dengan cepat dan Anda tidak secara langsung mengabaikan "kesenangan mereka" dengan menempatkan mereka di tumpukan simpanan.

Sunting untuk menanggapi sunting OP: Untuk meyakinkan klien mengapa sebaiknya melepaskan lebih awal produk yang layak minimum menjelaskan bahwa sampai produk digunakan oleh pengguna nyata, sulit untuk mengetahui apakah itu akan berhasil (terutama dalam hal kegunaan). Jika pelanggan ragu-ragu untuk mengeluarkan produk awal ke seluruh basis pengguna mereka, rekomendasikan untuk melakukan "beta terbatas" di mana ia hanya tersedia untuk subset yang ditargetkan dari pelanggan mereka. Beri tahu mereka sisi lain dari pendekatan ini adalah siklus pengembangan yang panjang dan mahal dengan tekad yang terlambat bahwa produk tersebut tidak dapat digunakan. 37 Sinyal telah menghasilkan beberapa referensi bagus tentang ini: Getting Real and Rework . Getting Real tersedia di web secara gratis.

Penyebab utama frustrasi Anda dengan situasi ini mungkin salah satu persepsi dan istilah yang menyesatkan / salah digunakan oleh pelanggan. Pelanggan biasanya tidak mendatangi Anda dengan daftar persyaratan , tetapi daftar harapan dari setiap hal yang dapat mereka pikirkan yang mungkin berguna bagi mereka. Itu tidak semua persyaratan karena pelanggan belum menghabiskan waktu untuk benar-benar berpikir jika setiap fitur benar-benar diperlukan .

Ini tidak selalu menjadi masalah

Jika pelanggan Anda memiliki uang untuk semua fitur itu dan bersedia untuk berpisah dengannya, dan Anda tidak benar-benar peduli untuk memecahkan masalah aktual dan nyata yang dimiliki pelanggan, maka ini bisa menjadi proyek yang sangat menguntungkan. Itu terjadi, sangat jarang, dan bagi sebagian besar pengembang itu adalah pekerjaan mematikan jiwa karena Anda dapat merasa di muka bahwa proyek pada akhirnya tidak akan berhasil bagi pelanggan (bahkan jika itu secara finansial berhasil bagi Anda sebagai pengembang). Ini juga berisiko tinggi karena Anda mungkin berakhir dengan proyek biaya tetap dengan banyak ketidakpastian, dan itu benar-benar masalah untuk salah menilai risiko pada proyek besar.

Bagaimana jika itu masalah?

Mari kita asumsikan Anda tidak dalam situasi langka itu. Dalam hal ini Anda akan ingin mengatasi dua kekurangan utama dari daftar keinginan seperti yang diberikan:

1. Tidak mungkin pelanggan memiliki gagasan yang benar tentang biaya pengembangan daftar persyaratan yang sedemikian besar, sehingga Anda tidak mungkin mendapatkan kontrak untuk jumlah uang yang sebenarnya Anda perlukan untuk melakukannya.
2. Tidak mungkin daftar keinginan ini secara akurat dan ringkas menggambarkan masalah nyata yang dimiliki dan ingin dipecahkan oleh pelanggan.

Dalam pengalaman saya, Anda perlu mengatasi 2 untuk memperbaiki 1. Mengebor ke masalah sebenarnya berarti bahwa Anda, pengembang, sekarang memiliki input yang diperlukan untuk membuat lompatan kreatif dalam memecahkan masalah dengan cara yang bahkan tidak pernah dipikirkan oleh pelanggan sendiri. Solusi ini cenderung jauh lebih murah dan lebih cepat daripada implementasi daftar keinginan lengkap.

Bagaimana Anda memperbaikinya?
Seperti yang dikatakan Matthew Flynn dalam jawabannya - mulailah dengan membuat pelanggan memprioritaskan persyaratan. Ini tidak selalu mudah, tetapi paksakan mereka untuk melakukannya. Jika perlu gunakan frasa "Jika seseorang memegang pistol di kepala Anda, satu persyaratan apa yang akan Anda simpan?". Anda akan sering menemukan selama proses ini bahwa pelanggan benar-benar tidak memiliki ide yang sangat jelas tentang apa arti persyaratan individu. Dalam hal itu lakukan apa yang disarankan Peter Rowell dan dapatkan pelanggan untuk bekerja melalui Cerita Pengguna. Anda dan pelanggan akan mulai memahami masalah dan persyaratan dengan lebih baik, dan kemudian Anda dapat kembali ke penentuan prioritas. Ulangi langkah-langkah itu sesering yang Anda butuhkan sampai Anda merasa nyaman bahwa Anda cukup tahu untuk menyelesaikan masalah pelanggan .

Bagaimana hal itu menjawab pertanyaan tentang mengembangkan solusi? Setelah Anda memiliki daftar persyaratan yang diprioritaskan, Anda memiliki input yang Anda butuhkan untuk menyarankan proses pengembangan tambahan kepada pelanggan Anda. Anda tidak harus menyebutnya Agile, tetapi Anda dapat menyarankan untuk memecah kontrak menjadi bagian-bagian yang lebih kecil untuk setiap persyaratan (atau serangkaian persyaratan yang tidak dapat dibagi) dan mengirimkannya satu per satu dengan validasi oleh pelanggan. Atau Anda bisa habis-habisan dan menggunakan banyak sumber daya yang tersedia online dan offline untuk meyakinkan pelanggan bahwa demi kepentingan terbaik mereka untuk bekerja sama dalam salah satu gaya pengembangan Agile. Dalam kasus apa pun, Anda dapat memberikan proposal kontrak / proyek Anda dalam bentuk yang dengan jelas menyarankan blok bangunan persyaratan ini dalam urutan prioritas, masing-masing dengan biaya dan kesimpulan sendiri. Pegang wortel itu di depan pelanggan,

Pertama-tama saya akan mencoba menjelaskan kepada mereka bahwa persyaratan mereka tidak realistis, dan memberi mereka seperangkat persyaratan tanggapan. Jelaskan bahwa ini akan menyelesaikan masalah mereka dengan lebih sederhana, dan lebih cepat, sehingga dengan biaya dan risiko lebih sedikit. Jangan mencoba dan menjadikan ini sebagai diskusi teknis, klien tidak peduli tentang itu. Klien peduli tentang mendapatkan produk yang baik pada waktunya, menyelesaikan kasus bisnis mereka. Jika klien tidak mau mengalah, baik menerima kontrak dan melakukan pekerjaan, atau menolak dan menjelaskan klien mengapa Anda tidak dapat mengambil tanggung jawab untuk proyek dalam formulir ini.

Mirip dengan apa yang disarankan orang lain, tetapi sedikit berbeda, saya menyarankan agar segala sesuatu yang pelanggan valid, tetapi mereka harus PRIORITASI. Item mana yang perlu dilakukan terlebih dahulu. Item mana yang perlu dilakukan kedua. Yang terpenting, jika Anda kehabisan waktu, item mana yang paling tidak menyakitkan untuk dimiliki. Prioritaskan setiap item dari 1 hingga 732 (atau apa pun) dan lengkapi dengan urutan itu.

Contoh historis aplikasi yang berakhir melebihi anggaran dan terlambat karena persyaratan yang berlebihan adalah File Kasus Virtual FBI. Itu dimaksudkan untuk menggantikan beberapa lusin aplikasi yang ada, dan mereka semua harus bekerja sepenuhnya, sekaligus, pada peralihan. Proyek itu akhirnya dibatalkan. Apa yang akan berhasil adalah merancang kerangka kerja, dan secara bertahap mengganti aplikasi individual ke dalam sistem baru. Alih-alih, politik dan pertikaian mengarah pada setiap pemangku kepentingan aplikasi yang menyatakan bahwa aplikasi mereka adalah yang paling penting, dan semua orang mempermasalahkan spesifikasi mereka dengan "harus memiliki" dari semua fitur yang ingin mereka tambahkan ke aplikasi yang ada. Pada akhirnya, volume permintaan perubahan yang ditulis setiap hari melebihi jumlah kode yang sebenarnya ditulis setiap hari.

Saya telah melihat "Aku harus memiliki semuanya" bekerja dalam 2 kasus. Dalam satu, klien keuangan besar (menggunakan air terjun dari semua hal), memiliki 40 sistem yang berbeda (perusahaan kami membuat salah satu dari 40) diganti dan dioperasikan dalam satu gerakan. Pengujian integrasi dan komunikasi adalah masalah besar. Perkiraan saya adalah bahwa mereka membakar sekitar $ 100rb / hari dalam panggilan konferensi (ketika Anda menghitung tingkat penagihan semua orang pada panggilan). Dalam kedua kasus itu, perlu negosiator yang kuat untuk menuntaskan daftar apa yang akan disampaikan dan kemudian memakukan kaki semua orang ke tanah. Tidak ada pergerakan tiang gawang, tidak ada negosiasi ulang. Kedua pekerjaan berakhir tepat waktu, dan sesuai spesifikasi. Yang satu jauh melebihi anggaran, yang lain sesuai anggaran. Untuk ini, Anda memerlukan manajer proyek yang sangat baik yang tahu apa yang dapat disampaikan oleh tim mereka (jenis yang dapat mengatakan bahwa fitur Q membutuhkan waktu 3.

Karena tidak memiliki PM yang hebat, negosiator dan metrik, saya akan menyarankan mendorong klien ke arah pengiriman tambahan. Jika mereka masih menginginkan seluruh batu bata emas sekaligus, mereka mungkin lebih baik dilayani dengan membantu mereka menemukan beberapa konsultasi lainnya. Terkadang jawaban terbaik adalah "kami tidak dapat membantu Anda."

Jawaban Singkat: Saya akan mendengarkan pelanggan saya dan menemukan pendekatan jalan tengah dengan mereka.

Saya akan menyarankan untuk mendengarkan pelanggan dan tergantung pada anggaran dan waktu mereka, membagi proyek menjadi beberapa fase (rilis, rilis2, dll.).

Kemudian Anda dapat melanjutkan estimasi setiap tahap pengiriman, anggaran, dan penentuan prioritas fitur yang harus disediakan aplikasi.

Dengan demikian, mendefinisikan ruang lingkup pekerjaan dan hasil adalah cara untuk pergi :)

Seperti yang dinyatakan oleh jawaban lain, penentuan prioritas sangat penting. Cara praktis untuk melakukan ini adalah melalui metode MoSCoW . Tetapi Anda mungkin ingin memulai dengan membagi seluruh daftar, jika tidak, daftar fitur itu sendiri akan memberi Anda (atau pelanggan Anda) masalah pemahaman :)

Di samping ini, Anda memiliki masalah dalam memandang masalah secara keseluruhan. Anda mungkin dapat menyelesaikan ini dengan duduk bersama pelanggan Anda dan melalui langkah-langkah berikut:

• Pergi secara global melalui fitur-fitur dan saring kategori dari mereka
• Prioritaskan (menggunakan MoSCoW) kategori, dan mungkin mendefinisikan hierarki (satu kategori dasar dengan fitur default, kategori untuk mata pelajaran utama, kategori untuk variasi spesifik mata pelajaran utama). Ini mungkin mengubah kategori yang Anda tentukan di langkah sebelumnya (terima kasih atas wawasan baru).
• Telusuri setiap fitur satu per satu, dan tetapkan ke suatu kategori
• Prioritaskan (menggunakan MoSCoW) item dalam kategori top-x.

Ini akan memberikan tampilan top-down yang bagus dan padat dari fitur yang Anda minta, dan akan memberi Anda setang untuk menentukan iterasi yang berbeda untuk memulai dengan basis dan memperluasnya dengan fitur lain.