PM Stories » Steve McConnell

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

Майк Рам — 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, 09 Jul 2009 05:10:59 +0000

Компанията Construx, собственост на един големите гурута на софтуерния бизнес – Steve McConnell – е разработила доста обемиста анкета за проучване на добрите и полезни практики в разработването на софтуер – като се тръгне от събирането и анализа на изискванията, мине се през писането на код и тестването и се стигне до управлението на проекти. Авторът призовава всички, които се занимават в тази област да отделят малко време и да се включат в изследването, за да може по-късно събраните данни от всички участници да ни покажат кое е наистина полезно като практика и върши работа, и кое – не.

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

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

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

Гласувайте за тази статия в 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 (който вече не съществува), посветен на отношението на лидера / мениджъра към хората от своя екип. Тя защитава тезата, че откритостта и честността са най-правилните методи за комуникация и за управление на екипа, включително и когато се налага да отправим критика.

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

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

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

Гласувайте за тази статия в 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 или по имейл

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

5 Въпроса към Steve McConnell относно Agile Development

Майк Рам — Sat, 13 Oct 2007 12:49:00 +0000

Steve McConnell е публикувал в своя блог 5 въпроса, зададени му от PM*Boulevard на интервю, посветено на Agile Development, както и неговите отговори.

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

Това, което е най-ценно за мен в интервюто на Стив МакКонъл, е въпрос #3: къде методите на Agile Development са най-добре приложими и къде – не. Според него, най-ефективно могат да се прилагат Agile принципите при фирми, които правят вътрешни проекти, поради ограничението на бюджета на годишна база и ограничения екип, който разработва проектите. В такъв тип компании е най-лесно да се привлече представител на “клиента” към софтуерния екип, което е едно от важните изисквания на Agile методологиите, защото този “клиент” е служител на същата фирма.

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

Като цяло, McConnell отчита изключителната полезност на някои отделно взети практики, които вече се “приемат на въоръжение” в почти всички project management методологии, което напълно обезсмисля религиозния фанатизъм, с който някои от лидерите на гъвкавите подходи рекламираха своите продукти.

В статията има и линк към една негова презентация, в която доста по-детайлно са анализирани различните особености на по-популярните Agile методологии и тяхното действително приемане в практиката. Steve McConnell е консултант с огромен опит и богата клиентска база, така че неговите впечатления относно практическите ползи от гъвкавите практики са изключително ценни.