Geçmişten Geleceğe Bir Bakış
Özcan Özbilge

1980'li yılların başında yazılım geliştirme alanında süreçlerden söz edildiğinde "kısa vade" 1-3 yıl arası, "orta vade" 3-6 yıl arası ve "uzun vade" 6 yıldan uzun sürmesi beklenen proje süreçleri için kullanılırdı. Orta ve uzun vadeli projeler, neredeyse bir kural olarak, bunlara girişen ticari işletmelerin sonunu getirecek kadar yüksek risk içerirlerdi.

Proje Yönetiminin Tarih Öncesi

Bugün 32-bit Windows OS kuşağı olarak bildiğimiz ve Microsoft tarafından ilk kez Windows NT (New Technology) adıyla piyasaya sürülen işletim sistemi gerçekte DEC (Digital Equipment Corp) tarafından VAX/VMS işletim sisteminin yerine geçmek üzere geliştirilmeye başlanmıştı. Üç yıl sürmesi gereken proje 5 yılı aşarak DEC'in mali bunalıma girmesine yol açtı ve sonunda Microsoft'un eline düştü. Microsoft'un pek çok ürünü (MsExcel, MsProject vb.) gerçekte üçüncü taraflarca geliştirilmiş ama ilk geliştirmecilerine yar olmamış girişimlerdir.

Benzeri bir son, 80'li yılların ikinci yarısında, benim meslek hayatıma başladığım ilk projenin de başına gelmişti. Telekom alanında sayısal santral çağını, o gün System 12 adı verilen ve hem donanım hem de yazılım olarak son derece devrimci fikirler içeren ürünüyle ITT başlatmıştı. Proje 3 yılda bitecek şekilde düşünülmüştü, 7 yıl sürdü ve ITT'yi batırdı. Operasyon Fransız kamu sermayesinin eline geçti, yeni şirkete Alcatel adı verildi, ürünün adı da Alcatel 1000 olarak değiştirildi. Bugün sözgelimi Türkiye'de sabit ve mobil telekom ağlarının yaklaşık üçte birinde hala Alcatel 1000'in amaca uygun farklı sürümleri kullanılıyor.

O dönemlerde arge proje yönetimi üstüne yapılmış araştırma ve çalışmalar henüz dünyada da yoktu. Geliştirme işine mühendislik yönetimi çerçevesinden bakılıyor ve proje takımları yönetsel-hiyerarşik yapı içersindeki birimler gibi düşünülüyordu. Arge bünyesinde "proje yöneticisi" aldığı işin yürütme sorumlusuydu. Sistem analizi ve mimari çalışması çoğunlukla kıdemli tasarımcı (senior designer) adı verilen çok deneyimli tasarımcılar eliyle bitirilir ve proje yöneticileri ellerine tutuşturulan "TLD" (Top Level Design) dokumanlarıyla işe başlarlardı.

Bu düzenleme içersinde başarısızlık riski en küçük projelerde dahi her zaman yüksekti. Windows NT'nin öyküsü "ünlü bir işletim sisteminin öyküsü" olduğu için dilden dile anlatılıyor, ama isimsiz projelerin isimsiz kahramanları da aynı sonuçlarla karşılaştılar. Proje yöneticileri "maliyet bilinci" içersinde çalışmadıklarından, yazılım geliştirme dünyasında ya takvimden ya da maliyetten patlamayan proje yok gibiydi.

Garaj Firmaları: İlerlemenin Kürek Mahkumları

Görece küçük projeler için başarıya giden tek yol garaj firması (garage company) diye ünlenen bir yapılanma içersinde mümkün oluyordu. "Garage company" yapısında esas olan, kendi de çok yetenekli ve/veya deneyimli bir geliştirmeci olan bir yöneticinin, cevval kişiliklerden oluşan küçük bir geliştirme takımını son derece yüksek bir tempoda ve iş-merkezli bir sosyal hayat içersinde sürüklemesidir.

Bu tarz bir iş ortamında: çalışanlar işe köpekleriyle gelir, günlerce ayrılmazlar; takım üyelerinin içtikleri su ayrı gitmez, gecenin üçünde pizzalar ısmarlanır; yoldaşlık ilişkisi hakimdir. Yöneticiye hem bir önder hem de problem çözücü olarak saygı duyulur, ama hiyerarşi yoktur. Girişimin başarılı olması durumunda çekirdek takımı oluşturan her üye için iyi bir kazanç güvencesi vardır: hisse seçenekleri (share options), kar payı dağıtımı vb. Çoğu durumda "garage company" pazarlama faaliyeti gerektirmeyecek, diğer bir deyişle kendi kendini satabilecek ürünler geliştirmektedir; bir – iki yıllık bir yoğun çalışma döneminin ardından pazarda adını duyurur; hızla büyür, yapısal olarak karmaşıklaşır, ama bir yandan da giderek "yönetilemez" bir yer olmaya başlar ve verimlilik bunalıma girer. (*)

Proje Yönetiminin Keşfi

Proje yönetiminin geliştirme faaliyetinin en merkezi işlevi olduğunun farkedilmesiyle, özellikle ABD'de bu yönde araştırmalar ve çalışmalar yoğunlaştı. 1989'da MIT'te "arge proje yönetimi" doktora çalışmalarına konu olarak kabul edildi; 1994'te UCLA lisans ve lisanüstü ders konusu olarak proje yönetimi eğitimini başlattı. 1990'lı yıllarda bu alanda giderek farklılaşan kuramsal çalışmalar yapıldı, birbirleriyle çelişen savlar öne sürüldü, bunların bir kısmı gerçekten de başarılı sonuçlar verdi; pek çoğu bir kaç kez denenip bırakıldı. O arada yazılım geliştirme faaliyetinin kendisi ve bunun pazarı da mahiyet değiştirdi; teknolojik ilerleme geliştirme süreçlerini kısalttı. Sertleşen rekabet koşulları işletmeleri daha iktisadi düşünmeye ve sonuç odaklı çalışmaya yönlendirdi. Bugün "kısa vade" dediğimizde üç aylık bir zaman diliminden söz ediyoruz.

Günümüzde yüksek teknoloji firmalarının uyguladıkları tek bir proje yönetimi modeli yok. Yazılım üretim düzeni çoğunlukla, işletmenin hizmet verdiği sektördeki koşullara uyacak ve yapılan işin tabiatına göre en verimli çalışma sürecini güvenceleyecek şekilde ortaya çıkıyor. Bir örnek vermek gerekirse: Büyük ölçekli ağ çözümleri sunan işletmelerde bütün sürece "saha yönetimi" hükmeder. Zira o sektörde işin en kritik (ve karar vericiler açısından en önemli) noktası "devreye alım" aşamasıdır. Devreye alımı başaramadığınız durumda mesela bütün bir eyaletin elektriksiz veya telefonsuz kalmasına ya da müşterinin bütün iletişiminin durmasına ve kendi müşterileri nezdinde rezil olmasına yol açabilirsiniz.

Takvim ve Hizmet Bütünlüğü

Kurumsal iş çözümleri alanında ABD ve AB pazarlarında en önemli iki rekabet etmeni "takvim" ve "hizmet bütünlüğü" (service integrity) olarak kendini gösteriyor. Biz Türkiye'de henüz bu gelişmiş pazarlardakine benzer rekabet koşulları içersinde değiliz. Rekabet ortamımız müşterilerin farklı kavrayış ve iş pratiği aşamalarında olmaları ve çözüm pazarının henüz gelişmekte olması nedeniyle biraz "bulanık su" özelliği taşıyor. Kimi firmalar hala 80'li yılların mantığıyla yönetiliyor, kimileri gerçekten yurtdışında dahi öncü sayılabilecek vizyona sahipler. İlginç bir nokta da şu: Türkiye'de çok eski tarzda yönetiliyor görünen bir işletme hiç beklenmedik bir şekilde sıçrama yapacak potansiyeli gösterebiliyor. Bir yandan da kurumsal müşterilerin önemli bir kısmının ihtiyaçlarının adını koyabilecek bir kavrayış seviyesinde dahi olmadıkları gözlemlenebiliyor. Öyle ki bu açıdan bakıldığında, hala bir "pazar oluşturma" sürecinin de bir yandan devam edeceği ortada.

Benim beklentim, önümüzdeki beş yıllık süreçte kurumsal iş çözümleri alanında hızlı bir gelişmenin yaşanacağı ve taşların yerine oturacağı şeklinde. Yani "takvim" ve "hizmet bütünlüğü" etmenlerinin Solice Technologies için de geçerli olacağını düşünüyorum.

(*) Biz, Solice Technologies olarak, pek tabii bu basmakalıbı değiştireceğimiz iddiasındayız.