Bir yazılım projesi nasıl patlatılır?
Yazılım projelerinin sadece %33'ünün planlanan zamanda tamamlandığını, sadece %24'ünün ise tamamlandıktan sonra başarılı kabul edildiğini biliyor muydunuz? Peki ya yazılım projelerinin %89'unun daha projenin başında başarısız olacağına inanıldığını?
Tek bir yazıda bütün sebepleri anlatmaya çalışırsak 300 sayfalık bir roman olabileceği için parça parça farklı yazılarda paylaşmak daha doğru olur diye düşündüğüm için her yazıda bir sebebi inceleyeceğim. Yazılarda gerçek hayattan hikayeleri kişi, şirket ya da proje adı vermeden, acı tecrübeleri anlatarak aktarmaya çalışacağım.
Doğru işi yanlış yapmak!
2014 yılında perakende sektöründe iş yapan bir firma e-ticaret sitelerine yatırım yapmak noktasında karar vermeye çalışmaktadır. Proje bir arkadaşıma verilir, o da ne yapmalı nasıl yapılır bu işler diye bana gelir. Oturup sitenin ziyaretçi rakamlarına yapılan satışa, sitenin mevcut deneyimine ve sorunlarına baktıktan sonra gerçekten tasarımsal ve işlevsel bir yenilemenin şart olduğunu, dönüşüm oranlarının çok düşük, gelen ziyaretçi sayısına göre yapılan satışın olması gerekenden çok az olduğunu anlattım. Sektör standartlarını araştırdıktan sonra düzgün çalışan, kolay kullanıma sahip bir sistem ile satışların çok rahat %30 kadar yükselebileceğini hesapladık ve ayrıldık. Benden aldıkları ile sunum yapan arkadaşım projenin yapılması konusunda yöneticilerini ikna eder.
Ve hikayemiz bu şekilde başlar.
Perakende sektöründe köklü bir firmanın e-ticarete yatırım yapması çok mantıklı ve doğru bir hareket olsa da bir sorun vardı, şirket bünyesinde bir yazılım ekibi bulunmuyordu. Yazılım işlerini anlaşmış oldukları bir firma ile hallediyorlar ya da hazır paket programlar satın alarak hayatlarını sürdürüyorlardı.
Klasik olarak çeşitli firmalardan teklifler aldılar ve en sonunda en iyi teklifi veren bir çok banka ile de çalışan bir yazılım şirketi ile anlaştılar.
Ne istediklerini anlatıp tasarım çalışmaları tamamlandıktan sonra süreç tamamen yazılım firmasına kaldı. 5–6 aylık bir geliştirme süresincinin ardından yazılım ekibi geliştirmeyi tamamladı. Bunu takiben yaklaşık 1 aylık bir süreçte yeni sistemin kabul testleri yapıldıktan sonra yeni arayüz yayına alındı.
Yeni siteleri açıldıktan sonra arkadaşım benim de fikrimi sordu. Girip kullandığımda gerçekten akıcı bir deneyim sunduğunu, kullanıcı deneyimi açısından gayet başarılı olduğunu söyleyebilirim.
Projenin yayına açılmasından sonraki ilk hafta yapılan satışlarda %20 civarı, ikinci hafta ise %50 civarı bir yükselme yaşanır. Sitenin trafiği artık öngörülen satış sonuçlarını da getirmeye başlayınca şirketin bir anda dijitale bakış açısını değiştirir. Ayda 150 bin lira ciro yapan site kısa sürede bunu 1 haftada yapabilir hale gelir. E-ticaret ile ilgilenen 2 kişilik ekibin en kısa sürede 15–20 kişiye çıkartılması için düğmeye basılır.
Peki madem her şey bu kadar mükemmel, sonuçlar bu kadar iyi proje nasıl patlatılır diye bize niye bunları anlatıyorsun dediğinizi biliyorum. Ama olaylar zaten bundan sonra başlıyor.
Herkesin gözünün bir anda e-ticarete döndüğü, insanların işe alınmaya başladığı bir ortamda sitenin önemi ve değeri bir anda yükselir. Fakat bir sorun vardır, gün be gün yapılan satışların sayısı yükselmek yerine düşmeye başlar. Sadece 2 hafta içerisinde site eski halinden de kötü satış yapmaya başlar. Ziyaretçi sayısının bir anda azaldığını hatta çakıldığını fark eden arkadaşlar bir danışmanlık firmasına giderler ve ilk incelemeden sonra problemin sebebi ortaya çıkar;
Sitenin trafiğinin %80'den fazlası organik trafikten gelmekteydi, fakat geçiş sonrası arama motorları artık siteyi tarayamıyordu! Çünkü proje AngularJs ile Single page application olarak kurgulanmıştı ve arama motoru artık siteyi tek bir sayfa olarak görüyordu!?
Peki böyle bir hata nasıl olmuştu?
Şirketin e-ticaret veya dijital dünya ile ilgili pek bir fikri yoktu. Ne istediklerini dışarıdan gördükleri bir kaç dünya çapındaki e-ticaret sitesine bakarak çıkartmış, “Bunun aynısını istiyoruz!” kıvamında bir talepte bulunmuşlardı sadece. Yazılımı yapacak firmaya ihtiyaçlarını bilmedikleri için haliyle bu ihtiyaçları aktaramamış onları yönlendirememişlerdi. Trafiklerinin bu kadar büyük bir kısmının arama motorlarından geldiğini bilselerdi projenin başında bunu yazılımı geliştiren ekibe kırmızı çizgileri olarak aktarabilir, bunun için projenin optimize edilmesini isteyebilirlerdi.
Eee peki yazılım firmasının hiç mi suçu yok?
Projeyi geliştiren yazılım firması bir çok banka ile çalışıyordu ve geliştirdiği projelerin büyük bir kısmı internet bankacılığı ya da şirket içi (intranet) kullanım içindi. Web projeleri geliştirmek konusunda çok büyük bir tecrübeleri olsa da arama motorları konusunda hiç bir fikirleri yoktu. Her zaman yaptıkları gibi son teknoloji ürünü bir sistem geliştirmişlerdi.
Projede her zaman kullandıkları bir yapı ile ilerlemişlerdi, bütün geliştirdikleri projeleri bu şekilde tek sayfalık uygulamalar olarak geliştiriyorlardı. Bu şekilde aşina oldukları bir dünyada daha hızlı bir şekilde üretebiliyorlardı. Fakat kullandıkları yapı, yaptıkları işe uygun değildi.
Yazılım geliştirirken çoğu problemi aynı araçları kullanarak çözebilirsiniz. Fakat kullandığınız araçları ne kadar harika kullanıyorsanız kullanın, o araçlar problemi en kolay şekilde çözmenizi sağlayacak araçlar olmayabilirler.
Bir ürün listeleme modülünü MsSql üzerinde yazdığınız stored procedure ile de çözebilirsiniz, elasticsearch üzerinde geliştirmiş bir çözüm ile de. Aradaki fark kimi zaman performans, kimi zaman yeni özelliklerin daha kolay eklenmesi, kimi zaman ise yaptığınız işe daha uygun bir araç olduğu için çok daha hızlı bir çözüm üretiyor olabilir.
Yeni kurulmuş bir startup projesini microservice mimarisi ile yazmaya çalışmak, uzayan süreler sonucunda geliştirilen proje canlıya çıkmadan startup’ın batmasına neden oluyorsa, microservice mimarisinin yanlış olduğunu söyleyemeyiz. Ama yapılan işin o şirketin ihtiyaçlarından fazlası olduğunu ve o proje için gereklilik değil aksine ayak bağı olduğunu söyleyebiliriz.
Bunun bir başka örneği ise yeni gelen yazılımcının her zaman eski yazılımcının koduna bok atmasını gösterebiliriz. Defalarca duyduğunuz bir başka durum ise bir şirketin yazılım departmanının yöneticisi ya da şirketin CTO’su değiştiğinde yeni gelen kişi projenin dilini değiştirmek gibi bir sorumsuzluğa girişmesidir. “x programlama dili yerine bu projeyi y programlama dili ile baştan yazacağız çünkü y programlama dili daha güzel daha ateşli, daha seksi” gibi bir cümle duyduğunuzda yapmamız gereken “y” programlama dili ile yapılabilen ama “x” ile yapılamayan bizim domainimizde ne var sorusunu sormak olmalı. Eğer burada gerçekten spesifik bir probleme çözüm var ise buna hak vermek mümkün olabilir, ama bu körü körüne yapılan geçişler çoğu zaman eski developerların yerine kişinin kendi ekibini kurma çabasından ya da mevcut programlama dili ile ilgili çok tecrübesi olmadığı için kendini güvende hissetmemesinden kaynaklıdır. Tabiki eğer asp ile yazılmış bir web siteniz var ve bunu başka bir platforma taşımak istiyorsanız kimse size neden demeyecektir, ama bu proje java ile yazılmış scala yapalım, yok efendim c# ile iş mi yapılır bunu nodejs ile değiştirmemiz lazım gibi sözler duyduğunuzda arkanıza bakmadan topuklarınız vura vura kaçmanız faydanıza olacaktır.
Bu tip geçiş projelerine girişip yöneticinin süreç içerisinde sürekli değişmesi sonucu, çünkü genellikle bu projeler başarısızlıkla sonuçlandığı için harcanan kaynak ve zaman sorgulandığında genellikle bu işe girişen yöneticiyi koltuğundan eder, bir anda karşınızda 4 farklı programlama dili ile parça parça yazılmış garabet sistemler ile karşılaşabilirsiniz. Bir şirketin yazılımcı gibi pahalı ve zor bulunan bir kaynağı bu kadar hoyratça sadece kişisel düşünceler üzerinden, hiç bir planlama ya da sorgulama olmaksızın değiştirmesini mantıklı bulmamız söz konusu olamaz sanırım.
Mevcut yapının geliştirme süreçlerine olan olumsuz etkilerini çözmeye çalışmak buradaki doğru yaklaşım olacaktır. Elimizde bir ekip var ve belki de 5 yıldır geliştirilen bir platform var. Bunu 2 ayda değiştirebileceğine inanmak en basit tabiri ile naifliktir diyebiliriz.
Bu konuyu belki de başka bir yazıda tartışmak çok daha mantıklı olacaktır yoksa ben sabaha kadar bu arkadaşlara sövmeye devam edebilirim (:
Çoğu zaman insanlar bu tercihleri daha güvende hissettikleri alanda kalmak için yaparlar. Kendilerine yeni gelen ya da bilmedikleri bir şey ile uğraşmak yerine güvenli bölgelerinde işi bildikleri gibi yapmak onlar için riski azaltıyor gibi görünse de aslında bambaşka problemlere sebep oluyor ya da aslında çok daha az efor ile yapabileceğiniz bir iş için gereksiz zaman ve kaynak harcıyor olabilirsiniz. Wikipedia’da law of the instrument tanımında psikoloji ile birlikte programlamanın da anılıyor olması aslında bu hatanın ne kadar sık yapılan bir yanlış olduğunu anlatmaya yeter sanırım.
Sadece daha “cool” daha “trend” olduğu ya da yeni çıktığı için projede bir teknolojiyi kullanmaya karar veremezsiniz. Kullanmak istediğiniz araçların yapacağınız işe uygun olması, projenin ve müşterinin ihtiyaçlarını karşılıyor olması gereklidir.
Bir sonraki bölümde görüşmek üzere, “Hype driven development nedir?”
