Yazılım Projelerinde Belirsizliklerle baş etmek

Basit bir kaç yöntem ile belirsizleri nasıl yönetebiliriz?

Nasıl bir haftaydı öyle!? Geçtiğimiz hafta “Yazılımcılıkta Kariyer Yolu” e-kitabını yayınladım. Öncelikle gelen tüm iyi tepkiler ve yapıcı eleştiriler için çok teşekkürler! O kadar güzel yorumlar ve yerinde eleştiriler aldım ki, sayenizde çok şey öğrendim. Bunun için teşekkür ederim! Eğer hala okumadıysanız, bir yazılımcı olarak kariyerinizi şekillendirmenize yardımcı olacak e-kitabı abone olarak ücretsiz bir şekilde indirebilirsiniz!

Geçen hafta duygusal olarak inişler ve çıkışlarla doluydu! Ne yazık ki aralarında yerli gururumuz Getir’in de olduğu bir çok firmadan kötü haberler aldık.

Mert Susur 🪁 @MertSusur

Bu hafta küçülmeye giden firmalar ve işten çıkartılan eleman sayıları.

İçinde bulunduğumuz global kriz hepimizi bir şekilde etkiliyor ve gelecek 18 ay boyunca etkilemeye de devam edecek gibi duruyor. Neyse şimdi kötü haberleri bırakalım.

Bu hafta sizlerden gelen sorulardan birini yanıtlamaya çalışacağım. Bundan sonra iki haftada bir bunu yapmaya devam edeceğim, eğer sorularınız varsa bu formdan ya da gelen mail üzerinden cevap vererek bana ulaşabilirsiniz!

Henüz senior değilim senior ile mid lvl arasında bir konumdayım. Bir startup’ta çalışıyorum ve yeni bir projeye başladık. Açıkcası projeyi tamamen benim kodlamamı bekliyorlar ben bu yazıda bahsettiginiz kolay yerlerden başladım. Çünkü diğer yerler tam olarak netleşmedi ve bundan kaynaklı da ben bir hayli huzursuzluk duyuyorum. İşlerin hangi detayda açılacağından tutun da anlatılan bir özelliğin nasıl olması gerektiğine kadar benden beklentileri var. Bu kısmı nasıl yönetmem gerektiği noktasında tecrübe ve bilgi eksikliğim var. Bu konuda neler önerebilirsiniz okumak/dinlemek isterim.

Soruyu soran okuyucunun da dediği gibi daha önce Yazılımcılar için proje yönetimine giriş ve Ne zaman biter sorunsalı makalelerinde bu konuya değinmiştim. Oradaki önerim projeye başlamadan önce risk analizi yapıp, sonrasında da belirsizliklerin üzerine giderek projeye başlamaktı. Ama yazılarımda bunun detaylarına çok fazla eğilmemiştim. Gelin şimdi projenin analizi konusunu biraz tartışalım.

Nasıl başlarım?

Bir projeye başlamadan önce yapılması gereken bir kaç tane önemli adım var. Kimi zaman firmanız size “Bu proje yapıla!” diye üstten bir emirle geliyor olsa bile eğer bir ürün geliştiriyorsanız bu adımı pas geçmemelisiniz. Peki nedir bu adım?

Günün sonunda projeyi oluşturan üç önemli soru var;

1. Neden yapacağız?

2. Ne yapacağız?

3. Nasıl Yapacağız?

İşte buradaki ilk iki sorunun cevabı genellikle ürün yöneticisinden, eğer küçük bir firmada çalışıyorsanız da firmanın CEO’sundan ya da CTO’sundan geliyor olabilir. Bunları cevaplamak onların sorumluluğunda olsa da doğru soruları sormak yazılımcının sorumluluğundadır. Bu süreci iyi atlatabilmek için amansızca ve cevapları çok iyi anlayana kadar soru sormalısınız. Eğer bunları çok iyi anlarsanız, sizin cevap vermeniz gereken üçüncü sorunun sorumluluğunu çok iyi üstlenirsiniz. Aşağıdaki örneği ele alalım;

Ürün yöneticiniz (ÜY) takıma geldi ve aşağıdaki gibi bir açıklama yapmaya başladı:

ÜY: Dün öğlen Aysel Hanımla (CEO) konuştum, müşterilerin bilgilerini hızlı bir şekilde güncelleyebilmesi için böyle bir özellik eklememizi istedi.

Şimdi bu emir yukarıdan gelmiş bile olsa, işi yapacak takımın sorması gereken sorular var.

Bunlar:

• Neden müşterilerin bilgilerini hızlı bir şekilde güncellemesi önemli?

• Bunu yaparak müşterilerin hangi problemini çözüyoruz?

• Elimizde bunun önemli olduğu ile ilgili nasıl bir veri var?

• Bu özelliği eklememiz uzun vade stratejimizde nereye oturuyor?

• Bu özelliği eklersek nasıl bir etki yaratmasını bekliyoruz? Hangi KPI’lar bundan pozitif ya da negatif etkilenecek?

• Bu özelliği eklersek bunun başarılı olduğunu nasıl ölçeceğiz? Hangi KPI’yı ne kadar arttırmak istiyoruz? O artışın o şekilde olacağını nasıl ölçtük?

• Bu özelliği eklediğimizde istediğimiz etkiyi yaratmazsa ne yapacağız?

• Bunu neden 6 ay sonra değil de şimdi yapıyoruz?

• Bu daha önce ortada yoktu, ne değişti de şimdi bunu yapıyoruz?

Fazla gibi geliyor değil mi? Ama aslında değil. Çünkü günün sonunda bu projeyi siz gerçekleştireceksiniz ve bu yüzden de sizin bu problemi en iyi şekilde anlamanız gerekiyor. Bunları sormaktan çekinmemelisiniz. Bazı sorularınızın yanıtları olmayabilir, bu tamamen normal. Bu sorulara cevap alamazsanız işi yapmıyoruz diyemezsiniz. Ama burada önemli olan soruyu sormak için değil, anlamak için soruyor olmanız.

Bunları anladıktan sonra bunun yan etkilerini araştırmanız ve incelemeniz gerekecektir. Çoğu ürün geliştirme ekibi bu noktadan sonra hemen geliştirmeye başlar. Ancak bu bence yapılacak en büyük hatadır. Bunun için benim önerdiğim iki önemli adım var. Bu iki adımı yerine getirirseniz güzel bir planlama aşaması atlatmış olursunuz.

Bu adımlar:

1. Ürün kick-off Toplantısı

2. Teknik kick-off Toplantısı

Ürün kick-off toplantısı

Bu toplantının amacı ekibin sorunu anlaması ve isterlerinden eksik olanlarının belirlenmesi. Bu toplantıda bütün sorulara cevap bulmak zorunda değilsiniz, ama neleri bildiğinizi ve bilmediğinizi, bilmediğiniz şeylerin de ne kadar önemli olduğunu anlamanız gerekli. Böylece toplantıda elle tutulur bir aksiyon planı çıkartabilirsiniz. Aynı zamanda bu noktada takımın başka ekiplere bağımlılıklarını bulmaya çalışmak da faydalıdır.

Bu toplantı üzerine yazılımcılar bir plan yapar ve bir proje planı hazırlamak için çalışmaya başlarlar. Bu noktada bir proje lideri belirlenirse iş sahipsiz kalmaz ve hızlı ilerler. Bu proje liderinin yazılımcı olması firmanın başarısı ve işin kalitesi için önemlidir.

Teknik kick-off toplantısı

Bu toplantının amacı proje planını konuşmak, farklı çözüm opsiyonlarını ve işin nasıl geliştirileceğini tartışmaktır. Proje lideri toplantının sonuna kadar bir karar aldırmakla sorumlu olmalıdır. Kararları o vermese de ekibin arasındaki tartışmaları doğru hedefte tutmalı ve sonunda bir aksiyon planı yaparak geliştirmeye başlamalıdır. Eğer bilinmezlikler varsa onlarla ilgili “Spike” ya da “Proof of Concept (PoC)” gibi çalışmalar planlanmalı, böylece iş yapılmalıdır.

Yazılımcıların vereceği proje planı kararında milestone’lar ve iterasyonlar belirlenmeli ve açıkça konuşulmalıdır. Böylece ekibin ne şekilde geliştirme yapacağı da ortaya çıkmış olur.

Bu aşamalar doğru atlatılırsa, ekibin elinde aşağıdaki çıktılar belirlenir.

• Olası riskler

• Bir yol haritası

• İterasyonlar ve milestone’lar

• Belirsizliklerin bir listesi

Proje planında ilk aşama, belirsizlikleri mümkün olduğu kadar azaltmak olmalıdır. Örneğin yeni bir servis geliştiriyorsanız, “Walking skeleton” modelini kullanarak ilk başta boş bir projeyi Dev, Staging, Acceptance, Production ortamlarının hepsine deploy edip uçtan uca çalışacak şekilde başlayabilirsiniz, böylece projenin sonunda canlıya alırken sürprizle karşılaşmazsınız. Ya da bir entegrasyon projesinde ilk başta belki kullanmayacak olsanız bile o entegrasyonun olduğu noktadan başlamanız size avantaj sağlayabilir. Ya da bir başka örnek vermek gerekirse bir tabloyu oluşturmak için bir sürü yerden veri toplamanız gerekiyor olabilir, bu durumda belki de o veriyi toplamanın zorlukları olduğunu düşünüyorsanız küçük bir PoC yaparak bu belirsizliği ortadan kaldırabilirsiniz.

Milestone ve iterasyon planlarını oluştururken yapmanız gereken en önemli şey, bu iterasyonlar arasındaki zamanı çok fazla açmamanız. Örneğin 3 iterasyon belirlediyseniz ve aralarında ikişer ay varsa o zaman bir şeyi yanlış yapıyor olabilirsiniz. Çünkü 6 aylık yaptığınız plan kesinlikle 6 ay sürmeyecektir. Ya daha az -ki bu çok nadirdir, ya da çok daha fazla sürecektir. Bu da sizin projenizin başarısızlığı ile sonuçlanacaktır. Bunun yerine iki ya da en fazla üç haftalık iterasyonlar belirlemeye çalışmanız kontrolü sizin elinize verecektir.

Düzenli takip

Projelerde düzenli olarak takipte kalmanız hem ekibi doğru hedefte tutmaya hem de projede çalışan herkesi sürekli bilgilendirmeye yarayacaktır. Özellikle büyük ekipler varsa bu daha da önemlidir. Hatta belki bu gibi noktalarda verilen kararların tutulduğu bir Karar Log’u da tutmayı düşünebilirsiniz. Takip konusunda genelde ekiplerimde uyguladığım yöntemi aşağıdaki gibi özetleyebilirim:

• Her hafta ekip kendi içinde planları istediği şekilde gözden geçirir. Grup yöneticisi olarak ekipten iki beklentim olur: kendi içlerinde sorunları takip etmeliler ve sürekli sorunlardan bir şey öğrenmeliler. Bu iki sağlandığı sürece ister kanban, ister scrum isterlerse gulu gulu yaparak! süreci yönetebilirler.

• İki haftada bir, projesine göre belki üç haftada bir, ekip benimle kısa bir toplantı yapar ve ben ekibin bir yardıma ihtiyacı olup olmadığını kontrol ederim. Bu toplantı en fazla 10-15 dakika sürer. Öncesinde en fazla 3 cümle ile durumu wiki sayfasında güncellerler. Bazen toplantıya gerek bile kalmaz. Böylece neler oluyor bitiyor ve benim yardımıma ihtiyaçları olup olmadığını öğrenirim.

Eğer ekip geride kalıyorsa eminim iyi bir sebebi vardır. Ekibin geç kalması sorun değil, ama bunu anlatmaması ya da gerçekleşen risklerin farkına varmaması bence büyük bir sorundur. Bundan daha da büyük olan sorun ise ekibin bu hatadan bir şey öğrenmemesidir.

Yazının sonuna gelirken söylemek lazım, yazılım projelerini geliştirmek, liderliğini yapmak sürekli belirsizlikleri yönetmekten başka bir şey değil aslında. Bu belirsizlikleri nasıl yönettiğiniz ve ne zaman doğru kişilerden yardım istediğiniz projenin başarısını dramatik bir şekilde değiştirecektir.