Kitabın ilk bölümünü birazda yorumlayarak Türkçeye çevirdim. Sanırım konu böyle daha iyi anlaşılacak. Buyrun...

Geleneksel piyasa savaşlarına bakarsak, rakipleri yenmek için sizin ürününüzde bir fazla özellik olmalıdır. Eğer onların 4 özelliği varsa sizin 5 özelliğiniz (veya 15, veya 20). Eğer rakipleriniz x para harcıyorsa siz xx kadar para harcamanız gerek. Eğer onların 20’ye ihtiyacı varsa sizin 30’a vardır.

Bu tür soğuk savaş yarışları artık güncelliğini kaybetmiş bulunuyor. Bu yöntem pahallı, izole ve paronayak ürün üretme yöntemidir. İzole ve paronayak firmalar önünü göremez. Onlar sadece geçmişi düşünür. Pazarda lider olmak yerine takip eden konumunda kalırlar.

Öyleyse ne yapmalıdır? Cevap küçük başlamak ve az özelliklerle piyasaya çıkmaktır. Rakiplerini yenmek için minimum özelliklerle piyasaya çıkın. Kolay problemleri çözüp zorlarını başkalarına bırakın. Küçük tepeleri yaratmak yerine ufak kum tepecikleri ile başlayın.

Bu bölüm içeriğinde:
Daha az özellik
Daha az seçenek ve parametre
Daha az insan ve kurumsal yapı
Daha az toplantı ve bürokratik seviye
Daha az “verilmiş sözler”

Yazılımı kendin için üret
Bir yazılım ürünü üretmeye başlamanın en güzel yolu kendi problemlerini çözecek bir yazılım üretmektir. Kendin hedef market olacaksın ve neyin önemli neyin önemsiz olduğuna sen karar vereceksin. Bu başlangıç sana; piyasayı kırıp geçirecek bir ürün için oldukça güzel bir zemin hazırlayacaktır.

Burada anahtar düşünce sizin yanlız olmadığınızdır. Eğer siz bu problemlere sahipseniz sizin gibi yüzlerce hatta binlerce insan da aynı problemlere “çok büyük bir ihtimalle” sahiptir. Bu kişiler sizin hedef piyasanız olacaktır. Kolay değil mi?

Kendi problemlerinizi çözecek bir yazılım geliştirirken bu yazılım için de bir aşk beslersiniz. İşte bu aşk sizin bu ürünü gerçekten kullanıp geliştirmeniz için gerekli gücü verecektir. Bu aşkı başkalarına da aşılarsanız sizinle çalışacak kişileri de buldunuz demektir.

ilk aşamada müşteri sen olduğun için ana gereksinimleri belirlemek te sana kalıyor. Yok eğer müşteri hazırsa ve yazılımı bir an önce kullanmak istiyorsa; bu ihtiyaçları sınıflandırıp en gerekli görülenleri ortaya çıkarmak lazım. Diyelim ki 10 tane ihtiyaç ilk sürümde isteniyor. Bu 10 ihtiyacı her hafta bir sürüm vererek 10 haftada sunabilirsen iyi olur düşüncesindeyim. Bir de her hafta sonunda sunulan ihtiyacı müşteri test etmeye başlarsa işler daha da hızlanabilir hatta müşteri çok gerekli gördüğü o 10 ihtiyaçtan elemeler de bile bulunabilir.

İlk çalıştığım firmada modül tabanlı geliştirme yapıyorduk ve proje çok büyük olmasına rağmen modüllere bölündüğü için yapılacak işlerin de karmaşıklığı azalmıştı. Her hafta sürüm veremesekte proje geliştirme işi kolaylaşmıştı. En gerekli görülen modülden başladık (Muhasebe). Bunu belirlerken diğer modüllere en az ihtiyaç duyan kendi başına çalışabilecek modülü seçmemiz ve sonrada biraz normalize etmemiz gerekti ki diğer modülleri düşünmeden geliştirme yapabilelim.

Gene kendimize dönecek olursak, ilk yazılım kendimiz için olacak ve core business zaten çok karmaşık olmayacaktır. Ufak parçalara ayırıp her parçayı haftalık olarak teslim edersek sonuçta problemimizin büyük bir kısmı çözülmüş olacaktır. Proje kapsamını küçültebildiğimiz kadar küçültüp aktif development yaparak (artık Agile, eXtreme, Iterative; Allah ne verdiyse) hızlı ve ünite testleri tam yapılmış mini sürümler ile olayı kotarabiliriz diye düşünüyorum.

Sağol Gökhan,

Pareto ilkesini kullanmadığım yer kalmadı ve evet çok haklısın. Tek eklemek istediğim ilk sürümü verirken o kesişim kümesini değilde, o kesişim kümesinden sadece bir isteği ilk hafta sonunda müşteri önüne çıkartabilirsem o zaman kendimi daha iyi hissederim. Hızlı ve kolay yönetilebilir, ufak sürümler ile, ünite testlerini birleştirerek kaliteyi arttırmak daha kolay bir yol gibi geliyor bana.