Путь камикадзе [Смертельный марш]

С другой стороны, некоторые разработчики (и менеджеры) с радостью соглашаются участвовать в таких проектах; спрашивается, почему же (не считая наивных оптимистов) нормальный здравомыслящий человек добровольно соглашается участвовать в проекте, где ему, скорее всего, придётся работать 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, это не так просто, когда вас интервьюируют по поводу новой работы: