18 Nisan 2015 Cumartesi

Startup'lar için projeye başlangıç stratejisi nasıl olmalıdır?

Merhaba, bu yazımda yeni yapılacak Startup bir projenin development başlangıç aşamasında nasıl bir yol izlenmelidir, bu konu hakkında deneyimlerimlerimden yola çıkarak fikirlerimi paylaşmak istiyorum. Umarım birilerine faydası olur (:


Önemli olan nedir?

Eğer yeni bir startup girişiminiz varsa öncelikle bu konuyu netleştirmeniz gerekli. Sizin için zaman ne kadar önemli?  Bu durum cebinizdeki para ile direkt olarak orantılır. Paranız ne kadar çok ise o kadar zamanınız vardır.

Teknik yönü ağır basan birilerinden danışmanlık, fikir alıyorsanız  development aşamalarının önemine vurgu yapar, ve kaliteli kod yazmak ister. Kendince haklıdır, çünkü resmin diğer tarafını göremez. Cebinizde ne kadar para var bununla pek ilgilenmez. Ona göre kod kalitesi en az zaman kadar önemlidir. Peki hangi durumda kod kalitesi önemlidir, hangi durumda zaman kod kalitesinden daha önemlidir?

1. model = Az kod çok iş
Eğer projenizin lokasyon olarak başka bir örneği yoksa, örneğin Amerika da tutmuş bir projeyi Türkiye de denemeye çalışıyorsanız sizin 1. önceliğiniz üründür. Aynı projenin Amerika da ki etkisi ile Türkiye de ki etkisi aynı olmayacaktır. Bir an önce ürünü çıkarıp etkilerini izlemeniz ve daha sonra oluşan tepkilere göre projeyi revize etmeniz gerekli. Burada zaman çok önemli bir unsurdur, zaman ne kadar artarsa maliyet de o kadar artar. Elinizde uygulanabilirliği kanıtlanmış bir model olmadığı için de proje development aşamasında başlangıçta düşünülenden çok daha farkı modellere dönüşebilir. Bu durumda kodunuzun kalitesi ne olursa olsun bazı yerleri tekrar yazmak zorunda olacaksınız. Yani projeye başlarken mümkün olduğunca az kod ve çok iş yapmanız gereklidir.

Ancak bu metodolojinin de dezavantajları var tabi ki. Diyelim ki temel ürünü çıkarttınız ve modeli stabil hale getirdiniz, ışığı gördünüz. Ancak işiniz burada bitmiyor, daha fazla büyüme için daha fazla geliştirme gerekli. İşte burada bu sistem kısa bir süre sonra tıkanır. Eğer az kod çok iş felsefesiyle başladığınız projenin üzerinden yürümek isterseniz, geliştirme maliyetiniz kaliteli yazılmış koda göre çok daha fazla maliyetli olacaktır.

Nasıl bir maliyet? 
Örneğin aynı geliştirme iterasyonu kaliteli kod ile yazılmış bir projede 1 gününüzü alıyorken, bu modelde bir haftanızı alabilir. Hatta bir süre sonra geliştirme yapılamıyor hale gelebilir. Proje yazılımcıya bağımlı bir hale gelecektir, yeni gelen bir developer in projeye entegrasyonu çok uzun bir zaman alacaktır. Neresinden bakarsanız bakın problem yani (:

Bunun önüne geçmek için de versiyon 2 projesinin versiyon 1 den bağımsız olarak tekrar yazılması gerekir. Yani aynı projeyi 2 kez yazmış olacaksınız. Bu 2. aşama 1. aşamanın %20-30 u kadar zaman maliyeti oluşturabilir. Ama bu kabul edilebilir bir maliyetdir. Sonuçta ürünüz çıkmış, iş modelinizin etkilerini izlemiş ve uzun vadede oluşturabileceği etkileri artık görebiliyorsunuz. Proje yönetim modeli olarak en uygun Spiral model kullanılabilir.

2. model = Çok kod, çok zaman
Eğer yapacağınız projenin lokasyon olarak başka bir örneği varsa, mesela yemek sepetinin bir klonunu yapacaksanız projeye başlamadan nasıl bir ürün çıkacağına dair elinizde bir modeliniz vardır. Projenin potansiyel etkileri hakkında bir know-how a sahipsiniz. Yani çıkacak ürün belli, ki en büyük problem budur zaten. Bu model de az kod çok iş yerine, çok ama kaliteli kod, çok iş felsefesi ile gitmek en mantıklısı olacaktır. Çünkü çıkacak ürün belli olduğu için ve development aşamalarında iş modelinde bir değişim olmayacağı için extra zaman maliyeti oluşmayacak,  kaliteli kod yazdığınız içinde yazdığınız kodu tekrar yazmak zorunda kalmayacaksınız. 1. model de bahsettiğim olumsuzlukların da önüne geçilmiş olacak. Proje yönetim modeli olarak Waterfall modeli uygulanabilir.

Son olarak en fazla karşılaştığım bir yanılgıdan bahsetmek istiyorum. Developer maliyeti zaman maliyetinden daha önemli bir konu değildir. Yani bir developer 3 ister diğeri 7 istiyorsa kısa vadede 3 isteyeni seçmek yerine 7 isteyen neden bu kadar fazla istiyor bunu anlamaya çalışın. Tabi bu durum teknik bir co-founder yoksa geçerli, varsa zaten bu konuya kafa yormanıza gerek yok.