Има нещо неизбежно в проектите (и живота като цяло) – промяната. Без значение колко много планиране, събиране, преразглеждане и одобрение на изискванията извършва бизнес анализаторът – винаги трябва да очаква и да бъде подготвен за промяна. В следващата статия от PMI-PBA® серията ще се фокусираме върху това как да поставяме граници, да оценяваме въздействие и да контролираме промени към изискванията, така че ще разгледаме различните дейности, които съставляват четвъртия PMI-PBA® домейн: Проследяване и Контрол (Traceability and Monitoring).
Какво се счита за промяна? Как да знаем какви са границите на нашите проектни изисквания? Отговорът на този въпрос е една дума – обхват (baseline). Всички одобрени задачи са в очертанията на обхвата на проекта. Всичко останало, което не е включено в него, подлежи на одобрение. Веднъж щом изискванията са одобрени, те могат да бъдат променяни само чрез процедурите за контрол на промените, дефинирани за дадения проект. Форматът и степента на формалност приложени към промените варират в зависимост от методологията (product life cycle), сложността на проекта, броят на заинтересованите страни и рискове, и организационните процеси за управление на промяната. Проект, който използва waterfall методологията е по-вероятно да прилага по-формален и сложен процес за контролиране на промените, а agile практиките обикновено използват не толкова формален процес.
За да обясня домейна за Проследяване по по-конкретен начин, ще се постарая да отговоря на следните въпроси:
Какво е проследяване?
Просто казано, проследяването е мониторинг на изискванията от тяхното начало до очакваните крайни резултати, които ще изпълнят.
Какво трябва да следим?
Трябва да внимаваме с качеството и количеството на информацията, която проследяваме или иначе ще попаднем в безкраен и безполезен омагьосан кръг (loop). Това, което трябва да проследяваме е специфично за всеки отделен проект, но диаграмата по-долу представя обобщен списък:
Как да извършваме проследяване?
Подходящите инструменти за извършване на проследяване и контролиране зависят от организационните практики и наличния софтуер. Лесен метод, който включва любимия на всички Excel, е requirements traceability matrix. Често срещани атрибути на матрицата включват:
- ID на изискванията (също Requirement Parent ID) и Описание
- Версия
- Приоритет
- Собственик
- Статус
- Use Case ID – ID на use case, които изпълнява даденото изискване
- Рефериращи документи
- Клас/ Метод/ Функция/ Процедура – в които е имплементирано изискването
- Test Case Номер – къде и как ще бъде тествано изискването
- Tester/Developer – кой е имплементирал/ тествал изискването
Тъй като е йерархична, матрицата лесно поддържа анализ на зависимости и на въздействия. Когато нови изисквания се появят или настоящи такива се променят, те се документират, добавят се към traceability matrix, оценява се тяхното въздействие върху проекта и продукта и се представят на заинтересованите страни за одобрение.
Какво е заявка за промяна, процедура за контрол, съвет за контрол на промените?
Заявка за промяна е формалното предложение за промяна. Тъй като трябва да контролираме промените, които се правят върху обхвата на проекта, ние имаме нужда от установен процес за тази цел – процедура за контрол на промените. И тъй като е необходим и упълномощен орган да разгледа, оцени, одобри, отложи или да отхвърли промените в проекта, се нуждаем от съвет за контрол на промените (change control board) (който често се назовава като CCB).
Как бизнес анализът се свързва с управлението на промени?
Управлението на промени е в интерес и на ръководителя на проекта и на бизнес анализатора. Проектният ръководител е ангажиран с всички въпроси отнасящи се до обхвата на проекта, докато бизнес анализаторът е ангажиран с обхвата на продукта – поддържайки целостта на изискванията и асоциираните очаквани крайни резултати, както и подсигуряването на това, че всяко ново изискване е в съгласие с бизнес нуждите и целите на бизнеса и проекта. При всички случаи, и двете роли трябва да работят заедно и да комуникират относно предложените промени.
В следващата статия от PMI-PBA® серията ще разгледаме детайлите от последния домейн Оценяването – как да валидираме решение или част от него, колко често да оценяваме и какви инструменти и техники да използваме, за да подсигурим, че решението отговаря на бизнес нуждите зададени от заинтересованите лица.
Вижте повече тук за:
- PMI Professional In Business Analysis (PMI-PBA)® Certification Preparation Training
- Насоки за PMI-PBA сертификационния изпит
PMI-PBA е регистрирана марка на Project Management Institute, Inc.
