Üstteki resim 10 ayrı küçük resimden ya da karikatürden oluşuyor ve her biri, müşteriye özel geliştirilen yazılım projelerinde sıklıkla yaşanan sıkıntıları komik bir şekilde resmediyor. Aslında, hani güldürürken düşündüren şeyler vardır ya tam böyle bir resim bu. Bakınca gülüp geçiyoruz ama gerçekte öyle olmamalı, çünkü halimizin pür melali bu resimler. Ben, bu resmi proje yönetimi, nesne merkezli analiz ve tasarım ya da yazılım mimarileri gibi konuları içeren ders ve konuşmalarda, çok sıklıkla kullanıyorum. “bir resim 1000 kelimeye değer” derler Amerikalılar, bu resimler de öyle. İsterseniz bir geçelim tek tek karelerin üzerinden ve ülkemizdeki tipik bir yazılım projesi üzerine bir hikaye yazalım onlardan.

Bence sondan yani 10. kareden (What the customer really needed – Müşterinin aslında ihtiyacı olan) başlayıp, başa dönerek ilerleyelim. Aslında ihtiyaç basit: Adam ailesiyle birlikte kırlara gittiğinde, çoluk çocuğun eğlenmesi için basit bir lastik salıncak istiyor. Ama iş güç arasında da bu konuda pek de fazla düşünmemiş, düşünmeye fırsat da bulamamış. Bir kaç kelimeyle anlatıyor derdini kendince ve “hani şu salıncaklar olur ya” ya da “bilirsin işte, küçükken sallanırdık” gibisinden cümlelerle, boşlukları karşıdakinin doldurmasını ister şekilde konuşuyor. Bu 1. karede (How the customer explained it – Müşteri onu nasıl açıkladı) anlatılıyor. Ama problem şu ki, 2. karede (How the Project Leader understood it – Proje Lideri onu nasıl anladı) resmedildiği gibi, karşıda onu dinleyen ve bu isteğe göre ona bir salıncak tasarlayıp gerçekleştirecek olan teknik takımın proje lideri olan kişi belli ki çok da salıncakla sallanmamış küçüklüğünde, öyle çok kırsal bir alanda büyümemiş yani, işi pek bilmiyor da denebilir. Ve müşterinin zaten eksik anlattığını akla muhal bir şekilde algılıyor. Proje liderinin algısında öyle bir problem var ki, analist, müşteriyle konuşunca hemen anlıyor ve problemi düzeltiyor, 3. kare (How the Analyst design it – Analist onu nasıl tasarladı). Tabi hep söyleriz analistlere, “müşteri ne istediğini düzgün anlatamaz, siz işin her yönünü düşünerek, onun anlatmak istediğini kerpedenle diş çeker gibi onun ağzından alın” diye. Neyse, cevval analistimiz yöneticisinin olayı tam kavrayamadığını farkeder ve durumu aklınca düzeltir. 🙂

4. karede (How theProgrammer wrote  it – Programcı onu nasıl yazdı) analistten daha cevval olan programcımız, “tamam abi/abla ben onu biliyorum” diye işe koyulur. Zaten analist anlatmaya başlayınca, Anadolu çocuğu delikanlı programcımız, leb demeden leblebiyi anlamıştır. Pek mümkün değildir ya varsayın ki analist, ihtiyaç hakkında tonla belge üretmiş olsun: Kullanım şekilleri (use cases), iş kuralları, her türlü UML diyagramları, iş nesneleri modeli (domain model), aktivite ve ardışıl diyagramlar (aktivity, sequence diagrams) vs. Aslında analist ile programcı arasındaki mimar karesi atlanmış. Analistin analizinde olması muhtemel sıkıntılı noktaları bulan en temel kişidir mimar. (Bu resimlerde mimar olmadığı için tasarım görevi de analiste yüklenmiş ki bu durum zaten çok sıkıntılı. Gerçekte mimar yoksa ve birileri bir tasarım yapacaksa bu kişi daha çok en tecrübeli olan programcı olur.) Düzgün bir mimar olsa zaten programcı da böyle saçmalamazdı. 🙂 Zaten analist ile programcının konuşup kavga etmeden anlaştıkları pek görülmemiştir. 🙂 Neyse belli ki ne kadar doküman olursa olsun hepsini kenara koyan programcımız, “ben zaten biliyorum bunu” diyerekten işe koyulmuş ve analistin anlattıklarındaki problemli noktaları da düzelterek aslında gerçeğe bayağı bir yaklaşmıştı ki test yapmaktan hoşlanmıyor olması, kodda yaptığı ufak tefek hataları görmesini önler.

5. kare (How the Business Consultant described it – İş Danışmanı onu nasıl anlattı) Türkiye’de pek de alışık olmadığımız, iş ile ilgili konularda yardımcı olan danışmanın, geliştirilmekte olan ürünü, müşteriye ve etrafa nasıl anlattığını gösteriyor. 🙂

6. kare (How the project was documented – Proje nasıl belgelendi) her yerde aynı: No documentation at all J Okumayan bir millete yaz demek ne kadar zordur, bilir misiniz? Zaten yazsanız kim okur ki? Niye yazalım o zaman, değil mi? Projelerde yazılmayı hakeden tek şey koddur. Geri kalan ise sadece bürokrasidir, dostlar alış-verişte görsündür. 🙂

7. kare (What operations installed – Canlı ortama hangi yapılar kuruldu) canlı sistemin durumunu anlatıyor: İpe tırmanmak isteyenler için geliştirilmiş bir sistem. Sallanmak isteyen bununla sallansın canım. 🙂 Gerisi arkadan geliyor, şimdilik bununla idare etsin çocuklar, hem bu pazu yapar. 🙂

8. kare (How the customer was billed – Müşteriye nasıl bir fatura çıkarıldı) de bize pek uymuyor. ABD ve Avrupa için daha doğru aslında. Oradaki projeler bizimkilere göre çok daha büyük boyutlarda ve bizim sıklıkla ıskaladığımız iş bölümü kavramını güzel bir şekilde uyguladıkları için projeler çok daha fazla kişiyle yapılıyor. Bir de tabi yazılımcıların yüksek gelir standartları var. Bu yüzden maliyetler ülkemizle kıyaslanmayacak kadar yüksek boyutlarda. Resimde tabi ki abartı var ama anlatmaya çalıştığı şey çok da yanlış değil. Problem, bu durumun ülkemizde pek de geçerli olmamasında. Çünkü ülkemizde proje sahibi olan işletme, proje yapan karşısında genel olarak daha güçlü durumdadır, çünkü alternatifi vardır ve yine genel olarak yazılım kalitesi konusunda çok da bilgili olmadığından, alternatifler arasındaki seçimde maliyetten yola çıkarak karar verir. Bu da proje için teklif veren yazılım evlerinin maça zaten 1-0 yenik başlamaları demektir. Tabi projeyi yapan yazılım evi, maçın rövanşını bakımda alır, kilit (vendor lock-in) denen durum yani. 🙂

9. kare (How it was supported – Canlı sistem nasıl desteklendi) bakım ve destek üzerine. Tabi bakım konusunda da durum çok karmaşıktır: Bakım neyi kapsar örneğin? Hataların düzeltilmesi mi, yeni versiyonlar mı yoksa müşterinin kendine has istekleri mi? Tabi müşteri bunlar arasında pek ayırım yapmama taraftarıdır ve bu durumda da işler karışır. Baştan yanlış anlayış üzerine kurgulandığında projeler, ya zaten bakım  noktasına gelemezler, çünkü öncesinde iptal edilirler ya da geldiklerinde çok ciddi sıkıntılar vardır ve bakımın çerçevesi çoktan değişmiştir.

Son kare zaten olması gerekeni anlatıyor. Belki proje sahibi, projenin son halini görünce, “yok canım benim istediğim sadece şöyle bir şeydi” diyerek bu resmi çiziyor. Adamın kafası net artık, ama çok geç. Zamanında düşünseydi ihtiyacının ne olduğunu, belki problem daha ikinci, en çok üçüncü karede düzeltilirdi.

Bu resimler yazılım projelerinin en temel probleminden bahsediyor: İletişim. Yazılımın kavramsal olan tabiatı, onunla ilgili hemen herşeyin aktarımını zorlaştırır. Aynı masanın etrafında oturan insanlar saatlerce çok temel bir şeyden bahsederler, anlaştık diye masadan kalkarlar ve daha sonra tekrar bir araya geldiklerinde konuşulan ve anlaşıldı zannedilen konu üzerine bir o kadar daha konuşurlar. Sebebi, sadece biz Türklerin, dili yanlış ve etkin olmayan bir şekilde kullanıyor olmamız değildir. Evet biz zaten, “çok belirli bir saatte ve noktada buluşmak” kadar sade ve anlaşılır bir şeyi bile en az 10 dakikalık bir telefon konuşmasında hallederiz ve bu konuşma sırasında da en az 10 defa “oldu”, “tamam”, “ok” cinsinden kelimeler kullanırız. Ama yazılım görülebilen bir şey değil, dolayısıyla da tabiatı itibariyle üzerinde konuşulması zaten zor olan bir alan. Ya Wittgenstein’ın dediği gibi konuşulabilecekler üzerine konuşur, konuşulamayacakları sessizce geçeriz ya da “şeyleri”, konuşulabilecek düzeye çıkarırız.  Aynı masanın etrafında olanlar, iş süreçleri hakkında asgari ve standart bir bilgi birikimine sahip değillerse büyük bir ihtimalle konuşmaya en temel tanımlardan başlamaları gerekir. Ülkemizdeki iş süreçlerinin pek de standart olmaması, her kurumun, işini kendi yoğurt yiyişiyle halletmesi, iletişimi daha da zorlaştırır.

Herhangi bir yazılım projesinden bağımsız olarak, kurumlar, çalışma şekillerini süreç olarak belgelemediği, süreçlerini iyileştirip standartlaştırmadığı, hatta varsa süreç olmayan işlerini tesbit edip, süreç tabanlı hale getirmediği sürece, kendi ortamlarında zaten bir konuşulamaz alan ya da iletişim problemi yaratıyorlar demektir. Böyle bir yapı için yazılım üretmek, süreç tabanlı olmayan, büyük bir ihtimalle de verimli olmayan iş yapış şekillerini, büyük paralar dökerek yazılım ile iyice kemikleştirmekten başka hiçbir işe yaramaz. Yani eskiden kötü olan bir yapı artık kötü bir yazılım sistemine dönüşmüştür. Bu şekilde süreçlerini düzenleyip basit ve standart hale getirmeyen kurumlarda da yazılım projesi yapmak son derece zordur, proje sırasında süreçler mi kurgulanacak ya da iyileştirilecek yoksa yazılım mı gerçekleştirilecek, herşey birbirine girer. Bilgi yönetiminde “gizli” (tacit) denen ve insanların zihinlerinde var olan bilginin, açık ve nesnel (explicit) hale getirilmesidir aslında süreçlerin belirlenmesindeki ilk adım. Ve en zor taraf ta burasıdır zaten. Çünkü bunun önünde, çalışanların kendilerini koruma içgüdülerinden tutun da ifade zorluklarına kadar pek çok zorluk ve engel vardır. Sağlıklı yazılım projeleri, ancak, çalışanların zihinlerindeki bilgileri, asgari miktarda açık ve nesnel hale getirip, süreçlerini standartlaştırmış ortamlarda yapılabilir. Aksi taktirde bir koltukta iki karpuz taşınmaz.

Dolayısıyla, bu resimlerde ifade edilenleri yaşamamak için, projelerde iletişimi daha sağlıklı hale getiren her yol denenmelidir. Önce süreçler belirlenmeli ve sağlıklı bir şekilde uygulanabilir hale getirilmelidir. Sonra da yazılım projesine has, yeteri miktardaki belgeler, eskizler, diyagramlar, sözlükler, prototipler, testler vs. yardımıyla, iletişim sağlıklı olarak yürütülmelidir.

Toplam görüntülenme sayısı: 6401