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 или по имейл.

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

Банка ДСК – софтуерно решение за управление на опашка от клиенти

Майк Рам — Thu, 10 Jan 2008 10:21:20 +0000

Днес в блога си The Man on the Silver Mountain публикувах една статия, озаглавена Банка ДСК – реален социализъм в действие. В тази история разказвам за два феномена, с които се сблъсках там. От една страна е нежеланието или неспособността на банката да се справи с огромните опашки от клиенти и превръщането им в нормално ежедневие, и от друга е софтуерното решение, с което банката иска да вкара опашката в някакъв ред, и което се оказва поредната софтуерна недомислица.

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

Тази история е поредния пример за софтуерно изпълнение, което напълно е игнорирало крайния потребител – нито е съобразено с неговите изисквания, нито пък с възможностите му и спецификата на неговото поведение. (Не бива да забравяме, че 90% от клиентите на банката са пенсионери, които не само нямат компютърна грамотност, но имат затруднения с четенето и придвижването.)

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

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

Класически грешки – 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 или по имейл

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

10-те най-важни грешки в разработката на софтуер, според InfoWorld Tech Watch

Майк Рам — Sun, 22 Jul 2007 15:20:00 +0000

Наскоро, в блога InfoWorld Tech Watch открих един пост, озаглавен 10 mistakes to avoid in software development (“10 грешки, които да избягваме в софтуерното производство”), където цитират резултатите от едно проучване на Forrester Research, публикувани наскоро. Въпреки, че принципно съм съгласен с това, че списъкът представя едни от най-важните грешки, които могат да доведат всеки проект до неуспех, ще навляза в малко по-дълбоки детайли и ще коментирам всяка една от тях.

Ето го и самият списък с 10-те грешки, които трябва да избягваме при разработката на софтуер (Както и в други постове, не съм превел оригиналния текст, за да не бъда обвиняван в идиотски превод. Вярвам, че няма да се затрудните с това.):

Never committing to project success. Това е твърде очевидно и тривиално. Естествено е, че ако не си отдаден на успеха, няма да го постугнеш. Не виждам никаква мъдрост тук.
Freezing the schedule and budget before a project is sufficiently understood. За съжаление, това се случва винаги и навсякъде, особено у нас. Според мене, това е основният проблем на управлението на софтуерни проекти: какво да направим, когато ни питат за оценка на времето и цената, или пък ни карат да подпишем договор за това, при положение, че въобще не сме наясно какво точно трябва да се прави в даден проект?
Overscoping a solution. Да, това е грешка, но аз мисля, че тя се случва все по-рядко в наши дни.
Circumventing the application development organization altogether. Тук може би ще трябва да сложа някакъв превод, за да стане ясен и коментара ми. Доколкото знанията ми по английски се простират, това трябва да се преведе така: “Заобикаляне на организацията по разработка на приложения”. Не мисля, че това винаги е грешка, особено ако човек е наясно какво прави. Понякога даже е наложително да се прескочат всички правила, особено ако си бил “насаден” на проект от типа “Death March”. Истинският въпрос, все пак е: Можеш ли дори и при тези обстоятелства да доведеш проекта до успех?
Underestimating the complexity of a problem. Обикновено това е най-важната причина за подписване на договори с ниски бюджети и съкратени срокове. За съжаление, тази грешка най-често се прави от висшия мениджмънт, най-вече поради това, че не се консултират с екипа си (или му нямат доверие). Вярвам, че всяка компания трябва да инвестира повече време преди да подпише договор или да даде някакво обещание, през който период да се проведе задълбочено проучване на нуждите и проблемите на клиента, за да се придобие по-вярна представа за сложността на задачата.
Being stingy with subject-matter experts, in which their participation is not sufficient. Това е резултат от предишната грешка.
Choosing the wrong project leadership. Or the wrong leaders. Or the wrong managers. Or the wrong customers (Can there be wrong customers?) Без превод.
Distrusting managers who have had tasks delegated to them. Мисля, че липсата на доверие към когото и да е в една фирма или екип, е ключова грешка.
Jumping into development without enough research. Отново, това се случва поради подценяване на проблема, който трябва да се реши с дадения проект.
Suppressing bad news, in which dialogue is insufficient. Сучайно да познавате мениджър, който обича да чува лоши новини?

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

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

Класически грешки – Случаят "ГигаЛийз", Част 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.