Kuruma özel yazılım geliştirme süreci: analizden bakıma

Kuruma özel yazılım, bir şirketin kendi işleyişine göre tasarlanıp geliştirilen uygulamadır: bayi portalı, saha operasyon paneli, teklif ve sipariş yönetimi, iç onay akışları, müşteri paneli gibi. Hazır ürünlerden farkı, sürecinizi yazılıma uydurmak yerine yazılımı sürecinize uydurmasıdır. Bu esnekliğin bir bedeli vardır: sonuç, büyük ölçüde sürecin nasıl yönetildiğine bağlıdır. Bu yazı, ilk görüşmeden bakıma kadar aşamaları, her aşamada neyin teslim edildiğini ve sizin tarafınızda ne yapılması gerektiğini anlatır.

Özel yazılım ne zaman doğru karardır?

Her ihtiyaç özel yazılım gerektirmez. Aynı işi gören, olgun bir hazır ürün varsa çoğu zaman onu kullanmak daha akılcıdır. Özel yazılım şu durumlarda anlam kazanır:

• İş, birbirine bağlı tablolar ve e-posta yazışmalarıyla yürüyor, hata ve gecikme artık ölçülebilir bir maliyet haline gelmişse.
• Hazır ürünler denenmiş, ama süreci taşımak için sürekli ek araç ve elle yapılan iş gerekmişse.
• İşleyişiniz sizi rakiplerinizden ayırıyor ve bunu standart bir kalıba sokmak istemiyorsanız.
• Birden çok sistemin (ERP, muhasebe, depo, web sitesi) birbiriyle konuşması gerekiyor ve aradaki boşluğu insanlar dolduruyorsa.

Bu karşılaştırmanın müşteri yönetimi özelindeki halini hazır CRM mi, kuruma özel CRM mi yazımızda ayrıntılı ele aldık.

1. Keşif ve ihtiyaç analizi

Yazılım projelerinde en pahalı hata, yanlış anlaşılmış ihtiyaçtır. Yanlış yazılmış bir ekran birkaç günde düzeltilir; yanlış anlaşılmış bir süreç ise bütün sistemin yeniden kurulmasını gerektirebilir. Analiz aşaması bu riski azaltmak için vardır.

Bu aşamada geliştirici ekip, işi bugün fiilen yapan kişilerle konuşur. Yalnızca yöneticilerle değil; sipariş giren, sahaya çıkan, fatura kesen kişilerle. Çünkü sürecin kâğıt üzerindeki hali ile gerçekte işleyen hali çoğu zaman farklıdır. Mevcut tablolar, formlar ve raporlar incelenir. Sorulan temel sorular şunlardır: İş nerede başlıyor, kimden kime geçiyor, nerede bekliyor, hangi istisnalar yaşanıyor, hangi bilgi iki kez giriliyor?

Teslim edilenler: mevcut ve hedeflenen sürecin akış şeması, kullanıcı rolleri, ihtiyaç listesi, entegrasyon gereksinimleri ve açık soruların listesi.

Sizin tarafınızda: süreci bilen kişilerin zamanını ayırması ve bir proje sorumlusunun belirlenmesi. Bu kişi, kararları toplayan ve geliştirici ekibe tek ağızdan ileten kişidir.

2. Kapsam ve önceliklendirme

Analiz, genellikle ilk düşünülenden daha uzun bir istek listesi çıkarır. Hepsini ilk sürüme koymak, projenin hem süresini hem riskini büyütür. Bu aşamada istekler üçe ayrılır: olmadan sistemin kullanılamayacağı şeyler, olması iyi olacak şeyler ve sonraya kalabilecekler.

İlk sürümün ölçütü şudur: gerçek kullanıcıların gerçek işini baştan sona yürütebildiği en küçük kapsam. Bu sürüm kullanıma girdiğinde öğrenilenler, geri kalan listenin önemli bir bölümünü değiştirir; bazı istekler gereksizleşir, hiç düşünülmemiş başkaları öne çıkar.

Bu aşamada neyin dahil olmadığını yazmak da en az neyin dahil olduğunu yazmak kadar önemlidir. Kapsam dışı maddeler baştan belli olduğunda, sonradan “bunu da konuşmuştuk” tartışması yaşanmaz.

Teslim edilenler: ilk sürümün kapsamı, kapsam dışı maddeler, aşamalara bölünmüş takvim ve teklif.

3. Mimari ve teknoloji seçimi

Teknoloji tercihi çoğu zaman karar vericiye uzak görünür, ama sonuçları doğrudan sizi etkiler. Sormanız gereken sorular teknik ayrıntıdan çok sonuçlarla ilgilidir:

• Nerede çalışacak? Bulutta mı, kendi sunucunuzda mı? Verinin bulunacağı yer konusunda bir kısıtınız var mı?
• Kim, nereden kullanacak? Ofiste masaüstünden mi, sahada telefondan mı? Bağlantının zayıf olduğu yerlerde çalışması gerekiyor mu?
• Hangi sistemlerle konuşacak? Bu sistemlerin veri alışverişine izin veren bir arayüzü var mı?
• Kullanılan teknoloji yaygın mı? İleride başka bir ekibin devralabileceği, belgeleri ve geliştirici topluluğu bulunan araçlar tercih edilmelidir.
• Yetkilendirme nasıl olacak? Kim neyi görecek, kim neyi değiştirecek, kimin yaptığı işlem kayda geçecek?
• Yük beklentisi nedir? Kullanıcı ve kayıt sayısı birkaç yıl içinde nereye varabilir?

Teslim edilenler: mimari özeti, veri modeli taslağı, entegrasyon planı.

4. Arayüz ve deneyim tasarımı

İç kullanıma yönelik yazılımlarda tasarım çoğu zaman önemsiz görülür. Oysa günde saatlerce kullanılan bir ekranda fazladan atılan her adım, yıl boyunca toplanan bir zaman kaybıdır. Kullanıcıların sistemi benimsemesi de büyük ölçüde buna bağlıdır.

Tasarım iki adımda ilerler. Önce tel kafesler çizilir: renksiz, sade ekran iskeletleri. Bu aşamada akış tartışılır; hangi bilgi nerede duruyor, bir işi tamamlamak kaç adım sürüyor? Ardından görsel tasarım ve tıklanabilir prototip gelir. Prototipi, sistemi gerçekten kullanacak kişilere denetmek, tek satır kod yazılmadan önce yanlışları yakalamanın en ucuz yoludur.

Teslim edilenler: ana akışların tel kafesleri, arayüz tasarımı, tıklanabilir prototip.

Sizin tarafınızda: prototipin son kullanıcılarla denenmesi ve geri bildirimin tek listede toplanması.

5. Geliştirme

Geliştirme, kapalı bir odada aylarca çalışıp sonunda bitmiş ürünü göstermek biçiminde yürümemelidir. Sağlıklı düzen, işi kısa dönemlere bölmek ve her dönemin sonunda çalışan bir ara sürüm göstermektir. Böylece yanlış anlaşılan bir şey haftalar değil, günler içinde fark edilir.

Bu aşamada dikkat edilecekler:

• Test ortamı. Ara sürümleri deneyebileceğiniz, gerçek veriden ayrı bir ortam bulunmalıdır.
• Sürüm denetimi. Kod, değişiklik geçmişiyle birlikte bir depoda tutulmalıdır.
• Kod incelemesi ve otomatik testler. Yeni eklenen bir özelliğin eskisini bozmadığını güvenceye alır.
• Değişiklik yönetimi. Yolda yeni istekler çıkması doğaldır. Her yeni istek yazılır, süreye ve maliyete etkisi belirtilir, onaylanırsa kapsama alınır. Sözlü eklenen işler, takvim kaymalarının başlıca nedenidir.

Teslim edilenler: düzenli ara sürümler, dönem sonu özetleri, güncel iş listesi.

6. Test ve kabul

Test yalnızca “hata var mı” sorusunu yanıtlamaz; “sistem işi görüyor mu” sorusunu da yanıtlar. Birkaç katmanı vardır:

• İşlev testleri. Her özellik, beklenen ve beklenmeyen girdilerle denenir.
• Kullanıcı kabul testi. Gerçek kullanıcılar, gerçek senaryoları baştan sona yürütür. Bu test sizin tarafınızda yapılır ve en değerli geri bildirimi verir.
• Yetki ve güvenlik testleri. Bir kullanıcı, görmemesi gereken bir kaydı görebiliyor mu?
• Yük ve performans. Beklenen kullanıcı ve veri hacminde sistem nasıl davranıyor?
• Veri aktarım provası. Eski sistemden ya da tablolardan taşınacak veri, deneme ortamında aktarılıp kontrol edilir.

Kabul ölçütleri baştan yazılmışsa, “bitti” kelimesinin anlamı iki taraf için de aynı olur.

7. Yayına alma ve geçiş

Yeni sistemin devreye girdiği gün, projenin en hassas anıdır. İyi bir geçiş planı şunları içerir:

• Veri aktarımı. Eski kayıtların temizlenmesi, eşleştirilmesi ve taşınması.
• Geçiş biçimi. Herkes aynı gün mü geçecek, yoksa önce küçük bir ekiple mi denenecek? Riskli süreçlerde eski ve yeni düzeni kısa bir süre yan yana yürütmek güven verir.
• Eğitim. Rollere göre kısa, uygulamalı oturumlar ve başvurulabilecek bir kullanım notu.
• Geri dönüş planı. Beklenmeyen bir sorun çıkarsa eski düzene nasıl dönüleceği.
• İlk hafta desteği. Geliştirici ekibin, soruları ve küçük düzeltmeleri hızla karşılayabileceği yoğun bir dönem.

8. Bakım ve geliştirme

Yazılım, teslim edildiği gün bitmez. Kullanılan kütüphaneler güncellenir, güvenlik açıkları yayımlanır, işiniz değişir. Bakım anlaşmasının kapsaması gerekenler:

• Güvenlik güncellemeleri ve bağımlılıkların yenilenmesi
• Düzenli yedekleme ve geri yüklemenin belirli aralıklarla denenmesi
• İzleme: sistem çalışıyor mu, hata veriyor mu, yavaşlıyor mu?
• Hata düzeltme için öngörülen yanıt süresi
• Yeni isteklerin nasıl toplanıp önceliklendirileceği

Yeni isteklerin kaynağı tahmin değil, kullanım olmalıdır. Hangi ekranın çok, hangisinin hiç kullanılmadığını görmek, sonraki yatırımın nereye yapılacağını gösterir.

Sizin tarafınızda gereken emek

Özel yazılım, sipariş verilip teslim alınan bir ürün değildir; birlikte yürütülen bir iştir. Proje boyunca sizin tarafınızda üç role ihtiyaç olur:

• Proje sorumlusu. Kararları toplar, öncelikleri belirler ve geliştirici ekiple düzenli görüşür. Yetkisi olmalıdır; her soruyu üst yönetime taşımak zorunda kalan bir sorumlu, takvimi yavaşlatır.
• Süreç uzmanları. İşi her gün yapan kişilerdir. Analizde süreci anlatır, tasarımda prototipi dener, testte gerçek senaryoları yürütürler.
• Teknik muhatap. Mevcut sistemlerinize erişimi, entegrasyon bilgilerini ve sunucu ya da güvenlik kurallarını sağlayan kişi ya da ekiptir.

Bu rollerin ayıracağı zaman proje başında konuşulmalı ve takvime yazılmalıdır. Geliştirici ekip ne kadar deneyimli olursa olsun, işinizi sizden daha iyi bilemez; iyi bir sonuç, iki tarafın da masada olmasına bağlıdır.

Sözleşmede bulunması gerekenler

• Kapsam ve kapsam dışı maddeler
• Aşamalar, teslimler ve kabul ölçütleri
• Ödemenin aşamalara nasıl bağlandığı
• Değişiklik isteklerinin nasıl ele alınacağı
• Kaynak kodun mülkiyeti ve teslim biçimi
• Gizlilik ve kişisel verilerin korunması yükümlülükleri
• Yayın sonrası hata düzeltme süresi ve bakım koşulları
• Erişim bilgilerinin ve belgelerin teslimi

Projeleri zorlayan yaygın nedenler

• Analizin atlanması ya da yalnızca yöneticilerle yapılması
• İlk sürüme her şeyin sığdırılmaya çalışılması
• Karar verecek tek bir kişinin bulunmaması
• Son kullanıcıların sürece geç dahil edilmesi
• Değişikliklerin yazıya dökülmeden eklenmesi
• Veri aktarımının son haftaya bırakılması
• Bakımın hiç planlanmaması

Bu listedeki maddelerin neredeyse hiçbiri teknik değildir. Özel yazılım projelerinin kaderini çoğunlukla kod değil, iletişim ve kapsam yönetimi belirler.

Sonuç

İyi yürütülen bir özel yazılım projesi, sürprizin az olduğu projedir: ne yapılacağı yazılıdır, ilerleme düzenli olarak gösterilir, değişiklikler kayıt altındadır ve yayından sonrası baştan düşünülmüştür. Biz de kuruma özel uygulamalar geliştirirken bu sırayı izliyoruz; analizle başlıyor, ilk sürümü küçük tutuyor ve ara sürümleri düzenli gösteriyoruz. Aklınızdaki işin özel yazılım gerektirip gerektirmediğini konuşmak isterseniz bize yazın.