Expert Judgment

[TR] Makale Gözden Geçirme Yazısı: “P.Y. – 21. Yüzyılda Çılgınlığa Karşı Metodolojiler”

Posted in Project Management by dnzrn on May 3, 2010

Proje Yönetimi: 21. Yüzyılda Çılgınlığa Karşı Metodolojiler

– Makale Gözden Geçirme Yazısı –


Deniz İREN, PMP

Orta Doğu Teknik Üniversitesi,

Bilgi İşlem Daire Başkanlığı

www.deniziren.com | diren@metu.edu.tr

Birkaç gün önce, bir arkadaşımın yönlendirmesi üzerine, 2000 senesinde yazılmış bir makaleyi inceledim. Makale, 2000 senesinde yapılan bir söyleşinin (Software Methods and Tools 2000), konuk konuşmacısının yaptığı açıklamaları konu almakta. İlginç olan konuşmanın konusu. Önlerindeki 10 sene boyunca Yazılım Proje Yönetimi alanında yaşanacak değişiklikleri öngörmüşler. Ben de tam 10 sene sonra (2010) bu makaleyi okuma ve öngörülerin ne kadar gerçek olduğunu değerlendirebilme fırsatı yakaladım.

Makalenin yazarları, Amerika’daki Capital One Bankası’ının Finans Departmanı’nda çalışan iki arkadaş; George Kelly Flanagin ve Susan R. Jacobs. Makale, yazarların yaptığı bir dizi öngörünün sıralanması ve açıklanması biçiminde organize edilmiş.  Bu öngörüler şu şekilde;

“Yazılım profesyonellerinin sertifikalandırılması büyüyen bir trend ve büyümeye devam edecek.”

Makalenin yazıldığı senelerde, Microsoft’un sadece üç sertifikası vardı ve bunlar da epeyce yeniydi. MCSE, MCSD ve MCDA sertifikaları yeni yeni çıkıyordu. 2000’lerin başlarında bu sertifikalar çok zor ediniliyordu ve çok değerliydi. Yazarların tahminleri, bu tür sertifikaların sayısının ve çeşitliliğinin artacağı ve sertifikasyon işinin büyük bir pazar olacağı yönünde idi. Haklı olduklarını bugünkü duruma bakarak görebiliyoruz. Microsoft’un şu anda 17 adet sertifikasyonu var. Ne var ki artık bu sertifikaları edinmek zor sayılmaz ve bunlara sektördeki kuruluşlar tarafından eskisi kadar değer de verilmiyor.

Yazarlar, sertifikasyonların detaylanmasında bir risk görmüşler. Öngörülerine göre, sertifika sahibi profesyoneller daha detaylı işler ile ilgilenecekler ancak kendi alanlarının uzmanları oldukları için bir çok projede kendi uzmanlık alanlarında “misafir” olarak görev yapacaklar. Yani bir “Sertifikalı İş Analisti” sıfatına sahip bir kişi, bir projede iş analizini yaptıktan sonra o projenin analiz fazının geçilmesi üzerine, başka projeye transfer edilecek ve yapmış olduğu işin ilk proje üzerindeki etkilerini izleyememiş olacak. Bu da son kullanıcılara karşı direk sorumluluğu olmayan (olmamış) kişilerin, yazılım geliştirme projelerinde, mimari sürecinin bir aşamasında kullanılmasına sebep olacak. Bugün itibariyle, sertifika sahiplerinin organizasyonlarda, yazılım geliştirme süreçlerinin ilgili aşamalarında görevlendirilmesine dair bir eğilim söz konusu. Ancak bu durumun yapılan işin kalitesi üzerindeki etkisinin ne olduğunun araştırıldığına henüz rastlamadım. İleriki bir araştırmanın konusu olarak not alıyorum.

“Yazılım her geçen gün daha büyük bir gereklilik oldukça, yazılım profesyonelleri, yazılım şirketlerine kayacaklar.”

Yazarların öngörülerine göre, diğer şirketlerin BT birimlerinde çalışan yazılım geliştiriciler, yazılım şirketlerine kayma eğilimi gösterecekler. Bu da nitelikle BT personelinin yazılım geliştirme şirketleri haricinde şirketlerde bulunulmasını zorlaştıracak. Özellikle yazılım geliştirme kökenli Yazılım Proje Yöneticileri, en zor bulunur personel olacak.

Baktığımızda, bu öngörünün büyük oranda doğru olduğunu görüyoruz. Sektörde, yazılım geliştirme projeleri genellikle, büyük yazılım şirketleri tarafından sahiplenilip, alt yükleniciler vasıtasıyla yürütülüp, tamamlanıyor. Yazılım Proje Yöneticileri bu süreçte hem yazılımı geliştiren alt yüklenicilerde, hem de alt yüklenicilerin işini denetleyen asıl proje sahibi organizasyonlarda bulunabiliyorlar. Ne var ki, bir numaralı iş alanı BT olmayan organizasyonlarda, yazılım projelerinin kurum içi veya alt yükleniciler vasıtasıyla yönetilmesi yazılım geliştirme kökenli olmayan personel tarafından da gerçekleştirilebiliyor.

“Yazılım ihtiyacı olan şirketlerin çoğu dış kaynaklı yazılım geliştirme yapacaklar.”

Öngörüye göre, kalifiye BT personelinin yazılım şirketlerine geçmesi sonucu, diğer şirketler çareyi yazılım projelerini geliştirirken dış kaynak kullanılmasında bulacaklar.

Günümüzde yazılım geliştirme projelerinin dış kaynak kullanımı ile yürütülmesi çok rastlanan bir durum. Tabii ki bunun sebepleri arasında yazılım şirketlerinin yetkinliklerinin, kurum içi BT birimlerinden daha yüksek olması da var. Ancak tek sebep bu değil. Dış kaynak kullanımı pek çok operasyon ve kalite maliyetlerinden de kurtulmayı ve yazılım geliştirmeyi optimize etmeyi sağlamakta.

Öngörülene göre ana faaliyet alanı BT olmayan organizasyonlarda kalmayı seçen proje yöneticileri, yazılım geliştirme projelerinin büyük kısmının 3. parti organizasyonlar tarafından yürütüleceğini tecrübe edecekler. Dana önce bahsettiğim sebeplerden bunu da gerçekleşmiş bir öngörü olarak değerlendiriyorum.

“3. dünya ülkelerinde yazılım eğitiminin artması, dış kaynak kullanımını uluslararası boyuta taşıyacak.”

Makale, Amerika, Kanada, Avustralya ve Batı Avrupa ülkelrindeki nitelikli BT iş gücünün azlığına dikkat çekmiş ve bu açığın kapatılması için Hindistan gibi gelişmekte olan ülkelerden işgücü transfer edileceğini öngörmüş. Yazarlar üç farklı uluslararası dış kaynak kullanım modelinden bahsetmişler. Bunlardan ilki, gereksinimlerin ve iş analizinin yerinde yapılmasını takiben, işin yapılacağı ülkeye transfer edilmesi ve işin burada yürütülmesi. Ne var ki yapılacak işin doğası gereği her tür proje bu şekilde transfer edilebilir olmuyor. Diğer bir yurtdışı dış kaynak kullanımı modeli ise, ucuz iş gücünün bulunduğu ülkede bir şirket birimi oluşturmak. Bunun da en büyük dezavantajı, yabancı ülkelerin kuralları, kanunları ve kültürlerine hakim olmamanın getireceği riskler. Makalede belirtilen üçüncü ve son dış kaynak kullanım modeli ise iş gücünün 3. Dünya ülkelerinden taşınarak, gelişmiş ülkelere taşınması.

Baktığımızda, bu öngörünün de büyük oranda gerçeğe döndüğünü görebiliriz. Amerika ve Avrupa’da konumlanmış olan pek çok büyük yazılım şirketinin, Hindistan, Çin ve Brezilya’da ofisleri var veya en azından çeşitli projeleri yürütürken bu ülkelerdeki yazılım çiftliklerinden faydalanıyorlar.

“Var olan servislerin kullanımı ile yazılım geliştirme yoğunluğu artarken, yazılımı sıfırdan geliştirme yoğunluğu düşecek.”

On sene önce yapılmış olan bu tahmin aslında, Hizmet Odaklı Mimari (SOA) nın bir habercisi adeta. Günümüzde pek çok yazılım çözümünün geliştirilmesinde bu yaklaşım uygulanıyor.

“İnternet, yazılım geliştirme ve proje yönetimini kökten değiştirecek.”

Yazarlar, 2000’lerin ilk on senesinde, özellikle internet tabanlı ürünlerin geliştirilmesinde, yazılım projeleri büyüdükçe, projedeki satıcı ve geliştirici paydaşların sayısının artacağını öngörmüşler. Projenin yaşam süresi boyunca bu paydaşların etkinliklerini hatta varlıklarını dahi kaybetmelerinin söz konusu olabileceğinden bahsedilmiş. Yazarlar, yoğun alt yüklenici yönetimi gerektiren projelerde, bir proje yöneticisinin sahip olması gereken en önemli özelliğin seri ve doğru düşünme ve karar verebilme olduğunu belirtmişler. Gerçekten de günümüzde yazılım yoğun sistemlerin geliştirildiği büyük projelerde çok sayıda alt yüklenici kullanılıyor. Gün geçtikçe organizasyonlar BT’nin kaldıraç etkisinden faydalanmak için yeni fırsatları araştırıyorlar. İş gereksinimleri karmaşıklaştıkça, sistemler de karmaşıklaşıyor. Doğal olarak bu yazılım geliştirme sürecinin de karmaşıklaşmasına, çok sayıda uzmanlık alanının ve işgücünün bir arada kullanılmasına ihtiyaç duyulmasına sebep oluyor. Bu da makale yazarlarının doğru çıkan öngörülerinden.

Makalede, çok sayıda alt yüklenici kullanılmasının bir riskinden daha bahsedilmiş. Bu risk, her alt yüklenici kendi iteratif veya çevik süreci ile iş geliştirirken, farklı alt yükleniciler tarafından geliştirilen ve farklı zamanlarda hazır olan iş ürünü parçalarının bir araya getirilerek, işlevsel bir bütünlük içinde test edilmesinin zorlaşması. Basitçe açıklamak gerekirse, alt yüklenici sayısı arttıkça, bu alt yüklenicilerin üretim döngülerinin birbirleri ile senkronizasyonunun sağlanması daha karmaşık bir süreç halini almakta. Bu da yazılım parçalarının bir araya getirilerek, alfa işlev bütünlüğünün ancak üretim fazının sonlarında oluşmasına sebep olmakta. Bu projenin sahibi olan organizasyon için test aşamasını –dolayısıyla kaliteyi- ilgilendiren büyük bir risk oluşturuyor.