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 ofislerde daha fazla sorumluluk alan kişilere dönüştüler. Bu dönüşümün en büyük etkisi de yazılımcılardan beklenen sorumluluklara yansıdı. Örneğin bulut devrimi ve DevOps akımı ile birlikte yazılımcıdan artık sadece kod yazmaları değil aynı zamanda bu kodların çalışacağı altyapıları da Infrastructure as Code araçları ile yönetmeleri de beklenmeye başladı.

Elbette beklentiler sadece teknik anlamda artmadı. Çoğu ürün organizasyonunda paydaşları yönetmek, yapılan geliştirmeleri diğer yazılımcılarla paylaşmak, dokümantasyon yazmak, teknik tasarım dokümanları yazmak ve yönetmek, hatta ve hatta proje liderliği yapmak da beklenmeye başlandı. Özellikle bir çok ürün organizasyonunda scrum master ya da proje yöneticisi gibi rollerin olmaması sebebiyle ve bu alanda gelişen çok fazla uygulama ile proje yönetimi ve ekip liderliği de tecrübeli yazılımcılardan daha da fazla beklenmeye başlandı.

Çalıştığım ve incelediğim başarılı organizasyonların büyük bir kısmında bu tarz rolleri genellikle yazılımcılar üstleniyor. Örneğin, Facebook’ta ürün yöneticileri ağırlıklı olarak vizyon ve stratejiye odaklanırken ekiplerdeki yazılımcılar taktiksel olarak projeleri yönetiyor ve liderliğini yapıyor. Bu firmalarda Teknik Proje Yöneticisi gibi bir rol de bulunabiliyor ancak genellikle bu rol çok fazla ekibin dahil olduğu büyük projelerde devreye giriyor. Yani çoğunlukla ürün içindeki geliştirmelerin projelerini yazılımcılar üstleniyor. Bir scrum master işin memuriyetini üstlenmiyor. Bu sayede yazılımcılar “Nasıl” sorusuna cevap ararken, ürün yöneticileri “Ne” sorusuna cevap arıyor.

Bu durum elbette firmanın içinde bulunduğu bir çok dinamiğe göre değişebiliyor. Firmanın ve ekibin olgunluğu gibi farklı birtakım konulara da bağlı. Ancak bu yazıda size yazılımcıların korkulu rüyası olan süre tahmininden ve bunun teknik kişiler tarafından nasıl yönetilebileceğinden bahsediyor olacağım. Daha önce yazdığım yazılardan biraz daha kısa olacağını düşünüyorum. Umarım bir faydası olur!

Her proje yeni bir macera

Aynı ürünü yıllardır geliştiriyor olsanız bile, her projenin kendisine göre farklı dinamikleri olabilir. Bu farklılıklar, ekip üyelerinin değişmesinden, teknolojinin değişmesinden, müşteri taleplerinin ya da ihtiyacının değişmesinden ya da basitçe firmanın stratejisinin değişmesinden kaynaklı olabilir. Bu durum elbette bir belirsizliği denkleme dahil eder. Yani her proje aslında belirsizliklerle ortaya çıkar. Bu belirsizliklerle ne şekilde başa çıktığınız sizin projenizin başarısını dramatik bir şekilde etkilemekle kalmayıp ekibin akıl sağlığını korumanıza ya da kaybetmenize neden olabilir. Bu belirsizliği anlatan çok güzel bir grafiği sizinle paylaşmak istiyorum. Bu grafiğin adı “Belirsizlik Konisi”.

Bu koni, projenin hangi aşamasında olduğunuza göre yapacağınız tahminlerin ne şekilde sapmaya uğrayabileceğini gösteriyor. Yani eğer projenin başında biri size bu 10 gün sürer diyorsa, aslında bu 2-40 gün arasında sürecektir gibi bir anlama geliyor diyebiliriz. Yani bu teoriye göre, en doğru süre tahminini ancak belirsizliklerden kurtulduğumuzda doğru tahmin edebiliriz. Bu da aslında projeyi bitirdiğimiz zamana denk geliyor, çünkü o noktaya kadar sürekli azalsa da bir belirsizlik kalmaya devam edecektir.

Öncelikle bu belirsizliği kabul ederek işe başlamak ilk yapmamız gereken şey. Bunu kabul ettikten sonra bu maceraya nasıl ve nereden başlayacağımızı planlamamız lazım.

İlk adım: Başlangıç Aşaması

Belirsizliği kabul etmiş ve bunu paydaşlarımızla doğru bir şekilde paylaştıysak bu durumda ilk adımımız bu belirsizliği bir an önce en aza indirgemek olmalı. Projenin bu aşamasında en az eforla en fazla değeri üretmemiz, israfımızı kontrol etmemiz açısından önemli. Bu noktada hala projeye başlamadık, ve belki de hiç başlamayacağız! Bu yüzden yapacağımız ön analizde şunları anlamamız gerekli;

1. Bu projeyi neden yapmak istiyoruz? Bunu yaparsak nasıl bir değer üreteceğiz?

2. Bu değeri neden şimdi üretmeliyiz? Neden 6 ay sonra değil?

3. Bu projeyi yaparken nasıl bir bağımlılığımız var? Başka takımlardan ihtiyaç duyabileceğimiz şeyler var mı?

4. Bu projenin başarı kriteri nedir? Çözümümüzü neye göre optimize edeceğiz?

Bu dört soruyu cevaplamak her zaman çok kolay olmayabilir. Bunun için bir çok kişiyle, iş birimiyle görüşmeniz gerekebilir. Diğer takımlardaki yazılımcılarla iletişim kurmanız gerekebilir. Ürün yöneticisinden başarı kriterlerini ve nedenini çok iyi öğrenmek için onunla da çalışmanız gerekebilir. Dolayısıyla bu aşamada hala kimseye bir söz vermemek en güzeli. Bu yüzden bu gibi noktalarda bildiğimiz bilgilerle T-shirt bedeni ile bir süre öngörebilirsiniz. Burada S, M, L ya da XL sizin tanımınıza bağlı. Mesela içinizden bir ses bu işin en az bir çeyrek (3 ay+) boyunca süreceğini söylüyorsa o zaman XL, bir iki ay sürecek gibi duruyorsa L, 2 aydan az ama haftalarca sürecekse M diyebilirsiniz. Bu tamamen size kalmış.

Bu noktada yapacağınız tahminler, atacağınız taşın ürküteceğiniz kurbağaya değer olup olmadığını anlamak için yapılacak. Yani bağlayıcı değil. Olamaz da zaten! Bir yönetici olarak bu noktada bir yazılımcı bana bu iş 3 ay sürer derse de inanmazdım. Ama en azından bir çeyreği buna harcayabileceğimize göre beklentilerimi düzenlerdim.

Ayrıntı Aşaması

Bu noktaya geldiğimizde artık şunları biliyoruz,

• Bu işi yapmak istiyoruz. Çünkü üreteceği değere ikna olduk. Ve bunu şimdi yapmalıyız, 6 ay sonra yaparsak hangi fırsatları kaçıracağımızı biliyoruz.

• Bu işi yapmak çok zor, zor, kolay ya da çok kolay.

• Bu işin başarısı için bazı takımlara ihtiyacımız var ya da yok.

• Bu işin başarıya ulaşabildiğini anlayabileceğimiz bazı metrikler keşfettik. Mesela kullanıcı başına %4 karlılığı arttırmak istiyoruz ya da siteye giren kullanıcıların %10’unun buna tıklamasını bekliyoruz ya da yazılımcıların bu işin sonunda en az %10 daha etkili olacağını umuyoruz.

Şimdi artık çözümleri ve opsiyonları düşünmeye başlayabiliriz. Elimizdeki bu parametreleri ve topladığımız bilgileri toplayarak en az iki farklı opsiyonu değerlendirmemiz lazım. Bazı nadir durumlarda tek bir opsiyona da düşebiliriz. Ancak biz olaya farklı bir kaç açıdan bakmak istiyoruz. Dolayısıyla en az iki opsiyon bulmaya çalışmalıyız. Bu bizim için de güzel bir kendimizi zorlama yolu olacaktır.

Bu aşamada hala daha belirsizliğimiz var, ancak bu proje artık parçalara bölecek kadar değerli ve önemli. Ayrıca bazı bilgilere de sahibiz. Dolayısıyla parçalara bölerken yapmamız gereken şey aslında daha fazla belirsizlik keşfetmek. Projenin bu aşamasında 3 durum geçerli,

1. Bildiğimizi bildiğimiz çözümler: Sepette değişiklik yapmamız lazım, ancak en son önceki projede sepette değişiklik yapmıştık dolayısıyla ekiptekiler bunu çok iyi biliyorlar. Dolayısıyla bildiğimizi biliyoruz.

2. Bilmediğimizi bildiğimiz sorunlar: Mesela bir sebepten sipariş modülüne dokunmamız gerektiğini biliyoruz, ama bu modülde değişiklik yapınca ne olacağını bilmiyoruz. Yani bilmediğimizi biliyoruz.

3. Bilmediğimizi bilmediğimiz sorunlar: Hala daha karşımıza çok farklı performans, güvenlik ya da karmaşıklık sorunları çıkabilir. Dolayısıyla ne bilmediğimizi bilmiyoruz.

Burada (1) en güzel durum. Zaten biliyoruz sorun yok. Ancak (2) için bir şeyler yapmamız ve belirsizliği düşürmemiz lazım. Mesela başka ekiplerle konuşabilir ya da spike yapabiliriz. Ancak (3) belirsizlik konisinin belirsiz kalmaya devam etmesinin en önemli sebeplerinden birisi. Bunu çözmeye uğraşmak verimli sonuçlar doğurmayabilir. Adeta yeldeğirmeniyle savaşmak gibi diyebiliriz. Projede ilerleyene kadar bu orada kalmaya devam edecektir.

Yavaş yavaş çözümler ortaya çıkmaya başladıktan sonra bir şey daha planlamamız gerekiyor. Bunun başında kilometre taşları yani İngilizcesi milestone’ları belirlemek.

Bunlar da belirlendikten sonra artık projeye başlayabiliriz.

Geliştirme döngüsü

Artık projeyi daha iyi tanıyoruz, ama hala belirsizliklerimiz var. Projenin başında vereceğimiz tahminler artık 0.8-1.5 çarpanı arasında bir belirsizliğe sahip diye bir öngörüde bulunabiliriz. Mesela takım bunun 1 ay süreceğini düşünüyorsa, bu proje 1 aydan biraz daha kısa ya da 1,5 ay kadar uzun sürebilir diye düşünebiliriz. Burada başlamak için doğru yeri seçmek de önemli. Eğer hala daha belirsizlik olan yerler varsa bunlara başta odaklanmak en mantıklısı.

Burada bir çok ekibin yaptığını gördüğüm hata ilk başta kolay işlere odaklanarak, zor işleri ileri bir tarihe ötelemek. Bu durum kısa vadede ekibi mutlu edecek bir ilerleme göstermemize sebep olsa da, genelde asla sonu gelmeyen ya da bitmeyen kuyruklu projelere yol açıyor. Bu durumda projenin başında ekip hızlı ilerlerken, sonuna geldikçe her defasında daha fazla sorun ve daha fazla problem ortaya çıkıyor. Başta motive olan ekip sonunda özgüvenini kaybediyor, sıkılıyor, mesailer yapıyor ve yine de bitiremiyor.

Bu yüzden başlangıçta zor ya da belirsiz yerlere odaklanmak daha gerçekçi ve sürdürülebilir bir proje sürdürmenize yardımcı olacaktır.

Bir başka önerim de “Yürüyen İskelet” modelini uygulamanız yönünde. Örneğin bir projeye başlarken boş da olsa bir şeyleri canlı ortama kurabilmeniz projenin ilerleyen aşamalarında sizin için çok önemli olacak test aşamalarını hızlı geçmenize sebep olacaktır.

Canlıya geçişler

Eminim bunu bir çok kişi biliyordur ama hızlıca özetlemek istedim. Her iterasyon, hatta her task sürekli canlı sisteme kadar hızlıca gitmelidir. Canlı sistemle test sistemi arasında hiç bir fark olmaması hem diğer ekipler hem de sizin açınızdan kritik bir fayda sağlar. Bunun için de canlı ortamına gönderdiğiniz geliştirmelerin “feature flag” ile kontrol edilmesini ve ürün kullanıcıya ulaşmaya hazır olana kadar görülmemesini sağlamanız gerekir. Burada çok daha sofistike yöntemler kullanabilirsiniz. Mesela,

• Sadece firmadaki kullanıcılara açık özellik - Internal beta

• Bazı müşterilere açık özellik. Mesela, müşterilerin %30’una ya da belli başlı müşterilere. — Feature throttling

• Belli bir süre boyunca, mesela sadece mesai saatlerinde, açık olan özellik.

Tabii ki bunun dışında yapılması gereken ve planlanması gereken bir çok farklı yöntem ve kontrol vardır. Bu tamamen sizin ürününüzün dinamiklerine bağlı olacağı için bütün örneklere girmek yersiz olacaktır.

Etki ölçümü ve öğrenimler

Ürünü kullanıcılara ulaştırdıktan sonra, belirlediğiniz kriterleri takip etmeniz ve başarınızı takip etmeniz şart. Bunu tek başınıza yapmak zorunda değilsiniz, ürün yöneticiniz burada en iyi ortağınız olacaktır.

Bunun yanında proje sonunda, projeye özel bir retrospektif yapmanız ileride proje boyunca yaptığınız hataları tekrarlamamanız için önemli.

Böylece bir projenin başından sonuna kadar tüm adımlarını ele almış olduk. Proje yönetimi becerisi, bir yazılımcının kariyerinde ilerlemesi için çok önemli bir yetkinlik. İleride başka bir yazıda da teknik tasarım dokümanından ve başka yöntemlerden bahsetmeye çalışacağım.

Bu yazıyla ilgili geribildirimleriniz varsa lütfen geribildirim formunu doldurmayı unutmayın! Aldığım geribildirim ve soruları yakında yazmaya başlayacağım yeni bir bölümde cevaplamaya çalışacağım!

Ayrıca, bu yazıyı önceden okuyup imla hatalarını bulan ve düzelten sevgili Şeyma Sağınç’a da ayrıca teşekkür etmek istiyorum!