- Название анти-паттерна: Убийственное планирование
- Также известен как: План-колпак, План-деталемания
- Уровень, на котором чаще всего встречается: Предприятие
- Название решения, направленного на улучшение: Рациональное планирование
- Тип решения, направленного на улучшение: Процесс
- Основные причины: жадность, безграмотность, спешка.
- Неуравновешенные силы: Управление глубиной алгоритма
- Примеры из жизни:
«Нам нельзя начинать до тех, пока не будет расширенного плана работы». «Успех зависит только от плана». «Пока мы следуем плану и неукоснительно соблюдаем его пункты, нам сопутствует успех». «У нас есть план, нужно просто его придерживаться».
Предпосылки
Во многих видах корпоративной культуры детальное планирование - это само собою разумеющееся в любом проекте. Это допущение работает с индустриальными процессами и другими типами проектов, но не обязательно с проектами по разработке ПО, которые включают много видов деятельности хаотичной и заранее неизвестной по своей природе. Убийственное планирование имеет место в случае, когда к детализированному планированию программных проектов относятся с излишним рвением.
Общая форма
Многие проекты терпят фиаско по причине чрезмерного планирования. Чрезмерное планирование часто возникает, как результат мониторинга затрат и слежения за персоналом. Эти два типа чрезмерного планирования известны под названиями «План-колпак» и «План-деталемания». «План колпак» - это подкласс «Плана-деталемании», в нём (чрезмерное) планирование прекращается в начале проекта. В «Плане-деталемании» чрезмерное планирование продолжается до тех пор, пока проект не прекращает своё существование из-за множества невыполнимых требований.
План-колпак
Зачастую, план созданный в начале проекта, всегда рассматривается, как безошибочное текущее видение проекта, даже несмотря на полное отсутствие корректировки. Подобная практика предоставляет руководству «красивое виденье» результата ещё до того, как сам проект начался. Однако, когда план не оценивается критически и не получает поправок, то он стремительно становится некорректным в ходе проекта.
Это обманчивое представление часто усугубляется отсутствием точной информации о прогрессе, которую зачастую получают только после того, как критический результат отстаёт по расписанию.
Рисунок ниже демонстрирует план проекта, созданный до запуска самого проекта. Управленцы полагают, что план автоматически обеспечит результат такой, какой он представлен в плане, и без необходимого оперативного вмешательства и менеджмента.
План-деталемания
Иногда хорошим подходом к достижению конечного результата считается тщательный контроль, который осуществляется посредством постоянного планирования, требующего внимания как управленцев, так и бoльшей части старших разработчиков.
Подобный подход к решению проблемы иногда разворачивается в древесную структуру планов, которая касается второстепенных (и маловажных) деталей. Возможность так близко рассмотреть мелкие детали плана производит впечатление полного контроля над проектом.
Симптомы и последствия
Симптомы плана-колпака поначалу могут встретиться и в плане-деталемании.
План-колпак
Обычно, среди его симптомов встречается хотя бы один из нижеприведённых:
- Неспособность планировать прагматически.
- Фокус внимания приходится скорее на расходы, чем на конечный результат.
- Достаточно жадности, чтобы разбирать каждую мелочь до тех пор, пока проект финансируется.
Последствия следуют по нарастающей:
- Незнание ситуации с развитием проекта. У плана нет смысла и контроль конечного результата слабеет с ходом времени. Проект будет как опережать предполагаемый результат, так и отставать от него, и чего-либо определённого никто сказать не сможет.
- Невозможность предоставить критичный результат (итоговый результат).
Последствия данного плана следуют по нарастающей до тех пор, пока проект не исчерпает себя. Далее варианты такие:
- Дальнейшее вложение капитала.
- Антикризисное управление проектом.
- Прекращение проекта.
- Возможная потеря ключевых специалистов.
План-деталемания
Его симптомы – надмножество подобных у плана-колпака:
- Неспособность планировать прагматически.
- Фокус внимания приходится скорее на расходы, чем на конечный результат.
- На планирование, составление плана прогресса и перепланирование уходит больше времени, чем на само производство ПО:
- Менеджер проекта планирует работу проекта.
- Руководители групп планируют работу команд и разработчиков.
- Разработчики разбивают работу на задачи.
Последствия переплетены и берут начало одно в другом:
- Каждый планирующий должен на уровне своего плана следить за прогрессом и фиксировать его, и так далее.
- Бесконечное планирование с перепланированием влечёт за собой последующее планирование и перепланирование.
- Цель сдвигается с выпуска ПО на выработку множества планов. Руководство предполагает, что прогресс будет эквивалентен производимому мониторингу затрат и вложенного труда. На деле, прямой связи здесь нет.
- Повторяющиеся отсрочки выпуска ПО и последующий провал проекта.
Стандартные причины
Главными источниками возникновения плана-колпака и плана-деталемании являются: отсутствие прагматичного, здравого подхода к планированию и расписанию, а также сбор данных о прогрессе.
План-колпак
- Отсутствие актуального плана с датами выпуска ключевых компонентов ПО.
- Незнание основных принципов управления проектом.
- Чрезмерно усердное планирование в начале, в попытке принуждением получить абсолютный контроль над развитием проекта.
- Выпуск рекламы для подписания контракта.
План-деталемания
- Слишком усердное постоянное планирование, с целью принуждением получить абсолютный контроль над развитием проекта.
- Планирование выступает основным занятием проекта..
- Принудительное соответствие требованиям заказчика по проекту.
- Принудительное соответствие требованиям исполнительного руководства.
Что можно противопоставить
Аналитический паралич, увы, ситуация неприемлемая.
Решения для улучшения
Выход из ситуации с планом-колпаком и планом-деталеманией один. В проекте плана должны быть обозначены основные конечные результаты (как бы много команд не было задействовано в проекте). Следует указать конечные цели на двух уровнях:
- Продукт(ов). Проданные покупателю рабочие продукты, в которых учтены внутренние требования использующего их бизнеса.
- Компоненты (самих продуктов). Базовые технологические решения, нужные для поддержки работы бизнеса.
Конечные результаты включают следующее:
- Постановка бизнес-цели
- Техническое задание
- Критерий приемлемости, поддающийся измерению
- Варианты сценариев использования товара
- Варианты использования компонентов
Для подтверждения соответствия каждого компонента определённым требованиям план следует дополнить следующими проверочными ориентирами:
- Одобрение концептуального проекта
- Одобрение дизайна перечня требований
- Одобрение дизайна реализации ПО
- Одобрение плана тестирования
Для того, чтобы убедиться в том, что планирование адекватное, а действия руководства исключают риски, связанные с реализацией проекта, планы поставок нужно актуализировать каждую неделю. Это позволяет своевременно, должным образом реагировать на проблемы, риски, а касательно терминов – на задержки и опережение выпуска определённого продукта.
Слежение производится на установленном уровне полноты. Иногда это предполагает снижение уровня полноты, внесённого в план в предыдущий период времени. Полнота данных должна предоставляться в валовом виде, а не в точном, и например, с шагом отображения в 25 процентов, а не в 5 процентов.
Для эффективного зрительного представления конечных целей, привязанных дат и взаимозависимостей можно использовать диаграмму Ганта. Сопоставление с базовым планом делает очевидным следующие состояния конечных целей:
- Точно по расписанию.
- Сдали.
- Опережение (с приблизительной новой датой сдачи).
- Запаздывание (с приблизительной новой датой сдачи).
Важно описывать состояние услуги пораньше и пореже. Иначе, возможность отслеживать изменения теряется. Последующие работы/задания/конечные цели должны иметь между собой проставленные зависимости (в случае, если эти зависимости есть).
При расчётах рекомендуется добавить времени на неминуемые непредсказуемые события, такие как:
- Возрастание требований (медленное продвижение).
- Тупики в разработке.
- «Заплатки» стороннего программного обеспечения.
- Идентификация дефектов (нахождение проблемы в наборе компонентов программного обеспечения).
- Устранение дефекта (устранение ошибки).
Также, важно установить минимальный период времени для выполнения любой работы. Это предотвращает возникновение требований вроде «написать код «простой» программы и протестировать её за пару дней».
Вариации
Есть варианты убийственного планирования, которые отличаются по глубине детализации и могут варьировать от определения основных проверочных ориентиров (обычно связанных со стадиями финансирования/утверждения), до микро-целей в стадиях выпуска относительно каждой команды.
Эти вариации встречаются как в плане-колпаке, так и в плане-деталемании:
- Вариации в финансировании (см. рисунок выше)
- Вариации в микро-целях (см. рисунок ниже)
Единственное отличие плана деталемании от микро-целевой версии плана колпака состоит в том, что последний никогда не корректируется. Он показывает крайне второстепенные конечные цели, которые невозможно полностью уяснить до начала осуществления проекта. Следовательно, любые прогнозы, должны быть, по определению, неверны, по причине недостатка какого-либо настоящего понимания ПО, которое предстоит создать. Такой тип плана обычно создаётся технически одарёнными любителями. Хоть задания и нужно ясно знать, но если включать их в план – то результатом станет не создание программы, а лишь бесполезное планирование и отслеживание (в случае в планом-деталеманией).
Пример
Эти примеры взяты из нашего личного горького жизненного опыта.
План-колпак
В этом примере, допустим, организация, занимающаяся системной интеграцией, решает создать связующее ПО, которое ещё не создают основные поставщики (хотя международные стандарты были выпущены уже как год назад). Эта же организация для получения финансовых ресурсов принимает детальный план поставок ещё до начала каких-либо плановых работ. Этот план построен на предположениях работников, которые не создавали ПО «в боевых условиях».
В технической точки зрения этот план весьма точен, а прогнозы весьма оптимистичны. Менеджер проекта постоянно руководствуется им, но сам план никем не обновляется и, следовательно, не отражает фактических трудозатрат.
Это приводит к сдвигу дат сдачи. Налицо полное отсутствие сведений касательно реальных достижений в проекте. Организация, занимающаяся системной интеграцией получает уведомление о срыве даты сдачи лишь после наступления самой даты. На рисунке ниже показана выдержка из подобного проекта разработки.
План-деталемания
В попытке контролировать разработку и утвердить полный контроль, организация-конечный потребитель создаёт трёхуровневый план:
- фазы развития.
- задачи и усилия команды.
- задачи и усилия членов команды.
Рисунок ниже показывает сложность алгоритма данного плана.
Деталемания уводит от плана тем, что требует сильно много внимания и этим отвлекает внимание от сдачи системы. Это приводит к значительному спаду продуктивности коллектива. Плановое управление переходит в разряд фантастики из-за своей сложности.
Решение - заменить развёрнутый план таким, который отображал бы ключевые цели в связи с датами, вместе с зависимостями и временными ограничениями. Если не уложились к дате сдачи – значит случилось нечто важное. Предыдущий нереалистичный план тщетно фиксировал прогресс в виде усилий: Усилие = коллектив Х трудодни. И что? Хоть E = MC2, но эта формула не породит ядерную энергию!
Схожие решения
Анти-паттерн Аналитический Паралич может усугубить последствия Убийственного Планирования. Если фаза анализа затягивается относительно назначенного расписания, то или срываются сроки, или к последующим фазам применяются несоответствующие модели анализа.
Применимость к другим масштабам и точкам зрения
Убийственное планирование неприменимо по отношению к хаотичной (бурной) природе разработки ПО, поскольку оно приводит к значительному рассогласованию между моделями планирования управления и реальностью процесса разработки.
Архитекторам и разработчикам порою приходится вести двойной образ жизни: с одной стороны они должны показывать желание работать согласно плану проекта, а с другой - они могут столкнуться с реальным положением дел в ПО (и эта реальность не согласуется с моделью управления). Например, план может заставлять разработчиков заявлять о готовности программного модуля ещё до фактической готовности самого модуля. Это влечёт последующие проблемы со сборкой и тестированием системы.
| 
