Bagaimana cara menjual Agile development kepada klien (air terjun)

Toko pengembangan kami benar-benar ingin melakukan proyek yang lebih gesit tetapi kami memiliki masalah dalam mendapatkan klien. Banyak klien menginginkan anggaran dan tenggat waktu. Sulit untuk menjual klien pada proyek gesit ketika pesaing kami datang dengan tenggat waktu tetap dan harga tetap berdasarkan air terjun. Kami tahu nomor tetapnya buruk, tetapi klien tidak tahu itu. Jadi, kami akhirnya terlihat buruk bagi klien karena kami tidak dapat menetapkan harga atau tenggat waktu tetapi pesaing kami bisa.

Jadi, bagaimana Anda bisa membuat tenaga penjualan Anda berhasil menjual proyek yang menggunakan metode pengembangan tangkas, atau produk yang dikembangkan menggunakan metode seperti itu? Semua informasi yang saya temukan tampaknya berfokus pada manajemen proyek dan pengembang.

Kunci untuk melakukan ini dengan baik adalah dengan menggunakan kontrak dukungan.

Pada dasarnya, ketika Anda pertama kali menjual klien, Anda menjualnya berdasarkan keahlian Anda, dan Anda melakukannya air terjun. Itu berarti kontrak yang menetapkan ruang lingkup dan tenggat waktu perusahaan. Inilah yang diinginkan klien. Klien kurang lebih mengetahui ruang lingkup. Air terjun bekerja sangat baik, dalam lingkungan lingkup tetap & terdefinisi, saya akan mengatakan itu bekerja lebih baik daripada gesit dalam lingkungan seperti itu. Dan dalam hal ini memberikan klien tingkat kenyamanan ketika kecenderungannya menjadi gugup karena dia belum pernah bekerja dengan Anda sebelumnya. Tidak apa-apa, Agile tidak selalu lebih baik dari air terjun.

Jadi, Anda memiliki kontrak harga tetap untuk lingkup X. Kemudian Anda memberi tahu klien, “ Lihat, Anda akan ingin melakukan perubahan, dan Anda akan membutuhkan kami untuk mendukung Anda pasca produksi, mari sisihkan 20% dari anggaran Anda untuk hal-hal ini untuk digunakan sesuai kebutuhan oleh sarana kontrak dukungan . "

Jika ada perubahan yang muncul selama proyek, cukup tunda untuk ditangani di bawah kontak dukungan. (Dengan asumsi perubahan ini akan menyebabkan gangguan serius pada proyek)

Ketentuan kontak dukungan adalah sebagai berikut: " Pekerjaan yang harus dilakukan berdasarkan per jam, seperti yang diminta oleh klien, dapat digunakan untuk permintaan perubahan atau dukungan dan pemeliharaan sistem umum ." BAM! Anda berada di Agile.

Anda kemudian dapat terus memperluas kontak dukungan, dan cukup menggunakan kontak dukungan sebagai sarana untuk menjalankan proyek baru. Selain itu jika jam ini dibeli dan dibayar di muka , kami biasanya memberikan diskon 15% kepada klien. Ini Menang-Menang.

Agile tidak menghalangi tenggat waktu dan anggaran. Jika saya seorang klien dan saya pergi ke pengembang dan mereka mengatakan kepada saya bahwa mereka tidak bisa memberi saya tenggat waktu atau perkiraan biaya, saya akan mempertanyakan kewarasan mereka. Dan memberi tahu mereka bahwa mereka hanya tidak mengerti tidak akan berhasil: mereka harus mampu membuat anggaran dan merencanakan.

Mereka tidak perlu tahu proses pengembangan Anda. Mereka perlu tahu berapa lama untuk mengembangkan fitur dan berapa biayanya. Beri mereka nomor berdasarkan asumsi (palsu) bahwa persyaratan mereka 100% akurat, dan ketika persyaratan mereka berubah, maka ubah perkiraan Anda.

Ini memberi mereka item baris anggaran dan tanggal penerapan yang mereka inginkan, dan ketika ada perubahan, proses Anda membuat Anda terlihat fleksibel dan akomodatif.

Sepertinya tenaga penjualan Anda menciptakan lapisan miskomunikasi antara tim pengembangan Anda dan pelanggan. Jika mereka belum pernah berjualan di pasar TI untuk waktu yang lama, mereka mungkin memandang peran mereka sebagai 'memindahkan produk', yang berarti mendapatkan tanda tangan pada kontrak 'apa pun yang diperlukan'. Singkatnya, mereka termotivasi untuk menutup, terlepas dari apa yang mereka janjikan. Dalam keadaan seperti itu mereka akan melacak bahasa pelanggan sedekat mungkin.

Saya catatan yang rusak mengutip ini, tetapi begini: Anda berada di meja operasi dan saat Anda berada di bawah ahli bedah mengatakan 'kami akan membuat Anda keluar dari sini tepat waktu dan sesuai anggaran'. Bagus. Apakah saya akan hidup?

Jika Anda bekerja pada organ internal bisnis, apakah Anda berhenti pada titik arbitrer? Biasanya suatu aplikasi dipengaruhi oleh kekuatan baik Anda maupun kontrol klien Anda - peraturan, iklim usaha, perilaku pesaing, munculnya beberapa paradigma baru, dll. Jika Anda hanya mengatakan 'kami akan melakukan' barang x 'untuk' harga y '' maka pelanggan akan kembali tiga bulan kemudian dan berkata - 'baik ...'. Secara umum berarti mereka tahu sesuatu yang tidak mereka ketahui ketika Anda menyetujui proyek air terjun.

Apa yang mungkin berhasil dalam situasi seperti itu adalah menunjukkan kepada staf penjualan Anda sendiri seperti apa perjalanan melalui ngarai. Di setiap belokan ada kejutan. Tidak mungkin melihat lebih dari tiga bulan, jadi jika pelanggan meminta proyek 18 bulan, itu tidak akan dapat dikenali pada saat Anda hampir selesai. Oleh karena itu tenaga penjualan Anda perlu memulai dengan mencari hasil keuangan proyek. Apakah ini akan meningkatkan penjualan sebesar $ 10 juta? Jika demikian, apakah bernilai menginvestasikan $ 2.000.000 untuk menghasilkan tambahan $ 10 juta itu? Jika pelanggan dan tenaga penjualan menyatu dengan komitmen $ 500.000, maka sesuatu mungkin salah dan tidak ada yang tahu apa itu - itu hanya rasanya tidak benar. Apa yang 'tidak terasa benar' adalah komitmen untuk melakukan sesuatu yang berisiko tidak berguna.

Dua model pesawat jet terbaru telah memiliki sejarah snafus. Healthcare.gov bahkan tidak perlu diskusi. Jika Anda dapat menemukan buku atau berita perdagangan pers di pesawat, Anda dapat mengemukakan bagaimana asumsi tertentu dibuat yang terbukti optimis, dan bahwa proyek-proyek melewatkan tenggat waktu mereka berulang kali. Seringkali ini karena meremehkan kompleksitas. Jika Anda tidak dapat benar-benar mengetahui seberapa kompleksnya sampai Anda mulai mengkodekannya, Anda akan memerlukan 'babak awal' untuk mendapatkan ide yang lebih baik tentang masalah yang sebenarnya. Pemotongan anggaran haruslah sebagian kecil dari total keuntungan tambahan (atau pendapatan dalam beberapa kasus), dan angka itu harus lebih dari yang diperkirakan oleh siapa pun yang akan menanggung biaya proyek saat ini. Jika Anda dapat menunjukkan bagaimana tonggak terakhir dapat dilewati tanpa melebihi 'batas hasil',

Rintangan utama dalam mencapai manfaat pengembangan perangkat lunak Agile-Scrum di luar adalah mengintegrasikannya dengan mekanisme kontrol yang ada. Mekanisme kontrol ini ditetapkan karena berbagai prasyarat organisasi dan biasanya diaktualisasikan dengan menggunakan pendekatan dan metodologi Linear Waterfall.

Empat prasyarat organisasi khas ini digambarkan di bawah ini:

• Korporasi global besar - dalam organisasi matriks hirarkis ini, kontrol portofolio top-down adalah aturan hari ini. Pendekatan gesit berjiwa bebas memiliki waktu yang sulit menyesuaikan diri dengan kontrol yang ketat. Khususnya konsep Agile bebas rencana yang melekat, membuat Agile-Scrum sulit untuk ditelan organisasi.

• Industri yang sangat diatur - beberapa industri diminta oleh badan kepatuhan dan tata kelola untuk memiliki mekanisme kontrol yang mengikat yang ketat. Ini dapat berupa misalnya peralatan medis, pesawat terbang, dan unit-unit bisnis penelitian dan pengembangan produk farmasi. Sementara masing-masing tim dapat mengoperasikan Agile-Scrum, proses pengembangan harus mengikuti metode pendekatan Linear Waterfall yang kaku untuk penelusuran dan tata kelola.

• Produk standar yang ditetapkan sebelumnya - beberapa produk terintegrasi yang meliputi perangkat keras, perangkat lunak, tertanam dan banyak lagi dikembangkan sebagai kontrak dengan pelanggan akhir di bawah seperangkat persyaratan yang telah ditentukan sebelumnya. Dalam kasus ini tingkat fleksibilitas persyaratan kecil, meskipun lebih besar dari apa yang diantisipasi pada awalnya. Konsep simpanan Agile-Scrum yang sepenuhnya fleksibel sangat menderita dalam kasus-kasus ini.

• Departemen TI umum - sebagian besar kegiatan harian dan mingguan di departemen TI yang didorong oleh pemeliharaan bersifat ad hoc. Perubahan jadwal harian sangat banyak dan langsung. Interferensi konstan dalam kerja tim adalah norma. Konsep tinju waktu dan tidak ada gangguan sulit dipertahankan dalam situasi ini.

Secara alami - berkali-kali empat kategori diskrit yang dirinci di atas, sebenarnya bercampur; jadi itu umum untuk menemukan produk yang kompleks di perusahaan besar global yang diperlukan untuk mematuhi peraturan perusahaan.

Berdasarkan pengalaman praktis, metode yang direkomendasikan untuk mengatasi skenario ini dan lainnya adalah dengan memberdayakan PMO Agile untuk bertindak sebagai enabler, pengemudi dan penerjemah antara tim Agile-Scrum yang baru muncul dan elemen Air Terjun Linear.

Lihat tabel di bawah ini untuk pedoman khusus

Sumber - Antarmuka antara Air Terjun Linear dan Pendekatan Agile oleh Michael Nir

Kami menyiapkan 2 atau 3 sesi estimasi dengan pelanggan potensial dan pengembang kami tempat kami membahas pekerjaan yang dihadapi dan menetapkan kriteria penerimaan. Pengembang memperkirakan pekerjaan dalam poin cerita selama pertemuan.

Setelah itu kami menjual pelanggan sejumlah poin cerita. Ini dimungkinkan karena ia memiliki ide bagus tentang nilai poin cerita. Kami memberi tahu dia bahwa dia memiliki kemungkinan untuk memperbaiki simpanan / cakupannya selama proyek dan bahwa itu akan mudah karena penggunaan poin cerita. Kami juga memberi tahu dia bahwa akan sering ada pengiriman perangkat lunak yang berfungsi sehingga dia dapat memantau kemajuan dan mendapatkan wawasan baru.

Dengan menyetujui sejumlah poin cerita, pelanggan dijamin mendapatkan nilai untuk uangnya. Jika dia tidak mengubah jaminannya, dia memiliki proyek harga tetap / ruang lingkup tetap, tetapi pengalaman saya adalah bahwa dia akan membuat perubahan. Dengan melakukan estimasi di hadapan pelanggan potensial, kami mencoba membangun hubungan berdasarkan keterbukaan dan kepercayaan.

Kami berhasil meyakinkan klien seperti yang Anda jelaskan, yang "menginginkan anggaran dan tenggat waktu", dan mereka senang kami ingin benar-benar memahami apa yang mereka butuhkan, alih-alih bekerja dari dokumen. Kami menunjukkan bahwa kami ingin berinvestasi dalam proyek-proyek ini.

Selama sesi estimasi, kami memperkirakan seluruh simpanan mereka. Ini memberi x poin cerita. Kami menyarankan untuk menambahkan 25% untuk fitur-fitur yang belum jelas atau diketahui saat itu. Dengan perkiraan simpanan yang terlampir pada kontrak, mereka diyakinkan bahwa mereka akan mendapatkan segalanya untuk anggaran tetap.

Awalnya tawaran itu waktu dan materi. Karena mereka ingin memiliki tawaran harga tetap, kami menyarankan untuk bekerja untuk harga yang kami berikan kepada mereka dan menggunakan poin cerita tambahan 25% untuk kemungkinan. Jika semuanya berjalan dengan baik, bagian dari 25% yang tidak digunakan untuk menutupi penundaan yang kami temui akan digunakan untuk memberikan lebih banyak fungsi bagi pelanggan.

Ini merangsang mereka dalam beberapa cara: pertama, mereka melakukan segala yang mereka bisa untuk memungkinkan pengembang kami bekerja secepat mungkin, karena ini jelas untuk kepentingan mereka sendiri. Kami tidak pernah harus menunggu jawaban atas pertanyaan. Kedua, mereka benar-benar memahami konsep poin cerita. Sebelum proyek dimulai, mereka sudah menghapus beberapa cerita dan meminta kami untuk memperkirakan cerita lain. Tidak diperlukan negosiasi kontrak yang rumit untuk ini.

Kami terus memberi tahu mereka tentang kemajuan dan menjaga komunikasi yang sangat terbuka. Mereka mendapat laporan kemajuan setiap 2 minggu: x% dari poin cerita yang dilakukan dalam y% dari perkiraan waktu menyisakan z% dari poin cerita tambahan yang tersedia. Kami memiliki sedikit permulaan yang sulit tetapi berhasil mengejar perkiraan pada akhir proyek, yang menyisakan 100% dari poin cerita tambahan yang tersedia untuk pengembangan tambahan. Pelanggan senang karena dia mendapatkan semua yang dia butuhkan (dan itu sedikit berbeda dari fitur yang awalnya diminta, dia menghapus beberapa dan menambahkan yang lain).

Pelanggan juga senang karena semuanya disampaikan dalam jangka waktu yang telah ditentukan sebelumnya (di mana ia juga melakukan segala yang mungkin untuk membantu kami seperti mengejar tiket, menjawab pertanyaan dengan segera, melibatkan pengguna dalam pertemuan analisis mingguan dan juga melibatkan mereka dalam pengujian fungsional).

Perusahaan saya senang karena kami mengirimkan tepat waktu dan sesuai anggaran. Perusahaan saya juga senang karena keberhasilan proyek ini membuka pintu untuk lebih banyak proyek. Kami bahkan disebutkan di majalah bulanan pelanggan yang dikirim ke orang-orang di seluruh dunia.

Melakukan estimasi yang baik adalah bagian paling sulit dari proyek, tetapi memiliki sesi estimasi di muka membantu kami untuk memahami kesulitan dan risikonya. Ini memungkinkan kami untuk memberikan perkiraan berdasarkan fakta dan menghapus banyak hal yang tidak diketahui.

Mencoba menggunakan metode Agile dalam lingkungan konsultasi / penawaran sangat sulit ketika pelanggan tidak berada di pesawat.

Jika mereka terbiasa dengan gaya Air Terjun "di sini adalah persyaratan kami, berapa banyak dan berapa lama waktu yang dibutuhkan?" ketik proyek, dan mengajukan tender, tidak ada waktu untuk meyakinkan mereka bahwa Agile atau cara lain lebih baik.

Agile memiliki kelebihan (dan kerugian tentu saja), tetapi terus terang pelanggan sering tidak tahu atau peduli dengan detail di balik layar.

Mereka menginginkan 2 hal - skala biaya dan waktu. Dan begitu Anda memberi tahu mereka, mereka kemudian menginginkannya lebih murah dan lebih cepat. Dan Anda tahu, kami menginginkan semuanya. Semua persyaratan. Tidak ada yang bisa menunggu, atau dicincang.

Dan sama seperti saya tidak suka orang-orang penjualan di sebagian besar lapisan masyarakat, jangan terlalu keras pada orang-orang penjualan. Itu pekerjaan yang sulit.

Mereka tidak membangun perangkat lunak, mereka kebanyakan tidak tahu bagaimana semuanya bekerja melewati kata-kata buzz.

Namun mereka harus datang dengan skala waktu dan biaya berdasarkan pada beberapa pertemuan persyaratan wol. Mungkin mereka memiliki beberapa orang teknologi untuk memerintah mereka, tetapi mereka perlu melakukan penjualan untuk menjaga keadaan.

Jadi, bagaimana Anda bisa membuat tenaga penjualan Anda berhasil menjual proyek yang menggunakan metode pengembangan tangkas, atau produk yang dikembangkan menggunakan metode seperti itu?

Dengan meminta tenaga penjualan Anda membawa pelanggan ke kantor. Seluruh titik lincah adalah untuk mendapatkan umpan balik langsung dari klien sehingga Anda dapat menghasilkan apa yang mereka inginkan (dan tidak lebih). Bawa mereka, tanyakan apa yang mereka inginkan. Dua minggu kemudian, bawa dan tunjukkan demo / prototipe. Jual mereka di interaksi itu. Tunjukkan pada mereka kemajuan dan jelaskan bahwa jenis iterasi ini adalah apa yang ingin Anda lakukan sehingga mereka mendapatkan apa yang mereka inginkan.

Berikan perkiraan untuk jumlah pekerjaan yang diperlukan (setelah itu anggaran), tetapi biarkan mereka memiliki kekuatan (baca: tanggung jawab) untuk memasukkan apa yang ingin mereka masukkan ke dalam anggaran mereka .

Saya pikir jawabannya adalah bahwa untuk sebagian besar kasus Anda mungkin tidak mau. Saya akan mencoba dan melihat ini pada awalnya sebagai bagian kecil dari bisnis Anda - mungkin 20%, dengan sisanya di bawah model tradisional. Seiring waktu saya akan mencoba untuk lebih fokus pada produk dan klien Agile dan mencoba untuk membuat bagian itu tumbuh lebih banyak.

Bagian lain dari mengatasi ini mungkin adalah mencoba dan menggunakan kedua pendekatan tersebut. Gunakan pendekatan air terjun dengan manajemen senior dan orang-orang negosiasi kontrak. Misalnya 'sistem untuk memungkinkan klien mempertahankan portofolio dan membuat keputusan investasi menggunakan perangkat berbasis browser dan ponsel (Apple dan Android).' atau semacam itu. Kemudian gunakan Agile untuk pengembangan tim pengembangan pada fitur yang lebih terperinci, misalnya, Buat Halaman Beranda, Buat Halaman Masuk, Buat Sejarah Manajemen Portolio, Buat Masuk Ponsel, dll.

Gagasan lain adalah menjadikan Agile pembeda Anda. Saya tahu bahwa banyak jika tidak kebanyakan organisasi besar tidak melakukan Agile. Namun sebagian besar (sebagian besar dalam pengalaman saya) dari perusahaan kecil. Saya pikir Agile tumbuh dengan cepat dan ini akan berlanjut. Keuntungan dari rute ini adalah bahwa Anda menyampaikan apa yang paling ingin Anda lakukan kepada pelanggan yang sudah mengenalnya. Pendekatan ini akan membutuhkan beberapa pekerjaan dari waktu ke waktu tanpa jaminan kesuksesan.

Anda mungkin juga menemukan beberapa daya tarik jika klien Anda menyukai pengujian. Memiliki produk yang telah teruji dengan baik dapat menjadi penjualan yang lebih mudah bagi beberapa klien. Sebuah buku yang menurut saya sangat membantu di bidang ini adalah 'Agile Testing' oleh Adison Wesley Press.

Anda juga dapat menggunakan acara terkini untuk mendukung kasus Anda. Misalnya, saat ini (menulis ini pada Oktober 2012) situs perawatan kesehatan merupakan kasus besar untuk bagaimana TIDAK menangani perubahan yang diperlukan 2 minggu sebelum ditayangkan. Selain itu, rekayasa berlebihan tampaknya akan lebih baik ditangani dengan metode yang lebih gesit.

Hubungi klien sebelumnya yang senang dengan pekerjaan Anda. Terutama jika mereka adalah orang yang terjun ke Agile. Paling tidak, mualaf yang bukan klien Anda.

Kesaksian mereka (sebagai pelanggan) akan melebihi apa pun dan semua yang Anda bisa katakan. Mereka dapat mengatasi kekhawatiran dan ketakutan pelanggan baru Anda lebih dari yang Anda bisa.

Dari perspektif manajemen, anggaran dan tenggat waktu adalah kebutuhan bisnis untuk proyek tersebut. Anda perlu memastikan bahwa Anda memenuhi kebutuhan itu, dan jika Anda melihat kesaksian bisnis tentang beralih, Anda akan melihat yang muncul secara langsung. Jika Anda melihat testimonial pengembang tentang beralih, Anda akan melihat bahwa sering kali tidak.