демотивацията на екипа

Класическите грешки: Демотивацията на екипа

демотивацията на екипа

Класическите грешки

Когато говоря на моите семинари за управление на проекти за факторите, които предричат успеха или провала на един проект, неминуемо стигаме до класическите грешки. Това е термин, дефиниран от Steve McConnell и публикуван в неговата книга “Rapid Development” (1996). Тя и до днес е “библия” в областта на проектното управление в софтуерния бизнес. В нея авторът постулира, че ако искаме един проект да бъде успешен, преди всичко трябва да престанем да правим класически грешки. Това са онези действия, които са доказали в практиката на много проекти, че със сигурност водят до провал. Един от тези важни фактори е демотивацията на екипа. Стив МакКонъл я постава сред най-важните причини за неуспеха на един проект.

Наскоро попаднах на една статия от Sean Kenney, който също я дефинира като един от двата големи фактора, които могат да “потопят” един проект. В този пост ще ви разкажа една история от моя опит, в която демотивацията изигра съществена роля за провала на проекта.

Моята история с демотивацията на екипа

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

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

Моята оценка на предстоящата работа

Аз имах опит в работа с банкови системи и прецених, че ще ни трябват 10-12 месеца за изпълнението на целия проект. Това включваше:

  • 3-4 месеца за цялостен анализ на изискванията и формулиране на функционална спецификация
  • поне 6 месеца разработка от един малък екип от четирима човека примерно.

Каква беше моята изненада, когато разбрах, че аз ще съм единствения програмист в екипа (а бях титулован Team Leader!) и вместо очакваните 10-ина месеца за цялостно изпълнение на проекта, имах само 4! Заедно с колегата, който изпълняваше функциите на проектен мениджър и бизнес анализатор, се опитахме да обясним на големия шеф, че при тези условия нямаме никакви шансове да изпълним този проект, но отговорът му беше, че ако не се справим, значи не сме достойни за тази фирма и че той е направил грешен избор като ни е назначил.

Грешният екип

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

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

Единият колега беше назначен с връзки и въпреки напомпаните препоръки, се оказа, че на практика няма никакъв опит в програмирането и почти с нищо не може да бъде полезен. Другият пък беше доста колоритна личност, за който понятията трудова дисциплина и отговорност не съществуваха. Той идваше на работа след 13:00 часа, защото до обяд си отспивал след нощни игри на Counterstrike, а в 17:00 вече си тръгваше, защото имал среща с гадже. Кодът, който пишеше и публикуваше в общата source code база, не се компилираше и в крайна сметка колегата носеше повече вреда, отколкото полза на работата. Да, беше веселяк, но това никак не помагаше на нашите проблеми.

Закономерният провал

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

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


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

8 Comments

  • Огнян says:

    Интересна статия, която със сигурност звучи до болка познато за повечето програмисти, които са работили по големи проекти…
    Btw, може би не е лоша идея да си сложиш +1 бутонче…

  • Да, блогът има нужда от малко обновяване, но междувременно съм споделил статията в Google+ тук: https://plus.google.com/u/0/115697930311666978542/posts/AUhSR54PZFy така че можеш там да цъкнеш един плюс 🙂

  • Ира says:

    Тъжна картинка.. Но дали е проблем в мотивацията? Не мисля, че има мотивация която да направи така, че този проект да приключи успешно при зададените от ръководството ресурси и време.

  • Безспорно, добрата мотивация не е гаранция за успех при такива ограничения, но определено проектът би могъл да завърши с готов продукт, макар и с някакво закъснение и надхвърляне на бюджета. Липсата на мотивация (при това даже и у мениджмънта) е категорична гаранция за провал.

  • Елена Иванова says:

    Класически пример на случая “Слаба подкрепа от мениджмънта”. А мотивацията в общия случай е следствие от мениджмънта.

  • Чудесен материал, Майк 🙂
    Мотивацията може да се срине за секунди и дори от неволна дума на мениджър, колега или клиент! Наистина е крехка и за жалост способни специалисти могат да оставят погрешното впечатление, че нямат умения или се разпиляват, а всъщност проблема да е на съвсем друго ниво. Особено при натрупване на грешки от комуникационно естество във вътрешен план, мотивацията може рязко да спадне.

  • Vupros says:

    Интересна случка, безспорно, пълна с абсолютни абсурди – назначения с връзки, липса на чуваемост с клиента от самото начало, и т.н. За мен тази история, разказана по този начин, оставя много въпроси:

    1. Как е било решено да се определи крайният срок на разработката от клиента – като че ли тяхната представа за кога трябва да е готово изобщо не се базира на анализ. Имало ли е такъв анализ? Сравнен ли е той с анализа който вие сте предложили?
    2. Бавна комуникация с клиента – няма как без своевременна комуникация с клиента нещата да вървят. Този проблем ескалирахте ли го с спонсора на проекта, за да осигури съдействието на хората от които реално зависи работата?
    3. Екип подводница – Тези хора е ясно че няма как да свършат работата. Това ескалирано ли е? Ако един проектов ръководител няма контрол над екипа си, как може да поеме какъвто и да е ангажимент? Идване в 13:00 на работа? На първия ден се говори с този човек, на втория се предупреждава, на третия се отстранява.

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

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

  • Vupros, отговарям ти отзад напред. Действително проектният мениджър беше назначен като бушон. Проектният спонсор беше лично шефът на фирмата и всичко беше ескалирано до него и всички негови решения баха препотвърдени. Можеш да ескалираш само до арменския поп 🙂

    Това беше т. нар. “стратегически проект”. От една страна искахме да задоволим клиента и да изпълним един негов проект за малко пари, за да можем да се възползваме от неговите услуги с голяма отстъпка. От друга страна, всеки проект се опитвахме да го направим печеливш, което в случая беше невъзможно. От тук и единия от парадоксите.

    Сега по конкретните въпроси:
    1. Срокът дойде от парите. Клиентът имаше малък бюджет, а искаше сложен продукт. Ръководството определи срока на база на парите и след това се опитаха да ни накарат да свършим 12-месечна работа за три месеца.
    2. Както казах, всичко се ескалираше до шефа, но той не искаше да безпокои “стратегическия клиент”.
    3. Не знам защо, но във фирмата беше приета политика на “не-уволняване” много дълго време. В следствие на това, въпросният колега беше прехвърлян 3-4 пъти в различни екипи поради системно несправяне с работата и закъсняване.
    Нещо повече – когато аз реагирах по-шумно и обясних на спонсора (сиреч ескалирах проблемите), че екипът не е в състояние да свърши поставената задача, бях наказан като ми бе отказано повишение на зплатата (и изобщо обсъждане на този въпрос) под предлог, че не мога да ги мотивирам да работят по-усърдно.

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

Leave a Reply

Your email address will not be published.