Çevik Projelerin Finansmanı

İçinde çalıştığım şirket geçici olarak çevik bir proje yönetimi stratejisine doğru ilerliyor - şelalenin "sevinçlerini" bir kereye mahsus. Bunun anahtarı, zor son teslim tarihlerine uymak yerine işlevsellik sağlamaya yönelik vurgudur.

Geliştirme süreci ve müşteri ilişkileri, Agile tarafından teşvik edilen yinelemeli yayınlarla kesinlikle iyileşmiş olsa da, aynı mantığı proje için finansman stratejilerine uygulamak biraz daha zor oluyor. Müşteriler genellikle Agile gibi kavramlara alışmazlar ve "hazır olduğunda hazır olacaklar" durumu olarak algıladıkları şeyle büyük endişelerini ifade ederler .

İnsanların Agile projelerini finanse etme konusundaki düşünce ve deneyimlerini duymak isterim

edit: Vurgulamak istiyorum millet Agile yöntemin artılarını ve eksilerini açıklamak istemiyorum, ya da inanıyorum inanıyorum Agile "hazır olduğunda hazır olacak", bu tarafından ifade edilen bir korku Çevik geliştirme uygulamalarını savunurken birlikte çalıştığım müşteriler / işletmeler.

İlgilendiğim şey, insanların işletme müşterileri / ilişkileri içine yerleştirilen "geleneksel" şelale bütçeleme yöntemleri ile daha ilerici kalkınma yöntemleri - ve bu evrimi desteklemek için benimsedikleri bütçeleme stratejileri arasındaki çatışmaları çözme deneyimleri.

Tüm özelliklerde kesin bir son tarihi olan bir projeye teklif verebildiyseniz, neden çevik bir yaklaşıma geçtiniz? Siz ve diğer herkes bununla mücadele ediyor ve çevik bir yaklaşım bu gerçeğin önünde yer alıyor. Rekabete karşı propaganda olarak kullanın. Southwest Havayolu size bunu yapan herkes gibi bir ada koltuğu vaat etmiyor ve sonra başka birine veriyor.

Tabii ki müşteri kesin bir bitiş tarihi istiyor. Orijinal istekte herhangi bir değişikliğe bakılmaksızın, zamanında, ucuz, hatasız yazılımlar istiyorlar. Satış ekibine çevik prensipleri kullanarak bir projenin nasıl satılacağını öğrenmesini söyleyin. Ne kadar çok entegrasyondan geçerseniz, projenin ne zaman biteceğini öğrenebilirsiniz. Müşteri, değişiklik taleplerinin etkilerini de hesaba katmayı öğrenir.

Çevik projeler "hazır olduğunda hazır olacak" çizgisinde çalışmaz. Bu şelale mühendisliğinin klasik bir çizgisidir.

Çevik projeler, müşteri ek özelliklere daha fazla para harcamak istemediğine karar verdiğinde tamamlanır. Bu, satış elemanlarınız tarafından önemli bir satış noktasına dönüştürülebilir. Müşteri, sabit bir miktar para için sabit bir özellik kümesine (önceden bilinmesi gerekebilecek veya bilinmeyebilir) bağlı kalmak yerine, başlangıç ​​özellik kümesi için başlangıç ​​miktarıyla başlayabilir ve daha sonra aşamalı olarak alabilir. Bu birkaç şeyi garanti eder:

• Özellik listesi doğru bir şekilde önceliklendirildiği sürece, müşteri her zaman bir sonraki en önemli özellikleri alır, böylece harcamasından faydasını en üst düzeye çıkarır ("dolarları için en büyük patlamayı alır").
• Müşterinin parası biterse, yatırımını en üst düzeye çıkardı VE size teslim ettikleriniz için ödeme aldı. Kimse incinmez, herkes kar eder.
• Müşteri, tekerleğin her dönüşünde (bir entegrasyonun her iki ucunda) öncelikler ve özellikler hakkındaki fikrini değiştirebilir. Normal sabit fiyat sözleşmelerine göre belirgin bir avantaj.

Muhtemelen daha fazlası var, ancak yukarıdakiler satış personelinizin doğru yönde gitmesi için yeterli olmalıdır.

Bunu "Hazır olduğunda hazır olacak" diye görmüyorum. Çevik metodoloji, her iki haftada bir olduğu gibi düzenli olarak teslim edilebilir ürünler sunmayı teşvik eder. Bu nedenle, müşteri, ürününüzün özelliklerinin nasıl şekilleneceği konusunda rehberlik sağladığı için yaşamı boyunca projenin önemli ve çok aktif bir parçasıdır. Bir şey varsa, müşteri şelale yaklaşımında olduğu gibi bir projenin sonuna doğru değil, sonuçları daha erken görmeye başlayacaktır.

Müşterinin projenin aktif bir parçası olacağı ve projenin erken şekillenmeye başladığını göreceği sürece, bu bitene kadar beklemenin bir durum olmadığını garanti edebilir.

Çalıştığım yer Agile'ın korkunç bir piç haline getirmesine rağmen, müşterilerin yinelemelerde yazılım geliştirmeyi tam sürümlerden daha fazla tercih ettiklerini düşünüyorum.

Yinelemeler, müşterilerin bir şey istedikleri ve özellik uygulandığında, bir kez yapıldıktan sonra ve bir sürüm için birlikte gruplandırılan diğer tüm şeylerin de yapıldıkları için bireysel isteklere borç verir.

Bir müşterinin "Bu özelliği istiyoruz ve umursadığımız bir dizi başka özellikle sunulması için 8 ay beklemek istiyoruz" demedim.

Yinelemelere uygun bir ödeme döngüsü oluşturmaya ne dersiniz? Çevik fikri, sadece kısa atakları gerçekten planlayıp tahmin edebileceğiniz ve bu kısa döngüler için itme ve bağlılık hala güçlüdür. Öyleyse neden fonlamayı aynı şekilde hedeflemiyorsunuz? Müşteriler rehberlikle katkıda bulundukları anda $$ ile işe katkıda bulunsunlar. Sonuçta, eğer istediklerini alamıyorlarsa, bunun bedelini ödememeliler.

Ve sonra bir projenin sonlandırılmasında neler olduğunu öğrenin - örneğin, müşteri kodun sahibi mi, yoksa sadece yürütülebilir dosya mı? Ancak bu daha önceki şelale tipi projelerle uyumlu olacaktır.

Agile fikri, hızlı bir şekilde yinelemeniz ve her sprint sonunda ne sunacağınızı belirlemenizdir, bu nedenle sprintinizin 2/3/4 haftası dolduğunda, uygulamanızda / projenizde somut özelliklere sahip olursunuz müşterinize sunabilir ve geri bildirim alabilirsiniz.

ETA: Tespit edilen teslimatlarla 'sprint'leri' kilometre taşlarına 'toplayabilir ve kilometre taşı başına ödeme alabilirsiniz.

Ben kendim sabit bir proje satmanız ve Agile'ı sizin tarafınızdan ele almanız gerektiğine ikna olmadım, daha ziyade müşterinize tekrarlar satmalısınız.

Yinelemelerin anlaşılması açıktır ve iki kavramı karıştırmazsınız.

Aşağıdaki iki belge size Çevik Yönetim ve satış süreci etkileşimleri hakkında bazı bilgiler sağlayacaktır:

http://www.nayima.be/html/fixedpriceprojects.pdf & http://www.nayima.be/html/agilefixedprice.pdf