PMI PMP: Kapsam, Gereksinimler ve Değişiklik Kontrolü — Çalışma kılavuzu

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Şunun bir parçası: PMP — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: PMI sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Gereksinimlerin Ortaya Çıkarılması, İzlenebilirlik ve RTM

Kapsam bütünlüğü, ilk iş paketinin tahmin edilmesinden çok önce başlar — disiplinli bir gereksinim ortaya çıkarma süreciyle başlar. Ortaya çıkarma tek bir çalıştay değildir; mülakatları, kolaylaştırılmış çalıştayları (JAD oturumları, tasarım sprint’leri), doküman analizini, gözlemi (“iş gölgeleme”), prototiplemeyi, anketleri ve bağlam diyagramlarını birleştiren katmanlı bir faaliyettir. Her teknik farklı bir gereksinim türünü ortaya çıkarır: iş gereksinimleri (neden), paydaş gereksinimleri (kim ne istiyor), çözüm gereksinimleri (fonksiyonel ve fonksiyonel olmayan), geçiş gereksinimleri, proje gereksinimleri ve kalite gereksinimleri. Herhangi bir katmanı atlamak, öngörülebilir bir başarısızlığa yol açar — örneğin, fonksiyonel olmayan gereksinimler olmadan fonksiyonel gereksinimleri yakalamak, “çalışan” ancak ölçeklenemeyen bir sistemle sonuçlanır.

Yakalandıktan sonra gereksinimler izlenebilir olmalıdır. Gereksinim İzlenebilirlik Matrisi (RTM), her gereksinimi çift yönlü olarak şu unsurlara bağlar: (a) onu gerekçelendiren iş hedefi veya fayda, (b) onu üretecek olan WBS teslimatı, (c) onu uygulayan tasarım öğesi veya kullanıcı hikayesi, (d) onu doğrulayan test senaryosu ve (e) kabulden sorumlu olan paydaş. Olgun bir RTM ayrıca öncelik, durum, kaynak ve değişiklik talebi ID’sini de taşır. RTM, kapsam kaymasına (scope creep) ve gereksiz lüksleştirmeye (gold-plating) karşı en güçlü silahtır: onaylanmış bir iş hedefine kadar izlenemeyen herhangi bir değişiklik önerisi reddedilmeye adaydır ve test senaryosu olmayan herhangi bir hedef, tamamlandığına dair doğrulanamaz bir iddiayı temsil eder.

Tipik bir RTM satır yapısı:

• R-042
  • Açıklama: Sistem SSO’yu destekler
  • İş Hedefi: Oturum açma destek taleplerini %30 azaltmak
  • WBS Ref: 1.3.2
  • Öncelik: Zorunlu (Must)
  • Test Senaryosu: TC-118
  • Kabul Kriterleri: SAML 2.0 ile oturum açma <2 sn
  • Sahibi: CIO
  • Durum: Onaylandı

Kapsam Temel Çizgisi, WBS ve Kabul Kriterleri

Kapsam temel çizgisi resmi olarak onaylanmış bir üçlüdür: kapsam beyanı, WBS ve WBS sözlüğü. Bu bir dilek listesi değildir; “tamamlandı"nın ne anlama geldiğinin sözleşmesel olarak referans alınan açıklamasıdır. WBS, teslimatları (asla faaliyetleri değil) iş paketi seviyesine kadar ayrıştırır ve %100 kuralına uyar — alt öğelerin toplamı üst öğeye eşittir, ne eksik ne fazla. Her bir nihai iş paketi için, işin kapsamını, kabul kriterlerini, varsayımları, sorumlu kaynağı, hesap kodu tanımlayıcısını, kilometre taşı tarihlerini ve kalite gereksinimlerini açıklayan bir WBS sözlüğü girdisi oluşturulur. Tahminlemeyi savunulabilir ve kontrolü mümkün kılan budur; tanımlamadığınız bir iş üzerinden değer kazanamazsınız.

Kabul kriterleri spesifik, ölçülebilir olmalı ve iş başlamadan önce müzakere edilmelidir. “Kullanıcı dostu arayüz” bir kriter değildir; “kullanılabilirlik testinde görevin ≤3 tıklama ile <%2 hata oranıyla tamamlanması” bir kriterdir. Her teslimat, bu kriterlere göre paydaş onayını gerektirir ve bu, resmi bir doğrulama faaliyeti aracılığıyla yapılır — genellikle Kapsamı Doğrula süreci, ki bu süreç kabul edilen teslimatları ve başarısız olanlar için değişiklik taleplerini üretir. Bir paydaşın kapanışa yakın bir zamanda onayı reddettiği senaryolardan çıkarılacak ders nettir: kabul kriterleri ve ara doğrulamalar projenin sonuna ertelenmemeli, yürütme süreci boyunca gerçekleştirilmelidir. Bir teslimat kapanışta reddedildiğinde, doğru hamle açığı kaydetmek, düzeltmek için bir değişiklik talebi oluşturmak, takvim ve maliyet etkisini yeniden değerlendirmek ve bunu değişiklik kontrolünden geçirmektir — işin “şartnameye uyduğunu” iddia etmek değil.

Backlog Önceliklendirmesi ve MVP

Adaptif ve hibrit ortamlarda kapsam, dondurulmuş bir temel çizgi yerine önceliklendirilmiş bir ürün birikim listesi (product backlog) olarak ifade edilir. Önceliklendirme teknikleri arasında MoSCoW (Must, Should, Could, Won’t), WSJF (Weighted Shortest Job First), Kano analizi (temel, performans, memnuniyet özellikleri) ve basit değer/efor matrisleri bulunur. Amaç her zaman aynıdır: işi, en yüksek iş değerinin önce teslim edileceği şekilde sıralamak ve proje yarıda kesilirse, yayınlanan artımın yine de gerçek bir sorunu çözmesini sağlamak.

Minimum Uygulanabilir Ürün (MVP), ölçülebilir değer sunan ve doğrulanmış öğrenmeye olanak tanıyan en küçük işlevsellik dilimidir. Bu, “sabit bir planın birinci aşaması” değildir; bir hipotez test etme aracıdır. MVP’yi erken teslim etmek, varsayımları gerçek kullanıcılarla yüzleştirir, backlog iyileştirmesi için geri bildirim üretir ve ekiplerin kimsenin kullanmadığı özellikleri teslim ettiği klasik başarısızlık modeline karşı koruma sağlar. Paydaşlar “teslim edilen işlevsellik, işin ihtiyacı olan şey değildi” diye şikayet ettiğinde, kök neden neredeyse her zaman sürecin başındadır: önceliklendirme, doğrulanmış iş hedeflerine bağlanmamıştır ve varsayımları test etmek için erken bir artım yayınlanmamıştır. Düzeltici disiplin, iş birimleriyle birlikte backlog iyileştirmesi yapmak, maddeleri faydalarına göre ağırlıklandırmak, artımlı olarak yayınlamak ve her demodan sonra yeniden önceliklendirmektir.

Değişiklik Talepleri, DDK ve Bütünleşik Değişiklik Kontrolü

Temel çizgiler oluşturulduktan sonra, “küçük” olanlar da dahil olmak üzere her değişiklik Bütünleşik Değişiklik Kontrolü Gerçekleştirme sürecinden geçer. İş akışı şöyledir: (1) neyin, neden ve beklenen faydanın ne olduğunu belgeleyen bir değişiklik talebi gönderilir; (2) bu talep değişiklik günlüğüne kaydedilir; (3) kapsam, takvim, maliyet, kalite, kaynaklar, risk ve tedarik genelinde etki analizi yapılır; (4) onay, erteleme veya ret için Değişiklik Denetim Kuruluna (DDK) yönlendirilir; (5) onaylanırsa, etkilenen temel çizgiler, GTM, İYK, risk kütüğü, varsayım günlüğü güncellenir ve etkilenen tüm paydaşlara iletilir; (6) reddedilir veya ertelenirse, kayıt denetim ve öğrenilen dersler için saklanır.

DDK’nın yapısı yetki eşiklerine uygun olmalıdır — sponsor, iş sahibi, teknik lider, PY ve genellikle finans ve kalite temsilcileri. Küçük değişiklikler bu süreçten muaf değildir; önceden tanımlanmış devredilmiş yetki aracılığıyla (örneğin, PY 5.000 doların altındaki ve 2 günden az etkili değişiklikleri onaylayabilir) ele alınır ancak yine de günlüğe kaydedilir. “Küçük” bir değişikliğin temel çizgi üzerinde sıfır etkisi olduğu varsayımı, projelerin sessizce kan kaybettiği noktadır: her biri “sadece yarım gün” maliyetli on beş küçük değişiklik, kimse fark etmeden üç haftalık bir tamponu tüketir.

Etki Değerlendirmesi ve Varsayım/Sorun Disiplini

Düzgün bir etki değerlendirmesi, bir e-postadaki bir paragraftan ibaret değildir. Takvim (ağ analizi ve bolluk tüketimi yoluyla), maliyet (işçilik, malzemeler, ihtiyat payı kullanımı), kalite (hata riski, test kapsamı), risk (ortaya çıkan yeni tehditler veya mevcut olanların büyümesi) ve paydaş katılımı üzerindeki delta’yı (farkı) nicelendirir. Bir değişiklik ihtiyat payını tüketirse, rezerv analizi güncellenmelidir. Eğer bir varsayımı geçersiz kılıyorsa — örneğin, bir üçüncü taraf API’sinin kararlı kalacağı varsayımı — varsayım günlüğü güncellenir ve buna bağlı olan tüm gereksinimler yeniden doğrulanır. Değişiklikten kaynaklanan yeni problemler, bir sorumlu ve bitiş tarihi ile birlikte sorun günlüğüne eklenir.

Yaygın Tuzakların Neden Başarısız Olduğu

Tekrar eden dört yanlış cevap kalıbını ele alalım:

• Düşük değerli işlevsellik sunmak başarısız olur, çünkü çaba, iş faydasına yönelik bir izlenebilirlik olmadan harcanmıştır. GTM ve MÜÜ disiplini tam olarak bunu önlemek için vardır; bunları atlamak, ekibin sonuç için değil, çıktı için optimizasyon yaptığı anlamına gelir.
• Geç gelen kapsam eklemelerini gayriresmi olarak kabul etmek başarısız olur, çünkü etki analizini atlar. Bu ekleme, diğer işlerin ihtiyaç duyduğu bolluğu tüketebilir veya test stratejisini geçersiz kılan bir risk ortaya çıkarabilir. DDK’nın görüşü olmadan, takvim saptığında kimse sorumlu tutulamaz.
• Değişiklik talebi olmadan değişiklikleri uygulamak başarısız olur, çünkü temel çizgiyi bozar — gelecekteki varyans analizi anlamsız hale gelir ve kazanılmış değer hesaplamaları gerçeklikten sapar. Bu aynı zamanda yönetişimi de aşındırır: bir kanalın atlanmasına bir kez göz yumulduğunda, tüm disiplin çöker.
• Küçük değişikliklerin hiçbir etkisi olmadığını varsaymak başarısız olur, çünkü etki kümülatiftir ve genellikle doğrusal değildir. Tek satırlık bir kod değişikliği, onlarca modül genelinde regresyon testini tetikleyebilir; “küçük” bir spesifikasyon ayarı, bir düzenleyici kurumdan yeniden onay gerektirebilir. Kural şudur: önce değerlendir, sonra kategorize et, asla varsayma.

Bir müşteri haftalık olarak kapsam değişiklikleri talep ettiğinde, doğru yanıt üç yönlüdür: her talebi resmi değişiklik kontrol sürecinden geçirmek, müşterinin her değişikliğin gerçek maliyetini görmesi için etki analizi yapmak ve paylaşmak, ve beklentileri yeniden belirlemek ve uygun olduğunda yeniden planlama veya yeniden temel çizgi oluşturmak için sponsor ve DDK ile yeniden temasa geçmek. Sessizlik, gayriresmi kabul veya tek taraflı ret, hepsi aynı disiplinin başarısızlıklarıdır.

Uygulamalı Problem: Örnek Senaryo

Senaryo: Meridian Health, acil servis kabul süresini %30 azaltmayı hedefleyen yeni bir hasta kabul platformunun 18 ay sürecek 4,2 milyon dolarlık uygulamasının ortasındadır. Proje Yöneticisi (PY) Priya, klinik, BT ve tedarikçi personelinden oluşan 22 kişilik hibrit bir ekibe liderlik etmektedir. 9. Sprint Değerlendirmesi sırasında, Başhemşire (CNO), sistemin sağlığın sosyal belirleyicileri verilerini de toplamasını talep eder. Klinik lider bu talebi “hayati önemde” olarak nitelendirse de, bu istek orijinal kapsam bildiriminde veya ürün birikim listesinde (product backlog) hiç yer almamıştır.

Zorluk: Priya, sürüm takvimini aksatmadan, maliyeti şişirmeden veya projenin başarısı için benimseme desteği kritik olan üst düzey bir paydaşı göz ardı etmeden CNO’nun talebini nasıl yöneteceğine karar vermelidir.

Önerilen Yaklaşım:

1. Talebi, sprint değerlendirmesinde sözlü olarak kabul etmek yerine, değişiklik kontrol sistemine resmi bir değişiklik talebi olarak kaydedin ve bu konuyu gündeme getirdiği için CNO’ya teşekkür edin.
2. Talebi Gereksinim İzlenebilirlik Matrisi (Requirements Traceability Matrix - RTM) üzerinden takip edin: mevcut bir iş hedefine (azaltılmış kabul süresi) hizmet edip etmediğini veya yeni bir fayda akışı getirip getirmediğini belirleyin ve İş Kırılım Yapısı (WBS), tasarım ve test senaryoları üzerindeki sonraki etkilerini işaretleyin.
3. Etki analizi yapmak üzere 48 saat içinde iş analisti ve klinik lideri bir araya getirin — efor, maliyet farkı, takvim etkisi ve tedarikçinin veri modeline olan bağımlılıkların yanı sıra HIPAA ve raporlama yükü gibi fonksiyonel olmayan etkileri de tahmin edin.
4. Analizi Değişiklik Kontrol Kurulu’na (Change Control Board - CCB) üç seçenekle sunun: Faz 2’ye ertelemek, eşdeğer büyüklükte daha düşük değerli bir birikim listesi (backlog) öğesini düşürerek yeniden önceliklendirme yoluyla absorbe etmek veya resmi bir bütçe ve takvim temel çizgisi (baseline) güncellemesiyle onaylamak.
5. CCB’nin kararını yansıtacak şekilde RTM’yi, kapsam temel çizgisini ve iletişim günlüğünü güncelleyin ve sonuç ile gerekçesi hakkında CNO’yu şahsen bilgilendirin.
6. Sağlığın sosyal belirleyicileri verilerinin ilk gereksinim toplama (elicitation) sırasında neden gözden kaçırıldığını gözden geçirmek için bir retrospektif eylemi ekleyin — bu durum muhtemelen hemşirelik liderliğinin eksik bir paydaş analizinden kaynaklanmıştır.

Bu Yaklaşım Neden İşe Yarar: Talebi belgelenmiş değişiklik kontrolü üzerinden yönlendirmek, paydaşı onurlandırırken temel çizgiyi (baseline) korur — talep ne reddedilir ne de sessizce absorbe edilir; bu iki durum da klasik kapsam yönetimi başarısızlıklarıdır. RTM üzerinden izleme yapmak, kararın paydaş kıdemine değil, iş değerine dayandırılmasını sağlar ve retrospektif adımı gelecekteki gereksinim toplama süreçlerini güçlendirir. Bu, kapsam kayması (kontrolsüz genişleme) ve paydaş yabancılaşması (katı bir şekilde reddetme) gibi ikiz tuzaklardan kaçınmayı sağlar.

← Agile · Tüm alanlar · Risk ve Sorun Yönetimi →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →