Özel yazılım geliştirme — hazır çözümün yetmediği yerde

Ne zaman özel yazılım gerekir?

Özel yazılım, hazır paketlerin karşılayamadığı bir iş sürecini ya da veriyi şirkete ait kodla çözen, mülkiyeti sipariş verende kalan geliştirmedir. Hazır çözüm varken özel yazılım yaptırmak çoğu zaman yanlış karar; özel yazılım kararı, hazır çözümlerin tükendiği noktada veriliyor. O noktayı gösteren belirtiler genellikle şunlar.

Süreç yazılıma değil, yazılım sürece uyduruluyor. Ekibiniz sistemin dayattığı adımları izlemek için işi olması gerekenden karmaşık yapıyorsa, sistem artık yardımcı değil engel.

Excel devreye girmiş. Kritik bir bilgi hazır sistemde tutulamıyor ve yanında elektronik tablolar dönüyorsa, sistem ihtiyacı karşılamıyor demektir. Bu, en yaygın ve en net belirti.

Aynı veri birden çok yere elle giriliyor. İki sistem arasında elle veri taşınıyor; bir siparişin üç ayrı sisteme elle işlenmesi hem zaman hem hata kaynağı.

Lisans maliyeti kullanımı geçmiş. Kullanıcı başına ücretlendirilen sistemlerde ekip büyüdükçe maliyet katlanıyor ve özel geliştirmenin amortismanını geçebiliyor.

Bu belirtilerden biri tek başına yeterli değil. İkisi birden varsa hesap yapmaya değer. Sürecinizin sektör standardından gerçekten farklı olması ve verinizin mevzuat veya politika gereği dışarı çıkamaması da özel yazılımı doğru kılan durumlar arasında.

Bunlardan hiçbiri yoksa hazır çözüm daha ucuz ve daha hızlı. Bunu baştan söylüyoruz.

Analiz aşamasında ne yapıyoruz?

Yanlış anlaşılmış bir süreci otomatikleştirmek, sorunu daha hızlı üretmekten başka işe yaramıyor. Kod yazmadan önceki bölüm bu yüzden projenin başarısını belirleyen bölüm.

Süreci izliyoruz. İlk iş, mevcut akışı olduğu gibi çıkarmak — kimin ne yaptığı, hangi bilginin nereden geldiği, nerede beklendiği. Nasıl çalıştığınızı anlatmanızı istemek yerine, işin gerçekte nasıl yürüdüğünü izliyoruz. Anlatılan süreçle yaşanan süreç çoğu zaman farklı oluyor ve fark, yazılımın çözmesi gereken asıl yerde duruyor.

İstisnaları çıkarıyoruz. Ana akış kolay; projeyi zorlaştıran istisnalar. İade, iptal, kısmi teslimat, hatalı giriş düzeltmesi. Bunlar baştan konuşulmazsa sonradan yeniden yazma gerektiriyor.

Kimin kullanacağını belirliyoruz. Aynı ekranı hem sahada tabletle çalışan biri hem ofiste bilgisayarla çalışan biri kullanacaksa, tasarım kararı değişiyor.

Önceliklendiriyoruz. İhtiyaç listesi her zaman bütçeden uzun. Hangi maddenin ilk sürümde olması gerektiğine birlikte karar veriyoruz.

Çıktı bir doküman: mevcut akış, tespit edilen darboğazlar ve önerilen yeni akış. Bu doküman sizin kalıyor; yazılımı bizimle yapmasanız bile işe yarıyor.

Örnek senaryo — Bir üretim işletmesi için sipariş takip sistemi geliştirileceğini düşünün. İlk toplantıda anlatılan akış dört adım. Sahada iki gün geçirildiğinde gerçek akışın yedi adım olduğu ve üç adımın hiç konuşulmadığı ortaya çıkabilir — çünkü o adımlar herkes için o kadar rutindir ki anlatılmaya değer görülmez. Analiz atlanıp anlatılana göre geliştirilirse, sistem ilk günden kullanılamaz olur.

Aşamalı teslim neden önemli?

Tek seferde teslim edilen projelerde en büyük risk şu: altı ay sonra teslim edilen şey, altı ay önce anlatılan ihtiyacı karşılamıyor. Bunun sebebi kötü iletişim değil; ihtiyacın kendisi o sürede değişiyor.

İkincisini uyguluyoruz: en kritik işlevle çalışan bir ilk sürüm çıkıyor ve genellikle 4–6 haftada devrede oluyor. Gerçek kullanımda test ediliyor, geri bildirim bir sonraki aşamayı şekillendiriyor ve kalanı sırayla ekleniyor.

Bu düzenin iki faydası var. Birincisi, yanlış yönde ilerlendiğinde erken fark ediliyor. İkincisi, sistem daha ilk aylardan iş görmeye başlıyor.

Entegrasyon

Çoğu projede asıl değer yeni ekranlarda değil, mevcut sistemlerin konuşturulmasında çıkıyor: ERP, muhasebe, CRM, tedarikçi sistemleri. Aynı veriyi iki yere girmek zorunda kalmamak, tek başına ciddi zaman kazandırıyor.

Devir, mülkiyet ve bağımlılık

Özel yazılımda en çok sorulan ve en haklı endişe bu: geliştirici ekibe bağımlı kalır mıyım?

Bu bağımlılığı azaltan şeyler sözleşmeye ve çalışma biçimine yazılıyor.

• Kaynak kod size ait ve teslim ediliyor
• Standart teknolojiler kullanılıyor; başka bir ekibin devralabileceği yapı
• Teknik doküman yazılıyor; sistemin nasıl çalıştığı belgeleniyor
• Sunucu ve veri erişimi sizin adınıza
• Veri dışa aktarımı her zaman mümkün

Son madde özellikle önemli. Verinizi istediğiniz zaman standart bir biçimde dışarı alabiliyorsanız, gerçek bağımlılık yok demektir.

Bakım ve ömür

Özel yazılım teslimle bitmiyor; canlı bir sistem sürekli bakım istiyor.

Bakım kapsamında yürüyenler: güvenlik güncellemeleri, altyapı bileşenlerinin yükseltilmesi, yedekleme kontrolü, çalışma durumu izlemesi ve küçük iyileştirmeler.

Bakım anlaşması isteğe bağlı. Bakım almadan da teslim ediyoruz; kendi ekibinizle veya başka bir firmayla devam edebilirsiniz. Bu durumda sorumluluk sizde oluyor ve bunu açıkça yazıyoruz. Ancak güncellenmeyen bir sistemin birkaç yıl içinde güvenlik ve uyumluluk sorunu üretmesi kaçınılmaz.

Dikkat — Özel yazılım kararı verirken sadece geliştirme maliyetine bakmak yanıltıcı. Sistemin beş yıllık toplam maliyeti — geliştirme, bakım, sunucu ve iyileştirmeler — hazır çözümün beş yıllık lisans maliyetiyle karşılaştırılmalı. Karar bu tabloda netleşiyor.

Fiyatlandırma nasıl yapılıyor?

Özel yazılımda sabit fiyat vermek, kapsam netleşmeden mümkün değil. Bu yüzden süreci ikiye ayırıyoruz.

Analiz aşaması. Ayrı fiyatlandırılıyor; sabit bedelli ve kısa. Çıktısı bir kapsam dokümanı: ne yapılacak, hangi sırayla, tahmini süre ve gerçekçi bir toplam maliyet aralığı.

Geliştirme aşaması. Analiz çıktısına göre fiyatlanıyor. Kapsamı netleşmiş projelerde sabit fiyat, kapsamı gelişerek ilerleyen projelerde aşamalı bütçe uygulanıyor. Aşamalı teslim yapıldığı için ödeme de aşamalara bağlanıyor.

Bu ayrımın sebebi şu: analiz yapılmadan verilen fiyat ya çok yüksek oluyor (risk primi) ya da sonradan aşılıyor. İkisi de kimsenin işine yaramıyor.

Analiz sonucunda projenin mantıklı olmadığına karar verilirse — ki bazen oluyor — o noktada durabiliyorsunuz. Elinizde yine de işe yarar bir süreç dokümanı kalıyor.

Kim kullanacak, nasıl öğrenecek?

Özel yazılım projelerinde en çok atlanan şey benimseme.

Teknik olarak mükemmel çalışan ama kimsenin kullanmadığı sistemler gördük. Sebep neredeyse her zaman aynı: sistem, kullanacak kişilerin alışkanlıklarına değil sürecin ideal hâline göre tasarlanmış.

Bunu önlemek için analiz aşamasında sahada çalışan kişilerle konuşuyoruz, ilk sürümü onlara kullandırıyoruz ve geri bildirimi bir sonraki aşamaya yansıtıyoruz.

Teslimde eğitim veriliyor ve kısa bir kullanım kılavuzu bırakılıyor. Ekibe yeni katılan kişinin sistemi öğrenebilmesi, sistemin ömrünü belirleyen şey.

Örnek senaryo — Diyelim ki bir işletme için geliştirilen sistem, teslimden birkaç ay sonra kullanılmıyor. Sebep çoğu zaman basittir: sistem sipariş girişini altı alanla istiyor, oysa ekip telefonda sipariş alırken yalnızca üçünü öğrenebiliyor. Kalan üç alan zorunlu olunca ekip sistemi atlayıp eski yöntemine döner. Alanlar isteğe bağlı hâle getirildiğinde sistem genellikle hızla yeniden kullanılmaya başlar.

Nereden başlıyoruz?

İlk görüşme kapsam değil sorun konuşmak için. Neyin çalışmadığını, hangi işin ne kadar zaman aldığını ve nerede hata olduğunu dinliyoruz.

Ardından yukarıda anlattığımız kısa ve sabit bedelli analiz aşamasını öneriyoruz.

Veri güvenliği ve erişim

Özel yazılım projelerinde iş verisi sistemin içinde duruyor; güvenlik bu yüzden tasarımın parçası.

Erişim kademeleri. Her kullanıcı yalnızca işi için gereken veriye erişiyor. Bu, hem güvenlik hem hata azaltma anlamına geliyor.

Kayıt tutma. Kritik işlemlerin kim tarafından ne zaman yapıldığı kaydediliyor. Sorun çıktığında geriye dönmenin tek yolu bu.

Yedekleme ve geri dönüş. Düzenli yedek, ayrı konumda saklama ve en az bir kez yapılmış geri yükleme testi.

Veri dışa aktarımı. Verinizi istediğiniz zaman standart bir biçimde dışarı alabiliyorsunuz.

Ne zaman özel yazılım yaptırmayın

Hazır bir çözüm ihtiyacınızı karşılıyorsa özel geliştirme pahalı bir tercih oluyor. Süreçleriniz sektörün genel işleyişine benziyorsa hazır sistem yeterli.

Ayrıca süreciniz henüz oturmadıysa beklemek daha doğru; değişmekte olan bir süreci yazılıma dökmek, kısa sürede yeniden yazma gerektiriyor.

Mevcut sisteminiz varsa

Çalışan bir sistemi tamamen değiştirmek her zaman doğru değil. Çoğu vakada sorun sistemin tamamında değil belirli bir süreçte oluyor.

Bu durumda mevcut sistemi koruyup eksik parçayı geliştirmek hem ucuz hem risksiz. Analiz aşamasında hangisinin doğru olduğunu birlikte belirliyoruz.

Bu konuyla ilgili

• yazılım geliştirme hizmetleri — Kapsamın tamamı.
• mobil uygulama — Aynı sistemin mobil tarafı gerekiyorsa.
• web sitesi geliştirme — Kurumsal site ile entegre çalışacaksa.
• proje öncesi sorulacak sorular — Kapsam ve devir konularını netleştirmek.