Трябва ли анализът да е “тромав”?
Търсейки интересна тема за бизнес анализ попаднах на дискусия по тема, която често съм обсъждал и аз с колеги. В своята статия Do we need Agile Business Analysys? Крейг Браун задава въпроса дали Agile не прави бизнес аналитика като позиция излишен, което провокира добър отговор от професионалист съчетаващ двете.
Според мен отговорът зависи от това как възприемаме бизнес аналитика като задължения и позиция. И с каква цел организацията е намерила такава позиция за нужна.
Много организации и ИТ фирми приемат бизнес аналитика като позиция, която придава тежест. Независимо дали си ИТ фирма бореща се за проекти или ИТ мениджър, желаещ да покаже професионализъм, винаги е от полза да имаш хубав, подреден бизнес анализ, завършващ с красив, голям документ с много диаграми, носещ гръмкото название Business Requirements Specification. Това показва че си сериозен. В тази ситуация бизнес анализа се налага да е бюрократичен, бавен и негъвкав, по простата причина, че той е създаден с тази мисъл и с тази цел.
Не мога да отрека, че за много колеги тази идея е привлекателна и дори признавам, че в много случаи именно бизнес аналитиците се явяват основен адвокат на бюрокрацията. Това обаче е черта на някои организации и хора, прилагащи бизнес анализ – не на самата дисциплина.
Лидер, мениджър или наблюдател?
Наскоро попаднах на една интересна категоризация на хората, заемащи позицията Project manager. Авторът ги дели на три архетипа, които имат следните характеристики:
- Лидер. Има дълбоки технологични познания, както и опит в бизнес областта, която се автоматизира. Може да пише код ако се наложи. Активно участва в код ревюта и обсъжда технически проблеми с екипа.
- Мениджър. Има технически или бизнес произход, но е минал и специализирано обучение в управление на проекти. Познава добре механизмите и средствата на управление на проекти. Не се занимава с технически подробности, но участва в обсъждането на детайли по функционалността.
- Наблюдател. Високо квалифициран и сертифициран проджект мениджър, който е вещ в процедурите и правилата, но въобще не се занимава с производствения процес. Следи изпълнението на плана, но не участва нитов технически, нито във функционални дискусии.
След като е дефинирал така трите типа мениджъри, авторът естествено задава въпроса “Кой е най-подходящият за управление на софтуерни проекти?” и без много замисляне отговаря: лидерът.
Разбира се, има и аргументи в полза на този избор. Един от тях е, че когато проектът започне да изостава от плана (а това се случва на практика с всеки проект), наистина най-добрият метод за връщане в релси е да се преразгледа обхвата на проекта, т.е. функционалността, заложена в софтуерния продукт и да се премахне всичко, което не е жизнено необходимо.
Категории: Професията на проджект мениджъра | Няма коментари
