Yanlış soruna, doğru çözüm!

Hangisi daha önce gelir, sorun mu çözüm mü?

Sorun olmadan çözüm olur mu?  Sizin hiç yanlış bir soruna çok iyi bir çözüm ürettiğiniz oldu mu?

Sizin olmamış olabilir ama start-up camiasında çok yaygın bir davranıştır, bu.  Start-up'ların bir çoğu hatta hemen hemen hepsi, çok iyi bir çözüm üretir ama ancak bu start-up'ların sadece %10'u çözümlerinin gerçek bir soruna karşılık geldiğini görür.  %90 start-up, ürettikleri çözümün aslında gerçek bir soruna karşılık gelmediğini oldukça pahalı bir şekilde öğrenir.  O yüzden, yalın (lean) start-up kitaplarında "önce sat, sonra yap" akımları çok yaygındır.  

"Önce sat, sonra yap", önce insanları gerçek bir derdine derman olduğuna emin ol, veya "gerçek bir sorundan bahsettiğine emin misin?" demenin başka bir yoludur.  

Sadece start-up'lar mı, yanlış sorunlara doğru çözümler üretiyorlar.  Yazılım projelerinin bir çoğu bu durumda değil mi?  Gerçek hayatta yaşayan arkadaşlar bilirler, bir çok gereksinim paydaşın dertini (sorununu) değil, bir çözümü tarif eder.  Proje çözümü başarı ile hayata geçirse bile aynen start-up'larda olduğu gibi KABUL TESTİNE gelen gerçek kullanıcı,  "bu çözüm, bir işe yaramıyor!" der.  

KABUL TESTLERİNDE bu kadar çok sorun yaşanması ile start-up'ların bu kadar büyük oranlarda başarısız olmasının arkasında ortak sebebler olduğunu hiç düşünmüş müydünüz? 

Her iki durumda da proje ekibi soruna değil maalesef çözüme odaklanmıştır ve büyük ihtimal ile anlamadıkları veya yanlış anladıkları bir soruna, kendilerince en doğru çözümü üretirler.  Ancak, ortada sorun olmadığında, hiç anlaşılmamış veya yanlış anlaşılmış bir soruna, ne kadar doğru bir çözüm üretebiliriz?

Projelerimizde ve start-up'larımızda en önemli kaygımızın ÇÖZÜMÜ değil SORUNU doğru anladığımızdan emin olmaktır.  

Bunu daha teknik terimlerle söylersek:  Şu 4 çeşit gereksinim tipinden ilk ikisi öncelikle ve hayati derecede önemlidir.  
1.  İş Gereksinimleri (Business Requirements)
2.  Paydaş Gereksinimleri (Stakeholders Requirements)
3.  Çözüm Gereksinimleri (Solution Requirements)
4.  Geçiş Gereksinimleri (Transition Requirements)

Proje yöneticisi olarak, projemizde dikkat etmemiz gereken en önemli konuların başında: Yukarıdaki gereksinim tiplerinden ilk ikisinin öncelikle dokümante edildiğinden emin olmak gelir!

İlk iki gereksinim tipi SABİT'tir; Kolay kolay değişmez.  Üçüncü tip gereksinimler yani çözüm gereksinimleri daha ESNEK'tir.  

Eğer, çözüm gereksinimleri esnek değil ise bu projenizde iş ve paydaş gereksinimlerinin kayıp olduğuna dair bir işaret olabilir.  

HEDEF:  İş gereksinimleri ve paydaş gereksinimlerinden taviz vermeden; alternatif çözüm önerileri arasından en uygununu seçmektir. 

Çözüm gereksinimlerinin ESNEK olması projenin maliyet ve süre aşımlarına engel olmak için çok önemli bir rahatlık sağlar.  

Projenizin başarısı için iş ve paydaş gereksinimlerinin eksiksiz ve hatasız dokümante edildiğinden emin olmanız çok değerli....  Gerçek hayatta ve PMP sınavında buna dikkat!  :) 

Barış, huzur, esenlik üzerinize olsun,
Orhan