Scope ve Out of Scope

30 saniyelik özet

Scope, yani kapsam, bir çalışmanın hangi problemi, kullanıcıları, süreçleri ve davranışları ele alacağını belirler. Out of Scope, yani kapsam dışı, bu çalışmada desteklenmeyecek durumları açıklar. Bir özellik listesi tek başına yeterli değildir; veri sınırı, istisnalar ve tamamlanma koşulları da anlaşılmalıdır. Kapsamı daraltmak, değeri veya gerekli kaliteyi rastgele azaltmak değildir. Amaç, anlamlı bir sonucu teslim edilebilir büyüklükte tanımlamak ve yeni taleplerin etkisini değerlendirebilmektir.

Neden önemli?

Bir toplantıda “müşteri adresini değiştirebilsin” denildiğinde herkes aynı işi anladığını düşünebilir. Oysa biri hesap adresini, diğeri siparişin teslimat adresini, başka biri kargoya verilmiş paketin yönlendirilmesini düşünüyor olabilir. Cümle aynı kalırken gereken süreç ve sistem bağlantıları değişir.

Bu fark geliştirme başladıktan sonra ortaya çıkarsa taraflar birbirini yanlış anlamış olmakla suçlayabilir. Satış, müşteriye bütün adres değişikliklerini vaat etmiş olabilir. Operasyon, gönderilmiş siparişlerin de yeni akışa gireceğini varsayabilir. Geliştirme ekibi ise yalnızca profil ekranını değiştirmiş olabilir. Sorun, ortak bir kapsamın oluşturulmamış olmasıdır.

Junior bir iş analisti için kapsam tanımlamak, talebin sınırlarını somutlaştırma becerisidir. Yönetici için kaynak ve taahhüt yönetimidir. Her yeni isteğin küçük görünmesi, toplam etkisinin küçük olduğu anlamına gelmez. Bir ekleme başka kullanıcıları, verileri ve sistemleri kapsayarak işin riskini değiştirebilir.

Kapsam dışı ifadeler bu yüzden değerlidir. “Bunu yapmayacağız” demek tek başına yeterli değildir; mevcut işin nasıl yürümeye devam edeceği de açıklanmalıdır. Yeni çözümün dışında kalan müşteri veya işlem grubu için destek düzeni bilinmezse teslimat tamamlandığında operasyonel boşluk oluşabilir.

Terim nedir?

Kapsam, çalışmanın ele aldığı alan ve teslim edeceği davranışlarla ilgili sınırdır. İş hedefi neden çalışıldığını, kapsam ise bu hedefe hangi bölümde katkı sağlanacağını açıklar. Hedef geniş olabilir; ilk teslimat belirli bir müşteri grubuna veya süreç aşamasına odaklanabilir. Bu odak, hedefle ilişkilendirilmelidir.

Ürün kapsamı, çözümün sağlayacağı davranış ve kabiliyetleri anlatır. Proje kapsamı ise bunları gerçekleştirmek için gereken çalışmaları içerir. Yeni ekran ürün davranışı olabilir; veri taşıma, kullanıcı eğitimi ve operasyon hazırlığı da teslimat için gereken işler olabilir. Sadece ekranda görünen parçayı tanımlamak, gereken çalışmanın bir bölümünü gizler.

Kapsam dışı, bu çalışma için alınmış bir karardır. Bir ihtiyacın hiçbir zaman karşılanmayacağı veya sonraki sürümde kesin yapılacağı anlamına gelmez. Gelecek taahhüdü ayrı değerlendirilmelidir. “Daha sonra” ifadesi, önceliği ve kararı belirlenmemiş bir işi teslimat sözüne dönüştürmemelidir.

Sınırlar gözlenebilir biçimde yazılmalıdır. “Kurumsal müşteriler desteklenecek” ifadesi hangi hesapların uygun olduğunu açıklamıyorsa farklı yorumlara açıktır. Sürecin hangi olayla başladığı, hangi durumda sona erdiği ve hangi işlem çeşitlerinin desteklendiği belirtilmelidir. Kullanıcının yetkisi ve işlenecek veri de bu sınırların parçasıdır.

Tamamlanma koşulu, teslimatın ne zaman kabul edileceğini netleştirir. Bir düğmenin görünmesi yeterli olmayabilir; işlemin doğru kaydı değiştirmesi, yetkisiz kullanımı engellemesi ve sonucunu açıklaması gerekebilir. Kapsamı azaltmak adına gerekli doğruluk ve güvenlik koşullarını çıkarmak, kullanılabilir bir çözüm üretmeyebilir.

Kapsam zaman içinde değişebilir. Yeni bilgi mevcut kararın yanlış olduğunu gösterebilir. Bu durumda sınırları korumak için kanıtı görmezden gelmek yerine etki değerlendirilir. Süre, maliyet, bağımlılık ve beklenen fayda yeniden ele alınır. Değişikliğin kim tarafından kararlaştırıldığı ve hangi sürüme uygulandığı kaydedilir.

Gerçek vaka: Basecamp’te “takvim” talebini sınırlandırmak

Basecamp’in Shape Up kitabındaki “Set Boundaries” bölümü, bir müşterinin takvim talebinin nasıl araştırıldığını anlatıyor. Müşteri uzaktan çalışırken toplantı odalarının uygunluğunu göremediği için ofise gitmek zorunda kalıyormuş. Ekibin bulduğu ihtiyaç, bütün takvim özelliklerini sunmak değil, uygun zaman aralıklarını görebilmekmiş.

Mevcut etkinlik listesi önemli tarihleri gösterebiliyor, ancak boşlukları görmeye yeterince yardımcı olmuyormuş. Ekip problemi bu kullanım durumuna daraltarak daha sınırlı bir çözüm fikrine yönelmiş. Kitap ayrıca “appetite” kavramını, ekibin bir işe ayırmaya hazır olduğu zaman bütçesi olarak açıklıyor; bunu işin ne kadar süreceğine ilişkin tahminden ayırıyor.

Bu vaka, kapsam kararının ihtiyacı araştırarak alınabileceğini gösteriyor. Talep edilen ürün kategorisi bütün özellikleriyle kabul edilmemiş; müşterinin yaşadığı belirli güçlük ele alınmış. Kaynak, Basecamp’in kendi yöntem anlatımıdır. Aynı sınırlandırma yaklaşımının her projede aynı teslimat sonucunu sağlayacağını kanıtlayan bir karşılaştırma sunmuyor.

Kaynak: Ryan Singer, Shape Up, “Set Boundaries”, Basecamp.

Varsayımsal örnek: Müşterinin teslimat adresini değiştirmesi

Bir e-ticaret işletmesinde destek ekibine gelen adres değiştirme taleplerini azaltmak için müşteriye kendi işlemini yapabileceği bir akış tasarlandığını düşünelim. İlk talep, “sipariş adresi değiştirilebilsin” olsun. Analist önce hangi sipariş durumlarında hangi değişikliğin mümkün olduğunu araştırır.

İlk teslimatın, hazırlık başlamamış uygun siparişlerle sınırlı tutulduğu varsayılsın. Kullanıcı grubu, sipariş sahibinin hesabı üzerinden doğrulanır. İşlem, teslimat adresini değiştirir; hesapta kayıtlı varsayılan adresin değişmesi bu davranışa otomatik olarak eklenmez. İki kayıt aynı görünse de farklı amaçlara hizmet eder.

Kapsam içinde uygunluk kontrolü, adres doğrulama, işlemin kaydedilmesi ve kullanıcıya sonuç gösterilmesi bulunabilir. Başlangıç, müşterinin değişiklik talebidir. Bitiş, ilgili sipariş adresinin güncellenmesi ve gerekli operasyon sistemlerinin değişikliği aldığına ilişkin tanımlı koşulun sağlanmasıdır. Bu koşul teknik ve operasyon ekipleriyle doğrulanmalıdır.

Kapsam dışında, kargoya verilmiş paketin yönlendirilmesi ve ilk teslimatta desteklenmeyen teslimat türleri açıkça yazılır. Bu gruplar için mevcut destek süreci devam edebilir. Kullanıcıya değişikliğin uygun olmadığı durumda ne gösterileceği ise kapsam içinde ele alınır. Desteklenmeyen işlemi güvenli biçimde reddetmek de bir davranıştır.

Adres değişikliğinin teslimat ücreti veya hizmet uygunluğunu etkileyebileceği fark edilirse yeni bir karar gerekir. Analist bunu küçük bir metin değişikliği gibi değerlendirmez. İş kuralı, ödeme ve operasyon etkileri araştırılır. Gerekirse ilk kapsam daha dar tutulur veya değişiklik ayrı bir teslimat olarak değerlendirilir.

Doğrulamada uygun sipariş, uygun olmayan sipariş, yetkisiz kullanıcı ve işlem sırasında durum değişmesi senaryoları incelenir. Böylece sınır yalnızca belgede kalmaz, uygulanacak davranışa dönüşür. Teslimattan sonra destek taleplerinin değişimi ve yanlış adres işlemleri izlenebilir; faydanın kalite kaybıyla elde edilmediği değerlendirilir.

Yaygın üç hata

1. Kapsamı yalnızca ekran isimleriyle yazmak. Ekran listesi, hangi kullanıcı ve işlem koşullarının desteklendiğini göstermez. Süreç sınırı, veri ve karar kuralları açıklanmalıdır. Aksi hâlde aynı ekran üzerinde farklı paydaşlar farklı davranışlar bekleyebilir.
2. Kapsam dışını sessiz bırakmak. Bir durumun belgede yer almaması, herkesin onu dışarıda kabul ettiğini göstermez. Yanlış beklenti yaratabilecek sınırları açıkça yazın. Ayrıca dışarıda kalan işin mevcut düzende nasıl yürütüleceğini belirtin; kullanıcıyı ve operasyonu cevapsız bırakmayın.
3. Yeni talepleri etki değerlendirmeden eklemek. Faydalı bir fikir mevcut teslimata otomatik olarak girmemelidir. Hangi hedefe katkı sağladığını ve başka neleri değiştirdiğini araştırın. Eklemeye karar verilirse mevcut taahhütlerin ve planın nasıl etkilendiği de görünür olmalıdır.

Mini uygulama: Kapsam karar kartı

Bir talebi geliştirme planına almadan önce aşağıdaki kartı doldurun. Dahil ve hariç ifadelerini aynı ayrıntı seviyesinde yazın.

İş hedefi

Hangi sonuç için çalışıyoruz?

Ele alınan problem

Hangi güçlük çözülüyor?

Kullanıcı ve işlem grubu

Kim, hangi koşulda yararlanacak?

Süreç sınırı

Başlangıç olayı ve bitiş koşulu ne?

Kapsam içinde

Hangi davranışlar teslim edilecek?

Kapsam dışında

Hangi durumlar desteklenmeyecek?

Veri ve sistem sınırı

Hangi kayıtlar ve bağlantılar değişecek?

Dışarıda kalan iş

Mevcut operasyon nasıl devam edecek?

Kabul koşulu

Teslimatın yeterli olduğunu ne gösterecek?

Karar düzeni

Sınır değişirse kim değerlendirecek?

Kartı satış, operasyon ve geliştirmeyle örnek senaryolar üzerinden inceleyin. “Bu durumda da çalışacak mı?” sorularına verilen farklı cevapları kaydedin. İyi kapsam, bütün olasılıkları sayan belge değil; teslimatın neyi taahhüt ettiğini ve neyi taahhüt etmediğini ortaklaştıran karardır.

İlgili terimler

Problem Statement, Business Objective, Requirements Elicitation, Stakeholder Analysis, Business Requirement, Business Rule, Functional Requirement, Acceptance Criteria, Gap Analysis, Change Request ve Impact Analysis, Minimum Viable Product, Scope Baseline and Change Control