Yeni teknoloji için bir öğrenme eğrisi eklemem gerektiğinde projeleri nasıl tahmin edebilirim?

Bazen, teknoloji, kavramlar ve müşteri hakkında önceden hiçbir şey bilinmeyen araştırma ve geliştirme projeleri vardır. Ancak, yöneticinin hala zaman tahminlerine ihtiyacı vardır. Yararlı tahminler üretmek için ne yapabilirim?

Dürüst olmak gerekirse, Nassim Nicholas Taleb, Kara Kuğu kitabında yazdığı gibi: 'sadece tahmin edemeyiz'. Temel olarak bilinmeyen bilinmeyenler nedeniyle. Bir tahminde bulunmak yerine, bu gerçeği, tahmin edemeyeceğiniz gerçeğini iletmek genellikle en iyisidir.

Talebin yazdığı gibi: geniş ölçüde doğru olmak, tam olarak yanlış olmaktan daha iyidir. Bu nedenle, tahmin etmekte zorlandığınız zamanları ilettiğinizden emin olun ve 'yeni teknolojide öğrenme eğrileri' gibi şeyleri argümanlardan biri olarak kullanın. Bu, tahmininizin kapsamının büyük olacağı anlamına gelir: 'bu proje 100k ile 500k arasında olacak.'

Böyle bir şey söyleyerek sizden bir şey tahmin etmenizi isteyen şey, işlerin o kadar basit olmadığını fark eder.

İhtiyacınız olan ilk şey, kapsam hakkında bir fikir. Ne kadar somut olursa o kadar iyidir, ancak ilk tahminler için herhangi bir gereksinim türü kullanılabilir. Müşteri gereksinimleri, vizyonu, kapsamı ve konsept belgeleri erken kullanılabilir. Gereksinimler ve çalışma ortamı daha açık hale geldikçe, tahminler iyileşecektir. Müşteri (özellikle müşteri ve gelişmekte olan kuruluş arasındaki arayüzler), işi yapan ekip, kullanılacak teknolojiler, sistem mimarisi ve ayrıntılı bir tasarım hakkında daha fazla bilgi sahibi olmak daha doğru bir tahmine katkıda bulunacaktır. Bu, Belirsizlik Konisinde görülebilir.

SLIM veya COCOMO gibi bir parametrik modelleme aracı kullanıyorsanız (Basic'in maliyet sürücülerini hesaba katmadığı için yalnızca Orta veya İleri Düzey), teknolojinin bilinmemesi için ayar faktörleri olmalıdır. Örnek olarak, COCOMO'nun, özellikle hedef platformu tanıma ve sistemi geliştirmek için kullanılan dil ve araçlar dahil olmak üzere çok sayıda maliyet sürücüsü vardır. SLIM ayrıca, kullanılan araç ve teknolojilerin dikkate alınması gereken geliştirme ekibinin genel deneyimini de hesaba katar.

Bu teknikle, modelleme araçlarının çıktısı tipik olarak doğrulanır, çünkü birçok kuruluşta uzun yıllar boyunca önceki yazılım projelerini tahmin etmek için başarıyla kullanılmıştır. Ancak, çıktı yalnızca aletin girişi kadar iyidir.

Tahmin için parametrik modeller kullanmıyorsanız, tahminlerinizi oluştururken bu faktörleri göz önünde bulundurmanız yeterlidir. Daha çok bir karar çağrısı haline gelir, ancak belgeleri okumak, yeni geliştirme ortamını kurmak ve hedef platformda veya hedef dillerle örnek uygulamalar geliştirmek gibi etkinlikleri düşünebilirsiniz.

Bu gibi durumlarda, tahminlerinizi göreve göre ayırmanız ve bunu desteklemek için mesleki muhakemenizi kullanabilmeniz gerekir. Umarım, tahminlerinizi dayandıracak geçmiş verileriniz ve diğer somut kanıtlarınız vardır. Aksi takdirde, daha çok yokuş yukarı bir savaş.

Önemli eğitim ve araştırma zamanlarını geliştirme zamanından ayırın. Projeyi mutlu sonları olan birden fazla alt projeye ayırın. Eğitimden sonra bir kavram kanıtı oluşturduğunuzdan emin olun.

Teknolojide yeniyseniz, asla gerçek geliştirme zamanına yaklaşamazsınız. Bunu projenin başında bir risk olarak yükseltin ve tahminde cömert olun. Bu, sizin ve ekibinizin aşina olmadığı temel teknolojiler için geçerlidir.

Bağımlı, çoğu zaman FPA ( İşlev Noktası Analizi ) kullandım , ama bu "enterprizey web geliştirme" ye girdik, yani, bilirsiniz, Forbes 500 web şirketleri.

Burada görev her zaman iki bölüme ayrılabilir: biri, FPA'ya gerçekten çok iyi uyuyor: giriş arayüzleriniz, çıkış arayüzleriniz, dahili mantıksal dosyalarınız (aka. Veritabanı tabloları / ihraç edilecek türler) ve bu karmaşık, bilinmeyen sistemleriniz var .

Kolay sürümde, karmaşık görev zaten yazılmış bir bileşendir, onunla arayüz kurmak zor ve bilinmez.

Zor sürüm, ne zaman yazılması gerektiğidir, o zaman pilot tabanlı tahminler, COCOMO, neyse.

Ancak iki önemli şey var:

1. Her türlü tahmin sisteminin kuruluşunuz için bir kalibrasyon süresi olmalıdır. Hiçbir zaman yalnız gelişmezsiniz, en azından kodunuzu bekleyen bir müşteri var (ya da bu konuda çaresiz kalmayacaksınız, kendi iyiliğiniz için kod yazacaksınız). Soru "ne kadar hızlı geliştirilebilir?" Değil, "hepinizle ne kadar hızlı geliştirilebilir?"

2. Bir keresinde Black Swan romanını okuyan ve bu konuda manyak bir menajerim vardı. Bize tahmin etmenin imkansız olduğunu söylüyordu ve sürekli olarak + -10% tahminlerime her zamanki hassasiyetimi yapıyordum ...

Bu tanıma uyan projeler düzenli olarak yapıyorum ve henüz çözemedim! Neyse ki çalıştığım yerde ihtiyacım olan şeyi yapma özgürlüğüne sahibim ve boş zaman sınırlamaları yok. Projeler her zaman başarılı değildir ve bu, pek çok bilinmeyenle çalışmanın sadece bir parçasıdır. Şirket her seferinde bilgi kazanıyor.

Üzgünüm, hiç yardımcı olmuyor.

Bilinen teknolojiyi kullanarak benzer bir proje yapmanın ne kadar süreceğini tahmin edin. 4 ile çarpın. Biraz öğrenme süresi ekleyin.

Tahmin çok kısaysa, saf ve kibirli görüneceksiniz. tahmin çok büyükse, cahil ve yetersiz görüneceksiniz. Akıllıca seçim.