Yazılım geliştirmede son teslim tarihleriyle barış imzalamak

Proje teslim tarihi...

Bir yazılım geliştiricisi olarak en büyük kabusun yoksa düşmanın mı demeliyim? Ne isim verirsen ver, sana kalmış.

Kabul et. Seni çok korkutuyor. Şimdi bile, bu cümleleri okurken tüylerinin diken diken olmasına sebep oluyor.

Nereden mi biliyorum?

Biliyorum çünkü ben de aynı şeyi hissediyordum. Ancak bu korku artık benim için geçmişte kaldı. Son teslim tarihleriyle barış imzaladım. Onları kucakladım.

Bunu size de öneririm. Onları kucaklayın, barış imzalayın. Bu onları yenmenin en etkli yöntemlerinden biri.

Tamam da, bunu nasıl yapabilirsin?

İşler son teslim tarihini belirlemeye gelince, görmezden gelme eğiliminde olduğumuz bir takım gerçekler var. Benim buradaki amacım, son teslim tarihleriyle ilgili endişelerinizi bir kenara bırakıp, yetiştirememe korkunuzun üstesinden gelerek, projeniz üzerinde çalışırken keyif almanızı sağlamak için bir kaç yöntem göstermek.

Sakin bir ortamda çalışın

Acele etmeyin. Hiçbirşeyi zorlamayın.

Öncelikle şunu bilmelisiniz ki, gerçekçi olmayan tarihler belirleyip, takımınızı telaş ve baskı altında çalışmaya zorlayarak projenizi geliştirirken huzur bulamazsınız. Büyük laflar edip, gerçekçi olmayan şeyler göstererek takımını motive etmeye çalışan yöneticiler var. Fakat takımdaki herkesin açıkça görebileceği bir takım gerçekler varken, gerçeklikten uzak, tutturulması zor hedeflere herkesin inanmasını nasıl bekleyebilirsiniz?

Sabit, en önemlisi de inanılabilir makul bir teslim tarihi belirlemeden sakin bir şekilde çalışmak neredeyse imkansız. Evet, sakin kalmak burada anahtar nokta. Belirlenen tarihe güvenmediğiniz zaman, veya birisi size limitli bir zaman aralığında herşeyi yapmanızı söylediğinde, veya proje geliştirme aşamasında size gerekli ek zaman verilmeden projeye yeni görevler eklendiğinde manyakça çalışmaktan başka bir çareniz yoktur. Bu artık bir iş olmaktan çıkar. Cehennemin ta kendisidir.

Baskı ve stress altındayken üretken olamazsınız. Sakin kalmayı başardığınız da düşünceleriniz üzerinde kontrol sahibi olursunuz ki bu da size daha sağlıklı kararlar verebilmeniz de yardımcı olur.

Tahminlerimiz berbattır

Windows kullanıcıları bu pencere diyaloğunu hatırlayacaklardır. Penceredeki tahmini kalan süre tıpkı bizim tahminlerimiz gibi değil mi?

Hadi kabul edelim. Tahmin etme yeteneğimiz tam bir felaket. Birşeyin ne kadar zaman alacağını tahmin edebileceğimizi düşünürüz. Ne tahmin edersek edelim bunun doğru olacağına inanma eğilimindeyizdir (aslında kendimizi kandırıyoruzdur).

Ancak, genellikle, bir tahminde buldunduğumuz zaman, tahminimizi etkileyecek bazı önemli faktörleri görmezden geliriz. Neden? Çünkü çok iyimseriz.

Bana göre, son teslim tarihleri ile barış imzalayıp, tarihleri belirlemede daha iyi bir duruma gelebilmek için ilk adım, tahmin etme yeteneğimizin berbat olduğu gerçeğini kabullenmektir. Bu gerçeği kabullendiğiniz zaman, gelecek sefere daha bilinçli olacak ve bu da sizi proje gereksinimlerini küçümseme hatasından koruyacaktır. Tahmin etmede daha iyi bir duruma gelebilmek için bir çözüm:

Büyük görevleri daha küçük görevlere bölün. Görevler küçük oldukça, onları tamamlamak için gereken süreyi tahmin etmek de kolaylaşacaktır. Bu sizin daha doğru tahminlerde bulunma şansınızı arttıracaktır.

Yeterince iyi iyidir

"Mükemmellik iyinin düşmanıdır." -Voltaire

İnsanlar büyük zorlukları sever. Basit problemlere karmaşık çözümler bulmada üstümüze yoktur. Fakat şöyle bir gerçek var ki:

Her problemin muhtemelen görmezden geldiğiniz basit bir çözümü vardır.

Mükemmel çözümler peşinde koşmayın. İlk versiyonunuz mükemmel olmak zorunda değil. Çalışan ve görevini yerine getiren yarım bir ürün geliştirin. Eğer çok beklerseniz; zaten limitli olan kaynaklarınızı ve kıymetli zamanınızı boşa harcayacak ya da son teslim tarihini kaçırma riski ile karşı karşıya kalacaksınız. Daha da kötüsü, mükemmelin peşinden koşarken ortaya hiçbirşey çıkaramayacaksınız. Çözüm:

Size en az çaba ile en yüksek değeri getiren çözümü bulun. Ve unutmayın ki iyi daha sonra mükemmele dönüştürülebilir.

İyimserliği gerçeklikle harmanlayın

Takımlarını bu işin kısa bir sürede bitebileceğine inandırarak onları motive etmeye çalışan aşırı iyimser yöneticiler görüyorum. Bu çok yanlış. Gelecekle ilgili kötümser olmanız gerektiğini söylemiyorum. Tam tersine, size dar boğaz yaratabilecek her bir ihtimali göz önünde bulundurmanız gerektiğini söylüyorum. Bu olasılıkları görebildiğiniz zaman, onları da göz önünde bulundurarak daha doğru tahminlerde bulunabilirsiniz.

Bir şirkette aynı proje üzerinde çalışan birden fazla takım vardır. Mühendisler, iş geliştiriciler, pazarlama vs. İş geliştirme takımı müşterilerin isteklerini öne sürerek sizi yakın bir tarih vermeye zorladığında onlardan etkilenmemelisiniz. Onlar sadece kendi işlerinin mümkün olan en kısa sürede bitirilmesini isterler.

Her takımın kendi tarafını düşündüğünü unutmayın.

"Yapmak zorunda olduklarınız", "yapılabilcekleriniz" ve "yapmak istedikleriniz" arasındaki ayrımı iyi yapın

Burada anlama anahtar kelime. Ürününüzü piyasaya sürmek için gerekli olan ana gereksinimler nelerdir? Genellikle, ürün ekibi bunları ayırmada zorluk yaşar.

Toplantıda takım üyerlerinden biri "Bu özelliği geliştirebiliriz, bize şu ölçüde katkı yapacaktır" veya bir diğer takım üyesi "Bu özelliği de yeni versiyona koyabiliriz" gibi önerilerde bulunabilirler. Fakat onlar kendi perspektiflerinden bakarlar. Tamam, bunu geliştirebiliriz  ve bize belli bir ölçüde değer getirebilir fakat asıl önemli soru şudur: "Buna gerçekten şimdi mi ihtiyacımız var?"

Çoğu durumda cevap HAYIR'dır.

Yapmak zorunda olduklarınız asıl odaklanmanız gerekenlerdir. Yapılması iyi olurdu diye düşündükleriniz ve yapmak istediklerinizi elemelisiniz. Çoğu durumda bunlar pazarlık konusu bile olmamalılar.

Varsayılan cevap HAYIR olmalı

Birşeye "Evet" derken çoğu zaman unuttuğumuz önemli bir gerçek var: Bitirmek zorunda olduğumuz diğer görevlere (asıl önemli olanlara) "Hayır" deriz.

Yeni birşeye evet dediğimiz zaman, hali hazırda üzerimizde olan görevlere gelecekte nasıl bir etkisi olacağını düşünmeyiz.

"Teslim tarihini belirledik fakat bu görevleri eklemeyi unutmuşuz. Hadi bu görevleri de ekleyelim." HAYIR (Projeye eklemeler zamanla azalmalıdır, çoğalmamalıdır.)

"Fark yaratan şeylere odaklandık. Tamam. Peki ya detaylar? Hadi ürünümüzü daha mükemmel hale getirecek küçük detaylar üzerine konuşalım." HAYIR. (İlk versiyon gereksiz detayları görmezden gel. Geleceği tahmin etmeye çalışma.)

Buradaki problem diğer şeyler için daha fazla zaman bulabilmek değil. Asıl problem yapılacak çok fazla şeyin olmasıdır. "mutlaka yapılması gerekenler" ve "olsaydı iyi olurdu" dediklerimiz arasındaki ayrımı iyi yapmalıyız.

Daha fazla iş bitirmenin tek yolu daha az bir yapılacaklar listesine sahip olmaktır.

Son teslim tarihini asla değiştirme

Yazılım geliştiricilerin ürün geliştirme sürecini etkileyebilecek kötü bir alışkanlıkları var: Son teslim tarihini tekrar tekrar değiştirmek.

Son teslim tarihini kaçırdıkların da, yeni bir tanesini tanımlıyorlar. Eğer bunu da kaçırırlarsa, yeni bir tane daha... Bunu tekrar tekrar yaptıklarında da bu kötü bir alışkanlığa dönüşüyor. Daha sonra bu kötü alışkanlık onların kültürlerinin bir parçası haline geliyor. Şirketteki diğer takımlar yazılım geliştirme ekibine olan güvenlerini kaybedip yaptıkları işi sorgulamaya başlıyorlar. Daha da kötüsü, yazılım geliştirme ekibinin kendisi de birbirlerine olan güveni kaybedebiliyorlar.

Son teslim tarihini değiştirmek temelde bir başarısızlığın kabulüdür. Tarihi değiştirmek ile aslında söylenen şudur: "Gereksinimleri planlamada başarısız olduk. Yeteri kadar "hayır" diyemedik. Asıl fark yaratacaklara odaklanamadık. Ekibimizi makul olmayan zaman aralığında makul olmayan şeyler yapmaya zorladık."

Birşeylerin her zaman ters gideceğini unutma

Çok fazla iyimserlik birşeylerin ters gideceği gerçeğini görmezden gelmeye neden olabilir.  Farkında ol. Muhtemelen birşeyler ters gidecek. Ve bu da senin birşeyleri düzeltmek için zaman kaybetmene neden olacak. Yani bu gerçeğin farkında olarak proje teslim tarihini tanımlarken bunun da hesaba katılması gerekiyor. Kötümser olup, geleceği tahmin etmeye çalışarak kendini ve ekibini bilinmeyen için hazırlaman gerektiğini söylemiyorum. Sadece iyimserlik ve kötümserlik arasındaki dengeyi bul. Gerçekçi ol.

Tecrübeme göre yazılım geliştirmede birşeyler her zaman ters gitme eğiliminde. Bunun için işimizi kış tutmakta fayda var:

Son teslim tarihini tanimlerken birşeylerin ters gideceğini hesaba kat ve bunun düzeltmelerini de göz önünde bulundurarak ek zaman ekle.

Projeye daha fazla insan kaynağı ekleyerek süreci hızlandırabileceğini düşünme

Bir çok yazılımcı hala eğer projeye yeni yazılımcılar eklerlerse süreci hızlandırabileceklerini düşünüyorlar. Ancak, çok önemli bir noktayı kaçırıyorlar. Brooks yasasını bir hatırlayalım:

Geciken bir projeye daha fazla insan kaynağı eklemek projenin yavaşlamasına ve daha da fazla gecikmesine neden olur.

Wikipedia'da Brooks yasasına göz attığımız zaman, bir projedeki artan kişi sayısı projenin bitirilmesi için gereken zamanı azaltmaz aksine arttırır. Peki bu neden böyle olur?

• Projeye dahil edilen yeni insan kaynaklarının üretken olmaları zaman alır. Onları ilk önce eğitmek zorunda kalırsınız. Zaten kısıtlı olan insan kaynağını da yeni gelenleri eğitmek için harcamak zorundasınızdır. Ayrıca yeni oldukları için, yeni hataların ortaya çıkmasına neden olurlar ve projenin tamamlanmasını yavaşlatırlar.
• Kişi sayısı arttıkça iletişim giderleri de artar.
• Bir otel odasını temizlemek gibi yüksek bölünebilirliğe sahip görevlere daha fazla kişi eklemek genel anlamda görevin daha çabuk bitmesini sağlayabilir. Fakat, özel uzmanlık gerektiren yazılım projelerindeki görevler daha az bölünürlüğe sahiptir. Üstad Brooks'un buna çok güzel bir örneği var: Bir kadının bir bebeği dünyaya getirmesi için 9 ay gibi bir süre gerekirken, 9 kadın bir bebeği 1 ayda dünyaya getiremez.

Richard Dalton'un bu konu üzerine isabetli sözleri var:

"Takımlar değişmezdir. Takıma yeni biri eklendiğinde veya takımdan bir kişi ayrıldığında, ortaya çıkan değişen bir takım değil yeni bir takımdır." -Richard Dalton

Erteleme! Çabuk karar alma alışkanlığını kazan

Ne demek istediğimi anlamanıza yardımcı olmak için bir örnek vereyim. Daha önce çalıştığım yerde ürün geliştirme toplantısındaydım. Ürüne yeni eklenecek özellik için son teslim tarihini belirlemeye çalışıyorduk. Hangi görevlerin bizim için öncelikli olduğu ve onları daha verimli bir şekilde nasıl geliştirebiliriz diye konuşuyorduk.

Zamanımızın çoğunu tartışarak harcadığımız bir görev vardı. Bu görevi geliştirmek için 3 muhtemel yol vardı ve nasıl olduysa biz karar vermede takılıp kalmıştık. Seçimi yapıp bir sonrakine geçemedik çünkü yazılımcılar geleceği tahmin etmeye çalışıyorlardı. "Ya böyle olursa, ya şöyle olursa" diye başlayan cümleler vardı.

Geleceğin sana neler getirebileceğini tahmin edemezsin. Kendini bilinmeyen için aşırı bir şekilde hazırlamaya çalışma.

Burada büyük teknik bir karar vermekten bahsetmiyorum. Tabi ki eğer ürünün kaderini etkileyecek ana özelliklerle ilgili karar vermeye çalışıyorsak bunun üzerine yatıp beynimize düşünmesi için gerekli zamanı verdikten sonra karar vermeliyiz. Fakat küçük detaylarda da çok fazla zaman harcayamayız. Kesin olmayan şeyler toplantı sayısını arttırır ve ilerlemenin önünü tıkar.

Erteleme! Karar ver ve ilerle.

Zihniyetimizi "Hadi bunun üzerine düşünelim"'den "hadi karar verelim"'e doğru eğitmemiz gerekir. Alınan her karar ilerlemeyi hızlandıracaktır. Birşeye karar verildiğinde, bu takımdaki herkes için net olacaktır. Herkes ne yapılacağını ve yapılması gerektiğini bilecektir.

İletişim: Dar boğazın nerede olduğunu anla

Herşeyi planladın. Ne yapılacağına ve neye odaklanılacağına karar verdin. Tam olarak ne kadar zaman gerektiğini biliyorsun. Yani son teslim tarihi kesinleşmiş oldu. Peki bu yeterli mi?

HAYIR.

Daha önce bahsettiğim gibi, birşeyin ters gitmesi her zaman ihtimal dahilinde olmalı. Takım üyeleri onlara atanan görevler üzerinde çalışırken, bloklanabilirler. Birşeyler onları durdururak görevlerin zamanında bitirilememesine neden olabilir. Darboğazın ne olduğunu zamanında görmen ve onun ne olduğunu anlayıp çözüm üretmen gerekiyor.

İletişim burada anahtar nokta. Takım sürekli senkron tutulmalı. Bazen takım üyeleri bir kutunun içine girebilirler ve o kutunun dışında neler olup bittiğinin farkında olmayabilirler. Bu bir takım lideri olarak senin sahne alacağın yerdir. Dar boğaz tespit edilir edilmez, en uygun çözüm bulunarak ortadan kaldırılmalıdır ki takım üyeleri takılıp kaldıkları yerden çalışmaya devam edebilsinler.

Tüm projelerinizi belirlenen zamanda teslim etmenizi dilerim:)

Sağlıcakla kalın.