Çevik gelişimi (şelale) müşterilere nasıl satarız?

Geliştirme dükkanımız gerçekten daha çevik projeler yapmak istiyor ancak müşterileri uçağa alma konusunda sorun yaşıyoruz. Birçok müşteri bütçe ve son tarih ister. Rakiplerimiz şelale temelli sabit tarihler ve sabit fiyatlar ile geldiğinde, çevik bir projede müşteriyi satmak zor. Sabit numaralarının kötü olduğunu biliyoruz, ancak müşteri bunu bilmiyor. Böylece, müşteriye kötü bakıyoruz çünkü fiyat veya son teslim tarihini belirleyemiyoruz, ancak rakiplerimiz bunu yapabilir.

Peki, satış gücünüzün çevik geliştirme yöntemleri kullanan bir projeyi veya bu yöntemler kullanılarak geliştirilen bir ürünü başarılı bir şekilde satmasını nasıl sağlayabilirsiniz? Bulduğum tüm bilgiler proje yönetimi ve geliştiricilere odaklanmış gibi görünüyor.

Bunu iyi yapmanın anahtarı, bir destek sözleşmesi kullanmaktır.

Temel olarak, müşteriyi ilk sattığınızda, onları uzmanlığınıza göre satarsınız ve bunu şelale yaparsınız. Bu, kapsamı ve kesin bir kesinti belirleyen bir sözleşme anlamına gelir. Müşterinin istediği bu. Müşteri az ya da çok kapsamı bilir. Şelale çok iyi çalışır, sabit ve tanımlanmış bir ortamda bu tür ortamlarda çeviklikten daha iyi çalıştığını söyleyebilirim . Ve bu durumda müşteriye eğilimin gergin olduğu durumlarda rahatlık verir çünkü daha önce hiç sizinle çalışmadı. Sorun değil, Çevik her zaman şelaleden daha iyi değildir.

Yani X kapsamı için sabit bir fiyat sözleşmeniz var. Sonra müşteriye “ Bak, değişiklik yapmak isteyeceksin ve üretim sonrası desteklememize ihtiyacımız olacak, bu gibi şeylerin ihtiyaç bazında kullanılması için bütçenin% 20'sini bir kenara bırakalım. bir destek sözleşmesi anlamına gelir . ”

Proje sırasında bir değişiklik meydana gelirse, destek teması altında ele alınmasını bekleyin. (Bu değişikliğin projede ciddi bir aksamaya neden olacağını varsaymak)

Destek temasının şartları şöyledir: “ Müşteri tarafından talep edildiği şekilde saat başı yapılacak iş, değişim taleplerinde veya genel sistem destek ve bakımında kullanılabilir .” BAM! Çeviksiniz.

Ardından, destek iletişimini genişletmeye devam edebilir ve destek iletişimini yeni projeler yürütmek için bir araç olarak kullanabilirsiniz. Ek olarak, bu saatler önceden alınıp ödenmişse , müşteriye genellikle% 15 indirim veririz. Kazan-kazan.

Çevik son tarih ve bütçeleri engellemez. Eğer bir müşteriysem ve bir geliştiriciye gidip bana son teslim tarihi veya tahmini bir maliyet veremediklerini söyledilerse, akıl sağlıklarını sorgulayacağım. Ve onlara sadece anlamadıklarını söylemek işe yaramayacak: bütçe ve planlama yapabilmeleri gerekiyor.

Gelişim sürecinizi bilmeleri gerekmez. Özellikleri geliştirmenin ne kadar süreceğini ve ne kadara mal olacağını bilmeleri gerekir. Gereksinimlerinin% 100 doğru olduğu (sahte) varsayımına dayalı olarak bir sayı verin ve gereksinimleri değiştiğinde tahminlerinizi değiştirin.

Bu onlara istedikleri bütçe satır öğelerini ve dağıtım tarihlerini verir ve işler değiştiğinde işleminiz esnek ve yardımsever görünmenizi sağlar.

Satış görevlileriniz, geliştirme ekipleriniz ve müşterileriniz arasında bir iletişimsizlik katmanı yaratıyor gibi görünüyor. BT pazarında uzun süredir satış yapmamışlarsa, rollerini 'ürünü taşımak' olarak görebilirler, yani 'ne olursa olsun' bir sözleşmeye imza atmak anlamına gelir. Kısacası, vaat ettikleri şey ne olursa olsun, kapanmaya motive oluyorlar. Bu gibi durumlarda, müşterinin dilini mümkün olduğu kadar yakından takip edeceklerdir.

Bunu söyleyen kırık bir kayıştım, ama işte: ameliyat masasındasınız ve cerrahın altına girerken “sizi zamanında ve bütçe dahilinde çıkaracağız” diyor. Harika. Hayatta mı olacağım

Bir işletmenin iç organları üzerinde çalışıyorsanız, keyfi bir noktada durur musunuz? Genelde bir uygulama, ne sizin ne de müşteri kontrollerinizin - düzenlemeler, iş ortamı, rakip davranışları, bazı yeni paradigmaların ortaya çıkması, vb. Güçlerden etkilenir. Müşteri üç ay sonra geri gelecek ve - "peki ..." diyecek. Genel olarak, bir şelale projesini kabul ettiğinizde bilmedikleri bir şeyi bildikleri anlamına gelir.

Böyle bir durumda işe yarayacak olan şey, satış personelinize kanyonda bir sürmenin nasıl bir şey olduğunu göstermektir. Her fırsatta sürprizler var. Yaklaşık üç aydan fazla bir süre görmek mümkün değildir, bu nedenle bir müşteri 18 aylık bir proje istiyorsa, bitmek üzere olduğunuz zaman tanınmaz olacaktır. Bu nedenle satış temsilcinizin, projenin finansal kazancını bularak başlaması gerekiyor. Bu satışları 10 milyon dolar artıracak mı? Öyleyse, 10 milyon dolar daha yapmak için 2.000.000 dolar yatırıma değer mi? Müşteri ve satış temsilcisi 500.000 dolarlık bir taahhüde yaklaşıyorsa, bir şeyler yanlış olabilir ve kimse ne olduğunu söyleyemez - doğru hissetmez. 'Doğru hissetmeyen' şey işe yaramaz olma riskini taşıyan bir şey yapmayı taahhüt eder.

En yeni iki jet uçağı modelinin snafus geçmişi var. Healthcare.gov'un tartışmaya bile ihtiyacı yok. Uçaklarda kitap bulabilir veya ticari basın hikayeleri bulabilirseniz, iyimser olduğu kanıtlanan bazı varsayımların nasıl yapıldığını ve projelerin son teslim tarihlerini tekrar tekrar kaçırdıklarını görebilirsiniz. Genelde bu, hafife alınan karmaşıklığın sonucuydu. Kodlamaya başlayana kadar ne kadar karmaşık olduğunu gerçekten anlayamıyorsanız, gerçek sorunlar hakkında daha iyi bir fikir edinmek için bir 'ilk aşamaya' ihtiyacınız olacaktır. Bütçe kesintisi, toplam ek karların (veya bazı durumlarda gelirlerin) bir kısmı olmalıdır ve bu rakamın mevcut projenin maliyet getireceğini düşündüğünden daha fazla olması gerekir. Son dönüm noktasının 'ödeme limitini' geçmeden nasıl geçilebileceğini gösterebilirseniz,

Agile-Scrum'un yazılım geliştirmenin dışındaki faydalarını elde etmedeki en büyük engel onu mevcut kontrol mekanizmalarıyla bütünleştirmektir. Bu kontrol mekanizmaları çeşitli örgütsel ön koşullar nedeniyle öngörülmüş ve normal olarak Doğrusal Şelale yaklaşımı ve metodolojisi kullanılarak gerçekleştirilmiştir.

Bu tipik organizasyonel önkoşullardan dördü aşağıda gösterilmiştir:

• Büyük küresel şirketler - bu hiyerarşik matris organizasyonlarında, yukarıdan aşağıya portföy kontrolü günün üstünlüğüdür. Özgür ruhlu çevik yaklaşım, titiz kontrollere uyum sağlamak için zor bir zamana sahiptir. Spesifik olarak doğal Çevik plan içermeyen konseptler, çevikliğin kurumasını yutması için Agile-Scrum'u zorlaştırır.

• Yüksek düzeyde düzenlenmiş endüstriler - bazı endüstrilerin uyum ve yönetim organları tarafından katı bir kontrol kontrol mekanizmasına sahip olmaları gerekmektedir. Bunlar örneğin tıbbi ekipman, uçak ve ilaç araştırma ve ürün geliştirme iş birimleri olabilir. Bireysel ekipler Agile-Scrum'u işletebilir olsa da, geliştirme süreci izlenebilirlik ve yönetişim için katı bir Lineer Şelale yaklaşım yöntemini izlemelidir.

• Karmaşık önceden tanımlanmış ürünler - hem donanım, yazılım, gömülü ve daha fazlasını içeren bazı entegre ürünler, önceden tanımlanmış bir gereksinim kümesi altında son bir müşteriyle sözleşme olarak geliştirilmiştir. Bu durumlarda gereksinim esnekliği derecesi, başlangıçta beklenenden daha büyük olsa da, küçüktür. Çevik-Scrum'un tamamen esnek bir biriktirme kavramı bu durumlarda önemli ölçüde acı çekmektedir.

• Genel BT departmanları - bakım odaklı BT departmanlarındaki günlük ve haftalık aktivitelerin çoğu geçicidir. Günlük programlardaki değişiklikler çok sayıda ve hemen yapılır. Takım çalışmasında sürekli müdahaleler normdur. Bu durumlarda zaman boksu ve parazitsizlik kavramını sürdürmek zordur.

Doğal olarak - yukarıda ayrıntılı olarak verilen dört ayrık kategoriyi birçok kez karıştırın; bu nedenle, şirket yönetmeliğine uyması gereken küresel büyük bir şirkette karmaşık bir ürün bulmak yaygındır.

Pratik tecrübeye dayanarak, bu senaryoları ve diğerlerini ele almak için önerilen yöntem, Çevik PYO'nun, ortaya çıkan Çevik Scrum ekipleri ve Doğrusal Şelale elemanları arasında bir destekleyici, sürücü ve tercüman olarak hareket etmesini sağlamaktır.

Özel kurallar için aşağıdaki tabloya bakın

Kaynak - Doğrusal Şelale ve Çevik Yaklaşımlar Arasındaki Arayüzün Michael Nir

Potansiyel müşteri ve geliştiricilerimizle elimizdeki çalışmaları tartıştığımız ve kabul kriterlerini belirlediğimiz 2 veya 3 tahmin seansı düzenledik. Geliştiriciler, toplantı sırasında çalışmayı hikaye noktalarında tahmin ediyor.

Daha sonra müşteriye çok sayıda hikaye puanı satıyoruz. Bu mümkün çünkü hikaye noktalarının değeri hakkında iyi bir fikri var. Proje sırasında biriktirme / kapsamını ince ayarlayabildiğini ve hikaye noktalarının kullanımı nedeniyle kolay olacağını söylüyoruz. Ayrıca, ilerlemenin izlenebilmesi ve yeni bilgiler edinebilmesi için sık sık çalışan bir yazılım dağıtımı olacağını söyleriz.

Birkaç hikaye noktasına katılarak müşteriye parasının karşılığını alması garanti edilir. Görevini değiştirmezse sabit fiyat / sabit kapsam projesine sahiptir, ancak benim deneyimim değişiklik yapacak. Potansiyel müşteri varlığında tahminler yaparak açıklık ve güvene dayalı bir ilişki kurmaya çalışıyoruz.

“Bütçe ve son tarih isteyen” gibi tarif ettiğiniz müşterileri ikna etmeyi başardık ve bir belgeden çalışmak yerine, neye ihtiyaç duyduklarını gerçekten anlamak istediklerine sevindiler. Bu projelere yatırım yapmak istediğimizi gösterdik.

Tahmin seansları sırasında tüm backlog'larını tahmin ettik. Bu x hikayesi puan verdi. O sırada henüz net olmayan veya bilinmeyen özellikler için% 25 eklemeyi önerdik. Sözleşmeye ekli tahmini birikim ile, sabit bütçeyle ilgili her şeyi alabilecekleri konusunda güvence aldı.

Başlangıçta teklif zaman ve malzeme oldu. Sabit bir fiyat teklifi almak istediklerinden, onlara verdiğimiz fiyat için çalışmayı ve beklenmedik durum için% 25 ekstra hikaye puanları kullanmanızı önerdik. İşler iyi giderse, karşılaştığımız gecikmeleri karşılamak için kullanılmayan% 25'lik kısım müşteriye daha fazla işlevsellik sunmak için kullanılacaktır.

Bu, onları çeşitli şekillerde teşvik etti: birincisi, geliştiricilerimizin mümkün olduğu kadar hızlı çalışmasını sağlamak için ellerinden geleni yaptılar, çünkü bu açıkça kendi çıkarlarına. Soruların cevaplarını asla beklemek zorunda kalmadık. İkincisi, hikaye noktaları kavramını gerçekten anladılar. Proje başlamadan önce, bazı hikayeleri çoktan kaldırdılar ve diğer hikayeleri tahmin etmemizi istediler. Bunun için karmaşık bir sözleşme müzakeresi gerekmedi.

Onları gelişmelerden haberdar ettik ve çok açık bir iletişim kurduk. Her 2 haftada bir ilerleme raporu alıyorlar: tahmini sürenin% y'si içinde yapılan hikaye puanlarının% x'i mevcut ilave hikaye puanlarının% z'sini bırakıyor. Biraz zor bir başlangıç ​​yaptık, ancak projenin sonundaki tahminlere yetişmeyi başardık, bu da ekstra gelişim için ilave hikaye puanlarının% 100'ünü bıraktı. Müşteri mutluydu çünkü gerçekten ihtiyaç duyduğu her şeyi elde etti (ve başlangıçta istenen özelliklerinden biraz farklıydı, bazılarını kaldırdı ve diğerlerini ekledi).

Müşteri de mutluydu, çünkü her şey öngörülen zaman diliminde teslim edildi (burada ayrıca bilet satın alma, anında soruları yanıtlama, kullanıcıları haftalık analiz toplantılarına dahil etme ve ayrıca fonksiyonel testlere dahil etme gibi) bize yardımcı olmak için mümkün olan her şeyi yaptı.

Şirketim mutluydu çünkü zamanında ve bütçeyle teslimat yapıyorduk. Şirketim de mutluydu çünkü bu projenin başarısı daha fazla projenin kapısını açtı. Dünyanın dört bir yanındaki insanlara gönderilen müşterinin aylık dergisinde bile bahsetmiştik.

İyi tahminler yapmak projenin en zor kısmıydı, ancak tahminleri önceden yapmak, zorlukları ve riskleri anlamamıza yardımcı oldu. Gerçeklere dayanarak bir tahmin yapmamızı ve bilinmeyenlerin çoğunu kaldırmamızı sağladı.

Çevik yöntemleri bir danışmanlık / teklif ortamında kullanmayı denemek, müşteri gemide olmadığı zaman çok zordur.

Şelale stiline alışkınlarsa "işte şartlarımız, ne kadar ve ne kadar sürecek?" projeler yazın ve ihaleye soktuğunuzda, Çevik veya başka bir yolun daha iyi olduğuna ikna etmek için gerçekten bir zaman yok.

Çevik bir avantaja (ve elbette dezavantajlara sahiptir) sahiptir, ancak açıkçası müşteri genellikle perde arkasındaki ayrıntıları bilmez veya önemsemez.

2 şey istiyorlar - maliyet ve zaman ölçeği. Onlara bir kere söylediğinde, daha ucuz ve daha erken olmasını istiyorlar. Ve biliyor musun, hepsini istiyoruz. Bütün gereksinimler. Hiç kimse bekleyemez veya doğramaz.

Ve satış insanlarını hayatın pek çok kesiminde beğenmediğim kadarıyla, satış elemanlarına çok fazla zor gelmeyin. Bu zor bir iş.

Yazılım inşa etmiyorlar, çoğunlukla tüm bunların buzz kelimelerden nasıl geçtiğini bilmiyorlar.

Yine de, bazı yünlü ihtiyaçlar toplantısına dayanan zaman ölçekleri ve maliyetleri bulmaları gerekiyor. Belki onları ele geçirmek için yanlarında bazı teknik elemanlar vardır, ancak işleri devam ettirmek için bir satış yapmaları gerekir.

Peki, satış gücünüzün çevik geliştirme yöntemleri kullanan bir projeyi veya bu yöntemler kullanılarak geliştirilen bir ürünü başarılı bir şekilde satmasını nasıl sağlayabilirsiniz?

Satış ekibinizin müşteriyi ofise getirmesini sağlayarak. Çevikliğin tüm amacı müşteriden anında geri bildirim almaktır, böylece istediklerini (ve daha fazlasını değil) üretebilirsiniz. Onları getirin, ne istediklerini sorun. İki hafta sonra onları içeri alın ve onlara demo / prototip gösterin. Onları bu etkileşimle sat. Onlara ilerleme göster ve tam olarak istediklerini elde edebilmeleri için bu tür bir yinelemenin ne yapmak istediğini açıkla.

Gerekli iş miktarına ilişkin tahminler (yani bütçe sonuçta budur) verin, fakat onları güç atalım (okuyun: sorumluluk) onlar sığacak istediklerini dahil etmek onların bütçesi.

Bence cevabım çoğu durumda muhtemelen istemeyeceğinizdir. Bunu başlangıçta işinizin küçük bir parçası olarak görmeyi denerdim - belki% 20, gerisi geleneksel bir model altında. Zamanla Çevik ürünlere ve müşterilere daha fazla odaklanmaya ve bu bölümün daha fazla büyümesini sağlamaya çalışacağım.

Bununla baş etmenin başka bir parçası da belki her iki yaklaşımı da denemek ve kullanmaktır. Şelale yaklaşımını üst yönetim ve sözleşme müzakere milletleriyle birlikte kullanın. Örneğin, hem tarayıcı tabanlı hem de mobil telefon cihazlarını (Apple ve Android) kullanarak müşterilerin portföylerini korumalarına ve yatırım kararlarını vermelerine izin veren bir sistem. ' ya da böyle bir şey. Ardından geliştirme ekibinin gelişimi için daha ayrıntılı özellikler için Çevik'i kullanın; örneğin, Giriş Sayfası Oluştur, Giriş Sayfası Oluştur, Portolio Yönetim Geçmişi Oluştur, Mobil Giriş Oluştur, vb.

Başka bir fikir de bu yüzden Agile'yi farklılaştırıcınız yapmak Çoğu büyük kuruluş Çevik yapmıyorsa, çoğu insanın bunu biliyorum. Ancak küçük şirketlerin çoğu (tecrübelerimin büyük çoğunluğu). Çevik hızla büyüyor ve bu devam edeceğini düşünüyorum. Bu rotanın avantajı, zaten tanıyan müşterilere en çok ne yapmak istediğinizi belirlemenizdir. Bu yaklaşım, zaman içerisinde başarı garantisi olmayan bir çalışma gerektirecektir.

Müşterileriniz test etmekten hoşlanıyorsa, biraz çekiş de bulabilirsiniz. İyi test edilmiş ürünlere sahip olmak, bazı müşterilere daha kolay satış yapabilir. Bu alanda yardımcı bulduğum bir kitap, Adison Wesley Press'in 'Çevik Testleri'.

Davanızı desteklemek için güncel olayları da kullanabilirsiniz. Örneğin şu anki (bunu Ekim 2012'de yazıyor) sağlık hizmeti sitesi, canlı yayından 2 hafta önce gereken değişiklikleri yapmama konusunda harika bir durum. Ayrıca görünen aşırı mühendislik, daha çevik yöntemlerle daha iyi ele alınacaktı.

Çalışmanızdan memnun olan önceki müşterilere başvurun. Özellikle Şelaleden Çevik ise dönüştürür. En azından müşterileriniz olmayan dönüşümler.

Onların referansları (müşteri olarak), söyleyebileceğiniz her şeyden ve her şeyden daha ağır basacaktır. Yeni müşterinizin endişelerini ve korkularını her zamankinden daha fazla ele alabilirler.

Yönetim açısından bakıldığında, bütçe ve son tarih proje için bir iş gereksinimidir. Bu ihtiyaçlara cevap verdiğinizden emin olmanız gerekir ve bir işletmenin anahtarlama ile ilgili referansları bakarsanız, bunun doğrudan ortaya çıktığını fark edeceksiniz. Geliştiricinin anahtarlama ile ilgili referanslarına bakarsanız, bunun çoğu zaman geçmediğini fark edeceksiniz.