Geçtiğimiz haftalarda yazılım geliştiricileri için proje yönetiminden bahsetmiştim. Doğrusu bu basit metodoloji çalıştığım her firmada ciddi oranda işimi kolaylaştırmaya yaradı. Gittiğim çoğu ekip “Ama bu scrum değil!” ya da “Aslında Kanban budur” gibi verimsiz tartışmalarla zamanlarını harcarken çok basit ve esneyebilir bir framework hazırlamak her zaman hayatımı kolaylaştırdı ve ekip içindeki verimi arttırmamıza yardımcı oldu. Bu yazıyı aşağıdaki bağlantıdan okuyabilirsiniz.

Ürün Geliştirici Kütüphanesi

Yazılımcılar için proje yönetimine giriş

Yazılım geliştirme kültürü ve trendleri 2000’li yılların başından bu yana inanılmaz bir şekilde değişti. Bunun en büyük etkisi şimdilerde big tech ya da FAANG dediğimiz firmaların daha hızlı, daha rekabetçi olabilmek için yarattıkları Silikon Vadisi kültürüyle birlikte yazılımcılar küçük odalarda tek başlarına kod geliştiren kişiler yerine açık ofislerd…

10 months ago · 12 likes · 2 comments · Mert Susur

Ancak hangi metodolojiyi kullanırsanız kullanın işin sonunda kısıtlı kaynaklarla maksimum değeri üretmeye çalışıyor olacaksınız. Bunu sağlamak için de acımasız bir önceliklendirme sürecinden geçmeniz gerekiyor. Bu önceliklendirme süreci de tam olarak başarıya ulaşmanız için yeterli olmayacaktır. Tam bir başarı için herkesin hedefi çok iyi anlaması, çıktı değil sonuç odaklı davranması ve pragmatik bir şekilde çözüm üretmesi gerekecektir. Kısacık bir paragraf yazı için fazlasıyla paradigmadan bahsettim. Gelin bunları açalım.

Ekibin ürettiği değer

Kimi zaman yazılımcılar, özellikle az tecrübeli yazılımcılar, bunu unutuyor olsa da, bir firma tarafından işe alınmamızın bir sebebi var. Bu sebep de firmaya değer üretmek. Bu değer firmanın stratejisine ve başarmak istediklerine göre değişebilir. Bir kaç örnekle üzerinden geçelim;

Yeni bir girişimde çalışıyor olabilirsiniz. Bu girişim product-market fit bulmaya çalışıyor olabilir. Bu durumda üreteceğiniz değer maksimum fikir doğrulama ya da yanlışlama olabilir. Yani sahip olduğunuz hipotezleri test etmeniz için çok hızlı, hatta belki de sallapati, bir şekilde hayata geçirip başarılı ya da başarısız olmanız gerekebilir. Bunun için yazılımcılarınızın yazacağı kodun kalitesine göre değil, hızlı bir şekilde üretime göre optimize olmalısınız. Böylece değer üretebilirsiniz.
Rüşdünü ispatlamış ve cidi bir rekabet içinde olan bir girişimde çalışıyor olabilirsiniz. Bu durumda kaliteden çok ödün vermeden hızlı bir şekilde üretim yapmak zorunda olabilirsiniz. Bu durumda üreteceğiniz değer rekabet içinde bulunduğunuz firmaların ne kadar önünde olduğunuza ya da pazarlama faaliyetlerini nasıl desteklediğinize göre değişecektir.
Çok hızlı büyüyen bir scale-up’ta ekipleri destekleyen araçlar çıkartan bir ekipteyseniz, yaratacağınız değer yazılımcıları ne kadar hızlandıracağınız olacaktır. Dolayısıyla üretim yaparken buna göre bir metodoloji izlemeniz ve bunu ölçümlemeniz gereklidir.

Yukarıdaki örnekleri göz önünde bulundurursak ekiplerin üretecekleri değer, firmalara ve firmaların içinde bulundukları durumlara göre şekillenebilir. Bu durumda ilk yapmanız gereken firmanızın sizden beklediği değeri çok iyi anlamaya çalışmanız. Sonra da bu değeri nasıl ölçeceğinizi belirlemeniz. Örneğin firmanız işlem başına karlılığı mı arttırmaya çalışıyor? Yoksa firmanız yıllık bilançoyu arttırmaya mı çalışıyor? Ya da firmanızın yapmak istediği karlılıktan farklı olarak kullanıcı sayısını arttırmak mı? Bunu anladıktan sonra artık bu sonuca odaklanmak için planlamaya başlayabilirsiniz ve çözümlerinizi bu sonuç doğrultusunda ele alabilirsiniz.

Marketing Channel Research: How to Design a Prioritization Scheme?|Marketing Channel Research: How to Design a Prioritization Scheme?

Çıktı ⚔️ Sonuç odaklılık

Çıktı (output) ve sonuç (outcome) arasındaki ilişkiyi eminim herkes çok iyi biliyordur. Ancak burada, ben de dahil olmak üzere, herkesin sürekli düştüğü bir tuzak var.

Çoğu ekip için çıktılara odaklanmak, sonuca odaklanmaktan daha kolaydır. Çünkü her ne kadar aksi iddia edilse de, insanlar her zaman kesinlik ve tahmin edilebilirlik ihtiyacı duyarlar. Bu çok insani bir istek olmakla beraber, benim gördüğüm başarılı takımlar genellikle bu belirsizliğin içinden başarıyla çıkarak kendi başlarına bu sonucu tanımlayabilen ve kendi kaderlerini kontrol edebilen ekipler olmuşlardır. Tabii ki bunda firmanın kültürünün oynadığı rol de azımsanamaz.

Çıktılara odaklanmak bize kısa vadeli de olsa kontrolün bizde olduğunu hissettirir. Böylece kendimizi direksiyonda hissederek kısa vadede bir güven hissedebiliriz. Ancak çoğu zaman yapmak istediğimiz aslında kullanıcı davranışını değiştirmektir. Örneğin siteye girenlerin alışveriş yapmasını isterken, onlara sürekli reklamlar göstermek aslında bizi amacımızdan yani ulaşmak istediğimiz sonuçtan uzaklaştırabilir.

Bir başka örnek daha vermek gerekirse, ekibinizin bir amacı yazılımcı sayısını arttırmak olsun. Günde 10 tane görüşme yapmanız başarma şansınızı arttırabilir. Amacınız uğruna günde 10 görüşme yapmanız sizi mutlu da edebilir. Ancak asıl odaklanmanız gereken bu görüşmelerin sonucunda ne olduğu ve buna bağlı olarak süreçte neleri değiştirmeniz gerektiği olmalı.

Peki ya önceliklendirme?

Gelişmiş bir ürün kültürü olan firmalarda önceliklendirmeler yukarıda anlattığım konular göz önünde bulundurularak yapılır. Örneğin firmanın ulaşmak istediği sonuç eğer karlılığı arttırmaksa, bunun sizin ekibinize düşen parçasını ele alırsınız ve bu amaca uygun bir plan yaparsınız. Bunu yaparken ekibiniz pragmatik yani yararcı olmalıdır.

Enter The Matrix - Lean Prioritisation - Mind the Product

Bir e-ticaret uygulamasında çalıştığınızı düşünün. Sizin ekibinizin sorumluluğu da sipariş verme süreci olsun. Bu kapsama kullanıcının ürünü seçip sepete ekledikten sonraki tüm akışı dahil olsun. Eğer sizin yıllık stratejideki hedefiniz müşterilerin sipariş vermelerini kolaylaştırmaksa yukarıda anlattıklarımdan yola çıkarak,

Sipariş kolaylığını ölçülebilir metriklere dönüştürmeniz,
Bu metrikleri mevcut haliyle ölçmeniz ve bunların ne anlama geldiğini anlamanız,
Sonra bu metrikleri arttırmak için bir takım hipotezler geliştirmeniz ve bunların sağlamasını a/b testleriyle yapmanız,
Ardından bu alanlarda geliştirmeleri projelere dönüştürüp tamamlamanız,
Sonunda da bu geliştirmelerin sonuçlarını ölçerek ne kadar etki yarattığınızı anlamanız gerekir.

Eğer bu hipotezlerden birisi adres düzenleme ekranını iyileştirmek değilse ya da bir şekilde bunun metriklere katkı sağlamadığını düşünüyorsanız bu iyileştirmeyi önceliklendirmemelisiniz. Bu karar her ne kadar canınızı sıksa da, oradaki arayüzden ne kadar nefret ediyor olsanız da bunu kabul edip yolunuza devam etmelisiniz. Kanımca bu, ürün ekibinin ne kadar pragmatik olduğunun bir göstergesidir.

Teknik borç ve önceliklendirme

Çoğu yazılım ekibi ürün yöneticisini “hiç teknik işlere zaman ayırmıyor” diye suçlarken, ürün yöneticisi de yazılımcıları “hep over-engineering yapıyor” diye suçlar. Bu özellikle iyi bir ürün geliştirme kültürü olmayan ekipler için önemli bir sorundur. Hatta bu bazen öyle bir noktaya gelir ki “Ürün takımı” dendiğinde yazılımcılar hariç tutulur sadece ürün yöneticisi ve ürün tasarımcısından bahsedilir. (Bkz: Ürün firmalarındaki biz ve onlar sorunsalı)

Güçlü ürün geliştirme organizasyonlarında “ürün takımı” tanımı yazılımcıları da kapsar. Bu basit değişiklik bile kendi başına yazılımcıların sadece teknik sorunlardan değil, ürün sorunlarından da sorumlu olduklarını anlatır. Böylelikle ulaşılmak istenen sonuçta yazılımcılar da etkili bir şekilde katkıda bulunabilir. Çünkü işlerinin tanımı içerisinde ürün geliştirmek olur. Sadece kod yazmak değil.

Bu gibi ekiplerde teknik borç her zaman olur. Teknik borç da kötü bir şey asla değildir! Teknik borç ayak bağı olmaya başlayana ya da ekibin üretkenliğini tehlikeye atana kadar da kalmaya devam eder. Ancak ne zaman ki “yeterince geç” olur, o zaman o problemin çözümü için bir planlama yapılır ve önceliklendirmeye dahil olur.

Ürün yöneticisinin de odağı sonuç olduğu için, ekibin günlük hayatını etkileyen bir soruna karşı kayıtsız kalamaz. Eğer ekibi her gün bu sorunu yaşıyor ve bu onları mutsuz ediyorsa bu sorun ürün yöneticisinin de başarısını etkileyeceği için önceliklendirmeyi bu kriter altında yapabilir. Ancak buradaki en önemli soru; “Bu problemi çözmek için yeterince geç mi?” sorusudur. Çünkü bu basit soru istemsiz de olsa yazılım ekibine güvenilir bir pusula sağlar. Eğer çözülmesi için yeterince geç değilse yani örneğin,

O alanda yakın zamanda bir geliştirme yapılmayacaksa,
Manuel bir iş 3-5 ayda bir kere yapılıyorsa ve çok zaman almıyorsa
O bölgedeki teknik borç ya da yavaş çalışan bir süreç henüz kritik bir etki yaratacak noktada değilse

Belki de bunları düşünmeye henüz gerek olmayabilir.

Önceliklendirme acıtmıyorsa yanlış yapıyor olabilirsiniz

Eğer ekibinizde önceliklendirme yaparken çok güzel fikirlerinizden vaz geçmiyorsanız, çok hoşunuza gidecek özellikleri ileriye atmıyorsanız yani canınız yanmıyorsa muhtemelen yanlış yapıyorsunuz.

Unutmayın ekibinizin amacı en eforla en fazla etkiyi yaratmak. Bu optimizasyon adımını düzgünce yapmıyorsanız firmanızın çıkarlarını korumuyor olabilirsiniz. Hatta daha da kötüsü müşterileriniz için değil, kendiniz ya da sesi daha çok çıkan bir yöneticiniz için yazılım geliştiriyor olabilirsiniz.

Esnek ve öğrenmeye açık bir süreçle acımasız bir önceliklendirme firmanız ve ekibiniz için en iyi başarıyı size getirecektir.

Ürün Geliştirici Kütüphanesi

Projelerin başarısı için önceliklendirme