Я лучше уволюсь».
Очевидно, некоторые разработчики и, вероятно, ещё в большей степени менеджеры возразят, что такой вариант им практически не подходит. Далее мы вкратце поговорим на эту тему, а сейчас важно отметить, что это одна из нескольких возможных «негативных» причин участия в безнадёжном проекте; в этом нет ничего особенно хорошего, но, возможно, альтернативы ещё хуже.
С другой стороны, некоторые разработчики (и менеджеры) с радостью соглашаются участвовать в таких проектах; спрашивается, почему же (не считая наивных оптимистов) нормальный здравомыслящий человек добровольно соглашается участвовать в проекте, где ему, скорее всего, придётся работать 14 часов в день, 7 дней в неделю и год или два без отпуска?
Наиболее распространённые причины приведены в табл. 1.2, ниже они будут подробно обсуждаться.

Таблица 1.2 Причины участия в безнадёжных проектах


Этот список далеко не полон. Kevin Huigens на одном из недавних совещаний предложил своей проектной команде устроить небольшой мозговой штурм, в ходе которого они попытались ответить на три моих вопроса:
1) Почему трезвомыслящие люди соглашаются участвовать в безнадёжном проекте?
2) Если ваш коллега собирается стать менеджером безнадёжного проекта, что бы вы посоветовали ему сделать?
3) Наоборот, что бы вы посоветовали ему не делать ни при каких обстоятельствах?

В результате были получены следующие ответы:
1. На первый вопрос:
1) каждый хочет быть нужным;
2) ожидаемые возможности;
3) ожидаемые доходы;
4) не могу позволить себе потерять работу;
5) приглашение со стороны возглавить проект;
6) желание преодолеть недоверие к себе;
7) возможность поработать с новой технологией, невзирая на возможный провал проекта;
8) обучение новой технологии в процессе работы;
9) вечный оптимизм;
10) вызов;
11) явная глупость;
12) шанс самоутвердиться;
13) работу надо выполнять;
14) это всего лишь проект;
15) мой друг руководит проектом;
16) мой брат руководит проектом (это ещё важнее, чем друг) ;
17) мой босс сказал, что так надо;
18) я не мыслю себе другой жизни;
19) лучшего дела не существует;
20) получение дивидендов по акциям;
21) ожидание повышения зарплаты по сравнению с имеющейся;
22) любовь слепа;
23) формирование послужного списка;
24) безразличие;
25) чувство товарищества;
26) ожидание, что проект продлится недолго.

2. На второй вопрос:
27) оставь меня в покое;
28) спасайся!
29) будь внимателен;
30) спроси: «Что я буду с этого иметь?»;
31) перед началом проекта как следует отдохни;
32) убедись, что можно полностью доверять всем своим сотрудникам;
33) помни, что разработчики тебе не враги, враги — менеджеры;
34) общение, общение и ещё раз общение;
35) не раздувай проектную команду;
36) нанимай молодых специалистов;
37) береги свою команду;
38) сделай так, чтобы к началу тестирования план тестирования был уже готов;
39) сделай так, чтобы каждый хорошо понимал, чем он занимается;
40) поддерживай документацию в актуальном состоянии;
41) каждый должен иметь доступ к документации;
42) проводи регулярно еженедельные совещания для обсуждения хода разработки;
43) проводи совещания ежедневно;
44) держи под рукой побольше хорошего кофе;
45) команда всегда должна быть в хорошем настроении;
46) обеспечь команду всем необходимым.

3. На третий вопрос:
47) не планируй бракосочетание;
48) не оставляй проблем, за которые непонятно кто отвечает;
49) не позволяй слишком беспечно относиться к внесению изменений в проект;
50) не думай, что первая версия будет и последней;
51) не раздражайся и не злись;
52) не теряй самообладания;
53) не позволяй другим терять самообладание;
54) не принимай слишком близко к сердцу успех или неудачу проекта;
55) не слишком полагайся только на одного человека из команды;
56) не относись слишком несерьёзно к распределению ресурсов;
57) не думай, что команда способна понять весь проект в целом;
58) если тебе что-то непонятно, не бойся спрашивать;
59) не начинай проект сам;
60) не начинай проект, если не хватает финансов для его завершения;
61) не соглашайся на нереальные сроки;
62) не бойся уйти из проекта, если видишь, что руководство ведёт себя неразумно;
63) не будь слишком строг к низкооплачиваемым сотрудникам;
64) не затягивай совещания больше, чем на 1,5 часа;
65) не забывай о личной жизни;
66) не бойся требовать от руководства то, что тебе необходимо;
67) не бойся начальства;
68) не забывай обновлять свой послужной список;
69) не молись на так называемых экспертов;
70) не забывай, что руководство ничего не смыслит в разработке ПО.

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

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

И, как отмечает Steve Benting (отвечая на те же три вопроса), иногда приходится сталкиваться с неприятными сюрпризами:
1) Первое время проект кажется довольно хорошо продуманным. У проекта есть лидер, есть реально заинтересованное лицо в руководстве, план выглядит достаточно солидным, а участники проекта —
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71