Yarım kalan yazılım projesi — ne yapmalı?

Önce durun, karar vermeyin

Yazılım projesi yarım kaldığında ilk refleks genellikle aynı oluyor: sıfırdan başlamak.

Bu refleks anlaşılır — yaşanan deneyim kötü ve aynı yola devam etmek riskli görünüyor. Ama sıfırdan başlamak da bir maliyet ve o maliyet, elinizde ne olduğunu bilmeden hesaplanamıyor.

Karar vermeden önce dört kontrol var. Hiçbiri teknik bilgi gerektirmiyor ve toplamda birkaç gün sürüyor.

Kontrol 1 — Kaynak kod fiilen sizde mi?

“Bizde” cevabı yeterli değil. Somut soru şu: kod hangi hesapta duruyor ve o hesaba siz girebiliyor musunuz?

Üç durum var:

Kod sizin hesabınızda. En iyi senaryo. Devam seçeneği açık.

Kod tedarikçinin hesabında ama devri sözleşmede yazılı. Talep hakkınız var. Yazılı talepte bulunun.

Kod tedarikçinin hesabında ve sözleşmede bir şey yazmıyor. Zor senaryo. Yazılım 5846 sayılı Fikir ve Sanat Eserleri Kanunu kapsamında eser sayılıyor — kanunun 2. maddesi bilgisayar programlarını ilim ve edebiyat eserleri arasında sayıyor ve metne mevzuat.gov.tr üzerinden ulaşılabiliyor. Hakların devri sözleşmeye bağlı olduğu için, yazılı bir devir yoksa zemin zayıflıyor.

Dikkat — Bu üçüncü durumdaysanız önceliğiniz kod değil veri olmalı. Sistem kapanmadan veritabanı yedeğini almak, kaynak kod tartışmasından önce yapılacak iş. Veri kaybı geri alınamıyor; kod tartışması ise sürebilir.

Kontrol 2 — Kod devralınabilir durumda mı?

Elinizde kod olması, devam edilebileceği anlamına gelmiyor. Devralınabilirliğin üç işareti var ve üçünü de teknik olmayan biri sorabilir.

Sürüm geçmişi var mı? Kodun değişim kaydı tutulmuş mu, yoksa tek bir klasör olarak mı duruyor? Geçmiş varsa neyin ne zaman değiştiği görülebiliyor.

Başka bir makinede kurulabiliyor mu? Devralacak ekip projeyi kendi bilgisayarında çalıştırabiliyor mu? Çalıştıramıyorsa üzerinde çalışmak da mümkün değil.

Veritabanı yapısı okunabilir mi? Tablo ve alan adları anlaşılır mı, yoksa kısaltmalardan mı ibaret?

Üçü de varsa devralma genellikle sıfırdan yazmaktan hem ucuz hem hızlı. İkisi eksikse karar zorlaşıyor.

Kontrol 3 — Yapılan iş ihtiyacın ne kadarını karşılıyor?

Bu, gözle görülebilen tek kontrol. Programı açın ve ihtiyaç listenizle karşılaştırın.

Sahada gördüğümüz yaygın tablo şu: proje yüzde yetmiş bitmiş görünüyor ama biten kısım kolay kısım. Ekranlar duruyor, veri giriliyor, ama entegrasyon, yetkilendirme ve raporlama hiç başlamamış. Bu durumda “yüzde yetmiş” rakamı yanıltıcı.

Tersi de oluyor: görsel taraf yarım ama arka taraf sağlam kurulmuş. Bu durumda devam etmek çok daha mantıklı.

Örnek senaryo — Bir işletme, sipariş yazılımının yarıda kaldığını söylüyor. Baktığımızda sipariş girişi, ürün tanımı ve stok tarafı çalışıyor; eksik olan yalnızca sevkiyat ekranı ve raporlar. Kod okunabilir, kurulum yapılabiliyor. Sıfırdan yazmak aylar alacakken, eksik parçayı tamamlamak birkaç haftalık iş çıkıyor. İşletme “proje battı” diye düşündüğü şeye altı hafta sonra devam ediyor.

Kontrol 4 — Neden yarım kaldı?

Bu, atlanınca aynı sonucu üreten kontrol.

Sebep tedarikçiyse — firma kapandı, geliştirici ayrıldı, iletişim koptu — yeni tedarikçiyle devam etmek makul.

Sebep kapsamsa dikkat gerekiyor. Kapsam sürekli büyüdüğü için tıkanan bir proje, tedarikçi değişince de tıkanır. Bu durumda düzeltilmesi gereken şey tedarikçi değil, çalışma biçimi: kapsamın yazılı ve dar tutulması, sonraki isteklerin ikinci aşamaya yazılması.

Sebep karar verilememesiyse — işletme tarafında kimin karar vereceği belli değilse — yeni proje de aynı yerde duracak. Bu, tedarikçi değiştirerek çözülmeyen tek sebep.

İpucu — Sebebi tespit etmenin pratik yolu: son üç ayda projede kaç kez kapsam değişti ve kaç toplantı karar alınmadan bitti? İki sayı da yüksekse sorun tedarikçide değil.

Devralacak ekipten ne istenmeli?

İlk istenen şey yeni özellik olmamalı. İlk istenecek şey durum raporu.

Kısa bir inceleme çalışması satın alın — genellikle birkaç gün — ve şu üç başlıkta yazılı çıktı isteyin:

1. Neler çalışıyor? Fiilen kullanılabilir durumda olan bölümler.
2. Neler çalışmıyor? Yarım kalmış veya hatalı bölümler.
3. Neler yeniden yazılmalı? Devam edilemeyecek kadar sorunlu bölümler ve gerekçesi.

Bu rapor iki işe yarıyor. Birincisi, devam kararını sağlam bir zemine oturtuyor. İkincisi, devralacak ekibin fiyatını gerçekçi hâle getiriyor — belirsizliği fiyatlamak zorunda kalmıyorlar.

Güvenlik tarafında da bir gözden geçirme isteyin. Devralınan kodda yaygın açıklar sık görülüyor; OWASP’ın ilk on maddesi sektörde ortak başvuru listesi ve inceleme raporunda bu başlıkların kontrol edilmiş olması makul bir beklenti.

Kişisel veri tarafını unutmayın

Yarım kalan sistemde personel veya müşteri verisi varsa, sistem kullanılmıyor olsa bile veri sorumlusu olarak yükümlülüğünüz sürüyor.

İki iş var: verinin nerede olduğunu tespit etmek ve eski tedarikçide kalan kopyaların akıbetini yazılı olarak netleştirmek. Kişisel Verileri Koruma Kurumu’nun temel ilkeler sayfası bu konuda başlangıç noktası.

Yeniden başlarken aynı hataya düşmemek

Yarım kalan projelerin büyük kısmında ortak olan şey, başlangıçta sorulmamış birkaç soru. Aynı listeyi yazılım firması seçerken sorulacak sorular yazısında topladık; en kritik üçü şunlar:

• Kaynak kod, veritabanı ve erişimler kimde kalıyor?
• Kapsam dışı istek geldiğinde süreç nasıl işliyor?
• Bu projede fiilen kim çalışacak ve ayrılırsa ne oluyor?

İnceleme çalışmasının kapsamı ne olmalı?

Devralacak ekipten istenecek inceleme, sınırsız bir keşif olmamalı; kapsamı ve süresi baştan belli olmalı. Genellikle birkaç gün yeterli.

İnceleme şu sorulara yazılı cevap üretmeli:

1. Proje başka bir makinede kuruluyor mu? Kurulamıyorsa devam seçeneği pratikte kapalı.
2. Veritabanında ne var? Tablo yapısı okunabilir mi, veri gerçek mi yoksa test verisi mi?
3. Kod ne kadar anlaşılır? Yorum, isimlendirme, tekrar eden bölümler.
4. Hangi bölümler bitmiş, hangileri yarım? Ekran ekran liste.
5. Güvenlik açısından ilk bakışta göze çarpan ne var?
6. Devam etmek mi yeniden yazmak mı? Gerekçesiyle.

Bu altı başlık, incelemeyi bir "fikir alma" toplantısından çıkarıp karar verilebilir bir çıktıya dönüştürüyor.

Eski tedarikçiyle iletişimi nasıl yürütmeli?

İlişki bozulmuş olsa bile bu aşamada duygusal değil işlemsel davranmak gerekiyor, çünkü elinizdeki tek kaldıraç yazılı kayıt.

Her talebi yazılı yapın. Telefonda verilen sözler sonradan dayanak olmuyor.

Önce veriyi isteyin, sonra kodu. Veri kaybı geri alınamıyor; kod tartışması sürebilir.

Neyin talep edildiğini tek tek sayın. "Her şeyi gönderin" değil: veritabanı yedeği, kaynak kod deposu, sunucu erişim bilgileri, varsa üçüncü taraf servis hesapları.

Erişimleri kendi adınıza taşıyın. Alan adı, sunucu ve e-posta hesapları sizin adınıza değilse bu, kod tartışmasından daha acil bir sorun.

İpucu — Eski tedarikçiden bir "devir toplantısı" isteyin ve buna devralacak ekipten birini de dahil edin. İki saatlik bir görüşme, haftalarca sürecek kod okuma işini kısaltıyor. Talep reddedilse bile yazılı olarak istemiş olmanız işinize yarıyor.

Sıfırdan başlıyorsanız aynı hataya düşmemek

Yeniden başlama kararı verildiyse, ilk projeyi batıran şeyin ne olduğuna göre çalışma biçimi değişmeli.

Kapsam büyümesi yüzünden battıysa: İlk sürümü tek bir işle sınırlayın ve yazılı olarak dondurun. Yeni istekler ikinci aşamaya yazılır, aynı aşamaya değil.

Tedarikçi kaynaklıysa: Kaynak kod, veri ve erişimlerin sizde olması bu kez sözleşmede yazılı olsun. Ayrıca kodu ilk günden kendi hesabınızda tutun; teslimde devralmayı beklemeyin.

Karar verilememesi yüzünden battıysa: Bir proje sahibi belirleyin ve karar yetkisini yazılı verin. Bu, tedarikçi değiştirerek çözülmeyen tek sebep.

Ne zaman devam edilmez?

İnceleme raporu geldiğinde devam etmemeyi gerektiren dört bulgu var.

Proje kurulamıyorsa. Kod elinizde olsa bile çalışır hâle getirilemiyorsa üzerinde geliştirme yapmak mümkün değil.

Veritabanında gerçek veri yoksa. Yalnızca test verisiyle çalışılmışsa, sistemin gerçek yükle nasıl davranacağı hiç denenmemiş demektir.

Kullanılan teknoloji artık desteklenmiyorsa. Güvenlik güncellemesi almayan bir temel üzerine geliştirme yapmak, her yıl büyüyen bir borç.

Yapılan iş ihtiyacın küçük bir kısmını karşılıyorsa. Yüzde yirmisi bitmiş bir projeyi devralmanın, sıfırdan başlamaya göre kazandırdığı şey az; devralma maliyeti bu kazancı yiyor.

Karar sonrası ilk hafta

Hangi yol seçilirse seçilsin, ilk hafta yapılacak işler aynı ve acil.

1. Veritabanı yedeğini alın ve iki ayrı yerde saklayın.
2. Alan adı, sunucu ve e-posta hesaplarını kendi adınıza taşıyın.
3. Üçüncü taraf servislerin hesaplarını listeleyin — ödeme, e-belge, harita, mesaj servisleri.
4. Eski tedarikçiye yazılı devir talebi gönderin.
5. Sistem hâlâ kullanılıyorsa kapatma tarihini belirleyin; kullanılmıyorsa verinin nerede durduğunu kayıt altına alın.

İlk üç madde tedarikçiyle ilişkiden bağımsız yapılabiliyor ve en çok risk azaltan adımlar bunlar.

Sonuç — “Proje battı” teşhisi çoğu zaman erken konuyor. Elinizde ne olduğunu birkaç günlük bir incelemeyle tespit etmeden verilen sıfırdan başlama kararı, bazen tamamlanmaya birkaç hafta kalmış bir işi çöpe atmak anlamına geliyor.

Devralma ve tamamlama işlerini özel yazılım geliştirme kapsamında yürütüyoruz; genel çerçeve fabrikalar için yazılım yazısında.

Bu konuyla ilgili

• yazılım geliştirme — Yeniden başlarken çalışma biçimi ve sözleşme.