Proje ne zaman batmaya başlar?
Her bilişim projesi benzer bir şekilde başlar. Hırslı planlar, takvim, ilk maketlerin sunumu ve birkaç ay içinde şirketin modern bir sistemi kullanacağına dair inanç vardır. Başlangıçta her şey umut verici görünür, ancak zamanla ilk gecikmeler ortaya çıkar. Teslim tarihi bir hafta, sonra bir ay ötelenir. Hata sayısı artar, yükleniciyle iletişim giderek zorlaşır ve gelen cevaplar şunlardır: "Biraz daha zaman", "Sadece küçük bir düzeltme" veya "Artık son aşamadayız."
Bir noktada, hazır bir ürün yerine şirketin kimsenin sahiplenmek istemediği yarım kalmış bir projesi olduğu ortaya çıkar.
Bu senaryo düşündüğünüzden çok daha sık yaşanır.
En büyük problem kod değildir
Çoğu girişimci, proje çalışmıyorsa suçun kötü yazılmış kodda olduğunu varsayar. Evet - bazen durum gerçekten budur. Ancak pratikte sorun çok daha derinlerde yatıyor.
Dokümantasyon eksiktir. Mimari "anında" oluşturulmuştur. Otomatik testler yoktur. Entegrasyonlar geçici çözümlerle yapılmıştır. Yeni fonksiyonlar tüm sisteme etkileri analiz edilmeden eklenmiştir. Sonuç olarak, küçük bir değişiklik bile yeni hatalara yol açar.
Bu biraz proje olmadan yapılan bir ev tadilatına benzer. Her bir oda hâlâ tamamlanabilir, ancak zamanla duvarların olması gerektiği yerde olmadığı, tesisatın rastgele döşendiği ve yeniden yapılanmanın giderek daha maliyetli hale geldiği ortaya çıkar.
Ne zaman "dur" demek gerekir?
Bir işletme sahibinin için en zor anlardan biri, mevcut yükleniciyle çalışmayı sonlandırma kararıdır. Birçok girişimci bu kararı gereğinden fazla geciktirir.
Neden?
Çünkü projeye zaten çok para harcandı.
Çünkü zaman kaybı olur.
Çünkü belki "hala işe yarar".
Psikoloji buna batmış maliyetler etkisi diyor. Ne kadar çok yatırım yaptıysak, mevcut yönün hiçbir yere götürmediğini kabul etmek o kadar zor olur.
Oysa bazen en iyi karar aynı probleme daha fazla bütçe eklemek değil, projeyi durdurup durumu sakinlikle analiz etmektir.
Her proje kurtarılabilir mi?
Hayır. - Ve bunu dürüstçe söylemek gerekir.
Onarılması, yeniden baştan yapmaktan daha pahalıya mal olacak projeler vardır. Kullanılan teknoloji eskimiş olabilir veya mimari, daha fazla gelişmeyi imkansız kılacak şekilde tasarlanmış olabilir.
Bu yüzden ilk adım asla söz vermek olmamalıdır.
İlk adım bir denetim olmalıdır.
Kod, dokümantasyon, altyapı ve süreçler dikkatle incelenmeden, mevcut çözümü onarmanın mı yoksa yeni bir proje başlatmanın mı daha karlı olduğu söylenemez.
İyi bir teknoloji ortağı, müşterinin duymak istediğini söylemez.
İş açısından en iyi olanı söyler.
Pratikte bir projeyi kurtarmak nasıl görünür?
İnanıldığı gibi programlamayla başlamaz.
Önce neyle karşı karşıya olduğumuzu anlamak gerekir.
Sistemin mimarisini, kod kalitesini, modüller arasındaki iletişimi, veri güvenliğini, performansı ve gelecekteki geliştirme imkanlarını analiz ediyoruz. Dokümantasyonu, değişiklik geçmişini ve kullanılan teknolojileri kontrol ediyoruz. Çoğu zaman birkaç gün içinde gerçek sorunun nerede olduğu anlaşılır.
Ancak o zaman bir eylem planı oluşturulur.
Bazen kodu düzenlemek ve birkaç kilit elemanı düzeltmek yeterlidir. Diğer zamanlarda belirli modüllerin yeniden inşası gerekir. Bazen en mantıklı çözüm, halihazırda ortaya konanlardan yararlanarak yeni bir sistem oluşturmaktır.
İki aynı proje yoktur.
Onları kurtarmak için de tek bir reçete yoktur.
Projeyi devralmak, yeni bir tane oluşturmaktan neden daha zordur?
Bu soruyu müşterilerden sıkça duyuyoruz.
Cevap basit.
Sistemi baştan yarattığımızda her tasarım kararını biliriz. Neden belirli bir çözüm seçildiğini ve hangi varsayımların yapıldığını biliriz.
Başkalarının projesini devralırken önce bu bilgiyi yeniden oluşturmak zorundayız.
Bu, planı, dokümantasyonu ve neyin yapıldığını gösteren bilgiler bırakmadan şantiyeyi terk etmiş bir ekibin ardından bir inşaatı devralmaya benzer.
Bu yüzden proje kurtarmak sadece programlama becerisi değil, aynı zamanda mimari, analitik ve tasarım deneyimi gerektirir.
Teknoloji ortağınız, sorun çıktığında da yanınızda olmalıdır
İyi bir yazılım şirketi projeyi nasıl başlattığıyla değil, zorluklar çıktığında nasıl tepki verdiğiyle tanınır.
Zorluklar ortaya çıktığında nasıl davrandığıyla tanınır.
Her şey öngörülemez. İş gereksinimleri, teknolojiler ve kullanıcı ihtiyaçları değişir. Önemli olan, ekibin çözüm bulabilmesi, riskleri açıkça iletebilmesi ve müşteriyle birlikte en iyi kararları alabilmesidir.
İşte o zaman güven inşa edilir.
Web24'te nasıl çalışıyoruz?
Devralma gerektiren projelere büyük bir özenle yaklaşıyoruz.
İlk görüşmeden sonra söz vermeyiz.
Önce durumu analiz ediyoruz. Nelerin yapıldığını, nelerin kullanılabileceğini ve nelerin yeniden inşa edilmesi gerektiğini kontrol ediyoruz. Ancak sonra bir tavsiye ve sonraki adımların planını hazırlıyoruz.
Amacımız bir sonraki binlerce satır kod yazmak değil.
Amacımız, projenin işin gelişimini gerçekten desteklemeye başlayacağı noktaya getirmektir.
Özet
Projeniz takılı kaldıysa, yüklenici iletişimi kestiyse, takvim sadece teoride mevcutsa ve her düzeltme yeni hatalar üretiyorsa, bu her şeyin kaybolduğu anlamına gelmez.
Birçok durumda sorun çözülebilir.
Ancak bunun için tek bir adımla başlamak gerekir - durumu dürüstçe analiz etmek.
Çünkü bir projeyi kurtarmaya başlamadan önce, neden batmaya başladığını bilmek gerekir.
