Kabul Kriterleri Nasıl Yazılır? Teslim Anlaşmazlığını Önleyin
Bir e-ticaret projesinin teslim tarihi geldiğinde müşteri siteyi açar, sepete ürün ekler, ödeme adımına gelir ve kargo entegrasyonunun eksik olduğunu görür. Yazılım ekibi sözleşmede kargo entegrasyonunun yazmadığını, sadece "ödeme altyapısı" dendiğini söyler. Müşteri ise bunu zaten kapsamın bir parçası saymıştır. Proje teslim edilemez, fatura kesilemez, iki taraf da kendi açısından haklıdır.
Bu tablo kabul kriterlerinin net yazılmadığı hemen her projede aynı şekilde tekrar ediyor. Ekibimizin gördüğü kadarıyla anlaşmazlıkların kaynağı kötü niyet değil, baştan tanımlanmamış beklenti. Kabul kriterleri, projenin "bitti" sayılması için karşılanması gereken somut ve ölçülebilir şartlardır. Bu şartlar yazılı değilse teslim anındaki yorum farkı taraflardan birinin aleyhine döner ve genelde bütçesi daha kısıtlı olan taraf kaybeder.
Kabul kriteri ile gereksinim arasındaki fark
Gereksinim, sistemin ne yapması gerektiğini anlatır: "Kullanıcı ürünü sepete ekleyebilmeli." Kabul kriteri ise bu gereksinimin karşılandığını nasıl doğrulayacağınızı söyler: "Kullanıcı sepete ürün ekler, sepet sayfasında ürün adı, adedi ve toplam tutar görünür, stok sıfırsa ekle butonu pasif olur." Gereksinim niyeti anlatır, kabul kriteri ise testi anlatır.
Birçok proje teklifi sadece gereksinim listesi içerir, kabul kriteri içermez. Bu durumda teslim anında "çalışıyor mu" sorusunun cevabını iki taraf ayrı ayrı belirler. Yazılım ekibi fonksiyonun teknik olarak çalıştığını gösterir, müşteri ise kendi kafasındaki akışın eksiksiz olmadığını fark eder. Bu boşluğu kapatan tek araç kabul kriteridir.
Kriterleri kim yazmalı, ne zaman yazılmalı
Kabul kriterleri keşif ve ihtiyaç analizi aşamasında, kapsam netleşirken yazılmalıdır. Geliştirme bittikten sonra yazılan kriter artık bir kontrol listesi değil, tartışma konusudur. Kriterleri idealde iş tarafı ile teknik ekip birlikte oluşturur: iş tarafı neyin önemli olduğunu söyler, teknik ekip bunu ölçülebilir bir ifadeye çevirir.
Tek başına müşterinin yazdığı kriterler genelde çok genel kalır ("sistem hızlı ve kullanıcı dostu olmalı"), tek başına geliştiricinin yazdığı kriterler ise iş mantığını kaçırır. İkisinin birlikte oturduğu bir kabul kriteri oturumu, sonradan yaşanacak birçok anlaşmazlığı projenin en ucuz aşamasında çözer. Biz SUNS Tech olarak hizmetlerimiz kapsamında yürüttüğümüz projelerde bu oturumu keşif aşamasının zorunlu bir adımı olarak planlıyoruz; sonradan eklemek çok daha pahalıya geliyor.
İyi yazılmış bir kriterin özellikleri
Bir kabul kriteri dört şeyi aynı anda sağlamalıdır: ölçülebilir olmalı, tek bir yorum yoluna izin vermeli, test edilebilir olmalı ve kapsam dışını da zımnen belirtmelidir. "Sayfa hızlı açılmalı" bir kabul kriteri değildir, çünkü hızlı kelimesi herkes için farklı bir eşik ifade eder. "Ana sayfa, standart bir mobil bağlantıda ilk içeriği üç saniye içinde göstermeli" ise ölçülebilir ve test edilebilir bir ifadedir.
Kriterleri yazarken şu kontrolü uygulayabilirsiniz: bu cümleyi okuyan iki farklı kişi, sistemi test ettiğinde aynı sonuca mı varır? Cevap hayırsa cümle yeniden yazılmalıdır. Bu basit test saatlerce süren kabul toplantılarının önüne geçer.
Olumlu ve olumsuz senaryoları birlikte yazın
Çoğu ekip sadece "doğru giriş yapıldığında kullanıcı panele yönlenir" gibi olumlu senaryoyu yazar. Anlaşmazlıkların büyük kısmı ise hata durumlarında çıkar: yanlış şifre girilince ne olacak, stok tükenince sepete ekleme nasıl engellenecek, ödeme reddedilirse kullanıcı hangi sayfaya düşecek. Bu senaryolar kabul kriterlerine girmezse test aşamasında geliştirici "bu durum tanımlanmamıştı" der ve haklı da çıkar.
Kabul kriterlerinin yaşadığı belge ve format
Kabul kriterleri sözleşme ekinde, proje yönetim aracında veya ayrı bir gereksinim dokümanında tutulabilir; önemli olan tek bir kaynağın geçerli kabul edilmesidir. İki farklı yerde, örneğin e-postada bir versiyon, proje yönetim aracında başka bir versiyon tutulan kriterler zamanla birbirinden sapar ve teslimde hangi versiyonun geçerli olduğu tartışma konusu olur.
Kurumsal projelerde kabul kriterlerinin sözleşmenin teknik şartname ekine bağlanması, teslim tutanağının bu ekteki maddelere referans vermesi beklenir. Daha küçük ölçekli projelerde proje yönetim aracındaki her iş kaleminin altına yazılan birkaç maddelik kriter yeterli olabilir. Format değişir ama tekillik ilkesi değişmez, bir proje için tek bir geçerli kriter listesi olmalıdır.
Değişiklik talepleri kriterleri nasıl etkiler
Proje ilerledikçe müşteri yeni bir talep getirebilir: "Aslında sepette kupon kodu alanı da olsun." Bu talep kabul edilirse ilgili kabul kriteri listesine yeni madde eklenmeli ve bu ekin süre veya bütçeye etkisi ayrıca not edilmelidir. Kriter listesine sessizce madde ekleyip süreyi sabit tutmak kapsam kaymasının en sık görülen biçimidir ve genelde geliştirme ekibinin fazla mesaisiyle kapatılır.
Teslim anında kriterler nasıl uygulanır
Teslim toplantısında yapılması gereken şey basittir: kriter listesi tek tek okunur, her madde için "karşılandı", "kısmen karşılandı" veya "karşılanmadı" işaretlenir. Kısmen karşılanan maddeler için ek süre veya ek kapsam tartışması o anda yapılır; genel bir "beğenmedim" ifadesiyle tüm teslim bloke edilmez.
Burada sık görülen bir yanlış anlama şu: müşteri teslim toplantısında kabul kriterlerinde olmayan yeni bir beklenti dile getirir ve teslimi bu yüzden onaylamaz. Kabul kriterleri varsa bu durumda net bir cevap vardır: talep haklı olabilir ama kapsam dışıdır, ayrı bir iş kalemi olarak planlanır. Kriterler olmadan bu ayrım yapılamaz, her yeni talep teslimi geciktiren bir tartışmaya döner.
Kriterlerin tamamı karşılandığında teslim tutanağı imzalanır ve bu tutanak hem ödeme hem destek sürecinin başlangıç noktası olur. Kurumsal müşterilerimizle çalışırken bu tutanağı, sonraki destek ve geliştirme taleplerinin referans noktası olarak tutmasını öneririz; aksi halde "bu zaten eski kapsamın parçasıydı" tartışması her destek talebinde tekrar eder. Projenizin kapsamını ve kabul sürecini netleştirmek istiyorsanız teklif al sayfamızdan bize ulaşabilirsiniz.
Kriter yokluğunun maliyeti nereye yansır
Kabul kriteri olmayan bir projede anlaşmazlık genelde iki şekilde çözülür: ya geliştirme ekibi ek talebi ücretsiz karşılar ve kârlılığından kaybeder, ya da müşteri beklediği şeyi alamadan ödeme yapar ve memnuniyetsiz kalır. Her iki sonuç da ilişkiyi yıpratır ve bir sonraki projede güvensizliğe dönüşür.
Özellikle sabit bütçeli projelerde kriter belirsizliği kapsamın sessizce büyümesine yol açar. Geliştirici her küçük talebi reddetmek istemez, müşteri de bunun ek iş olduğunu bilmez; sonuçta proje süresi uzar, ekip başka projelere geç başlar ve zincirleme bir gecikme oluşur. Kabul kriterleri bu zincirin ilk halkasını, yani "bu talep kapsamda mı" sorusunu baştan cevaplar.
Kurumsal projelerde veri işleme süreçleri gibi uyumluluk gerektiren maddeler de kabul kriterlerine somut şekilde yazılmalıdır. "KVKK'ya uygun olmalı" gibi genel bir ifade yerine hangi veri alanının hangi şartla saklandığı, kimin erişebildiği net yazılmalıdır; aksi halde bir denetim sırasında hangi tarafın sorumlu olduğu belirsiz kalır. Bu tür projelerde kapsamı baştan netleştirmek isteyen ekipler yazılım danışmanlığı sürecinden faydalanabilir, çünkü kriter oturumu burada kapsam belgesinin doğal bir parçası haline gelir.
