Bu karikatürü daha önce görmüşsünüzdür sanırım. Gerçek hayatta öyle örnekler yaşanıyor ki, karikatürdeki abartı hafif kalıyor diye düşünüyor insan.
Yazılım projelerinde tipiktir: Daha teklif aşamasından itibaren uzun analizler yapılır, raporlar yazılır; müşteri bu raporları onaylar, altına imza atar. Görsel tasarımlar yapılır, onaylanır. Ara prototipler gösterilir. Ne var ki, gün kabul günü olduğunda, müşteri istediği ürünün bu olmadığına karar verir. Proje yöneticisi tasarım raporlarının, toplantı tutanaklarının altındaki imzalara dikkat çeker; ama müşterinin daha güçlü bir argümanı vardır: Kullanamayacağı bir ürünü teslim almasının anlamı yoktur. Değişiklikler, ek bütçe ve zaman üzerinde tartışılır ve üretilenle ihtiyaç arasındaki mesafe çok fazla değilse bir hal yolu bulunur.
Yazılımın doğası gereği nihai ürünü gözünüzde canlandırabilmek, spesifikasyon oluşturmak kolay değil; ama bu sorunlu durumun yazılım projeleri ile sınırlı olduğunu sanmıyorum. Sipariş üzerine ürün hazırlanan çoğu ortamda, az veya çok, benzer sorunlar olsa gerek.
Yukarıda tarif ettiğim senaryoyu sürekli yaşamış olan biri olarak, olası nedenler ve çözüm yolları üzerine çeşitli fikirler duydum. Yazılımcılar, müşterinin ancak proje bitince ve nihai ürünü ilk defa kullanınca analize gerçekten kafa yormaya başladığını düşünürler. Onlara göre müşteri, ya tembellikten, ya da ihtiyacını tam dillendiremediğinden, analize gereği gibi katılmamış, ancak kabul günü geldiğinde dikkatini sürece tam olarak vermeye başlamıştır. Müşterinin görüşü ise farklıdır: Yazılımcılar, müşterinin ihtiyacının ne olduğunu anlayacak, onu yönlendirecek, hatalardan koruyacak uzmanlığa sahip olmalıdır. Nihai ürünün bazı yönlerinin gerçek hayatla bağdaşmadığı müşteri için o kadar açıktır ki, yazılımcıların böyle bir ürün üretebilecekleri aklına bile gelmemiştir.
Bu açmazı çözebilmek için iki yol denenir: Müşterinin önüne nihai ürünün taslaklarını olabildiğince hızlı ve sık getirip, onu sürece katmayı ve analizi sürekli teyit etmeyi, iyileştirmeyi öneren iteratif yöntemler işe yarar mutlaka. Diğer yol ise, projeyi bütçelerken hedeften bir miktar şaşma ve yeniden düzenlemeyi göz önüne alıp, zaman ve parayı buna göre belirlemektir.
Aşağıda linkini verdiğim makale, meseleye farklı bir açıdan bakmamı sağladı. Zorluk belki de ilk tanımın ne kadar doğru ve eksiksiz yapılıp yapılmadığı değil; bundan daha derin. Müşteri projenin bir sorununa çözüm olmasını istiyor. Bu amaçla tasarlamaya çalıştığı çözüm, analize dönüşüyor. Proje ekibi, bu çözümü tam ve eksiksiz gerçeklediğinde projeyi başarılı kabul ediyor. Ancak, projenin gerçekten başarılı olabilmesi için analize konu olan çözümü gerçeklemesi değil; müşterinin sorununu çözmesi lazım. Bu iki nokta arasında da kimi zaman küçük, kimi zaman büyük bir fark var.
Öyleyse bu açmazdan çıkabilmek için, projenin kurgusunu toptan değiştirmek, proje ekibine hayata geçirilecek bir çözüm tarifi değil, çözülmesi gereken problemi vermek gerek. Örneğin, ihtiyaç stok maliyetini %10 düşürmekse, projenin tanımlanan amacı bu hedefi gerçekleştirmek olmalı; birilerinin bu hedefe ulaşmak için tasarladığı bir çözümü aynen hayata geçirmek değil.
Bu kurgu, bütün paradigmayı değiştiriyor. Proje ekibi çözümü kendisi arayacak, farklı denemelerle yolunu çizecek; belki ilk düşünülenden çok başka çözümler üretilecek. Stok maliyeti düştüyse, proje tartışılmaz biçimde başarılı olacak; nihai ürünün uygunluğu hedefe olan yakınlığı ile ölçülecek.
Bu yaklaşımı uygulamak yapısal olarak kolay değil. Bir tanıma karşılık fiyat almak; tanımlanan çözümün tesliminde ödeme yapmak basit ve anlaşılır bir süreç. Bir soruna birlikte çözüm aramak, farklı disiplinlerden gelen kişilerin gerçek bir takım olarak çalışması ve güvene dayalı, açık bir ilişki demek. Bu terkibi tutturabilmek şirket içi projelerde bile kolay değil; iki veya daha fazla şirket söz konusuysa iyice zor. Ama başarılabilirse, ortaya sadece müşterinin isteğini yerine getiren değil, derdine gerçekten deva olan projeler çıkar.
Aşağıdaki makalenin çizgisi benim yazımla tam paralel değilse de bana ilham kaynağı oldu:
Aydın Ersöz'ün Blogu 