Gereksinim Toplama: Eksiksiz Rehber & Şablon
Gereksinim toplama, paydaşlarla beklentileri belirlemenizi ve yönetmenizi, kapsam kaymasını önlemenizi ve projenizin gerçekte ne sunduğuna ilişkin belirsizliği azaltmanızı sağlayan bir süreçtir.
Sahip olduğunuz gereksinim belgeleri ne kadar kapsamlı olursa hata ve varsayım payı da o kadar azalır. Kontroller ve dengeler, ekibinizin projeye ilişkin ortak anlayışına ve müşterinizin nihai ürüne yönelik beklentilerine katkı sağlar.
Proje Yönetiminde Gereksinim Toplama Nedir?
Gereksinim toplama, proje sponsorlarının ve temel paydaşların projeden neye ihtiyaç duyduğunu belirleme sürecidir. Proje yöneticileri, ne talep edildiğini ve bu talebin ayrıntılarını belirlemek için çalışır.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Bu talepler, projenin gereksinimler listesini oluşturur. Gereksinimlerin karşılanması, çalışmanın başarılı bir proje olarak değerlendirilip değerlendirilmeyeceğini belirler.
Proje yöneticileri, proje boyunca aşağıdaki gereksinim türlerini takip etmek için gereksinim belgelerini ve gereksinim yönetimi araçlarını kullanır:
- İşlevsel gereksinimler
- Teknik gereksinimler
- İşlevsel olmayan gereksinimler
- Sistem gereksinimleri
Gereksinim Toplama Neden Önemlidir?
Gereksinim toplama aşağıdaki nedenlerle önemlidir (bu gereksinimleri belgelemek de aynı şekilde önemlidir):
- Bir projenin gelişimini, değişen parçalarını ve uygulanmasını belgelemek için bir referans noktası görevi görür
- Proje paydaşlarının projeden ne beklemeleri gerektiğini daha iyi anlamaları için bir taslak görevi görür (projenin ne, nerede, ne zaman ve neden gerçekleştirileceği).
- Gereksinimler, çalışma başlamadan önce açıkça belgelenip üzerinde anlaşmaya varıldığı için hata ve belirsizlik payını azaltır.
- Projenin üretimi ve kalite güvencesi boyunca kontroller ve dengeler sağlar; proje yöneticilerinin ve ekip üyelerinin nasıl ilerleyecekleri konusunda şüpheye düştüklerinde bu belgeye başvurmalarına olanak tanır.
Etkili gereksinim yönetimi planlaması, neler bekleyebileceklerini açıklamanın yanı sıra neleri beklememeleri gerektiğini de açıklamalıdır. Korkulan müşteri hayal gücü riskini ortadan kaldırmak için “Varsayımlar” ve/veya “Kapsam Dışı Bırakılanlar” bölümü eklemek akıllıca bir yaklaşımdır.
Yazılım Gereksinim Belirtimi Örneği
Bir e-ticaret projesi için örnek bir gereksinim belirtimi aşağıda verilmiştir:
- Ne: PayPal entegrasyonu
- Nerede: Ödeme sayfası
- Ne zaman: Ödeme deneyimindeki 4 adımın 3. adımında (kargo adresi web formundan sonra, onaydan önce)
- Neden: Yerleşik bir entegrasyon (ör. PayPal), bu durumda bir ödeme hizmeti için kapsamlı bir özel entegrasyon geliştirmekten daha iyi bir çözümdür; çünkü iş gereksinimlerini kolayca karşılar.
- Varsayımlar
- Tüm kargo ve taşıma işlemleri için sabit ücret
- Tüm gönderimler ABD sınırları içindedir (Alaska ve Hawaii dahil değildir)
- Vergiler uygulanmaz
- Kapsam Dışı Bırakılanlar
- Özel kargo ve taşıma ücreti hesaplamaları
- Uluslararası gönderimler, Alaska'ya veya Hawaii'ye gönderimler
- Vergi kuralları
Unutmayın: müşterinin dijital ürününe ilişkin beklentisi ile gerçeklik arasındaki fark ne kadar küçükse, müşteriniz nihai sonuçtan o kadar memnun olacaktır. Gereksinim yönetiminizin kalitesi, konu müşteri beklentileri olduğunda gri alanları azaltma becerinizle doğrudan ilişkilidir.
Çoğu zaman müşteri, bütçesini koruduğunuz anlamına geliyorsa kapsam kaymasını sınırlandırmanıza sıcak bakacaktır; bir özelliğin neden ele alınacağını (veya alınmayacağını) müşteriye yeterince açıklarsanız ve ardından bu yaklaşımın arkasındaki mantığı gereksinimler içinde belgelerseniz, müşteriniz iş birliğine çok daha yatkın olacaktır.
Onay verme olasılıkları daha yüksek olacaktır ve ilerleyen süreçte Kullanıcı Kabul Testi (UAT) yaparken, ekibinizin çözümünün arkasındaki “neden”i anlamaya bir adım önde başlayacaklardır.
6 Adımda Gereksinim Toplama Süreci
Gereksinim toplama, bir çalışma başlar başlamaz ve tüm proje yaşam döngünüz boyunca devam etmelidir; ancak gereksinimleri toplamaya ve belgelemeye başlamak için hiçbir zaman çok erken değildir. Hatta dünden başlayın.
Gereksinimlerin nasıl toplanacağına ilişkin adımlar aşağıda yer alıyor.
1. Not Alın
İç toplantılarda proje ekibinizle ya da dış toplantılarda müşterinizle birlikte olun, her toplantıda mutlaka not alın. Notları başka birinin aldığını asla varsaymayın.
O anda konuşulan her şeyin hatırlanacağını düşünmek kolay olabilir; ancak 3 ay ve 15 toplantı sonra, ekibiniz ve müşteriniz dönüp bakabilecekleri bir tartışma kaydına sahip olduğunuz için size teşekkür edecektir.
Gereksinim notları almak için önerdiğim bazı yöntemlere buradan göz atın:
- Toplantınıza girmeden önce, not belgenizi gündeminizi yansıtacak şekilde hazırlayın; böylece eylem maddelerini ve noktaları düzenlemek daha kolay olacaktır. Bu şekilde, ilgili bilgileri düzenli bir biçimde kaydederken nelerin gerektiğini hatırlayabilirsiniz.
- Herhangi bir toplantıdan sonra kendinize notlarınızı gözden geçirmek, konuşulanları değerlendirmek, eylem maddelerini önceliklendirmek ve zorlukları/kırmızı bayrakları ya da açıklığa kavuşturulması veya ek toplantılar yapılması gereken konuları belirlemek için 15-30 dakika ayırın.
- Notlarınızı iç proje ekibinize gönderin. Belirlediğiniz eylem maddelerini, kırmızı bayrakları vb. gözden geçirip doğrulamalarını sağlayın.
- Ekip onayını verdikten sonra notlarınızı müşterinize gönderin.
- Son olarak, her eylem maddesinden görevler oluştururken notlarınızdan yararlanın. Yeni bilgileri gereksinim dokümantasyonunuza ekleyin ve ek keşif veya görüşme için gereken toplantıları planlayın.
2. Yaratıcı gereksinimleri gözden geçirin
Tasarım ve stil kararlarını ekip üyelerinin bireysel tercihine bırakmayın: mümkün olduğunca yaratıcı gereksinimleri yazılı ve standart hâle getirin. Yaratıcı yönlendirme geliştiriciler için paha biçilmezdir. En azından, elinizde bir stil kılavuzu bulunduğundan emin olun—bu kılavuz yalnızca yazı tipi ve marka renkleri kadar temel olsa bile.
Marka logoları veya marka yazı tipleri gibi yaratıcı varlıkları toplayın ve tüm ekibin erişimine ve görünürlüğüne sunmak için bunları dijital varlık yönetimi yazılımı gibi paylaşılan bir alana yükleyin.
3. Gereksinim belgesini yazın
Dokümantasyona daldığınızda şunu unutmayın: gereksinim dokümantasyonuna yönelik ilk çalışmanız en zor olanı olacaktır. Neden mi? Çünkü yararlanabileceğiniz önceki bir belge yoktur (diğer adıyla KOPYALA-YAPIŞTIR). Şanslısınız ki bu makale, size temel oluşturacak bir gereksinim dokümantasyonu şablonu içeriyor.
Bu şablonda gösterildiği gibi, gereksinim dokümantasyonumu dört bölüm hâlinde düzenliyorum:
- Açıklama: Açıklamalı tasarımınızdaki numaraları içerir. Sayfa tasarımınızda 8 öğe varsa 8 açıklamanız olur ve açıklama sütununuzda 8 satır bulunur
- Öğe: Her açıklamayla ilişkili öğe başlıklarını içerir
- İşlevsel gereksinim: Her öğe için bir tanım (gereksinimlerin açıkça belirtilmiş hâlini) içerir
- Yönetici/CMS işlevselliği: İlgili öğeyle bağlantılı tüm yönetim ve/veya CMS işlevlerini tanımlayın
4. Dahili bir inceleme gerçekleştirin
Gereksinimleri toplama sürecinin bu bölümünde, gereksinim belgelerinizi incelemek üzere proje ekibinizle başka bir dahili toplantı planlayın. Bu, uygulamayı doğru anladığınızdan emin olmak için gerçekleştirilecek son dahili kontrol ve dengelemedir.
Mümkünse, toplantıdan önce ekibin gereksinim belgelerinizi incelemesini sağlayın; böylece soruları ve/veya geri bildirimleriyle toplantıya hazırlıklı gelebilirler. Toplantıyı, gereksinimlerle ilgili soruları veya geri bildirimleri görüşmek için kullanın.
Dahili görüşmenize dayanarak belgelerde gerekli revizyonları yapın. Son olarak, revize edilmiş gereksinim belgelerini son bir onay için ekibe yeniden gönderin. Dahili proje ekibi gereksinim belgeleri için son onayını verdikten sonra, bir sonraki adım olan görevlerin oluşturulmasında belgenin son hâlinin korunmasını sağlamak için belgeyi PDF olarak kaydedin.
5. Görevleri oluşturun
Gereksinim belgelerinin PDF sürümünü geliştirme ekibinize sağlayın. İdeal olarak geliştiricileriniz veya geliştirme lideriniz, geliştirme için görevleri oluşturacaktır.
Bazı kuruluşlar proje yöneticilerinin tüm görevleri oluşturduğu bir süreçle çalışsa da geliştiricilerin kendi görevlerini oluşturmalarını tercih ederim; bunun için harcadıkları birkaç saat buna değer.
Geliştirme görevlerini ve teslimatlarını oluştururken ekibinize yine de yararlı yönergeler sağlayabilirsiniz . Görevler oluşturulduktan sonra nihai saat tahminini elde edebilirsiniz.
Bu öngörüyü daha önce müşterinize iletilen proje zaman çizelgesiyle karşılaştırın ve gerektiğinde buna göre yönetin. Proje tahminleri hakkında daha fazla bilgi için bu kapsamlı proje tahmin rehberine bakın.
6. Harici bir inceleme gerçekleştirin
Gereksinim belgelerini müşterinize sunma zamanı geldi. Herhangi bir düzenleme yapılmadığından emin olmak için bunu PDF olarak sağlayın. Bu, (1) dijital çözümün anlaşılmasını sağlamak için gösterdiğiniz çabayı örnekler ve (2) proje kapsamının kaçınılmaz olarak genişlediği durumlarda “Ben sana söylemiştim” diyebilmeniz için (ancak çok daha etkili bir şekilde) size güvence sağlar.
Müşterinizi bilgilendirin. Onlar için büyük bir özenle hazırladığınız bu değerli belgeyi adım adım açıklayın. Unutmayın: Kendi işlerinin uzmanı onlardır. Onlara sunduğunuz dijital çözümün uzmanı ise sizsiniz. Bu çözüm için size ödeme yapıyorlar. Müşterinizi bilgilendirin ve güçlendirin.
Müşteri gereksinim belgelerini anladığını onayladıktan sonra, resmî onay alma zamanı gelir. İmzalanmış ve onaylanmış gereksinim belgelerini ekibinize gönderin ve geliştirmenin başlayabileceğine dair resmî bir gösterge olması için belge yönetimi yazılımı kullanarak ortak bir alana kaydedin.
Gereksinimleri Toplama Teknikleri
Önemli gereksinim toplama çalışmalarını elinizden gelen en iyi şekilde yürüttüğünüzden emin olmanıza yardımcı olacak bazı teknikler şunlardır:
1. Hemen başlayın
Gereksinim belgeleri, kesin proje planını veya proje hedeflerini netleştirmeden önce, görüşmeler başlar başlamaz oluşturulmaya başlanmalıdır. Yapabildiğiniz her şeyi kaydedin ve ardından bunları ayıklayın. Müşterinizle deneyebileceğiniz bazı stratejiler şunlardır:
- Projede neler görmek istediklerine dair onlara bir anket gönderin
- Beyin fırtınası oturumu düzenleyin
- Bir odak grubu oluşturun
Belgeden bilgi çıkarmak yerine bilgileri nelerin dahil olduğu ve nelerin dahil olmadığı şeklinde kategorilere ayırın—bu, ileride müşterinin varsayımlarda bulunmasını önler.
WIP (devam eden çalışma) gereksinimleri dokümantasyonunuzu çıkarabilecek ve bu bilgilerin nerede kaydedildiğini, neden dahil edilmemiş olabileceğini, kararın arkasındaki mantığı ve bunun kaydedildiği tarihi belirterek izlenebilir hale getirebileceksiniz.
2. Şablonlardan yararlanın
Birkaç gereksinim dokümanı hazırladıktan sonra bunlardan yararlanmaya ve gelecekteki diğer projelerde kullanmak üzere şablon haline getirmeye başlayın. Özellikle e-ticaret veya öğrenme uygulamaları projelerine odaklanıyorsanız, işlevsellik kalıplarının ortaya çıktığını görmeye başlayacaksınız. Yeniden kullanabileceğiniz yerleri belirleyin.
3. Ekip çalışması hayalleri gerçeğe dönüştürür
Bir projede farklı türlerde ekip üyeleri varsa her uzmanlık alanına ilişkin gereksinimler, ilgili uzmanlar tarafından yazılabilir.
Çoğu durumda gereksinimlerle ilgili konuşma; telefon görüşmeleri, birbirinden ayrı çeşitli toplantılar ve görüşmeler gibi dolambaçlı bir yol izler. Bu nedenle, gereksinimleri ortaya çıkarma ve derleme sürecinde ilerlerken gereksinim dokümantasyonunu ilgili ekip üyelerine dağıtmanız kritik önem taşır.
4. Gereksinimleri yalnızca kaydetmeyin—öğrenin
Not almaktan fazlasını yapın. Kaynak kişilerin gereksinimlerin kendi bölümlerini oluşturan uzun bir metni size e-postayla göndermesinden daha fazlasını bekleyin. Geliştirici ekibinizle oturup ekibin uygulama için aklındaki çözümleri öğrenmeye zaman ayırın. Nedenini ve nasılını tartışın. Sorular sorun.
“Ama gün içinde yalnızca bu kadar zamanımız var—ya bütçe ne olacak?” demeden önce şunu anlayın: üzerinde çalıştığınız bir çözüm birden fazla projeye uygulanabiliyorsa, anlayış kazanmak için harcanan bu ek sürenin mutlaka faturalandırılması gerekmez. Günlük işinizi doğrudan geliştiren konu uzmanlığınızı artırıyorsunuz.
5. Müşterinizi süreçten haberdar edin
Dahili bir gereksinim dokümanının yanı sıra müşteriye yönelik bir WIP gereksinim dokümanı da hazırlayın. Dahili dokümanda daha şeffaf notlara yer verme konusunda daha az endişe duyabilirsiniz.
Hassas bilgilerle ilgilenmiyorsanız, müşterinin yorum yapabilmesi için izinleri etkinleştirerek bu ortak alanı bir Google Dokümanı aracılığıyla oluşturabilirsiniz. Hassas bilgilerle ilgileniyorsanız, kaydedilenleri müşteriye özet halinde sunmak için gereksinim dokümanının bir sürümünü haftalık olarak paylaşın.
6. Müşterinizin her zaman daha fazlasını bilmek istediğini varsayın
Müşterinizin gerçekte bildiğinden daha fazlasını bildiğini varsayarak riske girmek (sonrasında bunun bedelini ödemek) yerine, müşterinizin her zaman daha fazlasını bilmek istediğini varsayın. Her gereksinimin kapsamlı olmasını sağlamak için her açıklama için kendinize beş kez “Neden?” diye sorun.
Her gereksinim için kendinize beş kez “Neden?” diye sormak, her sayfa türünün her bir öğesinin ve işlevinin arkasındaki mantığı gerçekten değerlendirmenizi sağlar. Ne kadar çok şey öğrendiğinize (veya öğrenmeniz gerektiğini fark ettiğinize) şaşırabilirsiniz.
Proje Gereksinimleri Dokümanı Yazmaya İlişkin 3 Uzman İpucu
1. Genel öğeler için gereksinimleri ayrı yazın
Tekrarları ortadan kaldırmak için tüm genel öğeleri gereksinim dokümantasyonunuzun “Genel Öğeler” bölümünde ele alın. Bu, ana navigasyon menüsü öğeleriniz, genel üst bilginizdeki her şey ve alt bilginizdeki her şey gibi genel öğeler için geçerlidir.
Bu genel öğeler için gereksinimleri yazdıktan sonra bunları diğer sayfalarda tekrar tekrar açıklamakla uğraşmayın; yalnızca söz konusu sayfalara özgü öğeleri açıklayın.
2. Tutarlılığı sağlamak için aynı işlevselliği kopyalayıp yapıştırın
Bu, sizin (ve müşterinizin) akıl sağlığını korumak için aklınızda bulundurmanız gereken basit bir ipucudur. Bunu en çok; kahraman/afiş görselleri, üst bilgiler veya “geri” simgeleri gibi yaygın sayfa öğelerinde ve sayfa türleri genelinde tekrarlanan çok sayıda işlevsellikte görürsünüz (genel öğelerle karıştırmayın).
3. Yönetim panelini ve CMS'yi (veya bunların yokluğunu) kabul edin
Her sayfa öğesinin işlevselliğine bu kadar odaklandığımızda, yönetim ve/veya CMS işlevselliğini gözden kaçırmak kolaydır. Yönetim ve/veya CMS işlevselliği sunan bir çözüm uyguluyorsanız, bunu gereksinimlerinizde ayrı bir sütun olarak eklediğinizden emin olun. Aşağıdaki örneğe bakın:
Gereksinim Belgesi Şablonu [İndir]
Gereksinim tanımınızın ayrıntıları, müşteriyle olan ilişkinize, ekibinizin deneyimine ve diğer etkenlere bağlı olacaktır.
Ancak yine de bir özelliğin işlevselliğini, konumunu, tasarımını vb. tanımlayan bir proje gereksinimleri belgesinin temel bölümlerine ihtiyacınız olacaktır. İşte gereksinim belgesi şablonumuz (erişmek için üye olmanız gerekir):
100'den Fazla Üstün Nitelikli Şablonla Hızınızı Artırın
Daha hızlı ve verimli çalışmanıza yardımcı olacak uzmanlar tarafından hazırlanmış sınırsız sayıda şablona erişmek için DPM üyesi olun.
