Ни один план не выдерживает встречи с противником.

Методы двух предыдущих разделов обеспечили подбор ресурсов и создание описания продукта (бэклога). Теперь предстоит решить следующую задачу: организовать использование ресурсов таким образом, чтобы в результате появился реальный продукт.

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

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

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

1. Содержание.

2. Процесс.

3. Персонал.

4. Стейкхолдеры.

5. Коммуникации.

6. Закупки.

7. Стоимость.

8. Качество.

Разумеется, это выделение достаточно условно и служит исключительно для удобства поиска тех или иных методов в ситуации, когда у ПМ возникает проблема в какой-то конкретной области. На практике применение всех методов, описанных в данном разделе, требуется от ПМ постоянно, каждый день и не по одному разу. Пример: сетевой график (диаграмма Ганта, PERT, «критический путь») необходимо пересчитывать каждый раз, когда изменяется оценка продолжительности хотя бы одной задачи проекта (а такие изменения происходят чуть ли не ежечасно). Иначе получится как у Джеффа Сазерленда («Революционный метод управления проектами»): «Сколько проектов шло по диаграмме Ганта?» – «Ни одного».

Чтобы в общем понимать, что значит управлять разработкой, можно использовать метафору самолета. Вы находитесь в кабине, оснащенной огромным количеством приборов, и показания каждого из них влияют на конечный результат. Высота ниже нуля? Вы разбились. Скорость меньше плановой? Вы опаздываете. Перерасход топлива? Вы вообще не долетите, если не найдете способ дозаправиться в воздухе. Все приборы нужно контролировать одновременно и быстро реагировать на показания, приводящие к потенциальным неприятностям. Так вот, далее мы опишем основные «приборы», на которые нужно смотреть в ходе разработки.