Скотт Беркун - Сделано

Большинство проектов по разработке находятся примерно посередине. Есть предварительное планирование, однако с учетом изменчивости требований клиентов работа делится на этапы со своими сроками проектирования, реализации и проверки качества. Если возникнет новая проблема, ее можно рассмотреть на текущем этапе работы или отложить в «корзину» и уделить ей внимание уже на следующей фазе.

В большинстве проектов время изначального планирования используется, чтобы получить необходимую информацию от клиентов и бизнес-аналитиков и определить, сколько этапов будет в проекте и чему их посвятить (рис. 2.2): выделить больше времени на проектирование или тестирование, разбить каждый на две небольшие фазы (в соответствии с Agile) или же объединить (монолитный подход). Однако во всех случаях следует предусмотреть время на анализ изменений. Сюда входит решение проблем, которые возникли на предыдущем этапе и им не смогли уделить должного внимания.

Рис. 2.2.Масштабный проект представляет собой последовательность небольших проектов

Вот и все по поводу методологии планирования. В главе 14и главе 15мы поговорим о том, как управлять проектом, однако сделаем акцент на функциях менеджера и лидера, а не на подробном применении конкретной методологии. Если вы прочитали последние два параграфа (даже если вы не согласны с моим мнением), то советы из главы 14и главы 15будут актуальны и полезны для вас независимо от того, как вы организуете или планируете свой проект.

В любом случае я извиняюсь перед всеми ветеранами разработки, которые потеряли сознание или почувствовали приступ тошноты во время чтения этого раздела. Он закончился, и я обещаю, что этот облегченный и упрощенный подход к графикам – практически все, что нужно для понимания изложенных ниже концепций.

Графики проекта – извечный козел отпущений за все, что может пойти не так. Если кто-то ошибется с расчетом или прогнозом, не выполнит требования, даже если кого-то собьет автобус, – во всем виноват график (и тот, кто за него отвечает). Если электричество отключат во всей стране на десять дней или лучшие программисты команды заразятся чумой, кто-то обязательно скажет: «Вот видите, я же говорил, что график сорвется», – и ткнет пальцем в того, кто его составлял. Это абсолютно несправедливо, но происходит постоянно. Несмотря на всю свою ненависть к графикам, люди предъявляют к ним завышенные требования. Даже лучшие графики в мире, с лучшими умами и лучшими инструментами, – это всего лишь попытка прогнозировать будущее, а человеку она редко удается.

Если команда приступает к проекту, осознавая вероятные причины, по которым график может сорваться, и предпринимает определенные действия, чтобы свести эти риски к минимуму, график станет гораздо более полезным и точным инструментом процесса разработки.

Если график составляется на этапе изначального планирования, сотни решений, которые могут повлиять на него, еще не приняты. Будут трудности и вопросы, которые никто не способен предугадать, и на раннем этапе ориентировочного плана невозможно их учесть. Пока люди не поймут требования и не приступят к проектировке, у менеджера проекта слишком мало информации для реалистичных прогнозов. Однако зачастую черновой график составляют с выдуманными цифрами и совершенно дикими прогнозами, и это «соломенное чучело» вручают команде под видом надежного плана проекта. Его авторы часто становятся жертвами стремления к детализации (вместо того чтобы бросить все силы на достоверность): впечатляющий график с конкретными датами и сроками (детализация) далеко не всегда отражает реальное положение дел (достоверность). Детализация – довольно простая задача, в отличие от достоверности.

Однако все проекты и графики действительно должны с чего-то начинаться. Метод «пальцем в небо» тоже можно использовать – чтобы вдохновить команду и установить определенные границы. Так можно начать процесс анализа и исследования, чтобы конкретизировать график, поднять важные вопросы и ответить на них. Но если в основу графика легли непроверенные и неизученные залихватские предположения, причем без дальнейшей корректировки, вы сильно рискуете. Факты говорят о том, что любому человеку сложно рассчитать необходимое время на раннем этапе проекта.