PM Stories » Класически грешки

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

Майк Рам — Tue, 25 Oct 2011 02:12:43 +0000

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

Започвам с демотивацията, защото наскоро попаднах на една статия от Sean Kenney, който също я дефинира като един от двата големи фактора, които могат да “потопят” един проект. Това, което искам да ви разкажа, е една история от моя опит (нали затова този блог се казва PM Stories ), в която демотивацията изигра съществена роля за провала на проекта.

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

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

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

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

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

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

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

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

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

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

Добре забравеното – юли 2007 г.

Майк Рам — Tue, 14 Oct 2008 09:40:12 +0000

Това е една добра идея, която видях в други блогове и започнах да прилагам и в собствените си блогове отскоро. Да се извадят на показ хубави и полезни материали от миналото, които вече са позабравени. Въпреки, че официално блогът PM Stories още не е навършил година (той официално стартира на 1.1.2008), материалите в него са писани преди повече от година и първоначално бяха публикувани в блога Спри и помисли!

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

Ето кои бяха по-интересните неща, посветени на управлението на проекти, и публикувани от мен през месец юли 2007 година.

Съвременното виждане за управлението на проекти и теориите на мениджмънта:

Какви качества трябва да притежава един лидер:

Любимата ми тема за грешките:

10-те най-важни грешки в разработката на софтуер
Класическите грешки: случаят “ГигаЛийз” – част 1 и част 2 (на английски)

И накрая, още 2 публикации в бонус:

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

Ако искате да управлявате успешни проекти в условията на реалния бизнес, регистрирайте се за курса по управление на проекти, който водя във фирма RammSoft – професионално обучение, базирано на съвременните управленски теории и на най-добрите примери от практиката!

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

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

Препоръчано четиво: Workflow, Scrum, честност и продуктивност

Майк Рам — Thu, 09 Oct 2008 14:14:51 +0000

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

Steve McConnell ни информира от страниците на своя блог, че има публикувани нови white papers на сайта на неговата фирма – Construx. МакКонъл е известен като критик на модерните напоследък “гъвкави методологии”, затова мисля, че документите, посветени на успешното внедряване на Scrum и оптимизирането на гъвкавите процеси, биха били особено интересни за вас. Разбира се, обновената версия на неговия фундаментален труд за класическите грешки, е просто задължително четиво. Всички white papers можете да намерите на адрес: www.construx.com/whitepapers.

Mike Griffiths пък е публикувал в своя блог един много детайлен анализ на измеренията на високата продуктивност. Той твърди, че размерностите са три:

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

Статията е дълга, но е интересна и е обогатена с обилно количество тримерни (!) графики, които поясняват мисълта на автора.

Накрая завършвам с един цитат от Nina Simosko от блога Slow Leadership (който вече не съществува), посветен на отношението на лидера / мениджъра към хората от своя екип. Тя защитава тезата, че откритостта и честността са най-правилните методи за комуникация и за управление на екипа, включително и когато се налага да отправим критика.

По-добре е да си уважаван и нехаресван, отколкото харесван, но неуважаван.

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

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

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

Класически грешки – 2008

Майк Рам — Tue, 08 Jan 2008 09:59:00 +0000

Онзи ден получих писмо от Steve McConnell с линк към резултатите от изследването, което той проведе миналото лято върху Новите класически грешки на софтуерното производство. Аз участвах в това проучване и писах за него в Класическите грешки. Стив публикува своя списък от класически грешки в книгата си Rapid Development от 1996, но поради много динамичното развитие на софтуерния бизнес, той реши, че списъкът се нуждае от актуализация. В него бяха предложени няколко нови грешки, а всички останали бяха подложени на верификация.

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

Моят професионален опит ми показва, че повечето софтуерни компании все още са много далече от стандартите, които Steve McConnell поставя за Rapid Development и първата и най-важна стъпка, която трябва да се направи, е да се научим да избягваме тези “класически грешки”. Допускането на подобни грешки е гаранция, че няма да можете да завършите своя проект навреме. Според мене, всеки добър проджект мениджър трябва да има този списък пред себе си, за да го следи периодично и да си задава въпросите: Продължаваме ли да допускаме класически грешки? и Как можем да ги избегнем?

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

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

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

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

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

Класически грешки – Случаят "ГигаЛийз", Част 2

Майк Рам — Wed, 18 Jul 2007 15:26:00 +0000

Историята продължава с изграждането на екипа и първите внедрявания при клиента, когато някои неприятни истини излизат наяве. Още много грешки в един относително малък проект.

Четете втората част на случая “ГигаЛийз” в англоезичната версия на блога, а коментари може да пишете и тук. Ще съм безкрайно щастлив, ако и вие имате подобни истории, които да споделите с мене и моите читатели.

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

Класически грешки – Случаят "ГигаЛийз", Част 1

Майк Рам — Mon, 16 Jul 2007 17:21:00 +0000

След дълго умуване и канене започнах серията за класическите грешки с един пример от моята практика – случаят “ГигаЛийз”. Реших, че споделянето на реални примери от живота е най-добрия начин да видим и оценим грешките, които са допуснали различните участници в историята и да преценим как трябва да постъпваме ние в подобни ситуации, за да не ги повтаряме. Първата част на тази история можете да прочетете тук (на английски език).

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

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

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

Майк Рам — Wed, 20 Jun 2007 16:33:00 +0000

Снощи изнесох първата си лекция на семинар на БАРС и съдейки по положителните отзиви, смятам, че ако не моето лично представяне, то поне темата е била интересна за участниците в семинара. Темата за класическите грешки отново излезе на дневен ред, след като авторът Steve McConnell реши да актуализира списъка и да предложи анкета за това доколко често правим класически грешки и колко са сериозни пораженията в последствие. Горещо ви препоръчвам да се включите в изследването и да попълнете анкетата – това ще помогне на целокупното програмистко братство да си изясним кои са най-важните грешки, които правим в работата си и да се научим да ги избягваме.

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

Предполагам, че ще са малко по-различни от тези, които Стив МакКонъл е дефинирал, най-малкото поради това, че у нас нещата се правят по-иначе. Надявам се, че това ще обогати представите на колегите не само в България, но и по света и ще добави още няколко щрихи към “голямата картина” на софтуерното производство.

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

Благодаря на всички, които ме подкрепят!

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

Семинар на БАРС – 19.06.2007

Майк Рам — Tue, 12 Jun 2007 16:51:00 +0000

Щастлив съм да обявя, че на 19.06.2007 г. ще се проведе семинар на Българската асоциация на разработчиците на софтуер (БАРС), в който съм поканен да участвам и аз като лектор и ще изнеса презентация на тема Rapid Development – Part 1. Лекцията представя основните идеи и принципи на концепцията за Rapid development, представена от Steve McConnell в едноименната му книга, издадена още през 1996 г., но валидна в пълна сила и до днес и неслучайно считана за библия в света на софтуерното производство и управлението на софтуерни проекти.

Семинарът ще се проведе на 19.06.2007 г. в София, в клуб “Sugar” на ул. “Граф Игнатиев” 1. Заповядайте!

По-подробна информация за събитието можете да прочетете от официалната обява на сайта на БАРС.

Книгата “Rapid Development” можете да си купите от: Amazon.