Biliyorum ki sosyal medya başarı hikayelerinin vitrine konulduğu bir yer. Burada ışıltılı sahneler ve mutlu kareler sunuluyor oysaki çoğumuzun serüveni yenilgilerle dolu.Bunları anlatmıyoruz. Dijital dönüşüm ve yazılım projelerinin mutfağında çok sayıda geri dönüşler ve bir türlü olduramadıklarımız var. Bu yazıda hedefe ulaşamadığımız bir projenin anatomisini kaleme almak istedim.
Bir dönem yazılım projesinde yoğun bir çalışma yürüttüğümüz, inşaat sektöründe proje bazlı çalışan bir markanın patronu ile bir araya geldik. Müşterimiz tanışmamızdan önce CRM alanında birkaç yazılım ürününü kullanmış ve memnun kalmamıştı. Alternatif çözümler arasında detaylı görüşmeler yapmış birkaç rakip arasında kısa listeye kalmıştık. Değerlendirmeler sonucunda fiyat olarak yüksek kalsak bile bizimle çalışmaya karar vermişlerdi. Buraya kadar her şeyin normal göründüğünün farkındayım. Hikâyenin devamına geçmeden birkaç parantez açalım.
Yazılım firmaları arasında seçim yapılırken, aday firma sayısı söz gelimi 5 den fazla olduğunda, firma her bir firmanın kendince güçlü yanını not alıp bütün hepsini tek bir firmanın karşılaması gibi bir beklentiye kapılıyor. Oysaki firmaların güçlü yanları, sahada olgunlaşan taklidi kolay olmayan karakteristik rafine özelliklerden oluşuyor. Bu yüzden seçim yapılan firmadan bütün seçeneklerdeki beğenilen yanları üzerinde taşımasını beklemek gerçekçi değil.
Hem spor, hem yakıt tüketimi düşük, hem en güvenli, hem prestiji en üst seviyede, tasarımı en çok hoşumuza giden ve bakım maliyetleri tüm seçeneklerden daha ucuz bir araba modeli olamaz. Bunun gibi, ERP, CRM gibi başlıklar altında yerli ve global seçeneklerin tüm güçlü özelliklerini tek başına üzerinde toplayan bir seçenek aranmamalı.
Proje Kapsamının netleştirilmesi
Türkiye’de dijital dönüşüm çalışmalarında çoğu zaman işin nerede başlayıp nerede biteceği ile ilgili net bir tanımlama bulunmuyor. Kabul edelim , sadece kobilerde değil, büyük ölçekli işletmeler ve önemli markaların işlerinde de sözlü ve şifahen yürütülen görevlerle doluyuz. 20 yıldan fazladır yürüttüğümüz projeler ve yazılım devreye alma süreçlerinde, genel olarak zaman baskısı altında çalıştık. Sürekli yetiştirmek için çabalarken, önümüzde bitiş çizgisi genel olarak varsayımlar üzerinden yürütüldü. Saha tecrübesi, yetkinlik, iyi niyet gibi faktörler belirsizliği aşmakta işe yarayabilir ama yazılım ekiplerini işten çok netleşmeyen beklentiler yoruyor.
Hayır demeyi bilmek ve işin iptal olması
Güzel insan Alev Alatlı’nın “Hayır diyebilmeli insan” kitabında anlattığı gibi tüm istekleri olumlu karşılama tavrı, sanılanın aksine yıkıcı etkilere sebep oluyor. Projelerin sonuçlanması veya sürdürülebilmesi önündeki en önemli beş engel sayılsa bir tanesi de isterlerin disiplinsiz bir şekilde sürece dahil edilmesi diyebilirim. Yazılım firmaları üzerine boca edilen çeşit çeşit isteği, bazen müşteri memnuniyeti adına bazen geç kalmışlıkların telafisi için, kimi zaman da ilave geliştirme ücreti uğruna iş listesine ekleyiveriyor. Yönetilmesi zor ama projenin istikrarı için müşteri ilişkilerini doğru yönetmek ve güzel iletişimi bir şekilde bozmadan, “doğru zamanda HAYIR diyebilme yetkinliği” işin bam teli.
Hikayemize geri dönecek olursak, bu markanın proje geliştirme işini 7-8 ay üzerimizde taşıdıktan sonra proje iptal oldu. Biz haklıydık, onlar haklıydı demeye getirmiyorum. Aklımda kalan bizim tam hazır olmadığımız, müşterinin sabırsız olması, aşırı iştahlı bir tavır altında şu özellikte olsun sistem böyle de davransın sözlerinin havada uçuşması ve bu süreçte beklenti ile bütçenin ve proje takviminin uyuşmaması gibi durumları hatırlıyorum. Velhasıl proje sonlandı. Böyle projelerde iptal edilmesi elbette ki üzücü fakat doğru olan her zaman sevindirmez. Aradan 1 yıldan fazla geçti. Müşterimiz bizi aradı ve tekrar bir araya gelip, yazılım projemizi incelemek istediğini ve belki de yeniden çalışabileceğimizi belirtti.
Bizde yazılımda geldiğimiz aşamayı sunarak, bu yarım kalmış hikâyeyi bu sefer iyi bir sonuca taşıyabileceğimizi düşündük. Ekibimizden kıdemli arkadaşlarımla toplantıya gittik. Sunum esnasında defalarca “çok güzel olmuş” sözünü duydum. Sunum yaparken masadakilerin etkilenişleri, beğenileri ve aklında beliren soruları büyük bir dikkatle önemsiyorum. Buradan beslendiğimiz doğrudur. Bununla birlikte “şöyle de yapıyor mu?” şeklinde gelen bütün soruların hepsine birden evet yapıyor diyemiyoruz. Geçmiş yıllarda (hatta gençlik yıllarımda diyeyim) bunu önemli bir eksiklik olarak algılardım. Zaman şunu öğretti: bir iş yazılımı beklentinin tamamını karşılayamaz. Hazır paket çözüm %90 lar seviyesinde beklenenlerin omurgasını taşıyorsa ihtiyaç ile doğru bir eşleşme noktasındayız demektir. Tek bir uygulama üzerinden her şeyi birden karşılamanın milyon dolarlık bütçeli işlerde bile gerçekleşmediğini kabul etmek gerek. Bu yüzden her biri kendi alanında iş yapan yazılımlar arasında entegrasyon sağlanıyor. İlave geliştirmeler ile sistemler daha fazla uyumlu hale getiriliyor. Yine de bazı kör noktaları ve detayın detayı bazı senaryoları yazılım içine alıp, tüm ihtimalleri ele geçirmeye çalışmak, sistemi hantallaştıran, pahalı ve yıpratıcı bir girdaba dönüşebilir.
Yeniden hikayemize dönecek olursak, bizden sonra iki farklı global yazılım ürünü ve bir başka yerli firma ile çalışmışlar ve tam olarak kendilerine adapte edemedikleri için vazgeçmişler. Bilin bakalım ne olmuş? “Yazılımı kendi içlerinde yazmaya karar vermişler.” Bunun için ekip kurmuşlar ve harcadıkları milyonlarca masraf sonucunda spesifik birçok şey yapan bir çalışma ortaya çıkmış. Henüz kullanıma geçmemişler. Yakında bitecekmiş. Anladım ki, toplantı yeniden birlikte çalışma iradesi ile değil, kendi içlerindeki çalışmanın hangi seviyeye ulaştığını kıyaslamak içinmiş. Toplantıya davet etmeden önce bunu açıkça ifade etselerdi yine de katkı verirdik. Böylesi yaklaşımlar, kesinlikle şık değil. İş hayatında şeffaflık ve nezaket ayrı bir başlık olsun.
Velhasıl benim öngörüm şu: birkaç milyon daha harcayacaklar. İç bünyede geliştirilen bir çalışma, pazara sunulan bir yazılımın olgunluk seviyesinden belirgin seviyede uzak kalacak. Sonuca ulaşılsa bile ürün üzerindeki isterleri disipline edemeyecekler ve ilgili ilgisiz her şeyi yazılımın üzerine yüklemeye devam edecekler. Yazılımı yaşatmak ile ilgili tüm maliyetleri tek başına üstlenecekler. Güvenlik, performans, arayüz etkileşimi, yazılım kalitesi gibi ölçümlemelere bir türlü sıra gelmeyecek. Yazılım ekibini böyle bir projenin arkasında tutmak için gereken motivasyonu karşılayamayacaklar ve en nihayetinde binlerce satır kod ile baş başa kalınacak.
Bu yargı cümlelerini nasıl mı kuruyorum? Bu zamana kadar, farklı sektörlerde faaliyet gösterip iç bünyede kendi yazılımını üretmeye kalkışan ve pahalı bir üretim yolculuğundan sonra hedeften çok uzak sonuçlarla karşılaşan pek çok vakaya tanık oldum. Bugün kendi işinde belli bir hacme ve başarıya ulaşmış iş adamlarının teknoloji, otomasyon, yazılım konusunda istekli olmaları ve farkındalıkları, hiç şüphesiz çok değerli. Bununla birlikte yazılım geliştirmenin, nitelikli bir ekip tarafından derin ve inceliklerle dolu bir mühendislik faaliyeti ile yürütüldüğünü kavramak gerekiyor. Hatta yazılım şirketleri bile yazılım üretme konusunda genel olarak zorlanır. Kaldı ki sadece üretmek yetmez. Yazılımı yaşatmak için belli bir ekosistemin geri bildirimleri ile akışları beslemek gerekir. Bir de güncel teknoloji karşısında sistemi yenilemek gibi bir mecburiyet sizi takip eder.
Bütün bunları söylerken biliyoruz ki: girişimcilik ve üretim bir tutkudur ve kimse kimseyi aklına koyduğunu yapmaktan alıkoyamaz. Tamam dileyen dilediği yazılımı yazmaya kalksın, karışmayalım. Bununla birlikte gerçekçi olmak da iyidir. Yaşadığımız hayat ve zaman hepimiz için çok kıymetli. Diyorum ki: herkes inşaat yapmasın, herkes yazılımda yapmasın. Yazılımcıların yazılım, inşaatçılarında inşaat yapmasında fayda var 😊