Ankara Özel Yazılım Geliştirme: Kapsamı ve Kabul Ölçütlerini Netleştirmek

Belirsiz bir özellik, farklı beklentiler üretir

“Teklif yönetimi olsun” ifadesi bir yazılım projesini başlatabilir ama bitirmek için yeterli değildir. Satış ekibi fiyat geçmişini görmek, yönetici onay vermek, finans ekibi tahsilatı izlemek isteyebilir. Herkes aynı ifadeyi kullanırken başka bir işlev düşünüyor olabilir. Özel yazılım geliştirmede ilk amaç bütün ayrıntıları sonsuza kadar sabitlemek değildir; ilk sürümde hangi işlerin hangi kurallarla tamamlanacağını ortak bir dille tarif etmektir. Bu dil, anlaşılır görevlerden oluşmalıdır.

Ankara'da proje bazlı çalışan bir teknik hizmet şirketini düşünün. Talep e-postayla geliyor, ekip keşif yapıyor, maliyet hazırlanıyor ve yönetici teklifi onaylıyor. “CRM geliştirilecek” cümlesi bu akışı açıklamaz. Talebin kim tarafından açıldığı, keşif bilgisinin ne zaman eklendiği ve onay sonrası hangi alanların değişebildiği yazılmalıdır. Gerçek iş akışından alınan bu ayrıntılar, hem ekranları hem veri modelini belirler. Yazılımın kapsamı işletmenin çalışma biçimine bağlanmış olur.

İhtiyacı kullanıcı, görev ve amaç olarak yazın

Her gereksinimde kimin neyi neden yapacağını belirtin. “Satış temsilcisi olarak önceki teklifleri görmek istiyorum; böylece aynı müşteriye hazırlanan güncel teklifin geçmişini değerlendirebileyim” gibi bir ifade, ekran başlığından daha fazla bağlam sağlar. GOV.UK kullanıcı hikâyeleri rehberi, kullanıcıyı, ihtiyacı ve amacı birlikte tanımlamayı açıklar. Bu biçim zorunlu bir şablon değildir; eksik soruları fark etmeyi sağlayan bir çalışma aracıdır.

Hikâyenin amacı yazılamıyorsa özelliğin gerekliliğini yeniden değerlendirin. Örneğin raporda her alanı göstermek, karar vermeyi kolaylaştırmayabilir. Yönetici hangi kararı alacak ve bu karar için hangi bilgiye ihtiyaç duyacak? Aynı şekilde bir bildirim de yalnızca gönderildiği için yararlı olmaz. Bildirim alan kişi hangi işlemi yapacaksa içerik, zamanlama ve bağlantı ona göre belirlenmelidir. Gereksinimi bu seviyede tartışmak, gereksiz ekranların ve sürekli ertelenen ayrıntıların azalmasına yardımcı olur.

Kabul ölçütünü gözlenebilir davranışla kurun

Kabul ölçütü, bir işin tamamlandığını nasıl anlayacağınızı anlatır. “Kullanımı kolay olsun” yerine, “yetkili kullanıcı müşteri kaydında yeni görüşme notu ekleyebilir ve kayıt yeniden açıldığında notu görebilir” gibi bir sonuç yazın. Her ölçütün otomatik test olması gerekmez; insan tarafından yapılan gösterimle de kontrol edilebilir. Önemli olan farklı kişilerin aynı davranışı beklemesidir. Ölçüt, özelliğin amacıyla ilişkili ve gereksiz teknik ayrıntılardan arınmış olmalıdır.

Bir teklif onayı için örnekleri genişletin. Taslak teklif düzenlenebilir, onay bekleyen teklif belirlenen kişi tarafından incelenebilir, reddedilen teklif açıklamayla geri dönebilir. Onaylı fiyat değişirse yeniden onay gerekir mi? Eski sürüm görüntülenebilir mi? Bunlar iş kuralıdır; yazılım ekibinin tahminine bırakılmamalıdır. Normal yolun yanında hata ve yetki koşulları da yazıldığında test planı kendiliğinden somutlaşır. Ekip kabul sırasında hangi örnekleri göstereceğini daha baştan bilir.

Veriyi ve yetkiyi ayrı bir çalışma olarak ele alın

Özellik listesi hazır olsa bile veri soruları eksik kalabilir. Bir müşteri birden fazla şubeye sahip mi, aynı kişi farklı kurumlarla ilişkili olabilir mi, eski kayıt silinmeli mi yoksa pasife mi alınmalı? Bu kararlar raporları ve kayıt geçmişini etkiler. Mevcut tabloları doğrudan yeni sisteme taşımadan önce alanların anlamını kontrol edin. İşletmenin farklı bölümleri aynı kelimeyi farklı anlamlarda kullanıyorsa ortak tanım yapılmalıdır. Veri sözlüğü bu amaçla hazırlanabilir.

Yetki düzeninde “yönetici” ve “kullanıcı” ayrımı her zaman yeterli olmaz. Bir kişi kendi teklifini görebilirken ekip lideri bütün ekibin kayıtlarını görmek isteyebilir. Bazı alanların yalnızca finans tarafından düzenlenmesi gerekebilir. Rol tablosunda görüntüleme, oluşturma, değiştirme ve silme işlemlerini ayrı ele alın. Ortak hesap kullanımı yerine kişiye bağlı erişim ihtiyacını konuşun. Workhub CRM sayfasında yer alan rol bazlı yetkilendirme ve ortak veri yaklaşımı, bu tartışma için somut bir ürün bağlamı sunar.

Entegrasyon ve aktarım sınırlarını kaydedin

Dış sistem bağlantısı gerekiyorsa hangi verinin ana kaynak olduğunu belirleyin. Ürün fiyatı muhasebe sisteminden geliyor ama satış ekibi müşteriye özel fiyat girebiliyorsa iki bilginin ilişkisi tanımlanmalıdır. Bağlantı kesildiğinde işlemin durması mı yoksa beklemeye alınması mı gerektiği de iş kararıdır. Her entegrasyonun başarılı durumunu yazmak yetmez; gecikme, eksik veri ve tekrar gönderim gibi koşullar için de kabul örnekleri hazırlanmalıdır. Böylece sistemler arasında kaybolan sorumluluklar azalır.

Eski verinin taşınması için örnek aktarım yapın. Toplam kayıt sayısı tek kontrol değildir; müşteri ilişkileri, tarih bilgileri ve dosya bağlantıları da incelenmelidir. Eksik verilerin kimin tarafından düzeltileceği ve aktarım sırasında hangi kayıtların dışarıda bırakılacağı önceden kararlaştırılmalıdır. Geçiş gününde eski sisteme veri girişi devam edecekse son değişikliklerin nasıl alınacağı da planlanmalıdır. Bu iş, geliştirme bittikten sonra birkaç dosya yüklemek kadar basit olmayabilir ve ayrı kabul gerektirebilir.

İlk sürümün sınırını gerekçesiyle belirleyin

Bütün ihtiyaçları aynı sürümde çözmeye çalışmak, ilk faydanın görülmesini geciktirebilir. Öncelikleri yalnızca “olmazsa olmaz” etiketleriyle sıralamak yerine hangi görevin hangi sonuca hizmet ettiğini tartışın. Bir özellik başka bir işin çalışması için zorunluysa bağımlılık olarak kaydedin. Nadiren kullanılan ve geçici olarak manuel yürütülebilen işler sonraya bırakılabilir. Ancak manuel kalan işin sorumlusu ve sınırı belli olmalıdır. Görünmeyen geçici işler zamanla kalıcı yük haline gelebilir.

MVP geliştirme rehberindeki yaklaşım, ilk sürümün öğrenme ve kullanım amacını belirlemeye yardımcı olur. Bir özelliği ertelemek, ihtiyacı önemsiz saymak değildir. Ertelemenin gerekçesi, yeniden değerlendirileceği durum ve gerekli veri kaydedilebilir. Böylece proje listesi sürekli büyüyen bir dilek dosyası olmaktan çıkar. İlk sürümün başarılı sayılacağı koşullar da ekipçe bilinir. Bu koşullar hem teknik çalışmayı hem işletmenin hazırlığını kapsamalıdır.

Değişiklikleri kayıt altına alarak ilerleyin

Geliştirme sırasında yeni bilgi öğrenilmesi normaldir. Sorun, yeni kararların eski kapsamı sessizce değiştirmesidir. Değişiklik kaydında talebin nedeni, etkilenen görevler, süre ve test etkisi bulunmalıdır. Her değişiklik için ağır bir toplantı gerekmeyebilir; önemli olan kararın izlenebilir olmasıdır. İş kuralı değiştiğinde kabul ölçütleri de güncellenmelidir. Aksi halde geliştirici yeni beklentiyi üretirken test ekibi eski beklentiyi kontrol edebilir ve gereksiz bir anlaşmazlık oluşabilir.

Özel yazılım hizmeti için görüşmeye gelirken tamamlanmış bir teknik şartnameye sahip olmanız gerekmez. Gerçek görevleri, örnek kayıtları ve zorlandığınız adımları paylaşmanız yeterli bir başlangıç olabilir. Çalışmanın sonunda ise kapsamın iş görevleriyle, kabulün gözlenebilir davranışlarla ve sorumlulukların isimlendirilmiş rollerle anlatılması gerekir. İyi tanımlanmış bir proje dosyası değişimi engellemez; değişimin hangi kararı etkilediğini görmeyi sağlar. Yazılımın teslimi de bu açıklık üzerinden değerlendirilebilir.