Proje yöneticilerin projelerinde görmeyi istemediklerini listelemeye çalışsak, bu listenin tepesinde sanırım “belirsizlik” yer alacaktır. Belirsizlik arttıkça, sonucunda birçok olumsuzluk proje içerisinde belirecek, projenin yönetimi zorlaşarak belki de yönetilemez bir duruma gelecektir. Kontrol yöneticinin elinden çıkıp, bu belirsizliği besleyen faktörlerin eline geçmeye başlayacaktır. Faciaya adım adım…

Bu karamsarlığı ve olumsuzlukları bir kenara bırakalım, ve yönetimi geliştirme projelerinden çok farklı olan, teorik yaklaşımlarım ve metotların fazlaca sapmaya uğradığı “destek ve idame projelerine” sözü getirelim.

Projelerde teslimata veya kilometre taşlarına yaklaştıkça çoğu zaman stresin arttığı, yönetimin sistematik sınırlarını zorlamaya başladığı, zamanın daraldığı ve hata listesi baskısının ekip içerisinde hissedildiği bir durum ortaya çıkmaktadır. Müşteri teslimatı gerçekleştikten sonra, proje “idame” safhasına geçer. Ürünün teslimatı tamamlanmış olsa da proje henüz bitmemiştir. Bu safhanın en önemli özelliği, müşteri tarafından bildirilen hatanın düzeltilmesi zaman kıskacındadır. Zaman dardır ve geliştirme safhasındakinden farklı olan bir baskı yaşanır. İş ilanlarında yer alan ve yazılımcıların birçoğunun nefret ettiklerine inadığım, “baskı altında verimli çalışabilme” özelliği kendini projenin idame safhasında fazlaca gösterecektir. Benim kişisel gözlemim, bu safhada görev alan ekipteki yıpranma payının gözardı edilemeyecek kadar belirgin olduğudur. Uzun soluklu idame safhası öngörülen projelerin bu safhası, ayrı bir “idame projesi” olarak yapılandırılabilir.

Bu projelerin temel özellikliği ise, yapılan işin genelde müşteriden geri dönen bildirimler tarafından şekillenmesidir. Proje yöneticisinin önünde projenin başında belirsizlikler vardır. Acaba müşteriden talep edilecekler neler olacak? Hata bildirim listesinde 100 madde mi olacak, yoksa 10 mu? Projelerin başarısı bir anlamda, proje yer alan ekibe değilde, ürünün geliştirme safhasında yer almış önceki ekibin çalışma sonuçlarına bağlıdır. Yapılacak en büyük hata, idame safhasından önce müşterinin proje içinde yeterince yer almaması durumu olacaktır. Müşteri ürün ile esas teması teslimat sonrasındaki idame safhasında kuruyor ise, bu projenin hiç kolay geçmeyeceğini kolayca öngörebiliriz. Eğer testler etkili olarak uygulanmadıysa, normal şartlarda bu proje kabarık bir liste ile işe başlayacaktır. İdame projelerinde, müşteriden üründe yeni bir özellik isteği değilde sadece hata listesi geri bildirimi oluyor ise proje hata tarafından yönlendirilen bir hal alacaktır. Böyle bir projede sistematik yaklaşımlardan hangisini uygulayabilirsiniz? Projenin geliştirme safhasında hangi metotlar uygulandı ve sistematik yaklaşım için gerekli altyapı hazır durumda mı? Altyapıdan kastettiğim ise, en azından bir kaynak kod ve konfigürasyon kontrolü, hata takip sistemi, idame edilebilir tasarlanmış ürün ve bunun için yeterli bilgi kaynaklarıdır.

Biraz öncede bahsettiğimiz gibi, idame projeleri genelde müşterinin hata bildirimi tarafından yönlendirilirler. Hata raporu haftalık olabileceği gibi, çoğu zaman anlık olmaktadır. Müşteri üründe bir hata tespit ettiği zaman, hemen bu hatayı ekibe bildirir ve projenin bu safhasında bildirimin sonuca bir an önce bağlanmasını istemektedir. Bildirilen hataların önceliği hep en yüksek ve acildir. Projenin geliştirme safhası sorunlu ise, bu bildirimler bir yağmur gibi ekibin üzerine yağabilir. Eğer başarılı bir geliştirme süreci tamamlanmış ise, müşteri bildirimleri için geçmiş tecrübelerle elde edilmiş belirli bir oran veya sayı tahmin edilebilir. Olağan ve beklenen bu bildirimler ile, idame ekibi bir kaos ortamından uzak şekilde mücadele edecek ve listeyi başarılı bir şekilde temizleyecektir. Diğer durumda, artan baskı ve şiddet beraberinde birçok hatanın oluşması riskini arttıracaktır. İdame projelerinde ve bu safhada en büyük risk, bir hata için uygulanan çözümün başka bir hataya yol açmasıdır. Çünkü, zaman darlığı sebebi ile çözümün yan etkileri yeterince ve etkili olarak incelenmasi zorlaşabilmektedir. Bu kıstaslardan dolayı gözden kaçan durumlar, hatalı bir ürünü ortaya çıkarabilmektedir. Böyle bir durumun kontrolünü sağlayabilecek bir çözüm olarak, “Test Tarafından Yönlendirilen” geliştirme sürecinin çıktıları kullanılabilir. Ayrıca proje başlangıcında kurulacak otomatik test altyapısı, idame ekibinin işini kolaylaştıracaktır.

Destek projelerinin yönetimi birçok karakteristik özellikleri bakımından idame projeleri ile paralellik göstermektedir. Bu projelerdeki süreçte müşteri tarafından şekillendirilmekte ve yönlendirilmektedir. Başarılı geliştirilmiş bir ürünün desteğini müşterinize veriyor iseniz, bu süreç ekip için rahat geçecektir. Müşteri isteklerine hızlı yanıtlar ile geri dönebilir, bildirilen hataları veya yeni fonksiyonel işlevleri zamanında gerçekleştirebilirsiniz. Çoğu zaman, müşteri isteklerinde zaman kısıtlaması olmaktadır. İdame edilebilir bir tasarıma sahip bir ürün üzerinden destek projesi yönetmek daha kolay olmaktadır. Projenin gerekli geliştirme altyapının olması destek ekibi için çok önemli bir artıdır. Hızlı çözüme ulaşmak için, ürün ile ilişkili daha önce farklı projelerde bildirilmiş müşteri isteklerini araştırabilme ve takip edebilme özelliği çok önemlidir. Proje yöneticisinin önünde müşteri tarafından gelecek bildirimlere ilişkin belirsizlik destek projelerinde de vardır. Projenin başarısında belirleyici olan, bu bildirimlere karşılık zamanında cevap ve çözüm üretebilmektir. İdame ve destek projeleri, yazılım dünyasında büyük bir oranı oluşturmaktadır. Her ürünün bir idame safhası olmaktadır. Günümüzde bir yazılım ürünü birçok farklı ürün içerisinde bileşen olarak kullanılmaktadır, sonucunda yeni ürün geliştirilebilmektedir.

Ülkemizde yazılım mühendisliği ve yönetimi alanındaki çalışmaların, bilgi paylaşımının ve bu alanda düzenlenen konferansların artması dileğiyle…