İŞÇİ-HAVUZ PROBLEMLERİ

İŞÇİ-HAVUZ PROBLEMLERİ

Yazının başlığından da anlaşılabileceği üzere bu yazıda ilköğretim günlerimize doğru bir yolculuğa çıkacağız.

Neydi bu işçi-havuz problemleri denen konu? Kısaca hatırlayalım.

Bir işi; A işçisi tek başına x saatte yapabiliyorsa A işçisi 1 saatte işin 1 / x ‘ini bitirir. Benzer şekilde A musluğu bir havuzun tamamını y saatte doldurabiliyorsa 1 saatte havuzun 1 / y ‘sini doldurur. Eğer birden fazla işçi veya musluk varsa her birinin birim zamanda gösterdiği performanslar toplanır ve istenilen sonuca ne kadar sürede ulaşılacağı hesaplanır.

Gerçek dünyada biz bu çözümü nasıl kullanırız?

Yapılmasını istediğimiz iş net bir şekilde tanımlanmışsa ve iş bölünebilir (birden fazla kaynağın eş zamanlı olarak çalışabileceği) nitelikte ise ilgili işin hedeflenen tamamlanma zamanına göre kaynak tahsisi (resource allocation) yaparız. Acelemiz yoksa 1 işçi veya 1 musluk kullanırız, işin hızlı bir şekilde bitmesini istiyorsak sürece işçi veya musluk ekleriz. Çünkü yapılacak iş net bir şekilde tanımlanmıştır, belirsizlik düşüktür, muslukların ve işçilerin performansları fazla dalgalanma göstermemektedir. Bu koşullar çözümümüzün (planımızın) kusursuz bir şekilde çalışmasını garanti altına alır.

Peki bu bilgileri neden hatırlama ihtiyacı duyduk?

Tipinden (kamu, özel sektör, kar amacı gütmeyen) ve faaliyet alanından bağımsız olarak organizasyonların çoğunun yazılım projelerine işçi-havuz problemleri gibi yaklaştıklarını görüyoruz. Organizasyonlar yazılım projelerini net bir şekilde tanımlanmış ve bölünebilir nitelikteki işlerin toplamı (analiz, geliştirme, test) olarak ele alıyor ve bilgi teknolojisi çalışanlarına bir havuzu doldurmaya veya bir duvarı örmeye çalışan kaynaklarmış gibi davranıyor.

Oldukça yaygın olan bu yaklaşımın temel nedeni ise yazılım projelerinin inşaat projelerinin yönetiminde kullanılan proje yönetim metodolojisi ile yönetilmeye çalışılıyor olması. Diğer bir deyişle, yazılım dünyası halen işçi-havuz problemi çözmeye çalıştığını sanıyor. Hemen hemen tüm yazılım projelerinin planlanması aşamasında kullanılan “adam/gün” kavramı da konunun bu şekilde algılandığının ve çözümlerin bu bakış açısı ile üretildiğinin açık bir ispatı olarak karşımıza çıkıyor.

Peki gerçekte durum nasıl?

Yazılım projeleri özünde, birbirleri ile güçlü etkileşim içerisindeki oldukça fazla sayıda kararın alınmasından ve hayata geçirilmesinden ibarettir. Yazılım projeleri, duvar örmek veya bir havuzu doldurmak gibi basit fiziksel aktivitelerden oluşmaz; bilgi toplama, analiz etme ve karar verme gibi mental aktivitelerin yoğun olduğu kompleks bir süreçtir. Bu süreçte alınan her karar çıktıyı etkiler. Dolayısıyla bu projelerinin başarılı olabilmesi için proje ekibinin kollektif olarak sürekli doğru kararları alıyor olması gerekir. Geleneksel yaklaşımla yönetilen yazılım projelerinde testler sürecin sonunda yapıldığından bireyler proje süresince aldıkları onlarca kararın sonucu nasıl dramatik bir şekilde etkileyebildiğini pek fark edemezler. Çünkü kararları alma zamanı ile çıktıya ulaşılma zamanı arasında oldukça büyük bir fark vardır.

Yazılım projelerini işçi-havuz problemi olarak ele almaya devam etmek istiyorsak bakış açımızı değiştirmemiz ve problemi şu şekilde görmeye başlamamız gerekir:

Bir tatil köyünün havuzunun içerisinde yer alan musluklar havuzu hem doldurabilme hem de boşaltabilme özelliğine sahiptir (proje ekibi doğru karar alabileceği gibi yanlış kararlar da alabilir). Ayrıca musluklar stabil bir şekilde çalışmamaktadır. Musluklar bazen hızlı bir şekilde havuzu doldurmaktadır, bazen yavaşlamaktadır, bazen de havuzu boşaltmaya başlamaktadır. (İnsanlar her gün aynı sayıda doğru karar alamayabilirler. Hatta bazı günler yanlış kararlar alıp hedeften uzaklaşılmasına neden olabilirler.) Ayrıca tatil köyünün yönetimi deniz suyu ile mi yoksa tatlı su ile mi doldurması gerektiği konusunda ikilemdedir. (Talep sahipleri genellikle beklentilerini net bir şekilde ortaya koyamazlar veya zaman içerisinde fikirlerini değiştirirler.)

Çözülmeye çalışan problemi bu şekilde düşündüğümüzde havuzu doğru su ile verimli bir şekilde doldurabilmek için deneysel bir yaklaşım kullanılmalıdır. Süreç içerisinde talep sahibine sık sık çalışma sonuçlarının sunulması ve onların geri bildirimlerine göre yeniden bir strateji belirlenmesi gereklidir. Musluklar havuzu doldurmak yerine boşaltmaya başlarsa; durumun hemen tespit edilip düzeltici müdahalelerin yapılması gerekir. Bunun için muslukların davranışlarının sürekli olarak izlenmesi ve doğru bir şekilde çalıştıklarından emin olunması gereklidir. (Hedef ile uyumsuz kararlar alınmaya başladığını görebilmek için geliştirme faaliyetlerinin sürekli monitör edilmesi gerekir. İş birimleri ile geliştirme takımları bu nedenle bir arada çalışmalıdır. Hedeften şaşıldığı anda düzeltici müdahale gelmelidir. Geliştirme süreci sıkı bir şekilde takip edilip, düzeltici müdahaleler yapılmazsa hedefe ulaşılma ihtimali düşüktür.)

Bir sebebten dolayı havuzu boşaltmaya başlamış muslukları tekrar “doldurma” moduna geri döndüremiyorsak musluğu tamamen kapatmamız daha doğru bir yaklaşım olacaktır. Bu sayede en azından o ana kadar havuza doldurulmuş suyun kaybedilmesini engellemiş oluruz. (Yanlış kararlar almaya başlamış insanları doğru karar alır hale getiremiyorsak, bir süre hiç karar almamalarını sağlamak daha doğrudur.)

Özetle karar yoğun olan yazılım projelerini klasik işçi-havuz problemi gibi ele alarak çözmek doğru bir pratik değildir. Bireylerin kararlarının ve bunların birbileri ile olan etkileşimlerinin son derece önemli olduğu böyle bir süreçte proje ekibinin aldığı kararları talep sahipleri ile beraber sık sık gözden geçirmesi ve işlerin yolunda olduğundan emin olması gereklidir. Ayrıca, bilgi işçilerinin verimliliğini ve yazılım projelerinin başarısını arttırmak için bireylerin sürekli doğru kararlar alabilmelerine olanak sağlayacak, hatalardan kaçınmaları konusunda onları baskı altına almak yerine onları hata yapmaya ve bu hataları kısa sürede fark edip düzeltmeye teşvik edecek yönetim yaklaşımlarının kullanılması gereklidir.

Onur Özcan, Agile Team Coach, ACM