Yazılım Geliştirme Süreci: Müşteri Olarak Sizi Neler Bekler?

Yazılım geliştirme süreci, bir iş fikrinin ilk görüşmeden yayına ve bakıma kadar geçtiği aşamaların toplamıdır. Çoğu kaynak bu aşamaları yazılımcının gözünden anlatır. Biz işi yaptıran tarafa bakıyoruz. Her aşamada müşteriden hangi bilgi, onay ve erişim istenir? Aşama ne kadar sürer, sonunda hangi belge teslim edilir? Değişiklik isteği hangi noktadan sonra pahalılaşır? Aşağıdaki sıra, özel yazılım projelerimizde izlediğimiz akıştır.

Yazılım geliştirme süreci hangi aşamalardan oluşur?

Müşterinin gözünden yazılım geliştirme süreci yedi aşamadan oluşur. Her aşama yazılı bir onayla kapanır. Bir sonrakine de elde bir belgeyle geçilir.

1. Ön görüşme: İhtiyaç, bütçe çerçevesi ve tarih beklentisi konuşulur.
2. Analiz ve kapsam: İş akışları çıkarılır, kapsam belgesi yazılır ve imzalanır.
3. Tasarım: Ekranlar tıklanabilir bir prototipte gösterilir ve onaylanır.
4. Geliştirme: Yazılım parça parça yazılır, ara sürümler müşteriye açılır.
5. Test ve kabul: Önce ekip, sonra müşteri sistemi kapsam belgesine göre dener.
6. Yayın: Sistem canlı sunucuya taşınır, alan adı ve veriler bağlanır.
7. Bakım: Hata düzeltme, güncelleme, yedek ve küçük geliştirmeler sürer.

Aşamaların sırası sabittir ama aralarındaki sınırlar katı değildir. Tasarımın bir kısmı analiz bitmeden başlayabilir. Test de yalnızca sonda değil, geliştirme boyunca yapılır. Asıl kural şudur: her aşamanın kapanış onayı yazılı olmalı. Sözlü bir "tamam", aylar sonra iki tarafın farklı hatırladığı bir cümleye dönüşür.

Her aşamanın sonunda çıkan belge, bir sonrakinin girdisidir. Kapsam belgesi tasarımın, onaylı prototip de geliştirmenin girdisi olur.

Aşamalar toplam sürenin ne kadarını alır?

Orta ölçekli bir projede geliştirme, toplam sürenin yaklaşık yarısını alır. Analiz yüzde 15, test ve kabul yüzde 20 civarındadır. Kalan süre tasarıma ve yayına ayrılır.

Örnek olarak 20 haftalık bir randevu ve müşteri takip sistemi düşünelim. Analiz 3 hafta, yani yüzde 15 sürer. Tasarım 2 hafta ile yüzde 10 tutar. Geliştirme 10 hafta (yüzde 50), test ve kabul 4 hafta (yüzde 20) alır. Yayına 1 hafta, yani yüzde 5 ayrılır. Ön görüşme sözleşmeden önce olduğu için bu hesaba girmez.

Oranlar projeye göre kayar. Çok sayıda dış sisteme bağlanan bir yazılımda test payı büyür. Ekranı çok, iş kuralı az bir projede tasarım öne çıkar. Analize toplam sürenin onda birinden azını ayıran bir plan görürseniz nedenini sorun. Analizde kısaltılan haftalar, çoğu zaman test aşamasında fazlasıyla geri ödenir.

Takvim yapılırken tatiller ve yoğun sezonlar da hesaba katılır. Müşteri tarafındaki onaylayıcı iki hafta izne çıkarsa plan da iki hafta kayar.

Ön görüşmede müşteriden ne istenir?

Ön görüşmede müşteriden işin amacını, bugün nasıl yapıldığını ve kimlerin kullanacağını anlatması istenir. Genellikle 1–2 hafta içinde, bir ya da iki toplantıyla tamamlanır. Sonunda kaba süre ve bütçe aralığı içeren bir teklif çıkar.

Görüşmeye hazırlıklı gelmenin en kolay yolu, mevcut işin örneklerini getirmektir. Kullanılan Excel dosyaları, form çıktıları ve ekran görüntüleri çok şey anlatır. Şikâyet edilen adımlar da öyle. "Her şeyi yapsın" demek yerine "teklif hazırlamak şu an bir saat sürüyor" demek daha işe yarar. İkinci cümle ölçülebilir bir hedef verir.

Kullanıcı sayısı, kullanılacak cihazlar ve bağlanılacak sistemler de bu görüşmede sorulur. Muhasebe programı, ödeme hizmeti ya da kargo firması gibi bağlantılar süreyi doğrudan etkiler.

Ön görüşmenin bir amacı da özel yazılımın gerçekten gerekip gerekmediğini anlamaktır. Bazı işler hazır bir paketle daha ucuza çözülür. Bu karar için özel yazılım ile hazır yazılım arasındaki farklar iyi bir başlangıç noktasıdır. Bizim çalışma biçimimizin ayrıntıları ise özel yazılım geliştirme hizmeti sayfasında yer alıyor.

Analiz ve kapsam belgesi neden en kritik aşamadır?

Analiz, yapılacak işin sınırlarının çizildiği aşamadır ve sonraki her kararın dayanağıdır. Genellikle 2–4 hafta sürer. Sonunda imzalı bir kapsam belgesi çıkar ve geliştirmenin ölçüsü bu belge olur.

Kapsam belgesi, yazılımın neyi yapıp neyi yapmayacağını madde madde yazan ve iki tarafın onayladığı belgedir. İçinde kullanıcı rolleri, ekran listesi, iş kuralları ve dış bağlantılar bulunur. "Yapılmayacaklar" bölümü en az diğerleri kadar değerlidir. Sonradan çıkan anlaşmazlıkların çoğu bu bölümün boş kalmasından doğar.

Müşteriden bu aşamada üç şey istenir:

• İş bilgisi: Süreci en iyi bilen çalışanla iki üç görüşme. Çoğu zaman bu kişi yönetici değil, işi her gün yapan kişidir.
• Örnek veri: Gerçek yapıda ama kişisel bilgileri maskelenmiş birkaç kayıt.
• Tek onaylayıcı: Kapsam ve tasarım kararlarında son sözü söyleyecek bir kişi.

Örnek veride dikkatli olmak gerekir. KVKK'ya göre müşteri adına veri işleyen ekip de veri güvenliği için tedbir almakla yükümlüdür. Maskelenmiş veriyle çalışmak iki tarafın riskini birden düşürür.

Erişim bilgileri de analiz sonunda listelenir ve gerektiği anda verilir. Alan adı paneli, sunucu, e-posta gönderim hizmeti, Google Search Console ve reklam hesapları bu listededir. Şifre e-postayla paylaşılmaz; mümkün olan her yerde ekibe ayrı kullanıcı açılır. Proje bitince bu kullanıcılar kapatılır ve kimin neye eriştiği her zaman görünür kalır.

Tasarım onayı ne kadar sürer?

Tasarım aşaması çoğu projede 2–3 hafta sürer ve tıklanabilir bir prototiple kapanır. Müşteriden logo, kurumsal renkler ve varsa marka kılavuzu istenir. Onaylanan prototip, geliştirmenin görsel sözleşmesi olur.

Prototipi incelerken renkten çok akışa bakmak gerekir. Bir kayıt kaç tıklamada açılıyor? Telefonda form rahat dolduruluyor mu? Hangi rol hangi düğmeyi görüyor? Renk ve yazı tipi geliştirme sırasında birkaç saatte değişir. Akıştaki bir hata ise birden çok ekranı ve veritabanını etkiler.

Erişilebilirlik de bu aşamada konuşulur. W3C'nin WCAG 2.2 yönergesi, AA düzeyinde normal metin için en az 4,5:1 kontrast ister. Kontrastı prototipte düzeltmek kolaydır. Yayından sonra ise bütün renk sistemini yeniden ele almak gerekir.

Prototip onayında en sık atlanan konu boş ve hata ekranlarıdır. Hiç kaydı olmayan bir liste nasıl görünür? Bağlantı koptuğunda kullanıcı ne görür? Bu ekranlar prototipte yoksa geliştirmede tahminle çizilir. Telefon görünümü de ayrıca onaylanır; masaüstü onayı telefonu kapsamaz.

Geliştirme aşamasında müşteri ne yapar?

Geliştirme sırasında müşteri ara sürümleri dener ve geri bildirim verir. Bu aşama genellikle 6–12 hafta sürer ve iki haftada bir yeni sürüm çıkar. Aynı dönemde içerikler, görseller ve gerçek veriler hazırlanır.

Ara sürüm, o ana kadar biten özelliklerin test sunucusunda çalışan hâlidir. Scrum Rehberi bu çevrimleri (sprint) en fazla bir ay olarak tanımlar. İki haftalık çevrim çoğu proje için dengelidir; yanlış anlamayı erken yakalar. Her sürümün sonunda kısa bir gösterim yapılır, geri bildirimler tek bir listeye yazılır.

Geri bildirimde iki tür not birbirinden ayrılır. Birincisi hatadır: kapsamda yazan bir şey yanlış çalışıyordur ve ücretsiz düzeltilir. İkincisi yeni istektir: kapsamda yoktur, süre ve ücret etkisi ayrıca konuşulur. Ayrımı ilk günden yapmak, proje boyunca tartışmayı azaltır.

İçerik, bu aşamanın sessiz yüküdür. Ürün açıklamaları, hizmet metinleri ve e-posta şablonları müşteriden gelir. Web sitesi içeren işlerde kurumsal web sitesinde olması gereken sayfalar listesi içerik planına temel olur. Çok dilli projelerde her dil ayrı metin ve ayrı onay ister (sağlık turizmi ve saç ekimi işlerimiz böyleydi).

Test ve kabul aşamasında neye bakılır?

Test aşamasında önce ekip, sonra müşteri yazılımı kapsam belgesine göre dener. Ekip testi 1–2 hafta, müşterinin kabul testi 5–10 iş günü sürer. Sonunda bir test raporu ve imzalı kabul tutanağı çıkar.

Kabul testi, teslim edilen yazılımın kapsam belgesindeki ölçütleri karşılayıp karşılamadığını müşterinin denediği testtir. Ölçütler baştan yazılıysa bu aşama kısa sürer. Tipik kabul ölçütleri şunlardır:

• Kapsam belgesindeki her iş akışı en az bir kez baştan sona çalıştırılır.
• Her kullanıcı rolü yalnızca kendi ekranlarını ve verilerini görür.
• Formlar hem doğru hem hatalı veriyle denenir; hata mesajı anlaşılır olur.
• Sayfalar Google'ın Core Web Vitals eşiklerini geçer: LCP 2,5 saniye, INP 200 milisaniye, CLS 0,1.
• Çerez onayı verilmeden reklam ve ölçüm etiketleri çalışmaz.

Core Web Vitals eşikleri, ziyaretlerin yüzde 75'inde tutturulması gereken değerlerdir. Mobil ve masaüstü ayrı ayrı ölçülür.

Son madde bizim için bir alışkanlık. Kendi sitemizde Meta Pixel ve Dönüşüm API'si yalnızca çerez onayından sonra çalışıyor. Formlarda kullandığımız Cloudflare Turnstile da gerçek bir telefondan ayrıca denenir.

Performans testi bazen beklenmedik bir yük bulur. Kendi sitemizde bir animasyon katmanındaki CSS maskesini kaldırdık. Yeniden boyama süresi yaklaşık 2000 ms'den 9 ms'ye indi. Gözle fark edilmeyen böyle bir sorun ancak ölçülünce ortaya çıkar.

Yayın günü neler olur?

Yayın, yazılımın test sunucusundan canlı sunucuya taşındığı gündür. Teknik geçiş çoğu zaman birkaç saat sürer; ardından bir haftalık yakın izleme gelir. Müşteriden alan adı erişimi ve yayın saati onayı istenir.

Yayın saatini trafiğin en düşük olduğu zamana koymak riski azaltır. Eski bir site değişiyorsa, eski adresler yenilerine kalıcı (301) yönlendirmeyle bağlanır. Google bu yönlendirmelerin en az bir yıl korunmasını önerir. Orta büyüklükte bir sitede yeni adreslerin aramada yerleşmesi birkaç hafta sürebilir.

Kendi sitemiz Next.js, PHP ve MySQL ile yazıldı. Helsinki'deki bir Hetzner sunucusunda, Cloudflare arkasında çalışıyor. Yayın öncesinde sertifika, önbellek kuralları, yedek, hata kayıtları ve form gönderimleri canlı ortamda bir kez daha denenir.

Müşteri tarafında da yayın hazırlığı vardır. Çalışanlara yeni sistemin açılış tarihi duyurulur. Eski sistemdeki veriler son kez dışa aktarılır, aktarımdan sonra kayıt sayıları karşılaştırılır. Sayılar tutmuyorsa yayın ertelenir. Geri dönüş planı da yazılı olmalıdır: sorun çıkarsa eski sisteme nasıl dönülecek?

Yayından sonraki ilk 30 gün nasıl geçer?

İlk 30 gün, gerçek kullanıcıların sistemi ilk kez yoğun kullandığı dönemdir. Kapsam içindeki hatalar bu sürede ücretsiz düzeltilir. Dönemin sonunda bakım anlaşmasına geçilir.

İlk hafta hata kayıtları her gün okunur. Kullanıcılardan gelen sorular da bir listede toplanır. Bunların çoğu hata değil, alışkanlık farkıdır. Kısa bir eğitim videosu ya da yönetim panelindeki açıklama metinleri çoğunu çözer.

İlk ayın bir diğer işi ölçümdür. Search Console hata raporları, sunucu yanıt süreleri ve formlardan gelen talepler izlenir. Kendi sitemizde Search Console verisini, yazdığımız yönetim paneline API ile çekiyoruz. Ay sonunda kısa bir rapor hazırlanır: çıkan hatalar, düzeltilenler ve bakım listesine kalan istekler. Rapor, bakımdaki ilk işlerin sırasını da belirler.

Bakım; güvenlik güncellemelerini, yedek denetimini, sunucu izlemeyi ve küçük geliştirmeleri kapsar. Kütüphaneler düzenli güncellenmezse güvenlik açıkları birikir. Bakım anlaşmasında yanıt süresi, aylık iş saati ve yedeklerin nerede tutulduğu yazılı olmalıdır.

Değişiklik hangi aşamada pahalılaşır?

Değişiklik, onaylanan her aşamadan sonra biraz daha pahalılaşır. Analizde bir değişiklik yalnızca belgede bir satırdır. Yayından sonra aynı değişiklik belgeye, ekrana, koda, teste, veriye ve kullanıcıya dokunur.

Bir örnekle düşünelim: müşteri kaydına "vergi numarası" alanı eklenecek. Analizde bu, kapsam belgesine yazılan bir maddedir. Tasarım onaylandıysa birkaç ekranın da güncellenmesi gerekir. Geliştirme sırasında veritabanı, kod ve testler değişir. Yayından sonra eski kayıtlar için veri göçü yapılır, kullanıcılara da duyurulur.

Değişiklik istememek gerekmiyor; iş büyüdükçe ihtiyaç da değişir. Asıl mesele, değişikliğin yazılı bir taleple gelmesi ve süre etkisinin onaylanmasıdır. Acil olmayan küçük istekler bir listede biriktirilir. Yayından sonra tek bir sürümde toplu olarak ele alınır.

Değişiklik talebinde üç bilgi yeterlidir: ne isteniyor, neden isteniyor ve hangi tarihe kadar gerekiyor. Kapsam belgesindeki "yapılmayacaklar" listesi burada da işe yarar. İstek o listedeyse, yeni iş olarak konuşulacağı baştan bellidir.

Ödemeler hangi kilometre taşlarına bağlanır?

Ödemeler genellikle aşama onaylarına bağlanır: sözleşme, tasarım onayı, kabul ve yayın. Her ödeme, elle tutulur bir teslimin ardından yapılır. Böylece "yüzde kaçı bitti" gibi ölçülemeyen bir tartışma doğmaz.

Kilometre taşı, belgesi ve onayı olan, tarihi belli bir teslimdir. "Geliştirmenin yarısı" iyi bir kilometre taşı sayılmaz, çünkü ölçmesi zordur. "Randevu modülü kabul ölçütleriyle test sunucusunda" ise iyi bir örnektir. Bedelin nasıl oluştuğunu özel yazılım fiyatlarını belirleyen etkenler yazısında ayrıca anlattık.

Kabul ödemesi, kabul tutanağının imzasına bağlanır. Açık kalan küçük hatalar tutanağa liste hâlinde yazılır ve düzeltme tarihi verilir. Küçük bir eksik yüzünden bütün kabulü bekletmek iki tarafa da zarar verir. Bakım ise genellikle aylık ya da yıllık ayrı bir anlaşmayla yürür.

Projeyi en çok ne geciktirir?

Gecikmenin çoğu kod yazımından değil, bekleyen kararlardan doğar. Projelerde dört neden öne çıkar: geç içerik, kapsam kayması, onaylayıcı belirsizliği ve geç erişim.

• Geç gelen içerik: Metinler ve görseller gelmeden test anlamlı yapılamaz. İçerik takvimi, geliştirme takvimiyle aynı gün başlamalıdır.
• Kapsam kayması: Her toplantıda eklenen "küçük bir şey" toplamda haftalar eder. Yeni istek listeye yazılır, önceliği birlikte belirlenir.
• Tek onaylayıcının olmaması: Üç yönetici üç ayrı geri bildirim verirse ekip hangisini uygulayacağını bilemez.
• Dış hizmet başvuruları: Ödeme altyapısı ya da SMS hizmeti başvurusu günler sürebilir. Bu başvurular analiz biter bitmez yapılmalıdır.
• Geç verilen erişimler: Alan adı ya da ödeme hizmeti erişimi yayın günü aranırsa yayın kayar.

Müşteri tarafında her hafta düzenli zaman ayırabilen bir proje sorumlusu, bu gecikmelerin çoğunu baştan önler. Kararları o toplar, ekibe tek bir sesle iletir.