Gereksinim toplama şablonu: projelerde kullandığım 7 püf noktası

Bir gereksinim toplama şablonu ancak zor konuşmaları erkenden zorunlu kılarsa yerini hak eder: kim imzalıyor, kim engelleyebilir, başarı neye benziyor ve sistem ne kadar hızlı olmalı. Bu rehber, ilk yönlendirme komitesinden sonra da ayakta kalan bir şablona ihtiyaç duyan proje yöneticileri, iş analistleri ve SAP liderleri için. Aşağıda kullandığım tam taslağı, her bölüm için bir sahibiyle, hiç atlamadığım beş bölümü ve görüşmeler, önceliklendirme ve değişiklik için yedi püf noktasını bulacaksınız. Taslağı kendi belgenize kopyalayın ve tasarım başlamadan önce doldurun.

Bir keresinde altı haneli bir bütçesi olan bir projenin, kimse düzgün gereksinim çalışması yapmadığı için çöktüğünü izledim. Müşteri bir şey bekliyordu. Geliştirme ekibi başka bir şey inşa etti. Herkes suçlanıp gözden çıkarıldı ve beni o zaman çağırdılar.

Bu örüntü olağandışı değil. PMI'ın gereksinim yönetimi üzerine 2014 tarihli Pulse of the Profession raporu, başarısız projelerin %47'sinin hedeflerine zayıf gereksinim yönetimi nedeniyle ulaşamadığını buldu. Bunun onlarca kez yaşandığını gördüm.

Büyük bir sistem rollout'unda ben de neredeyse aynı duruma düşüyordum. Paydaşlar birbirinden kopuktu. Geliştiriciler tahmin yürütüyordu. Durduk, sağlam bir gereksinim şablonu hazırladık ve iş biriminin ihtiyaç duyduğunu zamanında ve bütçe içinde teslim ettik.

Bir arkadaşımın şirketi, kimsenin kullanmadığı özel bir CRM'e 350 bin dolar harcadı. Satış bir şey istiyordu, pazarlama başka bir şey, geliştiriciler de herkesin istediğini düşündükleri şeyi inşa etti.

Sağlık sektöründeki bir müşterim, doktorların kullanmayı reddettiği bir EMR implementasyonuna 18 ay harcadı. Günlük iş akışlarında neye ihtiyaç duyduklarını kimse onlara sormamıştı. Proje iptal edilip yeniden başlatıldı.

Geç keşif pahalıdır. Hata maliyeti artışı üzerine bir NASA çalışması, entegrasyon ve testte yakalanan bir gereksinim hatasının düzeltilmesinin, gereksinim aşamasında yakalanana göre 21 ila 78 kat daha pahalıya geldiğini buldu. Operasyonlarda yakalandığında çarpan 29'dan 1.500'ün üzerine kadar çıktı. Kurumsal bir programda bu, bir atölye ile yüz binlerce dolarlık bir değişiklik talebi arasındaki farktır.

1. GereksinimlerDüzeltmenin temel maliyetiGereksinimler henüz yazılırken yakalanır
2. Entegrasyon ve test21 ila 78 kat maliyetSistem inşa edilip test edilirken yakalanır
3. Operasyonlar29 ila 1,500 kattan fazla maliyetSistem canlıya geçtikten sonra yakalanır

Kaynak: NASA'nın hata maliyeti artışı çalışması

Bunu zor yoldan öğrendikten sonra, hiçbir gereksinim şablonunun atlamaması gereken beş bölüm şunlar.

1. İmza bloklu yönetici özeti

Meşgul yöneticiler 30 sayfalık bir gereksinim belgesini okumaz. Bir keresinde bir sponsorun neyi imzaladığını anlamadan bir projeyi onayladığını, sonuçla karşılaşınca da öfkelendiğini yaşadım. Bir sayfada tutun: iş etkisi, takvim, kaynaklar, beklenen fayda ve aynı sayfada bir imza bloğu; böylece onaylayanlar kritik ayrıntıları gözden kaçırdıklarını iddia edemez.

2. Rol ve etki haritalaması

İsim listesi yetmez. Bir güç haritasına ihtiyacınız var: projeyi kim batırabilir, kime danışılmalı, kimin yalnızca bilgilendirilmesi yeterli. Önceki bir işimde geliştirmenin altıncı ayındaydık ve hukuk birimi, yeniden tasarım gerektiren gereksinimlerle geldi. Kimse onları dahil etmeyi düşünmemişti. Etkilenen her departmanı, temsilcisini ve etki düzeyini haritalayın.

3. Teknik gereksinimler değil, iş hedefleri

Hangi sorunu çözüyoruz ve başarıyı nasıl ölçeceğiz? Bir üretim müşterisi stok yazılımını tam belirtildiği gibi uyguladı ve depo operasyonlarını %20 yavaşlattı. Şablon, paydaşları iş başarısını bir özellik listesiyle değil, mevcut bir referans değerle tanımlamaya zorlamalı.

4. Geliştiricilerin kullanabileceği fonksiyonel gereksinimler

Jargonu bırakın. Her gereksinimi spesifik ve test edilebilir yapın. “Sistem müşteri deneyimini iyileştirmeli” işe yaramaz. “Kullanıcılar bir iadeyi işleyip geri ödemeyi 3 dakikadan kısa sürede yapabilmeli” bir gereksinimdir. Yapıldığını doğrulayamıyorsanız, yeniden yazın.

5. Fonksiyonel olmayan gereksinimler

Performans, güvenlik, uyumluluk, erişilebilirlik, ölçeklenebilirlik. Neredeyse herkesin atladığı bölüm bu; sonra sistem yük altında çöker ya da bir güvenlik denetiminden kalır. Sistemin Black Friday'e kadar kusursuz çalıştığı, o gün kimse performans gereksinimlerini belirtmediği için yük altında çöktüğü bir perakende projesini duydum. Yanıt sürelerini, çalışma süresini, en yüksek kullanıcı yüklerini ve uyumluluk yükümlülüklerini rakamlarla yazın.

İşte tam taslak. Yukarıdaki beş bölüm, onay sonrasında şablonu canlı tutan kayıtlarla birlikte bunun içinde yer alıyor.

Bölüm	İçeriği	Sahibi	Onaylayan
1. Yönetici özeti	Sorun, iş etkisi, takvim, kaynaklar, beklenen fayda. İmza bloklu tek sayfa	Sponsor, taslağı iş analizi lideri hazırlar	Sponsor ve finans
2. Kapsam ve dağıtım referansı	Kapsam içi ve dışı, kısıtlar. SAP için: public edition, private edition veya on-premise	Program direktörü	Yönlendirme komitesi
3. Rol ve etki haritası	Departmanlar, temsilciler, etki düzeyi, danış veya bilgilendir	İş analizi lideri	Sponsor
4. İş hedefleri	Her hedef, bir KPI, mevcut referans değeri ve bir hedefle birlikte	Süreç sahipleri	Sponsor
5. Fonksiyonel gereksinimler	ID (ör. REQ-FUN-023), açıklama, köken, öncelik, kabul ölçütleri, fit-to-standard kararı	Fonksiyonel liderler	Süreç sahipleri
6. Fonksiyonel olmayan gereksinimler	Performans, güvenlik, uyumluluk, erişilebilirlik; SAP için her boşluğun uzantı yaklaşımı	Çözüm mimarı	BT, güvenlik ve uyumluluk
7. Park alanı	Ertelenen talepler, kimin istediği, sonraki inceleme tarihi	İş analizi lideri	Terfi edene kadar yok
8. Reddedilenler kaydı	Neyin reddedildiği, nedeni, ne zaman ve kim tarafından	İş analizi lideri	Sponsor
9. Değişiklik kaydı	Onay sonrası her değişiklik, süre ve maliyet etkisiyle	PMO	Değişiklik kurulu

1. Paydaş görüşmelerinde Beş Neden'i kullanın

“Neye ihtiyacınız var?” diye sorarsanız bir dilek listesi alırsınız. Bunun yerine acıyı sorun: “Bilgisayarınızı pencereden atmak istemenize ne sebep oluyor?” Sonra nedenini sorun, sonra yine nedenini, beş kez. Gerçek gereksinim genellikle ilk talepten farklıdır.

Karmaşık raporlama yetenekleri konusunda ısrar eden bir paydaşım vardı. Gerçek kullanım senaryolarını birlikte gözden geçirdikten sonra, ihtiyacı olan şeyin üç basit dashboard olduğu ortaya çıktı.

2. Bir gereksinim park alanı oluşturun

Paydaşların istediklerinin hatırı sayılır bir kısmı hiç kullanılmayacak. Biri şüpheli bir şeyde ısrar ettiğinde tartışmam. Park alanına koyarım ve her ay, aktif gereksinimlere taşınıp taşınmaması gerektiğini soran bir hatırlatma gönderirim. Çoğu kalıcı olarak orada kalır.

3. Fikrini sürekli değiştiren paydaşlar için üçlü kuralı uygulayın

İki kez sonuçsuz yön değiştirebilirler. Üçüncü değişiklikte, değişikliği ve etkisini açıklayan bir e-postayı patronlarına gönderirler. Kimse o e-postayı göndermek istemez. Değişiklikler durur.

4. Önceliklendirmeyi zorlamak için fon dağıtımı tekniğini kullanın

Her paydaşa tüm gereksinimler arasında harcamaları için 100 sanal dolar verin. Her şeye sahip olamazlar, bu yüzden parayı önemli olan yere koyarlar. Bunu 200'den fazla “kritik” gereksinimi olan bir finansal hizmetler müşterisiyle yaptım. Bir saat içinde gerçek ilk 20'yi elde ettik.

5. Her gereksinimi numaralandırın

REQ-FUN-023 gibi tutarlı bir format kullanın. Toplantı süresini boşa harcayan “hangi gereksinimden söz ediyoruz?” karışıklığını bitirir. Kökenini, yani kimin neden istediğini kaydedin; böylece kalemler kesilmesi gerektiğinde kimi arayacağınızı bilirsiniz.

6. Gereksinimleri paydaşın diliyle geri okuyun

Belgelendirdikten sonra gereksinimleri paydaşlara kendi kelimeleriyle geri okuyun. Karmaşık her şey için geliştirme başlamadan önce hızlı bir prototip ya da wireframe hazırlayın. Yanlış anlamalar hâlâ ucuzken ortaya çıkar.

7. Reddedilenleri belgeleyin

Biri reddedilmiş bir gereksinimi beşinci ayda geri getirecek. “Bunu Nisan'da tartıştık ve bu yüzden vazgeçtik” bu konuşmayı çabucak bitirir. Kayıt olmazsa aynı tartışmayı yeniden yaparsınız.

Yedi püf noktası her projede işe yarar. SAP programlarının şablona üç ek şeye ihtiyacı var.

Dağıtım modeli referans değere girer

Fonksiyonel gereksinimleri toplamadan önce dağıtım modelini belirleyin: S/4HANA Cloud Public Edition (GROW with SAP veya RISE üzerinden), Private Edition (genellikle RISE üzerinden) ya da on-premise. Neyin mümkün olduğunu bu şekillendirir. Public edition çekirdeğin modifiye edilmesine izin vermez; dolayısıyla standart dışı süreçlere dayanan gereksinimlerin yeniden şekillendirilmesi ya da reddedilmesi gerekir. Private edition ve on-premise daha fazlasına izin verir, ama bunun bedeli yükseltme eforudur.

Bu karardan önce gereksinim toplarsanız, karar geldiğinde çoğunu yeniden yazarsınız.

Her boşluk için bir uzantı kararı

SAP'nin Clean Core yaklaşımı, her boşluk için kayıtlı bir karar gerektirdiği anlamına gelir: konfigüre edin, yayımlanmış API'ler kullanarak genişletin (ABAP Cloud ile on-stack ya da SAP BTP üzerinde side-by-side) veya reddedin. Public edition'da bunu ürün zorunlu kılar. Private edition ve on-premise'de bu SAP'nin güçlü bir yönlendirmesidir ve izin verdiğiniz her modifikasyon sonradan yükseltme işine dönüşür. Kararı şablonun 6. bölümüne, performans ve güvenliğin yanına koyun ve onaylama yetkisini tek bir mimara verin. Clean Core rehberim seviyeleri açıklıyor.

Yapay zeka taslak hazırlar, kararı insanlar verir

Yapay zeka artık evrak işinde yardımcı oluyor. SAP Cloud ALM, fit-to-standard atölye transkriptlerinden bir şablona gereksinim taslağı hazırlayan, AI birimleri üzerinden ücretlendirilen bir gereksinim üretme özelliği sunuyor. Microsoft Copilot gibi genel asistanlar, toplantı notlarından özet ve tutanak taslağı hazırlar.

Yapay zeka taslak araçları, kaynak materyal temiz olduğunda evrak işinde gerçek zaman kazandırır. Görüşmeyi değiştirmezler. Beş Neden'i yine bir insan sorar. Ve hiçbir araç bir departman başkanına yönetici özetini imzalatamaz. Doğrulama, önceliklendirme ve onay insan işi olarak kalır.

Yazılım geliştirme. Teknik kısıtları, entegrasyon noktalarını, kullanıcı akışlarını (yalnızca özellikleri değil, kullanıcıların izlediği gerçek adımları) ve geçti/kaldı kabul ölçütlerini ekleyin. Bunu bir müşteri portalı projesinde kaçırdık ve özelliklerin “doğru çalışıp çalışmadığını” tartışarak üç ay harcadık.

Süreç iyileştirme. Mevcut durumu, insanların toplantılarda söz etmediği tüm dağınık geçici çözümleriyle haritalayın, etkiyi role göre değerlendirin ve somut performans referans değerlerini kaydedin. Bir üretim müşterisi depo sürecini referans değer olmadan elden geçirdi. Altı ay sonra iyileştirmeyi kanıtlayamadı ve harcamayı gerekçelendiremedi.

Satıcı seçimi. Olmazsa olmazları olsa iyi olurlardan ayırın, puanlama ölçütlerini ağırlıklandırın ve destek ile implementasyon beklentilerini can sıkıcı ayrıntıyla yazın. Bir şirketin satıcıyı neredeyse tamamen özelliklere ve demo izlenimlerine göre seçtiğini izledim. Destek gereksinimlerini göz ardı etti ve büyük ek danışmanlık ücretleri olmadan implemente edemeyeceği bir sistemle kaldı.

Daha küçük projeler için: gereksinimleri onay aşamalarından geçirmek için Trello, inceleme için yorumlu Google Docs ve atölyelerde süreç haritalaması için Miro.

Kurumsal programlar için: gereksinim yönetimi eklentili Jira, canlı belgeler için Confluence (yapay zeka özellikleri artık Atlassian'ın Rovo markası altında yer alıyor) ve Azure DevOps kullanıyorsanız Modern Requirements. SAP programlarında SAP Cloud ALM gereksinimleri, kullanıcı hikâyelerini ve test senaryolarını, SAP Activate yol haritasına bağlı olarak tek bir yerde tutar.

Araç, bağlantıdan daha az önemlidir. Gereksinimleri proje planınıza ve test senaryolarına bağlayın ve bir gereksinim değiştiğinde otomatik bildirim gönderin. “Bunun değiştiğini bilmiyordum” cümlesi, kötü araçlardan daha fazla projeyi öldürür. Gereksinimler onaylandıktan sonra, onları öyle tutmayı SAP implementasyonlarında kapsam kaymasından kaçınma rehberim, onayın yönetişim döngüsünde nereye oturduğunu ise SAP kalite kapıları yazım gösteriyor.

Onaydan sonra kimsenin açmadığı bir şablon tiyatrodur. İşe yarayanlar kısadır, bölüm bölüm sahiplenilir ve biri fikrini her değiştirdiğinde güncellenir; çalıştırmaya değer her programda bu her hafta olur.

Gereksinim toplamanın 5 aşaması nelerdir?

1. Ortaya çıkarma: görüşmeler, atölyeler ve gözlem yoluyla bilgi toplama
2. Analiz: gereksinimleri düzenleme, önceliklendirme ve aralarındaki çatışmaları çözme
3. Belgelendirme: spesifikasyonun yazılması (yönteme göre BRD, FRD veya kullanıcı hikâyeleri)
4. Doğrulama: gereksinimlerin gerçek ihtiyaçları yansıttığını ve test edilebildiğini teyit etme
5. Yönetim: projenin geri kalanı boyunca değişiklikleri izleme

Her aşama bir öncekinin üzerine kurulur. Çoğu ekibin yaptığı gibi ortaya çıkarmayı aceleye getirmek, sonraki her aşamada sorun yaratır.

BRD ile FRD arasındaki fark nedir?

İş Gereksinimleri Belgesi (BRD) iş ihtiyaçlarını kapsar: arka plan, hedefler, paydaşlar, kısıtlar ve üst düzey gereksinimler. “İş birimi neye ihtiyaç duyuyor?” sorusunu yanıtlar.

Fonksiyonel Gereksinimler Belgesi (FRD) sistemin nasıl davranacağını kapsar: kullanıcı hikâyeleri, sistem davranışı, arayüzler ve kabul ölçütleri. “Sistem ne yapmalı?” sorusunu yanıtlar.

İş birimi uyumunu sağlamak için her zaman FRD'den önce BRD ile başlarım. Doğrudan FRD'ye atlayan ekipler çoğu zaman teknik olarak doğru ama yanlış sorunu çözen bir sistem kurar.

3 gereksinim türü nelerdir?

1. İş gereksinimleri: projenin neden var olduğu, hedefleri ve başarı ölçütleri
2. Fonksiyonel gereksinimler: sistemin ne yapması gerektiği
3. Fonksiyonel olmayan gereksinimler: bunu ne kadar iyi yapması gerektiği (performans, güvenlik, ölçeklenebilirlik, uyumluluk)

Gördüğüm proje başarısızlıklarının çoğu eksik fonksiyonel olmayan gereksinimlere dayanıyor. Sistem istenen işi yapıyor, sonra gerçek yük altında çöküyor ya da bir uyumluluk denetiminden kalıyor.

SAP dağıtım modeli gereksinim toplamayı nasıl değiştirir?

Önce onu belirleyin. S/4HANA Cloud Public Edition çekirdeğin modifiye edilmesine izin vermez; dolayısıyla standart dışı süreçlere dayanan gereksinimlerin yeniden şekillendirilmesi ya da reddedilmesi gerekir. Private Edition ve on-premise daha fazla esneklik tanır, ama her modifikasyon yükseltme eforunu artırır.

Fonksiyonel gereksinimleri karardan önce toplarsanız, çoğunu yeniden işlemeniz gerekir. Her boşluk için kayıtlı bir uzantı kararı ekleyin (konfigüre et, yayımlanmış API'ler üzerinden genişlet ya da reddet).

Bir gereksinimi test edilebilir kılan nedir?

Net, ölçülebilir bir geçti/kaldı koşulu. “Sistem hızlı olmalı” test edilebilir değildir. “Arama sonuçları, standart yük altında sorguların %95'i için 2 saniyeden kısa sürede dönmeli” test edilebilirdir.

Benim testim: test senaryosunu şu anda, net geçti/kaldı ölçütleriyle yazabilir misiniz? Yazamıyorsanız gereksinimi yeniden yazın. Test edilemeyen gereksinimler, gördüğüm her şeyden daha fazla canlıya geçiş anlaşmazlığına yol açar.

Gereksinimlerin sürekli değişmesi nasıl önlenir?

1. Değişiklik kontrolü: onaydan sonraki her değişiklik, biri onaylamadan önce süre, bütçe ve kaynak etkisini belgelendirir. Değişikliğin maliyetini görünür kılın.
2. Park alanı: yeni talepler doğrudan kapsama değil, park alanına gider. Aylık inceleyin. Acil görünen taleplerin çoğu bekleyişe dayanamaz.
3. Kalite kapıları: “gereksinimler tamam” ifadesinin ne anlama geldiğini tanımlayın ve bu karşılanana kadar tasarıma başlamayın.

SAP programlarında uzantı kararı, üstüne teknik bir kontrol ekler: çekirdekte modifikasyon gerektiren bir talep, onaylanabilmesi için önce mimardan geçmelidir.