Logo Yazılım’ın Teknolojik Dönüşümü: Süreç Mühendisliği ve LAPIS’in Doğuşu

Mühendislik, ölçmeyle başlar. Yazılım üretimi; ölçme, öngörülebilme ve kontrol edilme açısından zorluklar arz eden, kompleks bir sistemdir.

Yazılım birimlerle ifade edilebilir mi? Sayısal bir teknoloji olmasına karşın, yazılım sayılmaya, ölçülmeye uygun bir “çokluk” değildir. Ben yazılıma başladığımda, yazılım, mühendislikten çok bir sanat gibi görülüyordu. Yapan kişinin ustalığına ve yaratıcılığına bağlı olması nedeniyle, yazılım bir sanattır da zaten. Ancak günümüzde yazılımlar çok önemli görevler üstleniyor. Küçük bir hatanın insan yaşamına mal olabileceği yoğun bakım sistemini ya da bir silah sistemini yöneten yazılımın, bir hata durumunda işletmeyi iflasa sürükleyebilecek iş yazılımının mühendislik disiplini dışında kalması düşünülemezdi.

Ben bu dönüşüm sürecini çok iyi hatırlıyorum. Yazılım mühendislik midir değil midir, olmalı mıdır, nasıl olabilir, neden olamaz tartışmaları uzunca bir dönem sürdü. Yazılım süreçlerini diğer mühendislik süreçlerine benzetme çalışmaları birçok kez başarısızlıkla sonuçlansa da, kaçınılmaz olan gerçekleşti. Yazılım sonunda, kontrol edilebilir (controllable), öngörülebilir (predictable), ölçülebilir (measurable) bir mühendislik disiplini olarak kendini ispat etti.

Logo ve CMMI

Süreç öncelikle, Amerikan Savunma Bakanlığı’nın kendisiyle iş yapan yazılım yüklenicilerini seçme, değerlendirme ve yönetme amacıyla başladı. Bitmeyen, iptal edilen veya geciken projeler nedeniyle büyük kayıplar yaşayan işverenler, yazılım üretimini sıkı disiplin altına almayı düşünüyordu. Yazılım da inşaat ve makine mühendisliği gibi, en ince detayına kadar önceden planlanmalı ve projelendirilmeliydi. Carnegie-Mellon Üniversitesi’ne bağlı SEI’ya (Software Engineering Institute) hazırlattırılan CMM (Capability Maturity Model / Yetenek ve Olgunluk Modeli) aracılığıyla, yazılım şirketlerini yetenek ve olgunluk açısından 1 den 5’kadar değişen derecelerle değerlendirmeye ve belgelendirmeye başladılar.

Üçüncü seviyeden derecelendirme belgesi alamayan kuruluşlar, askeri ihalelere giremeyecekti. Önce askeri ihalelere giren firmalar, ardından da Batı ülkelerinden yazılım dışkaynak işi almak isteyen Hindistan kökenli firmalar, CMM belgelerinin ilk taliplileri oldu. Biz; TÜBİTAK’ın desteklediği, CMM’nin Avrupa’da daha çok desteklenen karşılığı ISO 15504 standardı SPICE için 1990’larda yoğun bir çalışma yürütmüş, birçok süreçte 3. seviyeye ulaşmıştık. Zamanla CMM ile SPICE birleşti, CMMI oldu. Biz de iddialı bir proje olarak CMMI’da 4. seviye hedefini koyarak yola çıktık.

Aslında müşterilerimizin bizden böyle bir talebi yoktu. Eğer 4. seviyeye çıkabilirsek, yurtdışından iş alabileceğimizi ve ihracat yapabileceğimizi düşünüyorduk. Büyük bir grupla ve yüksek bir motivasyonla yola çıktık. Modeller, büyük miktarda ön ve son dokümantasyon içeriyor, çok ince detaylara kadar inen planlar gerektiriyordu. İşin içine zekâ katmaya çalıştık. Bu kadar dokümantasyonu oluşturacak personeli ve zamanı bulamayacağımızı bildiğimizden, gerekenleri otomatik yapan bir süreç yazılımı geliştirmeye başladık.

Yenilikçi içeriğe sahip bu ürünle, belki de yurtdışı pazarlarda bir şans elde edebilirdik. Nitelikli bir ürün olmaya yüz tutmuşken, CMMI’nın bizim bütçelerimizle gerçekleşemeyeceğine, aslında bunun ne bize ne de müşterilerimize hiçbir katkısı olamayacağına karar verdik. 

Neden vazgeçtik?

Bu sürecin hiçbir ekonomik anlamı yoktu. Genellikle KOBİ olan müşterilerimizin bizden böyle bir talebi de yoktu. Askeri projelere giremedik, yurtdışı özel yazılım piyasasında da Hindistan ile maliyet ve ölçek açısından rekabet edemeyeceğimizi anladık. Microsoft, Google gibi firmalar bu modellere zaten itibar etmiyor, kendilerine göre yöntemler geliştiriyordu. Çünkü bu modeller; zamanın en büyük rekabet ve maliyet değişkeni olduğu paket yazılım sektöründe, şirketlere altında kalkılamaz bir hantallık getiriyordu. Sonunda, CMMI-4 hedefi için şirket içinde astığımız motivasyon posterlerini geri dönüşüm kutularının içinde gördük.

Aynı tarihlerde Extreme Programming gibi yeni disiplinler çıkmaya başladı. SPICE ve CMMI projelerine harcanan zaman ve emek karşısında beklentilerin gerçekleşmemiş olmasının yarattığı hayal kırıklığı, bizi yeni metodolojileri denemekten alıkoyuyordu. Bu sırada, SEI’nın İstanbul Teknik Üniversitesi’nde yapacağı bir konferansa, o zamanlar TÜBİSAD Başkanı olduğum için açılış konuşmacısı olarak davet edildim.

Toplantıda SEI temsilcileri; savunma sektöründe faaliyet göstermeyen firmaların, hele Avrupa maliyetleriyle çalışıyorlarsa CMMI gibi bir modelin altından kalkamayacaklarını, bu nedenle bu gibi ülkelerde TSP (Team Software Process) sürecini önerdiklerini, bu konuda İTÜ’yü partner olarak seçtiklerini söylediler. “Logo bu modeli benimseyerek, ülkedeki yazılım firmalarına önderlik etmeli.” dediler. TSP’yi aldım, kısaca göz gezdirdim, yine sayfalarca dokümantasyon gerektiren, kocaman, hantal bir sistemdi. Değil TSP, yazılımcı bireylerin uygulaması için önerdikleri PSP (Personal Software Process) bile bizim için kullanılamaz bir modeldi. Bir daha böyle işlere girmemekte kararlılığımız perçinlendi.

Sistemsiz olmuyor…

Ürünleri Türkiye’de ve yurtdışında onlarca ülkede önemli işlerde kullanılan, ancak 200.000 adede ulaşan paket satışı yapmış bir yazılım firmasının informal yöntemlerle yürüyemeyeceği bir gerçekti. Biz de Microsoft ve Google gibi, kendi yönetim modelimizi geliştirmeliydik.

Ürün üretiyorsanız, pazar fırsatlarına odaklısınız demektir. Ürünü vaktinde çıkaramazsanız, pazardaki fırsatı kaçırabilirsiniz, fırsatı kaçırmasanız bile bütçe aşılabilir, maliyetler artar, kârlılık sağlanamayabilir. Piyasada başarılı bir ürününüz varsa, zamanlama önemlidir. Planladığınız veya müşterilerden gelen istekleri, ya da bilinen/bildirilen hataları (bug) hangi sürümle ne zaman çıkaracağınızı belirlemeniz, hatta taahhüt etmeniz lazım.

Genel Müdür, Yazılım Müdürü’ne sorduğu sorular karşısında net cevaplar alamazsa plan yapamaz, satış bölümü kendini güvende hissetmezse satış yapamaz. Şikayetçi müşterilerin tepkilerine maruz kalan destek bölümünde moraller bozulur, performans düşer. Belirsizlik, öngörülemezlik bir kurum için en kötü şeydir. Biz de süreç işine başlarken, bir yazılım şirketinde en önemli değişkenin zaman (t) olduğuna karar verdik. Eğer zamanımızı doğru yönetebilirsek, maliyetlerimizi de yönetebilirdik. İşte LAPIS’e giden yol böyle açıldı.

Logo’da Çevik Yönetim ve LAPIS

Hatalardan öğrenme, başarılardan öğrenmeden daha öğreticidir. Zaman değişkenine bu kadar önem vermemizin bir nedeni de, Almanya pazarında yaptığımız çalışmalardan alınan derslerden gelir. 90’ların ortasından 2008 krizine kadar Almanya’da faaliyet gösterdik. Logo iyi bir mühendislik firmasıdır. Yazılım işinde mühendisliği ve ustalığı öne alır, bundan taviz vermemeye çalışır. Bunca yıldır ayakta kalmasının en önemli nedenlerinden biri budur. İyi mühendislik sağlam ve sürdürülebilir altyapı demektir. İyi bir altyapınız varsa ürünleriniz daha sağlam ve dayanıklı olur. Aslında buna yazılım ustalığı da diyebiliriz.

Bugünlerde çok moda olan Software Craftsmanship, Logo’nun DNA’sında hep vardı. Ancak ustalık mühendislik yöntemleriyle ölçeklenebilirse, iş sanayiye dönüşür, endüstrileşir. Almanya mühendisliğin çok takdir edildiği, mühendislik kültürünün etkin olduğu bir ülke. Alman ürünleri bazen fazlasıyla mühendislik görmüş “overengineered” olarak anılır. Almanlar iyi bir ürün görünce sizinle ilgilenmeye başlar. Nitekim, Türkiye’den gelen küçük bir firma olmamıza karşın, ürünlerimiz epeyce takdir görmüştü. Fiyatımızın da iyi olacağı düşüncesiyle, bize güzel işler verdiler ve ne olduysa ondan sonra oldu…

Ancak ustalık mühendislik yöntemleriyle ölçeklenebilirse, iş sanayiye dönüşür, endüstrileşir.

Öncelikle, Almanların zaman konusundaki titizliğini çok iyi anladık. Zamanında yetişmeyen bir iş için fazlasıyla çalışıp üstüne birçok taviz vermeye kalktığımız, “bizden” ve “Doğulu” birçok davranışın geçerli olmadığını fark ettik. Yani, söz bir kez veriliyordu. Yetişmeyen projeleri fedakâr elemanlarımız işyerinde sabahlara kadar çalışarak düzeltmeye uğraşırken, firmadaki sendika olaya el koyabiliyordu. Sonunda Türkiye’de geçerli tarzımızın, sözünde duramayınca müşteriye ekstra taviz vermenin, alttan almanın, fedakârlık yapmanın müşteri nezdinde önemi olmadığını maalesef kabul ettik. 2008 küresel krizi ise ülkeden geri çekilmemize neden oldu, biz zaman yönetimine yani “t” değişkenine önem vermeye başladık.

Bir işletmenin verimi, birim zamanda yaptığı işin çokluğuyla ölçülür. Çevik yazılım metodolojileri literatüründe buna hız (velocity) deniliyor. Yani Hız = Yol/Zaman analojisi kullanılıyor. Biz; iş yaptığımız diğer paydaşlarımızın, yani müşterilerimiz, iş ortaklarımız, satış pazarlama ve destek bölümlerimizin zamanını doğru planlamasını sağlayabilmenin daha önemli olduğuna karar verip zamanı sabitledik. Yani, yapılacak işin miktarına değil zamana odaklandık.

Hızı tarif eden kesirin paydasını sabitledik. Bu süre, uzun tartışmalardan sonra 5 hafta kodlama, 2 hafta da test için toplam 7 hafta olarak belirlendi. Tüm yılın sürüm teslim tarihleri belirlendi. İş planı takvimi büyük posterlere basılarak herkesin görebileceği yerlere asıldı. Broşürler hazırlanıp, iş ortaklarına ve önemli müşterilere gönderildi. Takvime sadık kalınacağı konusunda topluca söz verildi.

Ardından, eşit zaman aralıkları içinde yapılabilecek iş miktarına odaklandık. Çok yüksek bir kesinlikle tespit edebileceğimiz iş miktarını taahhüt edelim, taahhüt ettiğimizi mutlaka saat ve dakika kesinliğiyle teslim edelim, teslim ettiğimiz ise her zaman çalışan bir ürün olsun dedik. Gerçekten de öyle oldu. Yazılımcılar, söylediklerini vaktinde hatta vaktinden önce yetiştirmeye başladı. Yapılan iş miktarını zamanla kademeli şekilde artırarak, sistemin, kararlı bir yazılımı üretebilecek kapasitesini tespit ettik. Şirket içinde ve dışında bir güven ortamı oluşmaya başladı, herkes işini planlayabildi. İç ve dış müşteriler, bu ana ritmin etrafında senkronize şekilde salınmaya başladı. Biz de süreçten şunu öğrendik: Bir organizasyondaki en büyük verimsizlik nedeni belirsizliktir.

“Ölçme” mühendisliğin başlangıcıdır demiştik. Zaman birimini sabitlemek, yapılacak iş miktarının ölçülmesini kolaylaştırdı. Yapılan işin birimini belirlemek, buna göre kapasite oluşturmak, işleri önem sırasına göre dizmek, üretim takımlarını birbiriyle karşılaştırabilmek gibi sistemler, 1-2 yıl içinde oturdu. Zamanla ürün gruplarına göre farklı sürüm aralıkları tespit edildi. Bu her zaman yıllık plan hazırlama sürecinde yapıldı ve 1 yıl boyunca ilan edilen plana sadık kalındı.

Dönüşüm süreci boyunca şirketin tüm bölümlerini, müşterileri, iş ortaklarını ikna etmek, bize bir zaman kredisi vermelerini istemek gerekiyordu. Yılların oluşturduğu güvensizlik ortamında bunu başarabilmek kolay değildi. İşte burada, üst yönetimin katılımının önemi ortaya çıkıyor. Aylar boyunca, içeride ve dışarıda bulunan paydaşlara güvence verecek konuşmalar yaptım. Ancak başarısı kanıtlandıkça, sistemin sahiplenilmesi ve katkıda bulunanların sayısı arttı. 4 yıl sonra, kapasite planlamadan proje yönetimine, kalite ve verimlilik ölçümlerine kadar geniş bir kümeyi kapsayan, uluslararası kongrelere sunabileceğimiz düzeyde bir çevik (agile) model oluşturmuştuk. Sistemimize bir isim koyalım dedik, “Logo Agile Process Improvement System“ LAPIS” adı böyle doğdu.

M. Tuğrul Tekbulut

Yönetim Kurulu Başkanı, Logo Yazılım