Yazılım Projelerinde Karar Almada Ortamın Önemi

Yazılım Projelerinde Karar Almada Ortamın Önemi

Bu yazıma bugün yaşadığım ilginç bir deneyimi anlatarak başlamak istiyorum. Bugün izlediğim bir futbol maçında dikkatimi çeken bir forvet oyuncusu bulunuyordu. Bu oyuncu takımının yakaladığı fırsatları bir bir harcadı. Kale önünde, altı pas içinde topu kaleciye nişanladı, çektiği şutlar defans oyuncularına çarptı, verdiği paslar arkadaşlarına ulaşmadan rakipler tarafından kapıldı. Maçın bir bölümünde rakip takım korner kullandı. Kornerden dönen top, kornerin kullanıldığı köşeye geri dönerken bizim ünlü forvetimiz rakip takımdan birini takip ediyordu. O anda bu topun dönüp gol olacağını düşündüm. Çünkü bu adam tam bir başarısızlık abidesiydi ve ne yapsa takımına negatif bir şekilde geri dönüyordu. Eminim demek istemiyorum ama rakibi takip etmese ve rakip boş bir pozisyonda orta yapsa o top bence gol olmayacaktı. Bu topun gol olması rakibin şansı bizim forvetimizin şanssızlığı değildi. Buna eminim. Bizim forvetimiz dışarıdan bakıldığından elinden geleni yapıyor, çok çalışıyor, canını dişine takmış ve herşeyini veriyor gibi görünüyor. Tek birşey dışında bunları yaparken doğru yolu izlemiyor. Çünkü doğru kararlar veremiyor. Dahil olduğu her pozisyonda işleri daha da karışık hale getiriyor ve bunun sonucu da takımına olumsuz olarak geri dönüyor.

Bunları neden anlattım. Çünkü yazılım projelerinde görev alanlarda bu yaklaşımı sergiliyor. Tabi kişinin sahip olduğu role göre yaptığı etkide ortamda farklı oranda değişikliklere neden oluyor. Örneğin bir futbolcu hata yaptığında bu çok önemli olmayabilir ve hatadan geri dönülebilir. Hatalı bir pas verip topu rakibe kaptırabilirsiniz. Biraz sonra topu rakipten geri alabilirsiniz ve bu çok büyük bir sorun olmayabilir. Bu tıpkı bir yazılımcının test senaryoları üzerinden geçerken birini atlaması gibi geliyor. Fakat teknik direktör maçı kaybederken ve gol atması gerekirken bir forvet çıkarıp bir savunma oyuncusu alıyorsa çok ciddi sıkıntılar var demektir. Bırakın oyunu okumayı bu teknik direktör skor tabelasını bile okuyamıyor diye düşünebiliriz. Aynı şekilde bir projenin planlamasında yada ilerlemesinden sorumlu kişilerin aldığı aksiyonlarda böyledir. Bazen hepimizin içinden geçiyordur. Bu adam ne yaptığını bilmiyor dediğiniz olmuştur. Örneğin beş altı ay sonra geliştirilecek bir proje için gerekli bilgilerin şimdiden toplanması yada bir projede çalışacak kişilerin projenin geliştirilmesi için gerekli olan teknik ve ortam bilgilerinden eksik olması gibi.

Birkaç ay önce karşılaştığım bir durumdan kısaca bahsedeyim. .Net MVC, Bootstrap, Typescript gibi görece az kullanılan teknolojilerin kullanılacağı bir projeye başlayacağız. Projeyi gerçekleştirecek takım arkadaşlarımızdan yarısından fazlası bu teknolojileri bilmiyor ve hakim değil ve bunun için eğitim alınması gerekiyor. Projenin geleceğine karar veren kişinin alınması gereken bu eğitim için yorumu ne oldu dersiniz?

  • Bu projeden sonra burada olmayacak kişileri eğitime göndermenin anlamı nedir? Gerek yok!

Bu cevap çok ilginç ve çok saçma değil mi? Diyelim ki bu insanlar projeden sonra burada olmayacaklar. Peki ama gidebilmeleri için ilk önce projeyi geliştirmeleri gerekmiyor mu? Projeyi geliştirebilmeleri için teknolojileri bilmeleri gerek, değil mi? Böyle paradoks yaşatan sahneler gerçekten beni eğlendiriyor. Proje yönetimi, insan yönetim, kaynak yönetimi, maliyet yönetimi, adına ne derseniz deyin. Bence bu iş bilmeme yönetimi. Bu insanlar gerçekten bilmiyorlar ve düşünmüyorlar.

Özetle durum şöyle ki; yazılım geliştirme çok zor bir iş özellikle geliştirenlerin içinde işi bilmeyen ve verdiği kararlar ile bilinmeyenlerin sayısını bilinenlerin sayısından fazla kılan insanların olduğu projeler çok daha zor. Yaptığı hareketlerle, aldığı kararlarla ortamı karışıktan, karmaşığa, karmaşıktan kaosa sürükleyen insanlarla işlerin bitirilmesi gerçekten bir mucize. Umarım yolunuza, karşınıza böyle insan çok az çıkar daha çok iş bitiren insanlarla karşılaşırsınız 🙂

Karışık, karmaşık, kaos demişken bunları yazılım projelerinde nasıl kullanabiliriz. Nasıl iş bitiremeyen birinden iş bitiren ve yaptıkları takımına negatif değilde pozitif dönen biri olabiliriz. İlk önce bu terimleri öğrenerek başlayalım.

 

Karışık ve Karmaşık Ortamlar

Bu bölüme Karmaşık ve Karışık terimleri arasındaki farkı açıklayarak başlayalım. 2014 yılında katıldığım bir seminerde konuşmacı karmaşık ve karışık arasındaki farkı anlatmak için şu örneği kullandı.

  • “Aramızda saat yapabilen biri var mı?” diye sordu, doğal olarak 400 kişi içinde saat yapabilen hiç kimse yoktu. 🙂
  • Saat yapmak kesinlikle çok zor bir iştir fakat bunun için bir rehber verilirse yapabilirim. Trafik ise karmaşık bir yapıya sahiptir. Varmak istediğim noktaya varıp varamayacağımı yada ne zaman varabileceğimi bilmem mümkün değildir. Çünkü ben şeridimde sabit bir hızla hedefime doğru ilerlerken nereden geldiğini anlamadığım biri bana çarpabilir ve ben hedefime varamayabilirim. Benim dışımda bir kaza gelişebilir ve tüm trafiği kilitleyebilir. Yola çıktığımda hesapladığım süreden çok daha geç bir zamanda hedefime varmama neden olabilir. Karmaşık ortamlarda bilinmeyenler bilinenlerden fazladır.

Karmaşık ve karışık ortamlarda problemlerin çözümünü kolaylaştırabilmek için farklı yöntemler ve çerçeveler geliştirilmiştir. Bunlardan biride Ralph Douglas Stacey tarafından 1996 yılında geliştirilen Stacy Grafiği’dir.

Yazılım Projelerinde Karar Alma - Stacey Grafiği
Yazılım Projelerinde Karar Alma – Stacey Grafiği

Yazılım projesi doğası gereği karmaşık bir yapıya sahiptir. Projeyi geliştirecek kişiler, paydaşlar, son kullanıcılar, bunlar arasındaki iletişim, rakipler, ürünün geliştirilmesinde kullanılacak teknoloji, ürünün mimarisi, ürünün üzerinde çalışacağı donanım, projenin geliştirildiği organizasyonun yapısı gibi saymakla bitiremeyeceğimiz birçok değişken bulunmaktadır. Bu denkleme katılan her değişken sonsuz kadar bilinmeyenle denkleme dahil olur.

Geleneksel proje yönetimi ise bir projeye başlarken bilinmeyen herşeyi bildiğini varsayar, insanları birey değil kaynak olarak görür – burada insanların değiştirilebilir olduğunu, Ali’nin yerine Mehmet’i koyarsam aynı birim zaman içinde aynı miktarda geliştirme yapabileceğini varsayar- ve böyle başlar. Bu nedenle projenin analiz adımı bitip geliştirme adımı başladığında projenin başarısız olacağı düşünülmeye başlanır. Çünkü hiç düşünülmeyen ve analiz dokümanında yer almayan gelişmeler yaşanmaktadır. Bu nedenle geleneksel proje yönetimi ile yönetilen projeler başlamadan hemen önce Stacey Grafiği’nde anlaşmaya yakın ve kesinliğe yakın eksenlerinin sıfır noktasında yer alırken proje başladıktan sonra bu eksenlerin sonsuz uçlarına yani kaos ortamına doğru ilerler.

 

Çevik yazılım geliştirme ise deneyciliğe dayanır. Deneycilik bilginin tecrübeden geldiğini söyler ve tecrübe olmadan karar alma işinin gerçekçi sonuçlar doğurmayacağını belirtir. Kaosun bulunduğu yada karmaşık bir ortamda ürün geliştiriyorsanız ortam hakkında tecrübe edinmeden karar almak görmediğiniz bir darta ok atmak gibidir. Şansınız yaver giderse hedefi vurabilirsiniz ki çoğu zaman şansınız yaver gitmez. Öte yandan kısa döngüler halinde geribildirimler alarak ve vererek bulunulan ortam hakkında bilgi edinilebilir. Çevik yaklaşımlar ise yazılım projelerine başlarken Stacey Grafiği’nde karmaşık alanda olduğunu varsayar ve bilgi edindikçe karışık ve basite doğru ilerlemesi sağlanır. Yani zaman geçtikçe projede yapılacak geliştirmeler hakkında ön görülebilirlik artar.
Karışık sistemleri, çevreleri anlamak için genellemeler, indirgemeler kullanılabilirken, karmaşık sistemleri, çevreleri anlamak için kullanılamaz. Karmaşık ortamları anlayabilmek için gözlem ve adaptasyon gereklidir. Gözlem ve adaptasyonun olduğu her geribildirim döngüsüyle basit ortama ulaşılmaya çalışılır. Karmaşık ortama sahip yazılım projelerinin başarılı olma şansı yükseltilmiş olur.

Stacey Grafiği
Stacey Grafiği

Stacey Grafiğini kısaca yorumlamak istiyorum. Grafiğe göre x ekseni teknolojiyi göstermektedir. Yine bazı Stacey Grafikleri’nde teknoloji yerine insan olarakta gösterilir, x ekseni. Sıfır noktasına yakın bölümü projeyi gerçekleştirecek kişilerin teknolojiyi çok iyi biliyorlar diye yorumlanır. Y ekseni ise projenin kapsamı yada geliştirilen ürünün ne yapması gerektiğine dair olan bilgidir. Buna göre ürünü hayata geçirecek kişiler ne yapılması gerektiğini biliyorsa – y ekseni – ve nasıl yapılması gerektiğini biliyorsa – x ekseni- bu basit bir çevre, ortam olarak nitelendirilir. Eğer ürünün geliştirileceği teknoloji hakkında kişilerin bilgisi yoksa bu x ekseninde sıfırdan sonsuza doğru bir artış demektir ve basitten karışığa daha sonra ise karmaşığa doğru yol alınır. Aynı şekilde projenin kapsamı -ürünün gerçekleştireceği fonksiyon- sürekli olarak değişiyor ve anlaşma sağlanamıyorsa yine önce karışık daha sonra ise karmaşık ortama girilmektedir. Eğer hem teknoloji bilinmiyor hem de projenin kapsamı bilinmiyorsa anarşiye yani kaosa doğru ilerlenmektedir. Burada kararlar sürekli olarak değişebilir ve ilerleme sağlanması çok zordur. Bu nedenle bazı sabitler kullanmak faydalıdır.

Stacey Grafiğine geliştirdiğimiz projenin hangi ortama denk geldiğine karar vermek ve alacağımız kararlarda bundan yararlanmak çok faydalı diye düşünüyorum. Umarım faydalı olur. 🙂

 

Resim 1 : http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm

Resim 2 : http://noop.nl/2008/08/simple-vs-complicated-vs-complex-vs-chaotic.html

7586total visits,7visits today

Leave a Reply

Your email address will not be published. Required fields are marked *