Özel Yazılım Ne Kadar Sürer? Aşamalar, Süreyi Uzatan Etkenler ve Hızlandırmanın Yolları

Bir işletme sahibi özel yazılım için görüşmeye geldiğinde ilk iki sorudan biri neredeyse her zaman aynıdır: "Bu iş ne kadar sürer?" Diğeri fiyattır. İkisi birbirine bağlıdır ve ikisinin de dürüst cevabı "neyi, ne ayrıntıda istediğinize bağlı" olur.

Bu cevap kaçamak gibi duyulabilir. Oysa bir mimara "ev kaç ayda biter?" diye sormaktan farkı yoktur; plan çizilmeden verilen süre tahminden öteye geçmez. Bu yazıda özel yazılım geliştirme sürecini aşama aşama açıyoruz: her aşamada ne yapılır, elinize ne geçer, takvimi neler uzatır ve siz müşteri olarak süreyi kısaltmak için neler yapabilirsiniz.

Proje büyüklüğüne göre gösterge süreleri de bir tabloda topladık. O tablodaki aralıklar genel piyasa gözlemidir, kapsama göre değişir ve bir taahhüt değildir.

Süreyi belirleyen üç temel değişken

Dışarıdan benzer görünen iki proje arasında aylarca fark olabilir. Bu farkın büyük kısmı üç değişkenden gelir.

• Kapsam: Kaç ekran, kaç kullanıcı rolü, kaç rapor ve kaç iş kuralı var? "Sipariş girilsin" ile "sipariş girilsin, stok düşsün, bayiye özel fiyat uygulansın, yönetici onayına gitsin, muhasebeye aktarılsın" arasında birkaç kat iş farkı vardır.
• Entegrasyonlar: Yazılımın konuşması gereken her dış sistem (muhasebe programı, ERP, ödeme altyapısı, kargo firması, pazaryeri, e-fatura) ayrı bir iş kalemidir ve kendi belirsizliğini getirir.
• Karar ve geri bildirim hızı: Geliştirme ekibi ne kadar hızlı çalışırsa çalışsın, bir ekran onayı bir hafta bekliyorsa proje de bir hafta bekler. Takvimin azımsanmayacak bir kısmı müşteri tarafında şekillenir.

Bunlara çoğu zaman dördüncü bir değişken eklenir: mevcut verinin durumu. Yıllardır Excel dosyalarında, eski bir programda ya da kâğıt üzerinde tutulan bilginin yeni sisteme taşınması, beklenenden çok daha fazla zaman alabilir. Buna aşağıda ayrıca değineceğiz.

Özel yazılım geliştirme süreci: aşamalar ve her aşamada teslim edilenler

Yazılım projesi aşamaları firmadan firmaya farklı isimlerle anılsa da özünde benzer bir sıra izler. Aşağıda özel yazılım geliştirme projelerimizde izlediğimiz sırayı, her aşamanın çıktısıyla birlikte anlatıyoruz.

1. Keşif ve ihtiyaç analizi

Proje burada başlar. İşinizin bugün nasıl yürüdüğünü, hangi adımlarda zaman kaybedildiğini, kimin hangi bilgiye ihtiyaç duyduğunu dinleriz. Mümkünse işi fiilen yapan kişilerle de konuşuruz. Yöneticinin anlattığı süreçle depodaki personelin her gün yaşadığı süreç her zaman aynı olmaz. Bursa'daki müşterilerimizle bu görüşmeleri yüz yüze, diğer şehirlerdekilerle uzaktan yapıyoruz.

Teslim edilen: İhtiyaçların yazılı listesi, mevcut iş akışının özeti, kullanıcı rolleri ve ilk entegrasyon listesi.

2. Kapsam ve önceliklendirme

Keşifte çıkan her istek aynı önemde değildir. Bu aşamada istekleri "ilk sürümde mutlaka olmalı", "sonra eklenebilir" ve "belki hiç gerekmez" diye ayırırız. Proje süresini en çok etkileyen kararlar burada verilir. İlk sürüme az ama doğru şey girerse, yazılımı o kadar erken kullanmaya başlarsınız.

Teslim edilen: Önceliklendirilmiş kapsam dokümanı, modüllere bölünmüş iş planı ve takvim taslağı.

3. Prototip ve arayüz tasarımı

Kod yazılmadan önce ekranlar çizilir. Sipariş ekranında hangi alanlar olacak, bir liste nasıl filtrelenecek, sahadaki personel telefonda hangi bilgileri görecek? Bunları tıklanabilir bir prototip üzerinde görmek, aylar sonra "biz bunu böyle düşünmemiştik" demekten çok daha ucuzdur.

Teslim edilen: Ana ekranların tasarımı veya tıklanabilir prototip ve onaylanmış kullanıcı akışları.

4. İlk çalışan sürüm (MVP)

İlk çalışan sürüm, en kritik iş akışını uçtan uca yapabilen ama henüz tüm özellikleri içermeyen sürümdür. Örneğin bir spor kulübü yönetim panelinde bu, sporcu kaydı ile yoklama olabilir; veli takibi ve raporlar sonraki döngülere kalır. Sürüm gerçek kullanıcıların eline geçtiğinde, kâğıt üzerinde görünmeyen eksikler hızla ortaya çıkar.

Teslim edilen: Gerçek veriyle kullanılabilen ilk modül, test ortamı erişimi ve ilk kullanıcı geri bildirimleri.

5. Geliştirme ve test sprintleri

Kalan özellikler kısa döngüler hâlinde geliştirilir. Her döngünün sonunda yeni eklenen kısımları test ortamında görür, dener ve geri bildirim verirsiniz. Test yalnızca bizim tarafımızda yapılmaz; gerçek senaryoları en iyi, o işi her gün yapan kişiler bilir.

Teslim edilen: Her döngü sonunda test ortamında çalışan yeni özellikler, düzeltilen hataların listesi ve güncel ilerleme durumu.

6. Veri taşıma

Müşteri kartları, ürün listeleri, geçmiş siparişler, stok bakiyeleri. Eski sistemdeki verinin yeni yazılıma aktarılması çoğu zaman ayrı bir iş olarak planlanmalıdır. Aynı müşterinin üç farklı yazımla kayıtlı olması, boş bırakılmış zorunlu alanlar ya da "adet" ile "koli" karışıklığı gibi sorunlar ancak veri incelendiğinde görülür.

Teslim edilen: Eski ve yeni alanların eşleştirme tablosu, deneme aktarımı ve kontrol edilmiş son aktarım.

7. Canlıya alma ve eğitim

Yazılım gerçek sunucuya alınır, kullanıcı hesapları açılır, ekip eğitilir. Bazı işletmeler eski sistemle yeni sistemi kısa bir süre paralel çalıştırmayı tercih eder. Bu, geçiş riskini azaltır ama o süre boyunca iki kez veri girişi demektir. Hangi yolun uygun olduğuna birlikte karar veririz.

Teslim edilen: Canlı sistem, kullanıcı eğitimi, kaynak kod ve teknik doküman.

8. Bakım

Canlıya alma projenin son durağı sayılmaz. Güvenlik güncellemeleri, yedekleme, küçük hataların düzeltilmesi ve sistemin izlenmesi aylık bakım sözleşmesiyle sürer. Kullanım başladıktan sonra gelen yeni özellik istekleri ise ayrıca kapsamlanır ve takvime alınır.

Teslim edilen: Aylık bakım hizmeti; yeni özellikler için ayrı kapsam ve takvim.

Proje büyüklüğüne göre gösterge süreler

Aşağıdaki tablo sektörde sık görülen aralıkları özetler. Bunlar genel piyasa göstergeleridir; Fietto Creative için bir süre taahhüdü değildir ve her proje kendi kapsamına göre planlanır.

Fietto Creative özelinde söyleyebileceğimiz net bilgi şu: tipik bir özel yazılım projemiz 3 ay veya daha uzun sürer. Tek bir modülün ilk çalışan sürümü ise tüm sistem tamamlanmadan önce kullanıma açılabilir. Bunun dışındaki her süre, kapsam ve önceliklendirme aşamasından sonra konuşulmalıdır.

Tablodaki örneklerin ayrıntılarını merak ediyorsanız teklif hazırlama programı, CRM nedir, B2B bayi portalı ve üretim takip programı yazılarımıza bakabilirsiniz. Süre ile bütçe birlikte hareket ettiği için özel yazılım fiyatları yazımız da bu tabloyu tamamlar.

Yazılım projesi neden gecikir? Süreyi uzatan etkenler

Gecikmelerin çok azı yazılımcının yavaş kod yazmasından kaynaklanır. Asıl nedenler genellikle planlamada görünmeyen ya da küçümsenen işlerdir.

Entegrasyonlar

Dış bir sistemle bağlantı kurmak, o sistemin dokümantasyonuna, test ortamına ve destek ekibine bağımlı olmak demektir. Muhasebe programının bağlantı izni bayiden alınıyorsa ya da kargo firmasının test hesabı açılması günler sürüyorsa, geliştirme o noktada bekler. Mobilya Depom gibi bir e-ticaret yazılımında ödeme, kargo ve taksit entegrasyonlarının her biri ayrı bir sağlayıcıyla çalışmayı gerektirir; her sağlayıcı da takvime kendi temposunu ekler.

Karar gecikmesi

"Bunu bir de ortağıma soralım", "muhasebe müdürümüz izinden dönsün" gibi cümleler küçük görünür. Ama projede bir ekranın ya da bir iş kuralının netleşmesi beklenirken o kısma bağlı her şey durur. Birkaç küçük bekleme üst üste geldiğinde toplam gecikme haftaları bulabilir.

Kapsam kayması

Proje ilerledikçe yeni fikirler gelir; bu doğaldır. Sorun, her yeni isteğin "bunu da araya sıkıştıralım" diye mevcut takvime eklenmesidir. Tek tek küçük görünen istekler birikince ilk sürüm sürekli ertelenir. Buna kapsam kayması denir ve gecikmelerin en yaygın nedenlerinden biridir.

Veri temizliği

Yıllar içinde birikmiş veride tekrar eden kayıtlar, eksik alanlar ve tutarsız biçimler neredeyse her zaman vardır. Bu temizlik ya sizin ekibinizin bilgisini gerektirir ya da kayıtların tek tek kontrol edilmesini. Projenin sonuna bırakıldığında canlıya almayı doğrudan geciktirir.

Onay süreçleri

Bazı şirketlerde her ekran tasarımı birden fazla kişinin onayından geçer, bazılarında bilgi işlem ya da hukuk birimi sözleşme ve güvenlik incelemesi yapar. Bu süreçler gereklidir; yalnızca takvimde önceden yer almaları gerekir.

MVP nedir, ilk çalışan sürüm takvimi nasıl değiştirir?

MVP (minimum uygulanabilir ürün), yazılımın en kritik işi gerçekten yapabilen ilk sürümüdür. Kapsamı dardır ama ele aldığı işi baştan sona yapar.

Burada dürüst olmak gerekir: ilk çalışan sürüm yaklaşımı toplam proje süresini her zaman kısaltmaz. Kısalttığı şey, yazılımdan fayda görmeye başladığınız ana kadar geçen süredir. Bütün modüller hazır olsun diye aylarca beklemek yerine, en çok zaman kaybettiğiniz süreci erkenden yazılıma taşırsınız.

Bunun ikinci bir faydası vardır. Gerçek kullanım, toplantılarda akla gelmeyen ihtiyaçları ortaya çıkarır. Sonraki modüller bu geri bildirimle şekillendiği için yanlış yöne giden iş azalır.

Örneğin Ortakçı Spor Kulübü sporcu yönetim paneli sporcu kaydı, grup ve seans yönetimi, yoklama, veli takibi ve rol bazlı yetki gibi birden fazla parçadan oluşur. Bu tür bir sistemde parçaların hangisinin ilk sürüme gireceği, kulübün günlük işinde en çok neyin sıkıştığına göre belirlenir.

Çok dilli bir ürün planlıyorsanız benzer bir karar dil sayısı için de geçerlidir. Kendi ürünümüz olan otel yapay zeka rezervasyon asistanı OSPITA AI 8 dilde çalışır ve bir yönetim paneline sahiptir. Her ek dil çeviri, test ve içerik kontrolü demektir; bu kalemleri ilk sürüme mi yoksa sonraya mı bırakacağınız takvimi doğrudan etkiler.

Süreyi kısaltmak için sizin yapabilecekleriniz

Geliştirme ekibinin hızı belli bir noktadan sonra artırılamaz; ama müşteri tarafındaki bekleme süreleri çoğu zaman ciddi biçimde azaltılabilir. Deneyimimize göre en çok işe yarayanlar şunlar:

• Tek bir karar verici belirleyin. Herkesin fikri alınabilir ama son sözü söyleyecek, ulaşılabilir bir kişi olmalı.
• Örnek belgeleri erkenden paylaşın. Kullandığınız teklif formu, sipariş fişi, Excel tabloları ve raporlar keşif aşamasını hızlandırır.
• Verinizi şimdiden toparlamaya başlayın. Hangi dosyanın güncel olduğunu, hangi kayıtların taşınmaya değer olduğunu bilmek veri taşıma aşamasını kısaltır.
• Entegrasyon erişimlerini önceden isteyin. Muhasebe programı sağlayıcınızdan, kargo firmasından ya da ödeme kuruluşundan alınacak bilgiler için başvuruyu proje başında yapın.
• İlk sürümü küçük tutun. İlk sürüme girecek her özellik için "bu olmadan kullanamaz mıyız?" diye sorun.
• Geri bildirimi toplu ve zamanında verin. Dağınık mesajlar yerine her döngü sonunda tek bir liste halinde iletin.
• Test ortamını gerçekten kullanın. Canlıya alma öncesinde bulunan her hata, canlıda bulunandan çok daha az zaman kaybettirir.

Aşağıdaki tablo, her aşamada sizden beklenen katkıyı özetliyor. Bu katkılar zamanında geldiğinde takvim genellikle planlandığı gibi ilerler.

Canlıya aldıktan sonra: bakım, sahiplik ve yeni özellikler

Takvim konuşulurken çoğu zaman canlıya alma tarihine odaklanılır. Oysa bir iş yazılımı yıllarca kullanılır ve o yılların nasıl yönetileceği de en baştan netleşmelidir.

Bizim çalışma biçimimizde kaynak kod ve veri müşteriye aittir; canlıya almada kaynak kod ve teknik doküman teslim edilir. İsterseniz proje başında gizlilik sözleşmesi (NDA) imzalanır. Bu konuyu ayrıntılı olarak özel yazılımda kaynak kod sahipliği yazımızda anlattık.

Canlıya aldıktan sonra güvenlik güncellemeleri, yedekleme ve küçük düzeltmeler aylık bakım sözleşmesi kapsamında sürer. Yeni özellik istekleri ise ayrıca planlanır. Bu ayrım takvim açısından önemlidir: bakım, sistemin sağlıklı çalışmasını korur; yeni bir modül ise kendi kapsamı ve süresiyle küçük bir proje gibi ele alınır.

Teklif alırken süreyle ilgili sormanız gereken sorular

Farklı firmalardan teklif alıyorsanız yalnızca "kaç ayda biter?" diye sormak yetmez. Aşağıdaki sorular, verilen sürenin ne kadar gerçekçi olduğunu anlamanıza yardımcı olur:

1. Bu süreye hangi aşamalar dahil? Veri taşıma ve eğitim ayrıca mı hesaplanıyor?
2. İlk çalışan sürüm ne zaman ve hangi modülle kullanıma açılacak?
3. Entegrasyonlar için bizden ve üçüncü taraflardan ne zaman, ne bekleniyor?
4. Proje sırasında gelen yeni istekler nasıl ele alınacak?
5. Her döngü sonunda ilerlemeyi nasıl göreceğiz?
6. Canlıya aldıktan sonra bakım nasıl yürüyecek, yeni özellikler nasıl planlanacak?

Bu sorulara net cevap alamıyorsanız, verilen süre büyük ihtimalle ayrıntılı bir kapsama dayanmıyordur. Kısa bir süre vaadi kulağa hoş gelir; ama aşamaları açıkça anlatılmamış bir takvim çoğu zaman en uzun süren takvime dönüşür.

Henüz özel yazılımın gerekli olup olmadığından emin değilseniz, önce özel yazılım mı hazır yazılım mı karşılaştırmamıza göz atın. Üretim yapan bir işletmeyseniz üretim sektörü sayfamızda size yakın örnekleri bulabilirsiniz.

Kurtuluş'taki ofisimizde Bursa'daki işletmelerle yüz yüze görüşüyor, Türkiye'nin diğer şehirlerindeki müşterilerimizle uzaktan çalışıyoruz. Bursa özel yazılım sayfamızda yerel çalışma biçimimizi, özel yazılım süreci sayfamızda ise aşamaların ayrıntısını bulabilirsiniz. Projenizin kabaca ne kadar süreceğini konuşmak isterseniz bize yazın; ihtiyacınızı dinleyip ilk sürüme neyin girmesi gerektiğini birlikte netleştirelim.

Sık sorulan sorular