Путь камикадзе - [11]

Этот список далеко не полон. Kevin Huigens на одном из недавних совещаний предложил своей проектной команде устроить небольшой мозговой штурм, в ходе которого они попытались ответить на три моих вопроса:

1) Почему трезвомыслящие люди соглашаются участвовать в безнадёжном проекте?

2) Если ваш коллега собирается стать менеджером безнадёжного проекта, что бы вы посоветовали ему сделать?

3) Наоборот, что бы вы посоветовали ему не делать ни при каких обстоятельствах?

В результате были получены следующие ответы:

1. На первый вопрос:

* каждый хочет быть нужным;

* ожидаемые возможности;

* ожидаемые доходы;

* не могу позволить себе потерять работу;

* приглашение со стороны возглавить проект;

* желание преодолеть недоверие к себе;

* возможность поработать с новой технологией, невзирая на возможный провал проекта;

* обучение новой технологии в процессе работы;

* вечный оптимизм;

* вызов;

* явная глупость;

* шанс самоутвердиться;

* работу надо выполнять;

* это всего лишь проект;

* мой друг руководит проектом;

* мой брат руководит проектом (это ещё важнее, чем друг) ;

* мой босс сказал, что так надо;

* я не мыслю себе другой жизни;

* лучшего дела не существует;

* получение дивидендов по акциям;

* ожидание повышения зарплаты по сравнению с имеющейся;

* любовь слепа;

* формирование послужного списка;

* безразличие;

* чувство товарищества;

* ожидание, что проект продлится недолго.

2. На второй вопрос:

* оставь меня в покое;

* спасайся!

* будь внимателен;

* спроси: «Что я буду с этого иметь?»;

* перед началом проекта как следует отдохни;

* убедись, что можно полностью доверять всем своим сотрудникам;

* помни, что разработчики тебе не враги, враги – менеджеры;

* общение, общение и ещё раз общение;

* не раздувай проектную команду;

* нанимай молодых специалистов;

* береги свою команду;

* сделай так, чтобы к началу тестирования план тестирования был уже готов;

* сделай так, чтобы каждый хорошо понимал, чем он занимается;

* поддерживай документацию в актуальном состоянии;

* каждый должен иметь доступ к документации;

* проводи регулярно еженедельные совещания для обсуждения хода разработки;

* проводи совещания ежедневно;

* держи под рукой побольше хорошего кофе;

* команда всегда должна быть в хорошем настроении;

* обеспечь команду всем необходимым.

3. На третий вопрос:

* не планируй бракосочетание;

* не оставляй проблем, за которые непонятно кто отвечает;

* не позволяй слишком беспечно относиться к внесению изменений в проект;

* не думай, что первая версия будет и последней;

* не раздражайся и не злись;

* не теряй самообладания;

* не позволяй другим терять самообладание;

* не принимай слишком близко к сердцу успех или неудачу проекта;

* не слишком полагайся только на одного человека из команды;

* не относись слишком несерьёзно к распределению ресурсов;

* не думай, что команда способна понять весь проект в целом;

* если тебе что-то непонятно, не бойся спрашивать;

* не начинай проект сам;

* не начинай проект, если не хватает финансов для его завершения;

* не соглашайся на нереальные сроки;

* не бойся уйти из проекта, если видишь, что руководство ведёт себя неразумно;

* не будь слишком строг к низкооплачиваемым сотрудникам;

* не затягивай совещания больше, чем на 1,5 часа;

* не забывай о личной жизни;

* не бойся требовать от руководства то, что тебе необходимо;

* не бойся начальства;

* не забывай обновлять свой послужной список;

* не молись на так называемых экспертов;

* не забывай, что руководство ничего не смыслит в разработке ПО.

Естественно, все сказанное предполагает, что вы заранее знаете о безнадёжности проекта. Как отмечает эксперт Dave Kleist, это не так просто, когда вас интервьюируют по поводу новой работы:

… вряд ли можно где-нибудь увидеть объявление о найме для участия в безнадёжном проекте. Какой смысл спрашивать: «Хотите ли вы работать сверхурочно без какой-либо прибавки к зарплате?»… На самом деле, безнадёжные проекты редко объявляются таковыми во всеуслышание, и вам придётся достаточно долго проработать в нанявшей вас компании, прежде чем удастся обнаружить, что она обладает склонностью плодить безнадёжные проекты.

И, как отмечает Steve Benting (отвечая на те же три вопроса), иногда приходится сталкиваться с неприятными сюрпризами:

1) Первое время проект кажется довольно хорошо продуманным. У проекта есть лидер, есть реально заинтересованное лицо в руководстве, план выглядит достаточно солидным, а участники проекта – достаточно квалифицированными. В таком проекте действительно хочется работать. Но в один прекрасный момент все летит кувырком, потому что руководство увлеклось политическими играми, план основывался, как оказалось, на неверных предпосылках, и один или два ключевых разработчика вдруг закапризничали. Как ни старайся, невозможно полностью застраховаться от ошибок. Не хочется верить, что такое может повториться сначала. (Лично я участвовал в одном крупном проекте, но он закончился весьма неудачно. Срок завершения был перенесён с октября 1994 г. на март 1995 г. Я работал над планом действий в непредвиденных ситуациях до самого конца и ушёл вслед за большинством участников проекта в январе 1995 г. Новая система так до сих пор и не разработана. В настоящий момент компания пытается приобрести другую систему, которая не обладает и половиной требуемой первоначально функциональности.)