Затова реших да напиша нещата които реално върша в рамките на работния ден, като се надявам да помогне на заинтересованите да си изградят представа. При други аналитици е различно, но обикновено има някакво сходство, за да е дисциплината една и съща.

1. Документиране – най-известната и обикновено най-досадната дейност на бизнес аналитиците. Проблемът, който се налага да избегна тук, е от 5 души екип по проекта и 3 поръчителя да има 15 различни представи какво точно трябва да се свърши. Софтуерната спецификация е средство за това, но не единствено и често недостатъчно надеждно.

2. Описание на процеси – не се занимавам с описание на процесите на организацията. Описанието на процеси в моя случай е в много по-ограничен обхват – когато променим системите неизбежно някой ще промени начина си на работа. Това, което трябва да опиша, е как се вършат нещата сега и как ще се вършат след промяната на системите. Целта е да илюстрирам на програмистите каква всъщност е целта на разработката, която правят. Също така да илюстрирам в детайли на “бизнеса” какво се опитват да постигнат.

3. Описание на изисквания – ключовата работа е именно описването какво ще се променя по системите. Идеята е, че с поръчителите сядаме и определяме в детайли какво се иска и какво ще правим. Задачата тук е да се превърнат общите приказки до конкретни и ясни изисквания какво в „поведението” на системите се иска да бъде променено. Тук се налага да съм запознат поне повърхностно с дизайна на системата, която променяме, защото някои (реално повечето) искания за промяна изискват прекалено трудоемки доработки и е загуба на време ако чакам разработчиците да ми кажат това и едва тогава да променяме изискванията.

4. Промени по изисквания – изключително неприятен израз за всички замесени. Означава, че с поръчителите сме забравили нещо или че някой е променил мнението си за това, което иска. Съответно трябва да се преосмисли всичко планирано дотук – зависимостта на тази промяна с други изисквания, увеличение на срока и цената, документация и комуникация на променените изисквания. (Разпространението на новата информация в екипа, всеки член на който е разпределен на 20% от времето си към проекта и няма постоянна комуникация с останалите, е истински кошмар.)

5. Приоритети – всички изисквания са важни, но е факт че някои са по-важни от други. При ограничен ресурс (а той винаги е ограничен) работата ми като бизнес аналитик включва решения свързани с определянето кое ще се прави веднага, кое ще се отложи за бъдеща разработка и кое ще се отложи за светлото неопределено бъдеще, когато всички наши желания ще бъдат изпълнени.

6. Проектен мениджмънт – изключително ценя проектните мениджъри за всичко, което вършат – организират срещи, взимат тежки решения, координират крайни срокове, следят за спазване на срокове и т.н. В повечето случаи, обаче, имам съмнителното удоволствие да върша и тази работа. Причината е, че като бизнес аналитик имам общ поглед върху изискванията и поддържам контакт с поръчителите, което ме прави първия заподозрян като се  избира „изпълняващ ролята”. Ако някога се чудите как да убедите някого, че е важно всеки проект да има мениджър – направете го PM „между другото” и много бързо ще му дойде ума в главата. Предполагам затова проектните мениджъри са най-големите поддръжници на бизнес анализа – по сходни причини те вършат нашата работа, когато ние не сме наоколо.

Това мога да се сетя от раз. Ако някой колега се сеща за още нещо което върши (а вероятно и аз върша, но не мога да се сетя в момента) може да се чувства свободен да допълва списъка.

Гласувайте за тази статия в Svejo.net:

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.

Вижте и тези публикации:

• Добре забравеното – юли 2007 г.
• PMBOK Guide на български език
• За плановете и планирането
• Документи на бизнес анализа
• Безплатна електронна книга за PRINCE2

Един от най-богатите и най-ценни ресурси в областта на проджект мениджмънта е GanttHead. Горещо ви препоръчвам да станете негови членове (безплатно е) и да се абонирате за неговия newsletter. Информацията и съветите, които можете да намерите там, са безценни.

Във връзка с моите скорошни публикации за лидерството (Как проджект мениджъра да стане истински лидер, Съвети от едно “плешиво куче” и 20-те качества на вдъхновяващия лидер), открих статията на Andy Jordan Project Manager vs. Project Leader, където той защитава тезата, че независимо колко квалифициран е един проджект мениджър в областта на управлението на задачи и ресурси, той трябва да притежава и качества на лидер. “Проджект мениджърът има задължението на управлява своя екип – даже и в матрична организация – и това означава да бъде лидер”. По-нататък той описва различните страни на водачеството, лесното и трудното на това да бъдеш не просто шеф на проекта, а и негов лидер.

Друга ценна статия, която можете да намерите на сайта на GanttHead е тази на Tom L. Barnett, наречена Leadership-Powered Project Management. Той твърди, че всички лидери, които познаваме от историята, без значение дали са били политически, военни или бизнес водачи, независимо от това, че са притежавали различни стилове, са имали някои общи лидерски качества. Давайки за пример Уошингтън и Линкълн, Гейтс и Уелч, Чърчил и Айзенхауер, Том Барнет ни дава онези специфични особености, които притежават всички велики водачи. Тези, които ни обособяват като лидери и ни отличават от другите.

Въпреки, че качества на водач са необходими на всеки проджект мениджър, има и техники на занаята, които също са задължителна част от уменията на ПиЕм-а. Блогът PM Hut публикува наскоро статията на Thomas Cutting How to Really Fix a Failing Project, където той се фокусира върху най-важните неща, които шефа на проекта трябва да направи, когато усети, че проекта му е попаднал в беда. Ако можете да запазите самообладание и да последвате неговите съвети, има голям шанс да измъкнете проекта си от калта.

PM Hut е великолепен източник на полезна информация за проджект мениджъри. Това е един вид агрегатор, където се публикуват статии от много опитни и интересно пишещи блогъри в областта на управлението на проекти (включително и от мене ).

Писането на проектните документи е може би най-неприятното задължение за повечето проджект мениджъри. Аз лично познавам доста хора, които не разбират смисъла и предназначението на повечето такива документи, което е и причината за тяхната неприязън към това задължение. PM Hut са публикували статия от Sam Elbeik по този повод. Тя е малко помпозно озаглавена Тайната на успешния проджект мениджмънт, но въпреки това представя просто и разбираемо обяснение на смисъла и важността на ключовите документи, които се изготвят в един проект като Project Charter, плана и отчета за напредъка.

Накрая ви представям една доста сериозна публикация от големия ПМ гуру Tom Mochal в блога на TechRepublic за управление на проекти, посветена на едно от първите неща, които се случват в един проект – the kickoff meeting. Защо е важно това и как да го проведем – четете тук (забележка: може да се изисква регистрация, която е безплатна!)

Приятно четене!

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл

Вижте и тези публикации:

• Кой е отговорен за проекта?
• Разликата между мениджър и лидер
• Добре забравеното – август 2007 г.
• Кой решава дали да стартира един проект?
• Проучване на “soft skills” на проектните мениджъри