İş Analizinde Sessiz Katiller: Projeleri Rayından Çıkaran Tehlikeli Kelimeler
- 11 saat önce
- 6 dakikada okunur
Bir gereksinim çalıştayında toplantı notuna tek bir cümle yazılmıştı: “Sistem etkinlik takvimini yönetecek.” Masadaki herkes başını salladı; konu anlaşılmış görünüyordu. Birkaç soru sonra ise paydaşın raporlama, hatırlatma ve dışa aktarma beklediğini, geliştirme ekibinin yalnızca kayıt ekleme, güncelleme ve silmeyi düşündüğünü gördük. Aynı cümle konuşulmuştu ama iki farklı ürün tasarlanıyordu.
Bu, sahada bir kez karşılaştığımız istisnai bir durum değildi. “Yönetmek”, “gibi”, “kolay”, “hızlı”, “esnek” ve “otomatik” gibi kelimelerin, ayrıntılar konuşulmadığında gereksinimleri sessizce belirsizleştirdiğini tekrar tekrar gözlemledik. Bu yazıda, bu kelimelerin nasıl risk ürettiğini ve toplantı bitmeden ortak anlamı nasıl görünür hâle getirebileceğimizi somut örneklerle ele alacağız.
Bu yazıda neler bulacaksınız?
Not: Yazıdaki saha örnekleri, gizlilik nedeniyle farklı çalışmalarda tekrar eden ortak örüntülerden birleştirilmiştir; belirli bir kurum veya projeyi temsil etmez.
Toplantıda Herkes Anlaştığını Sanıyordu
Etkinlik takvimi örneğinde ilk bakışta hiçbir sorun yoktu. İhtiyaç sahibi ne istediğini söylediğini, ekip de gereksinimi aldığını düşünüyordu. Sorun, “yönetmek” fiilinin konuşmadaki akıcılığı artırırken kapsamı görünmez bırakmasıydı.
Tahtaya iki sütun açtık. Bir tarafa paydaşın “yönetmek” dediğinde düşündüklerini, diğer tarafa ekibin çözüm taslağını yazdık. Paydaş için yönetmek; etkinlik oluşturmak, katılımcılara hatırlatma göndermek, doluluk bilgisi görmek, rapor almak ve veriyi dışa aktarmaktı. Ekip içinse aynı kelime; kayıt eklemek, listelemek, güncellemek ve silmekten ibaretti.
Bu ayrım geç fark edilseydi kodlanan çözüm teknik olarak çalışacak, fakat beklenen işi tamamlamayacaktı. Sahada çıkardığımız ilk ders şu oldu: Bir kelime kapsamı tek başına taşıyorsa, orada henüz gereksinim değil, araştırılması gereken bir başlık vardır.
IIBA'nın gereksinim kalite ölçütleri de bu noktayı destekler: Bir gereksinim tek anlamlı, paydaşlar tarafından anlaşılır ve doğrulanabilir olmalıdır. “Sistem takvimi yönetir” cümlesi bu üç ölçütü karşılamadan tasarıma geçtiğinde, herkes kendi zihnindeki çözümü doğru kabul eder.
“Yönetmek” Kaç Farklı Kapsam Saklar?
“Yönetmek” güçlü göründüğü için gereksinim cümlelerinde sık kullanılır. Fakat nesnesi değişse bile aynı sorunu taşır: müşteri yönetimi, içerik yönetimi, yetki yönetimi, stok yönetimi, başvuru yönetimi… Bu ifadelerin hiçbiri tek başına sistem davranışını anlatmaz.
Sahada bu kelimeyle karşılaştığımızda fiili daha küçük, gözlemlenebilir davranışlara ayırdık:
Kim, hangi kaydı oluşturabilir?
Hangi alanları görüntüleyebilir veya değiştirebilir?
Hangi iş kuralı bir işlemi engeller?
Hangi olay bildirim üretir?
Hangi rapor, kim için ve hangi sıklıkla hazırlanır?
Veri içe veya dışa aktarılacak mı; biçimi ne olacak?
İşlem geri alınabilir mi ve kim tarafından onaylanır?
Bu soruların amacı toplantıyı gereksiz ayrıntıya boğmak değildir. Amaç, paydaşın zihnindeki iş sonucunu ekibin geliştirebileceği ve test edebileceği davranışlara dönüştürmektir. Bir kelimenin altında beş farklı işlev çıkıyorsa, o kelime gereksinimin sonu değil başlangıcıdır.
“Gibi” Kelimesi Bağlamı Nasıl Gizler?
Bir başka çalışmada “Yeni portalın kullanıcı profili X sitesindeki gibi olsun” cümlesiyle karşılaştık. İfade hızlı bir referans veriyor, fakat hangi özelliğin örnek alındığını söylemiyordu. Görsel düzen mi, alanların sırası mı, gizlilik seçenekleri mi, düzenleme akışı mı, yoksa profil tamamlama davranışı mı?
Referans gösterilen çözümün kullanıcıları, iş kuralları ve teknik kısıtları bizim bağlamımızdan farklıydı. Ekip “gibi” kelimesini ekran tasarımı olarak yorumlarken, paydaş aslında profil bilgilerinin kademeli tamamlanmasını istiyordu. Referans çözüm tartışmayı hızlandırmış, aynı anda asıl ihtiyacı da saklamıştı.
Bu deneyimden sonra “gibi” duyduğumuzda üç soruyu birlikte sormaya başladık:
Referansın tam olarak hangi özelliğini örnek alıyoruz?
Bu özellik hangi kullanıcı ihtiyacını karşılıyor?
Bizim bağlamımızda aynen korunması gereken ve değişmesi gereken nedir?
Kıyaslama yararlıdır; fakat kıyaslanan şey somutlaştırılmazsa çözüm kopyalanır, ihtiyaç anlaşılmaz. IIBA'nın gereksinim analizine ilişkin güncel yaklaşımı da erken çözüm varsayımına kapılmak yerine alttaki ihtiyacı, kısıtları ve başarı ölçütlerini ortaya çıkarmayı vurgular.
Belirsiz bir kelime, paydaş ile geliştirme ekibinin aynı cümleden farklı kapsamlar çıkarmasına neden olabilir.
Sahada Duyduğumuz Diğer Tehlikeli Kelimeler
“Yönetmek” ve “gibi” en görünür örneklerdi; fakat tek değillerdi. Farklı toplantılarda aşağıdaki kelimelerin de ortak anlam oluşmadan kolayca tasarıma taşındığını gördük:
Belirsiz kelime | Sahada duyduğumuz olası yorumlar | Netleştiren soru |
|---|---|---|
Kolay | Az adım, sade ekran, eğitim gerektirmemesi, mobil kullanım | Hangi kullanıcı, hangi işi kaç adımda ve hangi destek olmadan tamamlamalı? |
Hızlı | Ekranın açılma süresi, işlemin tamamlanması, rapor üretimi, ekip yanıt süresi | Hangi işlem, hangi koşulda ve en geç ne kadar sürede tamamlanmalı? |
Esnek | Alan ekleyebilme, kural değiştirebilme, farklı rollere uyarlama, entegrasyon | Kim, neyi, geliştirme yapmadan hangi sınırlar içinde değiştirebilmeli? |
Otomatik | Zamanlanmış işlem, olay tetikleme, öneri üretme, onaysız karar | Hangi olay işlemi başlatır; istisna ve insan onayı nerede devreye girer? |
Kullanıcı dostu | Az tıklama, anlaşılır dil, erişilebilirlik, tutarlı gezinme | Hangi kullanıcı grubunun hangi görevinde başarıyı nasıl gözlemleyeceğiz? |
Uygun | Mevzuata, bütçeye, mimariye, güvenliğe veya kurum politikasına uyum | Hangi ölçüte, standarda veya karar kuralına uygun olmalı? |
Bu kelimeleri yasaklamadık. Tam tersine, onları birer uyarı işareti olarak kullandık. Çünkü belirsiz kelime çoğu zaman konuşulmamış bir beklentinin, istisnanın veya karar ölçütünün izidir.
Belirsizliği Araştırma Aracına Dönüştürmek
Belirsizliği yalnızca yazım kusuru gibi görmek yeterli değildir. İyi kullanıldığında belirsiz ifade, analiste nerede araştırma yapması gerektiğini gösterir. Sahada en etkili olan yaklaşım, kelimeyi hemen başka bir kelimeyle değiştirmek değil, onun altında saklanan iş kararını ortaya çıkarmaktı.
Örneğin “Sistem başvuruları otomatik değerlendirecek” cümlesini şu akışla açtık:
Aktörü belirledik: Sonucu kim kullanacak, kim itiraz edebilecek?
Tetikleyiciyi bulduk: Değerlendirme hangi olayla başlayacak?
Girdileri sınırlandırdık: Hangi veriler zorunlu, eksik veri olduğunda ne olacak?
Karar kurallarını görünür yaptık: Hangi koşullar kabul, ret veya insan incelemesi üretecek?
İstisnaları konuştuk: Çelişkili veri, sistem hatası veya kural dışı durum nasıl ele alınacak?
Sonucu ölçtük: İşlem süresi, doğruluk, açıklanabilirlik ve kayıt izi için kabul ölçütü ne olacak?
Bu çözümleme sonunda “otomatik” kelimesi kaybolmadı; anlam kazandı. Gereksinim, ekibin tasarlayabileceği, paydaşın doğrulayabileceği ve test ekibinin sınayabileceği bir yapıya dönüştü.
Gereksinimi talep cümlesinden uygulanabilir analize dönüştüren daha geniş akışı Gereksinim Analizi Nasıl Yapılır? 3 Aşamalı Pratik Yol Haritası yazısında adım adım inceleyebilirsiniz.
Belirsizlik Ne Zamana Kadar Kabul Edilebilir?
Her belirsizlik hata değildir. Bir fikrin ilk konuşulduğu keşif aşamasında “buna benzer bir deneyim istiyoruz” demek, araştırmayı başlatan yararlı bir ifade olabilir. Sorun, keşif dilinin hiçbir dönüşüm geçirmeden tasarım, geliştirme veya kabul aşamasına taşınmasıdır.
Sahada kullandığımız pratik sınır şuydu:
Keşifte: Belirsizlik soru üretmek için kabul edilebilir.
Analizde: Alternatif anlamlar, aktörler, kurallar ve istisnalar görünür olmalıdır.
Tasarım öncesinde: Beklenen davranış ve kapsam sınırları ortaklaşa doğrulanmalıdır.
Geliştirme öncesinde: İş, ekip tarafından uygulanabilir büyüklükte ve anlaşılır olmalıdır.
Kabul öncesinde: Sonucun hangi ölçüte göre doğru sayılacağı açık olmalıdır.
IREB, ortak terim anlayışını başarılı gereksinim mühendisliğinin temeli olarak ele alır. Bu yüzden netlik, analistin tek başına iyi cümle yazması değil; paydaşların ve teslimat ekibinin aynı ifadeyi aynı iş sonucu üzerinden doğrulayabilmesidir.
Toplantıdan Çıkmadan Önce Netlik Kontrolü
Toplantı sonunda uzun bir dokümandan önce kısa bir kontrol listesi daha fazla değer üretebilir. Biz, kritik gereksinimleri kapatmadan önce aşağıdaki sekiz noktayı görünür kılmaya çalıştık:
Aktör: Bu davranışı kim başlatıyor, kim sonucunu kullanıyor?
Amaç: Kullanıcı veya kurum hangi iş sonucuna ulaşmak istiyor?
Tetikleyici: Süreç hangi olay, tarih veya koşulla başlıyor?
Girdi: Hangi bilgi zorunlu; kaynağı ve kalitesi ne?
Davranış: Sistem gözlemlenebilir olarak ne yapacak?
Kural ve sınır: Ne zaman yapmayacak; yetki, mevzuat ve kapsam sınırı ne?
İstisna: Eksik, hatalı veya çelişkili durumda hangi yol izlenecek?
Kabul ölçütü: Sonucun doğru ve tamamlanmış olduğunu nasıl anlayacağız?
Bu kontrol her gereksinimi tek seferde kusursuzlaştırmaz. Ancak “herkes anladı” varsayımını test eder ve açıklanmamış farkları daha tasarım başlamadan görünür kılar. Netleşen gereksinimlerin backlog içinde nasıl parçalanıp önceliklendirileceğini İş Analistleri İçin Backlog Yönetimi: Adım Adım Rehber yazısında ele alıyoruz.
Kelime Toplamak Değil, Ortak Anlam Kurmak
Saha gözlemlerimizin ortak sonucu şuydu: Projeleri rayından çıkaran belirsizlikler çoğu zaman karmaşık teknik terimlerde değil, herkesin bildiğini sandığı sıradan kelimelerde saklanıyor. “Yönetmek”, “gibi”, “kolay” veya “otomatik” denildiğinde konuşma hızlanıyor; fakat ortak anlam kurulmamışsa karar yalnızca erteleniyor.
İş analistinin değeri, paydaşın cümlesini olduğu gibi dokümana geçirmekten gelmez. Değer; ihtiyacı, iş kuralını, istisnayı ve başarı ölçütünü birlikte görünür kılmaktan gelir. İş Analizi Nedir? İş Analisti Kimdir? yazısındaki temel rol tanımı da bu ortak anlayış kurma sorumluluğuyla tamamlanır.
Bir sonraki toplantınızda “yönetmek”, “gibi” veya “kullanıcı dostu” kelimelerinden biri geçtiğinde onu hemen düzeltmeye çalışmayın. Önce şu soruyu sorun: Bu kelimeyi herkesin aynı gözlemlenebilir davranış ve aynı iş sonucu üzerinden açıkladığından emin miyiz?
Sizin saha deneyiminizde en çok yanlış anlaşılmaya yol açan kelime hangisiydi?
İş analizi, gereksinim yönetimi ve paydaş iletişimine ilişkin yeni uygulama içeriklerini Pena Akademi LinkedIn sayfasından takip edebilirsiniz.
Netlik Kurma Becerisini Ekip Pratiğine Dönüştürmek
Belirsiz ifadeleri fark etmek ilk adımdır. Bu refleksi sürdürülebilir bir ekip pratiğine dönüştürmek; doğru soru sorma, paydaş analizi, modelleme, gereksinim yazma, doğrulama ve kabul ölçütlerini birlikte kullanmayı gerektirir.
Pena Akademi'nin IIBA® İş Analizi Teknikleri Eğitimi, iş analistleri, ürün ekipleri ve iş birimleri için gereksinim analizi, paydaş iletişimi, modelleme ve dokümantasyonu uygulama odaklı ele alır. Kurumunuza veya kariyer hedefinize uygun diğer programları İş Analizi Eğitimleri sayfasından inceleyebilirsiniz.
