Özel yazılım geliştirme süreci: aşamalar, teslimler ve onay noktaları

Özel yazılım geliştirme süreci; keşif ve analiz, kapsam ve kabul kriterleri, tasarım prototipi, aşamalı geliştirme, test ve kabul, canlıya alma ve bakım olmak üzere yedi aşamadan geçer. Her aşamanın sonunda size yazılı bir çıktı teslim edilmeli ve sizden açık bir onay istenmelidir. Onay noktası olmayan bir süreçte kapsam kayar, bütçe tartışmalı hâle gelir ve "ne istemiştik, ne yapıldı?" sorusu ancak proje sonunda sorulur. Bu yazı, her aşamada neyi teslim aldığınızı, neyi onaylamanız gerektiğini ve hangi soruları sormanız gerektiğini sade bir dille anlatıyor.

Özel yazılım süreci hangi aşamalardan oluşur?

Firmadan firmaya adlandırma değişir, ama sıra aşağı yukarı aynıdır. Aşağıdaki tablo, bir karar vericinin süreci tek bakışta okuyabilmesi için hazırlandı. Süre ve emek projenin büyüklüğüne ve karmaşıklığına bağlıdır; bu nedenle tabloda süre yok, çünkü her aşamanın uzunluğu kapsama göre değişir.

Aşağıda her aşamayı ayrı ayrı ele alıyoruz. Her bölüm tek başına okunabilir; yalnızca ilgilendiğiniz aşamaya atlayabilirsiniz.

Keşif ve analiz aşamasında ne teslim edilir?

Keşif, kod yazılmadan önce işin anlaşıldığı aşamadır. Yapılan iş basittir: sizi dinleriz, mevcut düzeni görürüz (defter, Excel, mevcut program, e-posta zinciri), kimin hangi işi nasıl yaptığını sorarız. Çıktı bir analiz dokümanıdır. İyi bir analiz dokümanında şunlar bulunur:

• Mevcut iş akışının adım adım anlatımı ve sorunların listesi
• Kullanıcı rolleri: kim sisteme girecek, kim neyi görecek, kim neyi değiştirecek
• Bağlanması gereken sistemler: muhasebe programı, ERP, ödeme altyapısı, mevcut web sitesi
• Hesaplama ve iş kuralları: yazılı olmayan "bizim hesabımız böyle" kuralları
• Açık sorular ve varsayımlar

Siz neyi onaylarsınız? İşinizin doğru anlaşıldığını. Dokümanda yanlış anlaşılmış bir cümle görürseniz bu aşamada düzeltmek kolaydır; geliştirme başladıktan sonra düzeltmek ise yeniden iş demektir. Analiz dokümanı sizin için hazırlanmış bir belgedir; başka bir firmayla çalışmaya karar verseniz bile elinizde kalmasını isteyin.

Kapsam ve kabul kriterleri neden ayrı bir aşamadır?

Analiz "ne var" sorusunu cevaplar; kapsam "ne yapılacak" sorusunu cevaplar. Bu iki belgeyi karıştıran projelerde anlaşmazlık genellikle burada başlar. Kapsam belgesi üç parçadan oluşmalıdır:

1. Kapsam içi maddeler: Her biri tek cümleyle ve ölçülebilir biçimde yazılmış işlevler. "Raporlama modülü" yerine "Aylık satış raporu, müşteri ve ürün bazında filtrelenebilir, Excel olarak indirilebilir" gibi.
2. Kapsam dışı maddeler: Açıkça yazılmış, bu projede yapılmayacak işler. Bu liste, sonradan çıkan "bunu da yaparsınız sanmıştık" tartışmalarını önler.
3. Kabul kriterleri: Her madde için "bu iş bitti sayılır" ölçütü. Örneğin "Yetkisiz kullanıcı rapor ekranının adresini yazsa bile ekran açılmaz."

Siz neyi onaylarsınız? Kapsamın yazılı hâlini. Bu onay, sözleşmenin ve değişiklik yönetiminin dayanağıdır. Kapsamdaki bir maddeyi anlamadıysanız imzalamayın; kabul aşamasında ölçüt olarak kullanılacak olan bu cümlelerdir.

Tasarım prototipi aşamasında neyi görür ve onaylarsınız?

Prototip, yazılım yazılmadan önce ekranların ve akışın tıklanabilir bir taslağıdır. Amacı güzel görünmek değil, yanlış anlaşılmaları erken yakalamaktır. Bir tablonun hangi sütunlarla açılacağı, bir formun kaç adımda doldurulacağı, bir onay düğmesinin nerede duracağı bu aşamada netleşir.

Prototipi incelerken şunlara bakın:

• Günlük işi yapacak kişi, ekranları kendi gerçek örnekleriyle gezdi mi? Yalnızca yönetici onayı yetmez.
• Hata durumları düşünülmüş mü? Zorunlu alan boş kalırsa, kayıt zaten varsa, yetki yoksa ne görünüyor?
• Telefonda ve geniş ekranda kullanım gerekiyorsa her ikisi için ekran var mı?
• Her ekran, kapsam belgesindeki bir maddeye karşılık geliyor mu? Kapsamda olmayan bir ekran varsa nedeni nedir?

Siz neyi onaylarsınız? Ekranları ve akışı. Prototip onaylandıktan sonra gelen "ekran şöyle olsaydı" değişiklikleri, kapsam değişikliği olarak ele alınır; bunun nasıl yönetileceğini aşağıda anlatıyoruz.

Aşamalı geliştirme ve sprint teslimleri nasıl işler?

Geliştirme tek bir büyük teslimde değil, küçük ve çalışan parçalar hâlinde ilerlemelidir. Bu parçalara sprint ya da aşama denir; her biri, kapsamdaki bir grup maddenin gerçekten çalışır hâle gelmesi demektir. Aşama sonunda size gösterilen şey bir sunum değil, kendi bilgisayarınızda ya da bir deneme ortamında kullanabildiğiniz bir sürüm olmalıdır.

Aşama sonunda şunları isteyin:

• Çalışan sürüm: Ekran görüntüsü yetmez; kendiniz denemelisiniz.
• Ne yapıldı, ne yapılmadı notu: Kapsamdan hangi maddelerin tamamlandığı yazılı olmalı.
• Açık hata ve değişiklik listesi: Bulunan sorunlar ve talepler ayrı ayrı görünür olmalı.
• Bir sonraki aşamanın içeriği: Önümüzdeki aşamada hangi maddelerin yapılacağı.

Siz neyi onaylarsınız? Aşama bazında geri bildirim verirsiniz: bu parça beklediğim gibi çalışıyor, şu noktalar düzeltilmeli. Ödeme aşamaları da bağlanmışsa, aşama onayı ödeme adımının dayanağı olur. Aylarca sessiz kalan bir ekiple düzenli görünürlük sağlayan bir ekibi ayıran şey budur. Hangi teknolojilerle çalışıldığını merak ediyorsanız teknoloji yığınımız sayfasında açıkça yazıyoruz.

Test ve kabul aşamasında müşteri neyi kontrol eder?

Test iki ayrı iştir ve ikisi karıştırılmamalıdır. Birincisi, yazılımı geliştiren ekibin kendi testidir: kodun beklenen şekilde çalıştığını sınar. İkincisi, sizin kabul testinizdir: yazılım, kapsam belgesindeki kabul kriterlerini karşılıyor mu? Kabul testini gerçek kullanıcıların, kendi gerçek örnek kayıtlarıyla yapması gerekir.

Kabul testi için pratik bir yöntem:

1. Kabul kriterlerini bir tabloya dökün; her satır bir test senaryosu olsun.
2. Her senaryoyu gerçek bir kullanıcı çalıştırsın ve sonucunu "geçti / kaldı" olarak işaretlesin.
3. Kalan maddeler hata listesine girsin; kimin düzelteceği ve ne zaman yeniden test edileceği yazılsın.
4. Kritik maddeler geçmeden kabul imzası atılmasın.

Kabul tutanağında nelerin bulunması gerektiği için teslim alırken kontrol listesi ve kabul tutanağı yazısına bakabilirsiniz. Yazılımın hiç hata içermeyeceğini söylemek gerçekçi değildir; gerçekçi olan, bulunan hataların kayıt altına alınması ve kabul kriterlerine göre kapatılmasıdır.

Siz neyi onaylarsınız? Kabul kriterlerinin karşılandığını. Bu imza, sözleşmedeki son ödeme adımıyla ve bakım dönemiyle bağlantılı olabilir; bu yüzden imzadan önce kalan işlerin yazılı listesini isteyin.

Canlıya alma sırasında neler olur?

Canlıya alma, yazılımın gerçek verilerle ve gerçek kullanıcılarla ilk kez çalıştığı andır. Bu aşamayı bir "düğmeye basma" olarak değil, plan olarak ele alın. Teslim alacağınız çıktılar:

• Canlıya alma planı: Hangi gün, hangi saatte, hangi sırayla, kim sorumlu.
• Veri aktarımı ve doğrulama: Eski sistemden veri taşınacaksa nasıl doğrulanacağı. Aktarım sonrası kontrolü veriyi bilen sizin ekibiniz yapmalıdır.
• Geri dönüş planı: Bir sorun çıkarsa önceki duruma nasıl dönüleceği.
• Yedekleme düzeni: Ne sıklıkla, nereye, kim erişebilir, geri yükleme denendi mi.
• Yetki ve erişim bilgileri: Alan adı, sunucu, yönetim paneli ve kod deposuna kimin eriştiği; bunların kimin adına kayıtlı olduğu.

Siz neyi onaylarsınız? Canlıya alma tarihini ve planı. Canlıya alma sonrasındaki ilk günlerde yakın izleme ve hızlı destek isteyin; bu dönemin nasıl işleyeceği sözleşmede yazılı olmalıdır. Eski bir sistemden geçiyorsanız legacy modernizasyon sayfasında bu geçişin nasıl ele alındığını okuyabilirsiniz.

Bakım aşamasında ne kapsanır, ne kapsanmaz?

Yazılım canlıya çıktığında iş bitmez; yazılım yaşayan bir üründür. Sunucu güncellemeleri, güvenlik yamaları, kullanılan kütüphanelerin sürümleri, yedekleme ve küçük düzeltmeler bakımın konusudur. En sık yapılan hata, bakımın neleri kapsadığını yazıya dökmemektir. Bakım kapsamı şu soruları cevaplamalıdır:

• Hata düzeltme bakım içinde mi, yoksa ayrıca mı hesaplanır? Hata ile yeni talep nasıl ayrılır?
• Destek nasıl istenir (e-posta, telefon, WhatsApp), hangi saatlerde yanıtlanır?
• Güvenlik güncellemelerini kim yapar, ne sıklıkla?
• Yedekleme ve barındırma kimde? Barındırma yeri neresi?
• Yeni özellik talebi nasıl fiyatlanır ve planlanır?

Kaynak kod ve lisans konusunu da bu aşamadan önce, sözleşme sırasında netleştirin: teklifte kaynak kod ve lisans maddesinin açıkça yazılmasını isteyin. Firma değiştirmeniz gerekirse kodu, dokümanları ve erişimleri nasıl devralacağınız bu maddeye bağlıdır.

Değişiklik talebi süreçte nasıl yönetilir?

Projenin ortasında yeni ihtiyaçlar çıkması normaldir. Sorun, bunların yönetilmemesidir. Sağlıklı bir değişiklik talebi akışı şöyle işler:

1. Talep yazılı olarak iletilir (e-posta ya da ortak bir liste).
2. Firma, talebin kapsam içinde mi dışında mı olduğunu belirtir.
3. Kapsam dışıysa emek ve takvim etkisi yazılı olarak sunulur.
4. Siz onaylarsınız; ardından talep planlanır. Onaylamazsanız proje mevcut kapsamla devam eder.

Bu akış sizi de korur: bütçe ve takvim sürpriz olmaz.

Aşama onayları sözleşmede nasıl yazılmalı?

Süreç belgeleri ancak sözleşmeye bağlandıklarında işe yarar. Sözleşmede şu üç cümlenin karşılığı bulunmalıdır. Birincisi, her aşamanın çıktısı adıyla anılmalıdır: "analiz dokümanı", "kapsam ve kabul kriterleri belgesi", "prototip", "test sonuçları", "canlıya alma planı". İkincisi, her çıktı için onay yöntemi yazılmalıdır: e-posta ile yazılı onay yeterli mi, imzalı tutanak mı gerekir? Üçüncüsü, onay verilmediğinde ne olacağı belirtilmelidir: düzeltme istenir, düzeltme yapılır, yeniden onaya sunulur.

Onay sessizlikle verilmiş sayılmamalıdır. "Bildirimden itibaren belirli bir süre içinde itiraz edilmezse kabul edilmiş sayılır" türünde maddeler görürseniz, bu sürenin makul olup olmadığını ve ekibinizin gerçekte o sürede geri bildirim verebilip veremeyeceğini değerlendirin. Geri bildirim veremeyecek bir ekip için bu madde, farkında olmadan verilmiş bir kabul anlamına gelebilir.

Son olarak, tüm belgelerin tek bir yerde, sürüm tarihleriyle saklanmasını isteyin. Aylar sonra "bu madde ne zaman değişti?" sorusunun cevabı, düzenli tutulmuş bir belge arşivinde bulunur.

Sürecin her aşamasında hangi kırmızı bayraklara dikkat etmeli?

• Analiz yapılmadan doğrudan teklif ve geliştirme önerilmesi
• Kapsamın "genel olarak anlaştık" gibi sözlü ifadelerle bırakılması
• Prototipsiz geliştirme: ekranları ilk kez bitmiş yazılımda görmek
• Tek bir büyük teslim: aylarca çalışan sürüm görmeden ilerlemek
• Kabul kriteri olmaması: "bitti" kararının firmaya bırakılması
• Canlıya almada geri dönüş ve yedek planının olmaması
• Bakımın ve kaynak kod/lisansın sözleşmede yer almaması

Müşteri tarafında neler hazırlanmalı?

Süreç tek taraflı değildir. Müşteri tarafında da bir hazırlık gerekir: işi bilen bir proje sorumlusu (kararları hızlı veren tek kişi), gerçek örnek veri ve dosyalar, kullanıcıların prototipi ve ara sürümleri deneyecek zamanı. En sık gecikme nedeni teknik değil, geri bildirimin gelmemesidir. Geri bildirim için bir iç takvim kurarsanız, proje tarihleri de daha gerçekçi olur.

Kodem bu süreci nasıl yürütüyor?

Bu aşamaları işimizin çerçevesi olarak izliyoruz; kapsam ve takvim, keşif görüşmesinden sonra aşama tarihleriyle yazılı teklife girer. Özel yazılım yaklaşımımızı özel yazılım geliştirme sayfasında bulabilirsiniz. Kendi projeniz için yazılı teklif almak isterseniz teklif alma sayfasını kullanabilirsiniz.