Ежедневието ми на бизнес аналитик

Прави ми впечатление че когато говоря за бизнес анализ хората често имат доста различна представа какво означава това. И колкото по-дълбоко изпадам в описание какво е бизнес анализ, толкова по-недоверчиво ме гледат. 🙂

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

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

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

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

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

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

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

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

Гласувайте за тази статия в Svejo.net: [wp:svejo-net]

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