Neden Sadece Bir IT Projesi Olamaz!

Yine, yeniden deneyimlediğim bir durumla yazılım işlerinin neden sadece bir kod projesi olmadığını bir parça izah etmeye çalışacağım. Çünkü çevremde daima böyle bir algıya şahit oluyorum. Başarısızlığın ardındaki sebepleri bu algının kuvvetiyle doğru orantılı olarak görüyorum.

Buraya ilk geldiğim dönemde bir yazılım firması ile işe başlanmış ve hatta "ha bugün ha yarın" projeyi teslim ediyoruz aşamasına bile gelinmişti. Elbette geçmiş tecrübelerim ışığında içimde şüphe yüksek ama, ulan ya dedikleri gibiyse diye de aklıma gelmiyor değil. Çünkü sadece hep övgü duyuyordum. Yani 10 numara 5 yıldız bir proje.  Bu bekleme sürecinde burada neler oluyor, işleri nasıl yapıyorlar kısmı ile ilgilenmeye başladım ki, durum hakikaten vahim denilecek düzeyde; bazı şeyleri gördükçe yok artık dediğim oldu; inanılır gibi gelmiyor ama işler öyle yürüyormuş. Beklentimin çok daha altında bir durum vardı. Tabi yapılmak istenenlerin önünde engel teşkil ediyorlar. O nedenle projenin acilen teslimi daha fazla önem kazanıyor. Bu süre uzamaya başladı derken, yapılan kısmı görelim, veritabanına bakalım derken ufak ufak işin içine girmeye başladık. Derken elime projenin analiz dosyası geçti, inceledim. Ihhh, alt başlıklar ve minik izahlar var sadece. Yeterli bilgiyi vermiyor. Kimi mantıksal akış sorunları görünüyor ama detay bulamıyorsunuz. Anlaşma bu şekil bir analiz üzerine olmuş.



Süre geçiyor, henüz teslimat yok. Gerginlikler başlıyor. Hızlanılıyor ve gecikmeli de olsa ilk test ekranları önümüze geliyor.

Ne yapıldığını anlamaya çalışıyorum. Şirket içinde çok kullanılacak olan ekrana giriyorum ve hatalar başlıyor. Hatalar olduğu için sonraki aşamaları göremiyorum ve  bu nedenle yapıyı anlamakta zorlanıyorum. Düzeltiliyor, peşinden başkası derken hatalar nedeniyle ilerlenemiyor. İlk başlarda çok sesimi çıkartmıyorum, çünkü yapılan işi henüz anlamadım ve anlamadığım bir yapı üzerinden konuşmak pek akıllıca gelmiyor. Elimde henüz yeterli done toplayamıyorum. Bu arada küçük toplantılara başlıyoruz, süreç ve yazılım ilişkisini kurmaya başlıyorum. Bu arada veritabanına erişim yetkisini nihayet alıyorum. Veritabanı hakkında ilk izlenimim olumlu oluyor. O konuda mühim bir sıkıntı görünmüyor. 

Ancak hatalar sona ermiyor. İlerlemeler oldukça süreç ve yazılım arasındaki problemler, mantıksal hatalar kendini göstermeye başlıyor. Veri arama, bulma, kaydetme ve gösterme şekilleri, yetkilendirme problemlerini gösteriyorum. Belirli bir akış, kullanıcı dostu ekranlar olması gerektiğinden dem vuruyorum. Ortada yazılımcının belirlediği ve dikte ettiği ekranlar var sadece. Neden böyle yaptınız, olması gereken bu şeklindeki soruma öyle istendiği cevabı dönülüyor ve proje dosyasında bulunduğu belirtiliyor. Evet proje dosyasında o var ama şöyle şöyle yapılacak şeklinde bir detay yok. Kendi aralarında yapılan toplantılarda öyle karar verilmiş deniliyor. Açıkcası bir çıkmaza doğru gidiyoruz. Üstelik en mühim, her yeri etkileyen ve çok emek verilmiş ekranlardan birisinde tamamen mantıksal ve yapısal sorunlar var. 

Tabi projenin canlı ortama geçmesi uzadıkça uzuyor. Yazılım firması ile gerginlikler başlıyor. Projenin en başında bulunmadığım için sorumlu olduğum bir durum yok ama bu gerginlikler ister istemez bana da yansıyor. Bu arada projenin nasıl geliştiğini, neden öyle yaptıklarını karşılıklı sohbetlerle öğrenmeye başlıyorum. Bu arada bana söylenmeyen, belki saklanan kimi durumları farketmeye başlıyorum. Analiz yapılırken ilgili kişiler şirket departmanlarıyla görüşmüş, mevcut destek ekibiyle ve diğer personellerle kısa çalışmalar olmuş ve bu doğrultuda bir analiz yapmış. Ne analiz yapanın ne de mevcut personelin daha önce sektöre dair bir tecrübesi yok. Herkes kendi ihtiyaçları, görmek istedikleri doğrultusunda birşeyler söylemiş, burada bir sıkıntı yok. Bunların tamamı da projeye dahil edilmiş. Ama herkesin söylediği, birbirleri ile olan ilişkisi, öncelik ve sonralık ilişkilerinin belirlenmesi, ekranların tasarımı ve çalışma mantığı kodu yazan kişinin inisiyatifine kalmış. Bir de sonradan üzerine eklenecek süreçler var ki, onlara dair hiçbir çalışma yok. Yapılanlardan bir örnek vermem gerekirse; mesela bir checkbox ile bir durum işaretleniyor, bu bilgi tutuluyor ama bu işaretin sonucu olacak durumlara dair hiçbir çalışma yok. Sadece bir işaretleme. O kısımlar ne analizde var, ne de kodlanmış. Hani var mı var durumları. Yani işin aslı şu: analiz, gerçek manada bir analiz değil. Hedeflenenlerle, yapılmaya çalışılanlar örtüşmüyor. Analize katkıda bulunanlar ile analizi yapanların hem iş tecrübeleri yetersiz, teknik tarafları zayıf, hem de sektörü bilmiyorlar.

Proje kesin başarısızlığa doğru gitmeye başlıyor. Bunu artık açık açık seslendiriyorum. Çünkü bu haliyle uygulamaya alınma şansı hiç yok. Alınabilir hale dönüştürülse bile beklentilere cevap verecek bir yapı değil. Oturup, minimum nelerin çalışır duruma getirilerek uygulamaya alabilirizi bulmaya başlıyorum. Neleri çıkartalım, neleri hangi aşamada düzeltelim, neleri uygulamanın hemen sonrasında, neleri sonraki aşamalarda düzeltiriz tespitlerine başlıyorum. Bir ufak ek proje ortaya çıkarıyorum. Firma bunların bir kısmının mevcut proje içinde olmadığını söyleyerek o kısımları yapmak istemiyor. Çünkü hem çok temel süreçlerde ve ekranlarda mühim, yapısal değişiklikler yapıyorum hem de kendi projelerine o kadar inanmışlar ki, benim söylediklerimin hatalı olduğunu düşünüyorlar. Evet bir kısmı projede yok ama bu sektörde iş yapıyorsan bunların böyle olması da gerekiyor. Örnekler veriyorum ve elbette bunu çürütecek donanımları olmadığı için mecburen kabul ediyorlar. Eğer bu şekilde düzeltilmezse mevcut haliyle koca bir çöp diyorum. Bu başarısızlığın sonuçlarına hem firma, hem de yazılımı yapan olarak sizler ortak olacaksınız. Yani bir başka deyişle artık masaya elimi vuruyorum. 

Biraz geçmişi deşiyorum; şirket içinde karşılıklı görüşmelerimizde daha önce neler olmuşu öğrenmeye başlıyorum. Proje, büyük umutlar ve büyük vaadlerle başlamış. Oturduğun yerden herşeyi görecek, herşeyi yöneteceksin şeklinde bir ortada bir vaad var. Bunu sağlayacak herşey projeye dahil edilmiş. Konuşulan, adı geçen herşeyin olması elbette tarafların keyfini arttırmış. 

Ben yaşanacak sorunlardan, hatalardan, zorluklarından, harcanması gereken emekten, masraftan yani realiteden bahsettikçe ufak ufak ayaklar yere basmaya başladı. 

Neyse, ek projeyi başlatıyoruz. Zar zor da olsa tamamlıyor ve uygulamaya alıyoruz. Daha çok şimiz var. Bu arada yazılımsal sorunlardan ziyade, mantıksal sorunlar daha çok başağrıtıyor. Ufak ufak onları bizi idare edebilecek şekilde dönüştürmeye başlıyoruz.  Bir kısmını sonraya bırakıyoruz. İlk plana göre % 10 fazla maliyetle birinci fazı tamamlıyoruz. Halbuki başarısızlığı kesin ve sorunlu bir proje için en az 2-3 kat fazla maliyet beklenirken bunu % 10 seviyesinde tuttuk. Kısa zaman aralıklarında güncellemeler yaparak şirkette tespit ettiğim mühim problemleri de yazılım aracılığıyla ortadan kaldırmaya başlıyorum.

Bu kadar laf kalabalığı yaparak bu örneği niçin verdim?

Pek çok yazılım projesi aynı yaklaşımların sonucu olarak başarısız oluyor. Bir yerlerde gördüğüm rakama göre bu tip projelerde başarı oranı sadece % 30. Bir başka yerde % 8, % 3 gibi rakamlar bile gördüm. 

Yazılım projelerinin aslında sadece bir kodlama işi olduğu düşüncesi buradaki  tarafların bakışı olarak kendini gösteriyor. Hem şirket, hem yazılım firması bu şekilde kabul etmiş ve bu konuda fikir birliğine varmışlar. Tüm sorumluluk IT'cilere atılmış ve IT'ciler de tüm bu sorumluluğu almışlar. Hani sen bilirsin denmiş, onlar da evet ben bilirim demişler. 

Aslında bu hatalar pek çok projelerde aynı şekilde ortaya çıkıyor. Nedense proje sadece bir kod projesi olarak alınıyor? Arka plandaki kocaman bir operasyon, business bir anda geriye kalıyor. Ayrıca yazılımla birlikte herşeyi düzeleceği sanılıyor. Havada sadece hayaller uçuşuyor. Halbuki o sadece bir yazılım; güncel yönetim ve operasyon kaynaklı sorunları çözmez. Size vereceği en fazla şey bunların teşhisini kolaylaştırmak olur. Bir mucize yaratıp herşeyi size sunmaz. Sadece talep edilenleri ortaya döker. Talep edebilmek için önce bilmek gerekir. 

Proje başından sonuna bir kerede tasarlanmış ve kodlanmaya başlanmış. Aynı şekilde bir kerede bitecek ve herşey güllük gülistanlık olacağı düşünülmüş. Yazılımcının yaptığı minik kod testleri dışında ara testler hiç yapılmamış, ekranlar ve mantıksal akış konusunda yeterli tartışmalar yapılmamış. Farklı kullanıcılar, müşteri görüşüne başvurulmamış. Şirket tarafında projenin net bir sahibi olmamış. Ortada işin uzmanı olacak kimse bulunmamış.

Örneklemem gerekirse sadece müşteri kodunun üretiminde kurulan mantığı düzeltebilmek bile bizi çok uğraştırdı. İş sadece kod ve veritabanı tarafında bir düzeltmeden ibaret değildir. Satışından, ürünün faturalandırılmasına kadar pek çok yer etkilenmektedir ve bunun bütün aşamalardaki geçişini tereyağından kıl çeker gibi halletmek gerekmektedir.

Yazılım, aynı zamanda yürüyen operasyonu yola koyacakken, operasyonun nasıl yürümesi gerektiğini yanlış bir şekilde dikte ettirmiş. Mevcut akış, operasyonel sorunlar, kullanıcı hataları yeterince dikkate alınmamış. Çeşitli ilişkiler var ama ilişkilerin yönetimi yoktu. Kimi süreçler var ama onun öncesi süreç yahut alt süreçleri yoktu. Herşey idealize edilmiş bir yapı üzerinden planlanmış. Gerçek iş hayatında tek bir gün bile yoktur ki sorunlar olmasın. Buradaki bilgileri size kullanıcı vermez. Kullanıcıdan aldığınız bildirimler üzerine planlarsınız. Kullanıcı nerelerde hata yapar, nasıl düzeltir bunları düşünmelisiniz. Neden yok diye sorduğumda kimse istemedi diye verilen cevabın altındaki neden tecrübe eksikliğidir.

Süreçler ve süreçler arası bağlantılarda kopukluklar mevcut. 

Ekran tasarımlarında kullanıcı dostu olması çok mühim. Kullanıcıyı hem çalışırken yormayacaksınız, asla ekranı beklemeyecek, hem de mümkün olan en düşük seviyede bir eğitimle, hatta hiç eğitim vermeden uygulamaya aldığınızda sorunsuz olarak rahatlıkla çalışabilir olacak. Gerekirse geçiş sürecini kaynaklarınızı rahat kullanabilmek adına birkaç aşamada da yapabilirsiniz. Yaptığı her işlemin sonucunu da kullanıcının görmesini (rapor) sağlamak durumundasınız. Elbette bu konuda eksiklik çok fazlaydı. Aşamalı olarak, kullanıcıyı alıştıra alıştıra ideal olana doğru kaydırdık. Buna mecburduk, çünkü hem yeterli kaynağımız yoktu, hem de kullanıcılardaki yerleşik alışkanlıkların işleri zora sokmadan ve aksatmadan, yani farkettirmeden kırılması gerekiyordu.

Yazılım planlanırken şirketin kaynakları, teçhizat ve donanım durumu dikkate alınmamış, herşey var ve olacak diye kabul edilmiş. Ama her yerde ideal ortam yok ve kurulması düşünülemez. Bambaşka bir sorun ama dolaylı bile olsa yazılımla organik bir ilişkisi oluyor.

Elbette bu tip bir projeyi ayağa kaldırmak kolay olmadı. Aşama aşama düzenlemeler yapılarak belirlenen öncelikler doğrultusunda uygulamaya alındı. Zaman içinde veritabanı ilişkilerine müdahale edildi, yeni alanlar yeni tablolar oluşturuldu. Üzerine inşaa edeceğimiz uygulamaların temeli sağlamlaştırıldı. Şirketin gelecek planları, yapmak istedikleri üzerine temel altyapıda ve mantıksal akışlarda düzenlemeler yapıldı. Özetle altyapı oturtuldu. Birinci faz sonrasında, ikinci faz uygulamaya alındı. Devamında dışkaynak olarak çözümlenen ihtiyacı içeriye bir yazılımcı alarak çözümlemeye başladık. Bu konunun da kendine göre sorunları olsa bile çok daha verimli olduğu kesindir. Halen ilk başta yapılan ekranların, kurulan mantığın yarattığı sorunlar zaman zaman karşımıza çıkmaktadır. Bir kısmı çözülme zamanını beklemektedir. Buradaki öncelik ihtiyaçların aciliyetine göre belirlenmektedir. 


Özetle yazılım projeleri asla tamamen ve sadece bir IT projesi değildir. Sadece IT'ye yahut yazılım firmasına ait bir proje de değildir. Arkasında ilgili ve doğru seçilmiş kişi ve departmanların bilgi birikimleri olmayan projelerin istikametinin çöp olması, yahut beklenen maliyetlerin katlanarak karşılanması kuvvetle muhtemeldir. İster in-house yazılsın, ister piyasada yazdırılsın, isterse hazır yazılımların uyarlanması olsun. Sonuç çok değişmiyor. İşinizi, süreçlerinizi, beklentilerinizi doğru ve iyi tanımlamadığınız sürece iyi bir yazılım yapamazsınız yahut uyarlayamazsınız. Yazılımın teknik becerilerinin sizin ihtiyaçlarınızla örtüşmesinin analizi de ayrı bir birikim gerektirmektedir.

Bu sadece bir örnekti ve bunu ilk kez görmedim. A şirketinin B yazılım firması ile çalışması yerine C yazılım firması ile çalışması da; aynı yaklaşım olduğu müddetçe aynı sonucu doğuracaktı. B veya C işi almak adına, bazen bir adım öne geçmek adına işe bu şekilde atlayacaktı. Yahut firma A firması değil, M firması da olabilir. Çünkü eğer karşınızdaki müşteri yeterli tecrübeye, teknik birikime sahip değilse; ayakları yere basan, gerçekleri söyleyen bir firma olarak iş alamazsınız. Bu büyük yazılım projeleri için değil; bir web sitesi projesi için bile böyledir. Ancak bir şekilde yaptırdığı, kullandığı yazılımla sıkıntı yaşamış, emek ve para harcayarak benzer tecrübeleri deneyimlemiş firma doğruları duymaya hazırdır. 

Burada değinmediğim pek çok husus da bu tip projelerde etken olarak var. Sadece bir yönünü ele almaya çalıştım.