- Birçok şirket karmaşık süreçlere veya uzun gereksinim listelerine takılıp geliştirme hızını yavaşlatıyor, ancak aslında önemli olan hızlı bir şekilde ‘doğru ürünü’ yapmak.
- Ürün geliştirme sürecindeki gereksiz unsurlar kaldırıldığında ürün geliştirme hızı çok artıyor. Doğru ürünü yapmak zaten özünde hızlı bir süreç.
- Ürün ekibinin hızını yavaşlatan şey; süreçler, karar vericiler ile uygulayıcılar arasındaki mesafe ve aşırı ayrıntılı dokümanlar gibi gereksiz unsurlar.
[Product Velocity için İlkeler]
1. ‘Daha az yapmak’ gerekir
- Genel olarak hız ile kalite arasında bir trade-off vardır.
- Çoğu şirket gereksinimleri ve teslim tarihini belirleyip kaliteyi sonuç olarak ele alır, ancak biz bunun tersini yapıp kalite standardını belirliyor ve 60 gün içinde neyi yayına alabileceğimizi düşünüyoruz.
- Önemli olan tüm gereksinimleri karşılamaya çalışmak değil, önemli olanları hızla tamamlamaktır.
- Gereksinimleri azaltıp sadece gerekli işleri yaparsanız hem hızı hem kaliteyi artırabilirsiniz.
- Elon Musk da benzer bir yaklaşım öneriyor ve “Önce gereksinimleri daha az aptalca hale getirin” diyor.
2. ‘Aptal modu’ çoğu zaman etkilidir
- ‘midwit meme’ örneğinde olduğu gibi, zeki insanlar ile aptallar basit çözümlerde uzlaşırken ortalama insanlar gereksiz yere karmaşık problemler yaratır.
- Biz de sorunlara sık sık ‘aptal modu’ ile yaklaşıyor, karmaşık düşünmek yerine basit çözümler bulmaya çalışıyoruz.
- Hata yaptığımızda çoğu zaman fazla düşünmüş oluyoruz; basit yöntem daha sık işe yarıyor.
- “Ben aptal olsaydım ne yapardım?” diye kendine sormak, çoğu zaman uygulanabilir çözümlere götürüyor.
3. Her sorun önemli değildir
- Sadece az sayıdaki sorun gerçekten çok önemlidir. Güvenlik gibi kritik problemler mutlaka çözülmelidir, ama her problemi çözmek gerekmez.
- Örneğin mobil UI iyi değil, ancak müşteriler mobil kullanımı neredeyse hiç tercih etmediği için bunu iyileştirmiyoruz.
- Müşterilerin ciddi biçimde önemsemediği sorunlar bu şekilde göz ardı edilebilir.
4. Sadece yapın
- Bizim ürün geliştirme için bir sürecimiz yok. Figma mockup, PRD, design system, agile, OKR, net bir ürün roadmap’i, A/B testing, growth hacking gibi şeyler yapmıyoruz.
- Müşterilerimiz mühendis olduğu için, kendi mühendislerimizin ürün, tasarım ve benzeri işleri de üstlenebilmesini bekliyoruz.
- Ürünü hızlıca yapıp müşterilerin tepkisine bakmayı tercih ediyoruz.
5. Yeniden yazımı gerektiğinde yapın
- Şirketler çoğu zaman teknik borcu mümkün olduğunca uzun süre ertelemenin daha hızlı hareket etmelerini sağlayacağını düşünür, ancak biz gerektiğinde büyük çaplı yeniden yazımlardan rahatsız olmuyoruz.
- Bazen doğru şeyi yapmanın en hızlı yolu, önce yanlış olanı yapmak, onun yanlış olduğunu fark etmek ve sonra onu doğru olanla değiştirmektir.
- Teknik borcu temizlemek faydalı görünüyorsa bunu yaparız.
6. Mümkünse dış kaynak kullanın
- Mümkün olduğunda şirket içinde geliştirmek yerine dış tedarikçilerin çözümlerini satın alıyoruz. Örneğin SDK üretmek için Fern adlı bir şirketi kullanıyoruz.
- Elbette tedarikçi kullanmanın kayda değer bir başlangıç maliyeti vardır ve hareket alanını sınırlar, ancak genel olarak doğru seçim budur.
- Bizim mühendislik kaynaklarımız çok sınırlı ve pahalı; bir mühendisin bir haftalık zamanı yaklaşık 5 bin dolara mal oluyor. Fırsat maliyeti hesaba katıldığında bu değer çok daha yüksektir.
- Gerçekten inşa etmeye değecek şeylerin sayısı görece azdır.
7. İşe almayın
- Kadroyu büyütmenin ekibin çıktısını artıracağını varsaymıyoruz. İşe alım yavaş ve zordur; onboarding ve insan yönetimi zaman tüketir.
- Özellikle çok fazla destek gerektirmeden katkı sağlayabilecek yetenekli insanları bulmak zordur.
- Bu nedenle büyük bir mühendislik ekibi kurabilecek kaynağımız olsa da küçük kalmak için elimizden geleni yapıyoruz. Bu hayatı çok daha kolay hale getiriyor.
Son düşünceler
- Daha önce fark ettiğimizden de fazla biçimde, ürün geliştirmenin aslında bu kadar uzun sürmemesi gerektiğini anladık.
- Müşterinin neye ihtiyaç duyduğunu biliyorsanız, güçlü bir ekibiniz varsa ve dikkati dağıtan gereksiz unsurları dışarıda bırakabiliyorsanız, yüksek hızda ürün geliştirebilirsiniz.
10 yorum
Ben de yine bakmaya geldim. Bir dahaki sefere tekrar görüşürüz.
Tekrar tekrar bakınca da güzel.
?? Oldukça idealist görünüyor.
Dış kaynak kullanımının yönetim maliyeti ya da buna ayrılması gereken kaynaklar da hiç az değil gibi... Yine de genel olarak harika tavsiyeler.
Her zaman dış kaynak kullanımını öneriyorlar. Ama dış kaynak kullanırken nasıl hareket edilmesi gerektiğine dair neredeyse hiç şey görmedim gibi.
Net bir hizmet resmi olmadan yalnızca basit bir taslak teslim ederseniz, beklediğinizden daha kötü şeyler alabileceğinizi fark etmiyorlar....
???: Hızlı ama çevik olmayacak şekilde yapın lütfen
Bunun, ürün net olduğunda mümkün olduğunu düşünüyorum
Yapılması gereken şey net olduğunda, bunun ötesindeki tasarım gereksiz geliyor gibi
"Önce gereksinimleri daha az aptalca hale getirin"
Taşeron firma bir gün ortadan kaybolursa... telefona da çıkmazsa ağlamaklı
Bu iç geliştirme olsa bile, bir gün herkesin birden istifa ettiğini düşünürsek durum benzer olmaz mı..?