Yazılım Projesine Başlarken Altın Kurallar: Satış, Odak ve İnat
Ekip olarak şu anda yeni bir yazılım projesine başladık. Uzun zamandır geliştirmek istediğimiz hem bizim hem de başkalarının ihtiyacını çözecek bu proje için kolları sıvadık. Proje için fikirler havada uçuşurken acaba hangi prensiplere uysak da ilerleyen zamanlarda kafamızı duvarlara vurmasak diye düşünürken bu yazı serisi ortaya çıktı.
Yeni bir yazılım projesine başlarken uyulması gereken birçok altın kural var, ben sadece birkaç tanesine değineceğim. O da var bu da var demeyin, bu yazının devamı gelecek inşallah.
Satış: Evet, bildiğimiz anlamda. Hayır, kodlamayı falan düşünmeyin. Bu yazılım ürünü satılır mı, bize gelir sağlar mı, bu ürünü kimlere satabiliriz, kim bu ürüne neden para verir/ne kadar para verir, bu ürüne benzer ürünler piyasada var mı, bu ürünün diğerlerinden farkı ne olacak …
Yazılımcıların evine ekmek götürmesi, sunucu ve lisans masrafları ile operasyonel maliyetlerin karşılanması için para gerekli. Benim amacım para kazanmak değil insanlığa hizmet etmek istiyorum diyorsanız, o sizin bileceğiniz iş ama yıllarca sürecek bir projede motivasyonunuzu nasıl sağlayacağınızı iyi düşünün.
Projenizde özgürce karar vermenin ve çalışmanın yolu gelir elde etmekten geçiyor.
Yazılım ürünün satış yönünü düşünürken kullanıcının ihtiyacını belirleme yolunda ilerleyeceksiniz. Çünkü kullanıcının bu ürüne para verip vermeyeceği gerçekten de bir ihtiyacın olup olmadığını ortaya çıkaracaktır. İhtiyacın zaten piyasada mevcut ürünler ile karşılanması bu projenin mevcut ürünlerden hangi yönlerde farklı olacağını ortaya çıkaracaktır.
Satış yönünü düşünmek yazılım mimarisi açısından da bazı soruların cevaplarını bulmanızda yardımcı olacaktır. Örneğin sadece Türkiye pazarına hitap edecek bir ürün için bulut teknolojileri kullanmamayı tercih edebilirsiniz, kullanıcının kendi kaynaklarında (on prem) çalışacak bir yazılım için veya kalabalık bir yazılım ekibini maddi açıdan karşılayamayacak bir yazılım ürünü için tercih edeceğiniz yazılım teknolojileri farklı olabilir.
Ayrıca satış yönünü düşünürken yazılım ürününüz ile birlikte kullanacağınız ek bir donanım mevcut ise bu donanımı piyasadan nasıl elde edeceğinizi ya da nasıl ürettireceğinizi araştırmış olacaksınız.
Odak: Özetle MVP’ye (Minimum Viable Product) odaklanın. Çalışan basit bir sürüm ortaya çıkarın. Erkenden. Olabildiğince erken. Evet, ilerleyen zamanlarda utanın yazılımın bu halinden. Evet, bu hali sizin ve ekibin teknik yeteneklerini göstermiyor. Evet, belki de o havalı yeni teknolojiyi kullanmadan…
Kendinizi durdurun. Önce MVP ortaya çıkacak!
Kullanıcılarınız ile mümkünse yüz yüze görüşün, telefonla görüşün, e-posta ile görüşün. Yeter ki elinizi kana bulamadan ihtiyacı netleştirin. Hangi özelliklerin olmazsa olmaz olduğunu belirleyin. Beyin fırtınası yapıp şöyle bir özellik daha ekleyelim, böyle bir özelliği şuraya sıkıştıralım demeyin. Bunları not alın ilerleyen zamanlarda yaparsınız.
Yazılımı geliştirmeye başlamadan önce kullanıcılardan geri bildirim almanın bir diğer yolu ise sanki o yazılım hazırmış gibi bir websitesi yapmaktır. Bu websitesinin ne kadar ziyaret edildiği, A/B testleri ile farklı ücretlere ne kadar tıklama alındığı, websitesi sayesinde ne kadar telefon ve e-posta aldığınız size ihtiyaç konusunda bir şeyler söyleyecektir.
Kolları sıvadınız yazılımı geliştirmeye başlayacaksınız. Hemen bir yapılacaklar listesi oluşturun ve bu liste dışında iş yapmayın. Aklınıza gelen fikirleri sadece “ben doğru yolda mıyım” diye değerlendirin. Ek özellikleri ve kullanımı kolaylaştıracak muhteşem senaryoları sadece not alın. Önce MVP ortaya çıkacak ve kullanıcıdan geri bildirimler alınacak.
İnat: Geliştirme, istediğiniz hızda ve kalitede ilerlemiyor mu? Basit diye başladığınız bir özellik beklediğinizden zor mu çıktı? Veri tabanının tasarımını defalarca değiştirdiniz mi? Yapılacaklar listesinde üstü çizilecekler öylece duruyor mu? Yeni bir teknoloji mi çıktı? Denemek istediğiniz bir şeyler mi var? MVP’yi ortaya çıkarmaya odaklanın ve inatlaşın!
Tahminleriniz sizi yamultmasın. Büyük ihtimalle geliştirme süresi tahmininizden uzun sürecektir. Hatta bazı araştırmalara göre tahmin sürenizi pi sayısı ile çarptığınızda gerçekçi bir geliştirme süresi elde edebilirsiniz.
Varsayımlarınız sizi yıkmasın. Kullanıcının kendi sektörü hakkındaki bilgisi, kullanıcının bilgisayar kullanma alışkanlıkları, kullanıcının bu yazılıma ayıracağı süre (para değil, süre) gibi konularda farkında olmasanız da aslında birçok varsayıma sahipsiniz. Özellikle kalabalık bir yazılım ekibi ile geliştirilecek bir yazılım projeniz varsa bu varsayımlar ekibin içinde de değiştiğinden tehlike büyük oluyor. Proje ile ilgili maddeleri özellikle kullanıcı ile ilgili olanları yazılı hale getirin ve herkesin bu maddeleri okuduğunda aynı şeyi anladığından emin olun.
İletişim kazaları, tahminler ve varsayımlara karşı mücadeleyi bırakmayın.
Yazının ikinci serisinde “ekip” kavramına değinmeye çalışacağım.
Yorumlar
Yorum Gönder