С използването на сайта вие приемате, че използваме „бисквитки" за подобряване на преживяването, персонализиране на съдържанието и рекламите, и анализиране на трафика. Вижте нашата политика за бисквитките и декларацията за поверителност. ОK
Регистрация

Седемте грешки на PM-a

Или какво да (не) правите, ако искате да бъдете успешен ръководител на проекти
Share Tweet Share
Снимка

[Shutterstock] 

Тази седмица гост в блога на karieri.bg е Георги Христов - ръководител на проекти с над 10 годишен опит в тази сфера (повече за него в края на текста). С него се свързахме покрай събитието на Висшето училище по мениджмънт във Варна - "Свиквай с успеха", на което "Кариери" беше медиен партньор и на което той беше един от лекторите в програмата. Помолихме Георги да разкаже малко повече за най-често допусканите грешки от хора, които се занимават с управление на проекти. А ето и резултата – полезно и практично четиво какво да (не) правите, ако искате да бъдете успешен ръководител.

Ако и вие сте професионалист в конкретна област и искате да споделите своите съвети за успех на принципа "от професионалисти за професионалисти" в блога на "Кариери", пишете ни с вашата идея на karieri@karieri.bg.

Да бъдеш мениджър на проекти (PM) е едно от най-големите предизвикателства, с което можете да се сблъскате. Самата позиция е крайно деликатна, тъй като вие сте връзката между клиента (независимо дали става въпрос за външна организация или човек или друг отдел от вашата собствена компания) и екипа. Вие сте и човекът, който трябва правилно да разпределя ресурсите и да оценява ситуацията. Вие сте и човекът, който носи отговорността за всяка грешка на вашия екип.

Затова е много важно преди да се заемете с подобно предизвикателство да сте наясно, че ще ви се наложи да се сблъскате с много и различни проблеми. Аз самият имам над 10 години опит в тази област, което означава и че имах възможност да допусна много от грешките, които един PM може да направи. Ще ви запозная с моя списък със 7 от тях, които определям и като най-големи и фатални, за да можете да се поучите от опита ми, а не да тествате всичко на свой гръб.

#1 Предоверяване в екипа
Има моменти, в които човек става твърде самоуверен. Ако сте проджект мениджър, който е работил успешно дълго време с един екип или пък просто решавате, че хората, които сте събрали в екипа са най-добрите, можете да изпаднете в ситуация, в която да им се предоверите.

Аз съм правил тази грешка два пъти, като и двата пъти това завърши катастрофално. В първия случай се доверих на моя екип за избора им на технология, чрез която да бъде реализиран един проект, без да задам простичкия въпрос "Защо?". Трябва да знаете, че "защо" е наистина думичка вълшебна. С този въпрос провокирате хората да ви дадат аргументиран отговор, който може да бъде отправна точка за дискусия. Разбира се, не можете да имате понятие от всичко при реализацията на проекта и че трябва да можете да разчитате на познанията и преценката на своите специалисти, но никога не приемайте всичко казано от тях безрезервно. Аз го направих, изхождайки от позицията, че двамата ми топ девелъпъри имаха впечатляващи кариери с повече от 15 години стаж като програмисти. И в моя случай това доведе до избор на погрешна платформа и загуба на проект и клиент.

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

#2 Микроуправление на екипа
От целия списък, който ще споделя с вас, това е единствената грешка, която не съм допуснал аз лично, а бях в екипа на мениджър, който имаше подобно поведение към нас, хората, които ръководи. Според мен хората, които се опитват да управляват всичко до най-дребния детайл, се делят на два основни типа: егоцентрици с мания за величие, които смятат, че могат всичко най-добре и всички трябва да правят нещата като тях или абсолютно неуверени мениджъри, които изпитват панически страх от делегирането на права на своя екип. Независимо за кой от двата типа става въпрос, според мен това в крайна сметка е предпоставка за посредствена работа.
Първо, няма начин един мениджър да е еднакво наясно с всеки един аспект на даден проект (финанси, човешки ресурси, планиране, техническа част и др.). Второ, в крайна сметка вие трябва да работите с хора, а не с ваши клонинги. Не можете да очаквате, че всеки ще прави всичко, както го правите вие (и в повечето случаи това е за добро).

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

#3 Неефективна комуникация
Лошата комуникация си е направо като бърза магистрала към провал на проекта. Като междинно звено между клиент и екип от вас зависи цялата информация да достига максимално бързо, ясно и точно и към двете страни. Много лоша практика според мен е един PM да делегира отговорност на друг член от екипа да комуникира с клиента. Вие трябва във всеки един момент да сте наясно какво се случва и дали някъде има информационна "тапа". Ваша е отговорността да получавате максимално много детайли за проекта и неговото развитие и да предприемате необходимите корекции. Този аспект е жизненоважен, особено когато вашият клиент е външна организация.

Комуникирайте за всеки един проблем, с който вашият екип се е сблъскал. Ако сте изправени пред нещо сериозно, по-доброто решение е да говорите с клиента и да намерите някакъв компромис, отколкото да се опитвате да го държите "на тъмно", разчитайки на чудо. Като начинаещ PM в един от първите си проекти направих точно тази грешка. Вместо да се свържа с клиента си и да му подам информация за случващото се, реших да го държа в неведение, докато вече беше прекалено късно да се намери компромис. Ще се изненадате, но в повечето случаи ефективната комуникация може да спаси проекта дори и при сблъскване със сериозен проблем. Просто е нужно аргументирано и реалистично да обясните ситуацията.

#4 Неясно задание
Има един израз: Ако не знаете накъде отивате, най-вероятно ще се озовете на грешно място. Напълно вярно е! Никога, ама наистина никога, не започвайте проект, без да имате ясно и точно задание. Особено пък, ако става въпрос за такъв, свързан с информационни технологии (IT).

Отделете нужното време и си подгответе документацията преди да започнете работа, защото иначе се случват много, ама много неприятни неща. Като например любимото ми "Ама аз не си го представях така!". Едно такова изречение обикновено в IT бранша значи поне още неколко дена (че може и седмици) работа, които, поради липсата на добро задание, най-вероятно няма да ви бъдат заплатени. Опитайте се да бъдете максимално детайлни при написването на заданието, питайте за нещата, които могат да бъдат направени по няколко различни начина, за да имате документирано черно на бяло за какво си плаща клиента и вие какво сте поели като ангажимент да изпълните.

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

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

#6 Неправилна оценка на сложността на проекта
Преди години бях чел един разказ "Ако програмистите строяха къщи", който по много весел начин описва до голяма степен IT бранша в началото на XXI век. Та там имаше един откъс: "Обсъждахме сроковете. Петров казва, че ще стане за 4 месеца. Значи за 8 месеца. В договора записахме 12 месеца, но едва ли ще се оправим за по-малко от 16." Тази грешка до голяма степен всъщност е свързана и с неясното задание и с предоверяването в екипа. Напълно разбираемо е, ако не знаете конкретно какво се иска от вашия екип, да не можете да оцените правилно проекта, както и да сбъркате, ако сте стигнали етапа, в който смятате, че можете да правите чудеса от храброст.

Дори и да имате страхотна документация пак има голяма вероятност да сбъркате, просто заради самата динамика на средата. Бил съм свидетел, как двама програмисти с общо 20 години стаж търсят 1 ден един елементарен бъг в кода си. Аз лично няколко пъти съм имал глупостта да дам срок за изработка на нещо без да се консултирам предварително с екипа си, просто защото съм смятал, че е нещо дребно, което всъщност се оказва доста сложно поради някаква причина. Затова вече съм приел политика, че всяка една оценка на проект минава през моя екип, независимо какво мисля аз. Силно ви препоръчвам да спазвате и вие това правило, със сигурност ще ви спести много неловки моменти.

#7 Липса на ясна програма и приоритети
След като имате добро задание и оценка на проекта, трябва задължително да си направите план-график и да следите прогреса на екипа. Най-малкото за индикация с какво темпо се движите. При особено сложни и големи проекти е добра практика да ги разделите на функционални части, които могат да бъдат изградени поотделно (това е също практика от SCRUM), така че да можете да показвате на своя клиент работещи неща по време на целия проект. Това внушава доверие, а освен това предпазва и от допускането на генерални грешки, които могат да бъдат пагубни за целия проект. Без подобна програма просто настъпва хаос и губите от фокус какво точно се случва, кое е готово и кое не е. Дори да става въпрос и за сравнително лесен и малък по обем проект, отделете време да съставите план-график, това ще ви се отблагодари.

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

 

Георги Христов е предприемач и ръководител на проекти (project manager, PM) в софтуерната компания IGC. Работи в сферата на IT и WEB технологиите от 11 години. Реализирал е над 200 проекта в различни сфери и с различна сложност. За себе си казва, че е преминал през всякакви превъплъщения и че има опит в областта на SEO, социални мрежи, IT сигурност... Любопитен факт за него - на обратната страна на визитките му пише "Aut inveniam viam aut faciam" (Или ще намеря пътя, или ще прокарам път).


Share Tweet Share
още от тази рубрика:

Реклама

Реклама

© 2003-2019 Икономедиа АД съгласно Общи условия за ползване. Политика за бисквитките. Декларация за поверителност.
Общи условия за публикуване на обява ново.
Поставянето на връзки към материали в сайтовете на Икономедиа е свободно. Уеб разработка и дизайн на Икономедиа. Сайтът използва графични елементи от famfamfam + DryIcons. Някои снимки © 2019 Associated Press и Reuters. Всички права запазени.
Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов.
mobile Към мобилната версия на сайта

Бизнес: КапиталКариериБизнесРегалОдитFoton.bg

Новини: ДневникЕвропа

IT: IDG.BGComputerworldPC WorldCIONetworkworld

Развлечение: БакхусLIGHT

На английски: KQuarterly