Някой, управлявал проекти в продължение на години, може да ви каже, че в тази работа има малко слава и признание. Всеки ден местим планини, за да постигнем и доставим това, което клиентът очаква, без дори да си поемем дъх, и накрая няма нито триумф, нито овации. Управлението на проекти често изглежда като професия, която носи минимално признание, и с течение на времето води до усещане за разочарование. В тази статия бих искал да засегна този привиден проблем и да споделя моята собствена гледна точка, за да вдъхна една нова отдаденост и гордост от нашата професия.

Ироничното е, че ако един PM е добър в своята работа, много малко хора ще го забележат, защото крайният ефект е проект с минимални сътресения и спокоен, постоянен прогрес. На практика това означава, че няма нищо за отбелязване и в случая това е супер. Ние работим с нашите екипи сякаш те са перфектно синхронизиран оркестър. С времето този успех се превръща в нещо нормално и очаквано, и внимание привличат само сериозни предизвикателства и грешки.

В моята практика, проектите, които привличат най-голямо внимание, са тези, които водят до неуспех или недоволство. Ангажиментите, които сме поели, привличат вниманието на всички заинтересовани и поставят шефа на проекта под микроскоп – не точно онова позитивно внимание, което търсим!
С това не искам да кажа, че няма неизречена благодарност както от екипа разработчици, така и от мениджмънта, и от клиентите. Поради това, че нашата основна задача е да осигурим успеха, когато го постигнем, това просто означава, че сме си свършили работата. В резултат, дори и най-трудните ни постижения могат да минат незабелязани. Затова удовлетворението трябва да идва от другаде, а не от публичното признание.

Тези разсъждения ни връщат към въпроса какъв тип личност е най-подходяща за ролята на проджект мениджър – според мен той трябва да бъде независим, безстрашен и мислещ. Някой, който не разчита на другите за постоянно одобрение и потвърждение, а изпитва чувство на гордост и удовлетворение отвътре. Това е напълно възможно – да мотивираш себе си чрез професионалния успех. Като ръководители на проекти, ние трябва да поставим индикатори за производителност (key performance indicators) и за себе си.

Една проста цел би била да извършваме постоянно подобрение на собствения си стил на работа или пък да постигнем по-високо ниво на доходност от всяка следваща инициатива. Този подход е особено важен там, където формален PM отдел не съществува. Поставените цели ще ни осигурят оценка за нашето подобрение и ще ни помогнат да поддържаме фокуса си върху професионалното усъвършенстване.

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

Човек може да открие огромно удоволствие в тази професия – положителната реакция може и да не идва винаги от външни източници, но аз вярвам, че човек сам е най-добрия съдник на собствената си работа. Оценете собствените си успехи и се стремете към повече и по-големи успехи в процеса на работа. Дори и да не е видимо за вас, хората ще го забележат.

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

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

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

• PMBOK Guide на български език
• За плановете и планирането
• Безплатна електронна книга за PRINCE2
• Вероятност за риск
• Как се справяте с рисковете?

Опитвайки се да формулира изисквания за промени по системите, на бизнеса му става все по-трудно да ги дефинира добре, тъй като не знае каква е настоящата ситуация. Това твърдение напълно съвпада с действителността, която виждам.

Когато събирам детайлна информация за настоящия бизнес процес, невинаги намирам такава при съответните представители на бизнеса. Съответно, налага се да търся тази информация в структурите именно на ИТ, на места, където тя по принцип не би трябвало да се намира.

Бизнесът, от своя страна, не изглежда притеснен от тази тенденция, като дори открито се обръща към мен да проверя в рамките на ИТ какви бизнес правила в момента са заложени в системите, за да преценят как искат да ги променят. Маркетингът иска точна информация какви продукти продава компанията, а продажбите искат точна информация при какви условия даден продукт може да бъде продаван в момента и т.н. Разбира се, те имат най-важната част от тази информация, нужна им ежедневно, но недостатъчно пълна и централизирана за да се планира цялостна промяна.

Какви са вашите наблюдения? Можете ли да потвърдите тази тенденция?

Ето още няколко въпроса, по които бих искал да узная вашето мнение:

• Ако сте ИТ специалист, случва ли ви се да знаете повече за бизнес процеса от отговорните за него?
• Ако сте представител на бизнеса и утре ИТ отдела бъде изцяло заменен, мислите ли, че можете да формулирате детайлно обяснение към новите специалисти как работите в момента и как искате това да се промени?
• Смятате ли, че отлива на знание за процесите от бизнес специалистите към ИТ представлява риск за организацията?

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

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

• Какво знаят опитните проджект мениджъри?
• Хиляда лева за мотивация. Нова анкета
• Не се задълбавайте в технически проблеми
• Предимства на комерсиалния софтуер пред open source решенията
• Разликата между мениджър и лидер

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

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

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

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

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

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

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

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

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

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

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

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

Петър е бивш програмист и състезател по информатика, завършил Факултета по Математика и Информатика към СУ „Св. Климент Охридски”. По-рано се е занимавал с разработка на приложения с ASP .NET и Delfi. От две години се е фокусирал основно върху бизнес анализ на софтуерни проекти. Сегашната му позиция е на старши бизнес аналитик в IT отдела на Българска Телекомуникационна Компания.

През свободното си време води лекции по бизнес анализ и софтуерни технологии в мениджмънта в Стопански Факултет на СУ. Активен участник е в Движение Български Великден, на което е и действащ председател.

С първата статия на Петър слагаме началото на една нова фаза в развитието на блога, с което вярвам, че той ще стане по-богат на информация и по-интересен за читателите, интересуващи се от проблемите на софтуерното производство и управлението на проекти.

Приканвам всеки, който има интереси в тази област и който смята, че има какво да сподели със своите колеги, да заповяда на страниците на PM Stories и да стане един от нашите автори. Така заедно ще създадем един център, който да фокусира интересите на професионалната общност в България. Заповядайте! Свържете се с мен чрез страницата за контакти и аз ще ви отговоря незабавно!

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

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

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

• Българската секция на Международния институт по бизнес анализ е вече факт