Расползание содержания: причины, примеры и как его предотвратить

Что такое расползание содержания?

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

PMI использует почти такую же формулировку в своём глоссарии, и это полезный тест: если работа добавлена, а базовый план по содержанию, расписание и бюджет не изменились, — у вас неконтролируемое расширение содержания.

Полезно различать два вида содержания. Содержание продукта — это характеристики и функции того, что вы создаёте, например сайта с поиском и оформлением заказа. Содержание проекта — это работа, необходимая для его создания: проектирование, разработка, тестирование, обучение и запуск. Неконтролируемое расширение может затронуть любое из них. Клиент, просящий добавить онлайн-чат, расширяет содержание продукта; спонсор, просящий команду заодно перенести архивные данные за десять лет, расширяет содержание проекта.

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

Это ещё и распространённое явление. Согласно отчёту PMI *Pulse of the Profession* 2018 года, в 52% проектов, завершённых за предыдущие 12 месяцев, наблюдалось неконтролируемое расширение содержания, тогда как пятью годами ранее — в 43%.

Наше руководство по содержание проекта объясняет, как изначально правильно определить содержание.

Scope creep, изменение содержания, «золочение» и разрастание функций

Не каждое изменение содержания — это scope creep. Проекты учатся по ходу дела, и утверждённые изменения, добавляющие ценность, — часть хорошего управления проектами. Разница — в контроле.

«Золочение» (gold plating) — это форма неконтролируемого расширения содержания, исходящая изнутри команды. Обычно намерения благие, но оно расходует время и бюджет, добавляет риски и может привнести дефекты в области, о которых заказчик даже не просил. Разрастание функций (feature creep) — термин из разработки продуктов для той же закономерности, с акцентом на продукте, а не на проекте.

Что вызывает неконтролируемое расширение содержания?

У неконтролируемого расширения содержания почти всегда несколько причин. Вот наиболее частые.

Неясное содержание и требования

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

Нет формального управления изменениями

Без определённого процесса управление изменениями нет согласованного способа сказать «да, и вот сколько это стоит». Запросы либо молча принимаются, либо неловко отклоняются, и молчаливые согласия превращаются в scope creep.

Заинтересованные стороны действуют в обход руководителя проекта

Запросы, отправленные напрямую дизайнеру или разработчику по почте, в чате или на совещании, минуют руководителя проекта. Сотрудник хочет помочь, выполняет работу, а план об этом так и не узнаёт.

«Золочение» и благие намерения

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

Длительные проекты и меняющиеся потребности бизнеса

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

Слабое спонсорство и коммерческое давление

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

Примеры неконтролируемого расширения содержания

Эти примеры показывают, как выглядит неконтролируемое расширение содержания в разных типах проектов. В каждом случае исходный запрос был разумным; проблема в том, что его так и не оценили с точки зрения сроков и стоимости.

Разобранный пример: как складываются мелкие запросы

Представьте 12-недельный проект по созданию сайта с фиксированной датой запуска. За шесть недель клиент просит о пяти «мелочах», каждая из которых согласована неформально:

• Дополнительная посадочная страница (3 дня).
• Форма подписки на рассылку, подключённая к их почтовой платформе (2 дня).
• Третий раунд правок дизайна главной страницы (3 дня).
• Настройка баннера cookie (1 день).
• Импорт 40 старых записей блога (4 дня).

Ни один из этих запросов сам по себе не выглядит значительным, но вместе они добавляют 13 рабочих дней — почти три недели — к 12-недельному плану. В расписании и бюджете ничего не изменилось, поэтому команда перерабатывает, тестирование сокращается, а запуск либо сдвигается, либо проходит с дефектами.

Теперь пропустим те же запросы через управление изменениями. Каждый регистрируется, его влияние показывается, и клиент делает выбор: посадочная страница и форма подписки утверждаются с продлением на одну неделю и дополнительным бюджетом; импорт блога переносится во второй этап; дополнительный раунд дизайна заменяет менее приоритетную страницу. Проект всё равно растёт, но растёт осознанно.

Последствия неконтролируемого расширения содержания

Неконтролируемое расширение содержания вредит проектам из-за тройного ограничения: содержание, сроки и стоимость связаны между собой. Если содержание растёт, а два других параметра не меняются, страдает что-то ещё — обычно качество или команда.

• Задержки сроков: дополнительная работа сдвигает вехи, и чаще всего первым её поглощает критический путь.
• Превышение бюджета: больше трудозатрат, материалов и расходов на поставщиков без бюджета на их покрытие.
• Снижение качества: тестирование, проверки и документация урезаются ради соблюдения срока.
• Выгорание команды: люди дольше работают над тем, чего нет ни в одном плане, и это подрывает мотивацию.
• Подорванное доверие: заинтересованные стороны удивляются сдвигу сроков, хотя сами просили о дополнениях.
• Отложенные выгоды: основная ценность проекта доходит до пользователей позже, чем могла бы.
• Ухудшение отчётности: процент выполнения теряет смысл, потому что базовый план больше не отражает реальную работу.

В коммерческих проектах есть дополнительная цена — неоплаченная работа. Агентства и консалтинговые компании, поглощающие расширение содержания, теряют маржу в каждом таком проекте.

Тревожные признаки неконтролируемого расширения содержания

С неконтролируемым расширением содержания проще всего справиться, если заметить его рано. Следите за такими сигналами:

• На доске или в табелях появляются задачи, которых нет в иерархической структуры работ.
• Запросы приходят по почте, в чате или на совещаниях, а не через согласованный канал приёма.
• Вы слышите фразы вроде «раз уж вы этим занимаетесь», «это займёт всего пять минут» или «мы думали, что это входит».
• Критерии приёмки переписываются после начала работ.
• Команда перерабатывает, но расписание не меняется.
• Результаты неделями остаются «почти готовыми».
• Линия содержания на диаграмме роста постоянно поднимается, или бэклог растёт быстрее, чем команда поставляет.
• Фактические трудозатраты значительно превышают оценки по хорошо понятным задачам.
• Заинтересованные стороны, не участвовавшие в планировании, начинают формировать решение на поздних этапах проекта.

Как предотвратить неконтролируемое расширение содержания

Профилактика в основном сводится к чёткому согласованию содержания и заблаговременному согласованию того, как будут обрабатываться изменения. Эти шаги работают в традиционных и гибридных проектах любого размера.

1. Согласуйте ясные цели. Запишите измеримые цели в устав проекта , чтобы каждый запрос можно было проверить на соответствие им: помогает ли он достичь цели?
2. Собирайте требования как следует. Привлекайте тех, кто будет пользоваться результатом, а не только тех, кто за него платит, и фиксируйте требованиям с приоритетами.
3. Составьте описание содержания с исключениями. Перечислите, что входит в содержание, и, что не менее важно, что не входит. Исключения предотвращают разговоры в духе «мы думали, что это входит».
4. Декомпозируйте работу. Приступите к созданию иерархической структуры работ и словарь WBS, чтобы всё содержание было на виду, а у каждого результат было определение.
5. Определите критерии приёмки. Для каждого результата согласуйте, как вы поймёте, что он готов. Сдвиг критериев приёмки — одна из самых незаметных форм неконтролируемого расширения содержания.
6. Получите утверждение и зафиксируйте базовый план. Попросите спонсора или клиента утвердить описание содержания, WBS и словарь WBS. Вместе они образуют базовый план по содержанию, относительно которого вы будете оценивать изменения.
7. Настройте управление изменениями до того, как оно понадобится. Согласуйте, как регистрируются запросы, кто их оценивает, кто утверждает и как обновляется план. Для небольших проектов сделайте процесс лёгким.
8. Создайте единый канал приёма. Попросите заинтересованные стороны направлять все запросы руководителю проекта или через форму запроса, а команду — вежливо перенаправлять запросы, поступающие в обход.
9. Регулярно общайтесь. Поддерживайте устойчивый ритм отчёты о статусе и обзоров, чтобы заинтересованные стороны видели прогресс и чувствовали, что их слышат, — это сокращает неформальные запросы.
10. Включите условия изменений в контракты. В работе с клиентами техническое задание должно описывать, как изменения запрашиваются, оцениваются по стоимости и утверждаются.

Именно шаблон содержания проекта охватывает цели, результаты, что входит и не входит в содержание, критерии приёмки, ограничения и допущения — то есть большую часть описанной выше подготовки в одном документе.

Управление изменениями — самый важный механизм контроля в этом списке.

Что делать, если расширение содержания уже происходит

Даже в хорошо спланированных проектах появляются новые запросы. Цель — не отказываться от изменений, а сделать каждое изменение видимым и осознанным.

Пошаговая реакция на новый запрос

1. Сделайте паузу, прежде чем соглашаться. Поблагодарите человека и скажите, что оцените влияние. Избегайте мгновенного «да» или «нет».
2. Зарегистрируйте его. Запишите запрос в журнал изменений или шаблон запроса на изменение: о чём просят, кто и зачем.
3. Сверьте с базовым планом. Действительно ли это что-то новое или уже покрывается существующим требованием или критерием приёмки?
4. Оцените влияние. Оцените воздействие на сроки, стоимость, ресурсы, качество и риски. Привлеките тех, кто будет выполнять работу.
5. Подготовьте варианты. Представьте реалистичные варианты выбора, а не единственный ответ (см. таблицу ниже).
6. Получите решение от нужного человека. Решение принимает спонсор, клиент или совет по изменениям, а не член команды, получивший запрос.
7. Обновите план. В случае утверждения обновите описание содержания, WBS, расписание, бюджет и реестр рисков, затем пересмотрите базовый план.
8. Сообщите о результате. Сообщите инициатору запроса, команде и другим заинтересованным сторонам, что решено и что это меняет.

Как сказать заинтересованной стороне «нет» (или «да, но»)

Прямой отказ может испортить отношения, особенно с клиентами и высшим руководством. Обычно лучше показать компромисс и дать лицу, принимающему решение, выбрать:

Ведите разговор в терминах целей проекта, а не личных предпочтений, и фиксируйте итог письменно. Наше руководство по управление заинтересованными сторонами рассказывает, как вести такие разговоры с разными типами заинтересованных сторон.

Неконтролируемое расширение содержания в Agile-проектах

Agile-подходы предполагают, что содержание будет меняться. Это не значит, что Agile-команды застрахованы от неконтролируемого расширения содержания; это значит, что изменения обрабатываются иначе.

В Scrum вся известная работа находится в Бэклог продукта, который упорядочивает Владелец продукта . Согласно Руководству по Scrum 2020 года, во время спринта не вносятся изменения, ставящие под угрозу Цель спринта, а объём работ можно уточнять и пересогласовывать с владельцем продукта по мере получения новых знаний. Поэтому новые идеи попадают в бэклог, а не напрямую к разработчику, и берутся в один из будущих спринтов на Планирование спринта , если они достаточно ценны.

Время и стоимость обычно фиксированы для каждой итерации, а содержание — переменная величина. Неконтролируемое расширение содержания в Agile выглядит иначе, чем в традиционном проекте:

• Заинтересованные стороны просят разработчиков втиснуть работу в текущий спринт.
• Цели спринта регулярно не достигаются, потому что незапланированная работа берётся посреди спринта.
• Бэклог растёт без упорядочивания и уточнения, поэтому ничему никогда не понижают приоритет.
• И дата релиза, и полный список функций считаются фиксированными.
• Понятие «готово» незаметно меняется, потому что нет общих критериям готовности (Definition of Done).

Диаграмма роста с отдельной линией содержания делает это видимым: если линия содержания поднимается так же быстро, как линия выполненной работы, дата релиза никогда не наступит. Здесь помогает и отслеживание скорости; см. наше руководство по диаграмма скорости в Agile.

Инструменты и шаблоны для контроля содержания

Для контроля содержания не нужно специализированное ПО, но несколько документов сильно облегчают задачу:

• Шаблон содержания проекта: цели, результаты, включения, исключения, критерии приёмки, ограничения и допущения.
• Шаблон запроса на изменение: форма запроса на изменение и журнал изменений с влиянием на содержание, сроки и стоимость.
• шаблон WBS: коды WBS, уровни, результаты, ответственные, трудозатраты и стоимость.
• Шаблон журнала RAID: риски, допущения, проблемы и зависимости, включая допущения, от которых зависит содержание.
• Шаблон документа бизнес-требований: требования и приоритеты, согласованные до начала разработки.

ПО для управления проектами помогает, когда запросы поступают от многих людей. Формы запросов, процессы согласования и видимый базовый план сокращают работу в обход. Инструмент №1 в нашем рейтинге, Wrike, хорошо подходит командам, которым нужны структурированные формы запросов и согласования в нескольких проектах; с этим хорошо справляются и другие инструменты, как объясняют наши рейтинги ПО для управления проектами .

Типичные ошибки, которых стоит избегать

• Считать любые изменения плохими. Отказ на каждый запрос раздражает заинтересованные стороны и может привести к тому, что проект поставит то, что никому не нужно. Контролируйте изменения, а не блокируйте их.
• Принимать устные согласования. Если это не записано, позже это запомнят по-разному.
• Игнорировать мелкие изменения. Разобранный выше пример показывает, как мелкие незафиксированные запросы превращаются в недели работы.
• Не указывать исключения. Описание содержания без списка того, что не входит, провоцирует домыслы.
• Позволять команде заниматься «золочением». Оцените намерение, но направляйте дополнительные идеи в запросы на изменение или в бэклог.
• Утверждать изменения без пересмотра базового плана. Если план не обновлён, отчёты о прогрессе вводят в заблуждение.
• Делать процесс слишком тяжеловесным. Десятистраничная форма для изменения на один день побуждает людей обходить процесс. Масштабируйте процесс под размер изменения.

Чтобы увидеть более широкую картину того, чем управление изменениями в проекте отличается от организационных изменений, прочитайте управление организационными изменениями и контроль изменений.

Бесплатные шаблоны по этой теме

Все шаблоны

Частые вопросы