Yazılım Projesine Nasıl Başlanır: Şartname mi, Product Discovery mi?

KOBİ'lerde en yaygın proje başlangıcı şöyledir: birisi aylarca bir şartname yazar, üç teklif toplar, en ucuza verir — ve altı ay sonra belgenin yanlış problemi tam isabetle tarif ettiğini fark eder.

Bir şartname kalın olduğu için güvenli hissettirir. Ama hacim güvenlik değildir. Proje başlangıcında asıl soru „her şeyi yazdık mı" değil, „gerçekte neyin riskli olduğunu biliyor muyuz"dur.

Büyük şartname neden başarısız olur

80 sayfalık bir şartname, en başta en çok şeyi bildiğinizi varsayar — yani tam da en az şey bildiğiniz anı. Hiçbiri test edilmeden varsayımları dondurur. Sonraki her içgörü, normal bir iyileştirme yerine bir „değişiklik talebi"ne dönüşür.

DORA'nın 2024 Accelerate State of DevOps Raporu deseni gösterir: büyük, seyrek, geç test edilen taahhütler; küçük, sık, erken test edilenlerden daha istikrarsız ve daha yavaştır. Bu kod için geçerlidir — gereksinimler için de tıpatıp.

Product discovery, planlamanın zıttı değildir

Discovery çoğu zaman „plan yapmıyoruz, öylesine deniyoruz" diye yanlış anlaşılır. Tersi doğrudur: discovery, en kolay varsayım yerine en riskli varsayıma önce saldıran disiplinli bir planlamadır.

Bir varsayım, yanlış olduğunda proje başarısız oluyorsa — ve doğru olup olmadığını kimse kesin bilmiyorsa — risklidir. İyi bir proje tam orada başlar, giriş formunda değil.

Bir projeyi doğru başlatan dört soru

1. En riskli varsayım nedir?

„Önce neyi inşa ederiz" değil, „bütünün anlamlı olması için neyin doğru olması gerekir". Bu varsayımı önce test edin — bütçe bağlanmadan önce.

2. En küçük yararlı ilk kesit nedir?

Tüm sistem değil, erkenden gerçek değer sunan ve riskli varsayımı test eden tek süreç. Geri kalan her şey bilinçli olarak — yazılı biçimde — ertelenir.

3. Başarıyı nasıl tanırız — önceden?

Önceden tanımlı, ölçülebilir bir hedefi olmayan bir proje pahalı bir önsezidir. „Daha iyi olsun" bir hedef değildir. „Çevrim süresi 5 günden 1 günün altına" bir hedeftir.

4. İlk kesitte bilinçli olarak olmayan nedir?

Proje başlangıcındaki en değerli cümle „bunu bilinçli olarak henüz yapmıyoruz"dur. Bunu yazmayan, örtük biçimde her şeyi inşa eder — ve erken hiçbir şey teslim etmez.

Şartname ölü değil — sadece başlangıç değil

Resmi bir şartnamenin anlamlı olduğu bağlamlar vardır: düzenlenmiş tedarik, ihaleler, keskin sınırlı kapsamda sabit fiyat. Ama o zaman bile: önce discovery, sonra şartname. Kısa bir discovery'den sonra çıkan şartname doğru problemi tarif eder. Ondan önceki bir tahmini tarif eder.

Tahminleri dürüstçe okuyun

Proje başlangıcında ciddi bir tahmin, bir nokta değil, adı konmuş belirsizliklerle bir aralıktır. Belirsiz bir şartnameye kesin bir sayı veren ya tampon saklamıştır ya da riski anlamamıştır (bkz. Özel yazılım ne kadar tutar?). Ve bir projenin hiç eigenentwicklung gerektirip gerektirmediği her proje başlangıcından önce gelir (bkz. Özel mi Hazır mı?).

Proje başlangıcı için kontrol listesi

• En riskli varsayımı biliyor muyuz — ve onu önce mi test ediyoruz?
• „Tüm sistem" yerine bir en küçük yararlı kesit var mı?
• Hedef metrik önceden ve ölçülebilir tanımlı mı?
• İlk kesitte bilinçli olarak olmayanlar yazılı mı?
• Bir şartname varsa discovery'den sonra mı çıkıyor, önce değil?
• Tahmin bir nokta değil, belirsizliklerle bir aralık mı?
• Hiç özel geliştirme gerekip gerekmediği netleşti mi?

Sık sorulan sorular

Artık hiç şartnameye gerek yok mu? Çoğu zaman var — ama kısa bir discovery'nin sonucu olarak, onun yerine geçen olarak değil. Önce riski anlayın, sonra temiz şekilde belirtin.

Discovery sadece gecikmiş bir proje başlangıcı değil mi? Hayır. Bir discovery günler ila birkaç hafta sürer ve aylarca yanlış geliştirmeyi önler. O, proje başlangıcının kendisidir.

Müşteri bitmiş bir şartname isterse? O zaman ilk teslimat, onu en riskli varsayıma karşı birlikte test etmektir. İyi bir ortak belgede yazanı körü körüne teslim etmez.

Anlamlı bir discovery ne kadar büyük? Küçük. Hedef, en riskli varsayım, ilk kesit, başarı kriteri — birkaç sayfada, çeyreklerle değil günlerle.

Sonuç

Bir yazılım projesi en kalın belgeyle değil, en dürüst soruyla başlar: bunun işlemesi için neyin doğru olması gerekir — ve bunu zaten biliyor muyuz? En riskli varsayımı önce test eden, küçük kesen ve başarıyı önceden tanımlayan, güvenle başlar. 80 sayfayla başlayan çoğu zaman yanlış problemi kusursuzca tarif eder.

İlgili okuma

• KOBİ'ler için Özel Yazılım mı Hazır Çözüm mü? — her proje başlangıcından önceki soru.
• KOBİ'lerde Yapay Zekâ & Otomasyon: 90 günlük pilot — riski önce test etmek, pratikte.

Sonraki adım

Aylarca yanlış belgeye yatırım yapmadan bir yazılım projesine başlamak mı istiyorsunuz? Kısa bir ihtiyaç değerlendirmesiyle başlayın. En riskli varsayımı adlandırır ve ilk, test edilebilir bir adım keseriz.

Kaynaklar

• DORA, Accelerate State of DevOps Report 2024 — dora.dev
• Atlassian, Çevik Proje Yönetimi — atlassian.com
• Thoughtworks, Technology Radar — thoughtworks.com