на виду и
непосредственно участвовал в ежедневном процессе, а не уподоблялся генералу, который получает ежедневные сводки с поля боя, находясь за много миль от него в тылу.
* Поскольку вполне вероятно, что ночной процесс ежедневного формирования версии потребует минимального человеческого вмешательства, будет полезным установить следующий порядок: любой программист, допустивший ошибку в коде, которая привела к аварийному завершению ежедневной сборки, удостаивается высокой чести наблюдать за очередной сборкой, пока не появится следующая жертва. Разумеется, такой порядок имеет как плюсы, так и минусы, но по крайней мере благодаря ему команда гораздо «ближе» знакомится с принципом ежедневной сборки проекта.
* Поручите одному из программистов, который обычно приходит в офис рано утром, проверять успешность завершения ежедневной сборки и вывешивать результаты на видное место. Если ни у кого нет желания или возможности появляться в офисе рано утром, наймите студента колледжа. Одна компания велела студенту поднимать над офисом флаг, чтобы таким образом предупреждать сотрудников, какой день ожидается: плохой или хороший. Зелёный флаг означал успешное завершение процесса ежедневной сборки, а красный – аварийное завершение.
Если управление требованиями – особенно определение приоритетов требований – является в безнадёжном проекте наиболее важным процессом, то вторым важнейшим процессом является управление рисками. Если бы понятие «риска» не было столь критическим, тогда мы не употребляли бы по отношению к проекту определение «безнадёжный». Интересно отметить, что один из вопросов «теста на алкоголь» связан с идентификацией проектных рисков, и если ответом на такой вопрос со стороны менеджера «нормального» проекта может быть удивлённый взгляд (даже если проект оказался в плачевном состоянии), то менеджер безнадёжного проекта скорее всего даст на такой вопрос чёткий и ясный ответ. Менеджер был бы просто глупцом, если бы он приступил к безнадёжному проекту, не имея какого-либо серьёзного представления об основных рисках и о том, как с ними бороться.
Увы, но в ходе проекта ситуация может выйти из-под контроля. Это происходит потому, что управление рисками строится в основном на эмоциях и инстинктах, а не на формальных процессах, и менеджер зачастую может просто не заметить вовремя появление новых рисков в ходе проекта. В лучшем случае будут устраняться риски, которые являются очевидными в самом начале проекта; в нормальной ситуации они будут поводом для беспокойства в течение всего проекта (например, риск ухода ключевого разработчика). Однако, могут неожиданно возникнуть совершенно новые риски, которых никто не ожидал, и поскольку команда обычно обладает слишком малым запасом прочности (в терминах плана, бюджета и ресурсов), эти риски могут оказаться для проекта убийственными.
