Как бы тщательно мы ни планировали проект, что-нибудь всё равно изменится. Клиент принесёт новые вводные, команда найдёт более удачное решение, сроки сдвинутся, или появится проблема, которую сложно было предусмотреть.
И это нормально 😉 Если правильно управлять изменениями, у команды получится вовремя реагировать на новые требования и обстоятельства, корректировать работу и при этом не терять из виду сроки, бюджет и цель проекта.
Что такое управление изменениями в проекте
— это поправка к первоначальному плану, который команда согласовала с клиентом или другими заинтересованными сторонами. Оно может затронуть сроки, бюджет, задачи, состав команды, процессы или итоговый результат
Например, клиент попросил добавить новую функцию, перенести релиз или подключить к проекту более опытного специалиста. Кажется, что поменялась всего одна деталь, но она может потянуть за собой остальные: новая функция потребует времени разработчика, сроки увеличатся, а вместе с ними вырастет бюджет.
Причём проект редко меняется резко и за один раз. Чаще небольшие правки накапливаются постепенно. Каждая сама по себе кажется незначительной, а к концу проекта оказывается, что команда делает уже совсем не то, о чём договаривалась на старте.
Какие изменения возникают в проекте
Чтобы управлять изменениями, сначала нужно договориться, что вообще считать изменением. Иначе команда будет либо согласовывать каждую мелочь, либо незаметно менять проект, не оценивая последствия.
Изменения, которые затрагивают базовый план
Базовый план фиксирует, что команда должна сделать, к какому сроку, за какой бюджет и с каким уровнем качества. Если новая просьба меняет эти договорённости, её нужно оформить и согласовать.
К таким изменениям относятся:
- добавить или удалить функции
- перенести сроки и этапы
- увеличить или сократить бюджет
- изменить состав команды или ключевые роли
- появились новые требования к безопасности, качеству или стандартам
Главное — не оставлять согласованные изменения в переписке или на созвоне. Их стоит сразу переносить туда, где команда ведёт проект. Например, в Weeek можно обновить задачи, сроки, ответственных и описание работ, чтобы у всех участников была одна актуальная версия плана.
Изменения внутри команды
Не каждую доработку надо отдельно согласовывать. Иногда команда меняет способ работы, а договорённости с клиентом остаются прежними.
Например, можно подробнее разбить задачу на подзадачи, выбрать другой технический подход, иначе распределить работу внутри этапа или уточнить оценку после новых данных.
Главный вопрос тот же: изменится ли то, что обещали клиенту или другим заинтересованным сторонам? Если нет, скорее всего, перед нами обычный рабочий момент.
Срочные и несрочные изменения
Не все изменения могут ждать одинаково долго. Срочные нужны, когда медлить нельзя и есть риск: возникла проблема с безопасностью, появилось новое требование закона или под угрозой важное обязательство перед клиентом. Такие вопросы стоит рассматривать быстрее обычного и сразу назначать человека, который примет решение.
Остальные изменения — новые функции, улучшения, дополнительные пожелания — можно провести через стандартный процесс: оценить пользу, сроки, ресурсы и приоритет.
Если изменение реально срочное, согласование можно сократить. Хватит минимума: что меняем, кто принимает решение и какие последствия/риски принимаем
При этом ограничения проекта никуда не исчезают: если времени стало меньше, придётся добавить ресурсы, сократить объём или принять больший риск. После этого стоит обновить план проекта и разобраться, почему решение пришлось принимать в таком режиме
Принцип довольно простой: в срочной ситуации можно ускорить принятие решения, но нельзя отменить само решение и ответственность за его последствия
Как оценить влияние изменения на проект
Перед тем как согласовать изменение, проверь, что оно потянет за собой. Даже небольшое исправление может повлиять на сроки, бюджет или загрузку команды.
Смотри на пять вещей:
- Объём работ. Появятся ли новые задачи или придётся переделать уже готовые?
- Сроки. Сдвинется ли дедлайн проекта или отдельных этапов?
- Ресурсы и бюджет. Кто возьмёт новую работу и хватит ли на неё времени и денег?
- Зависимости. Какие другие задачи, команды или проекты затронет изменение?
- Риски. Может ли правка привести к новым ошибкам, задержкам или проблемам с качеством?
Например, клиент просит добавить экспорт отчёта в CSV. Сама функция кажется небольшой, но для неё нужны разработка, изменения интерфейса и тестирование. Разработчики уже заняты другими задачами. Значит, команда должна либо перенести менее важную функцию, либо сдвинуть срок релиза, либо выделить дополнительные ресурсы.
В итоге оценка должна отвечать на простой вопрос: чем проект заплатит за это изменение? Сроками, бюджетом, ресурсами, другой задачей — или ничем существенным. Если цена понятна, принять решение гораздо проще.
Сначала нужно разобраться, откуда берётся эта неопределённость: что мы уже понимаем, чего пока не знаем и какие части проекта затронет изменение. После этого можно дать вилку и обозначить допущения
Если неизвестного всё ещё слишком много, правильнее сначала оценить небольшой этап исследования, который поможет снизить неопределённость, и только потом считать основную работу
Хорошая оценка — не обязательно одна цифра. Важно показать, что уже известно, где пока остаются предположения и при каких условиях стоимость может измениться
Чем проектные изменения отличаются от организационных
Здесь легко запутаться, потому что в обоих случаях речь идёт об изменениях. Разница — в объекте управления.
В проекте нужно решить, что именно поменять и как это повлияет на работу. Добавить ли новую функцию, сколько времени она займёт, нужен ли дополнительный бюджет и кто её согласует. После решения команда обновляет план, чтобы все работали по актуальной версии.
Организационные изменения больше связаны с людьми. Здесь важно объяснить, зачем нужны новые правила, подготовить сотрудников, обучить их и помочь встроить изменения в повседневную работу.
Эти процессы дополняют друг друга. Можно отлично спланировать изменение проекта, но провалить его, если команда не понимает, как теперь работать. И наоборот: одной хорошей коммуникации недостаточно, если никто не оценил влияние изменений на сроки, бюджет и результат.
🤔 Задач становится больше, а общей картины — меньше
Как собрать проекты, сроки и приоритеты, чтобы важное не терялось в потоке дел →Классические модели управления изменениями
Если изменение заметно влияет на работу команды, одного обновлённого плана может быть мало. Новые требования, роли или процессы нужно ещё встроить в ежедневную работу. Для этого можно использовать классические модели управления изменениями. Они появились для организационных трансформаций, но отдельные принципы пригодятся и внутри проектов.
Модель Курта Левина
Модель делит изменения на три этапа: подготовка, переход к новому и закрепление результата.
- Разморозка. Сначала объясни команде, почему старый план больше не работает. Например, после тестирования продукта выяснилось, что пользователям нужна другая логика сценария, поэтому часть уже запланированных задач придётся пересмотреть
- Изменение. Команда начинает работать по новому плану: меняет задачи, роли или привычный процесс. На этом этапе важно быстро отвечать на вопросы и следить, где возникают сложности
- Заморозка. Когда новый подход заработал, закрепи его: обнови документацию, шаблоны и правила работы, чтобы команда не возвращалась к старой версии проекта
Модель хорошо подходит для крупных изменений с понятным переходом из состояния «было» в «стало». Для проектов, где требования меняются постоянно, она менее удобна: закрепить процесс окончательно получается далеко не всегда.
Модель ADKAR
ADKAR помогает посмотреть на изменение глазами отдельного участника команды. В ней пять этапов:
- Осознание (Awareness). Сотрудник понимает, почему проект меняется
-
Желание (Desire). Видит смысл поддержать новый подход, а не продолжать работать по-старому
- Знания (Knowledge). Понимает, что теперь нужно делать иначе
- Умение (Ability). Может применить новые правила в реальной работе
- Закрепление (Reinforcement). Новый способ работы становится привычным
Например, команда меняет процесс согласования макетов после постоянных задержек со стороны клиента. Недостаточно просто объявить новую схему. Дизайнеру и менеджеру нужно понимать, зачем она появилась, где теперь фиксировать комментарии и что делать, если клиент не отвечает вовремя.
Модель Коттера
Модель Коттера больше подходит для крупных изменений, которые затрагивают много людей и требуют долгой перестройки.
Сначала нужно показать проблему и объяснить, почему действовать нужно сейчас. Затем подключить ключевых участников проекта, сформулировать понятную цель и рассказать о ней всей команде. После этого — убрать препятствия, получить первые результаты, распространить удачный подход и закрепить его.
🖍️ Коттер даёт подробную дорожную карту, но для небольших изменений внутри проекта восемь шагов могут оказаться избыточными
Модель 7S McKinsey
7S помогает проверить, не забыли ли вы что-то важное при крупном изменении. Она рассматривает проект или организацию как систему из семи связанных элементов: стратегии, структуры, процессов, навыков, ценностей, стиля управления и людей.
Представим, что проект резко вырос и вместо одной небольшой команды над ним начинают работать три отдела. Просто добавить новых людей недостаточно. Нужно проверить, изменились ли роли, хватает ли компетенций, подходят ли текущие инструменты, кто принимает решения и одинаково ли все понимают цель проекта.
Процесс управления изменениями в проекте
Теперь мы знаем, какие изменения бывают и как их оценивать. Пора пройтись по процессу — его можно разбить на семь шагов.
1. Отправить запрос на изменение
Частая ошибка — бежать выполнять работу после сообщения клиента «А давайте вот это ещё сделаем». Железобетонное правило — запрос надо зафиксировать.
Опиши, что именно нужно изменить, зачем это нужно, какой результат ожидается, кто предложил изменение и насколько оно срочное. На этом же этапе можно предварительно отметить, на что оно способно повлиять.
Например, вместо «Добавить экспорт» запрос будет звучать конкретнее: «Добавить экспорт отчёта в CSV, чтобы пользователи могли работать с данными вне системы. Желаемый срок — следующий релиз».
При этом не стоит решать за клиента. Задача эксперта — объяснить последствия каждого варианта и дать рекомендацию, а клиент уже выбирает приемлемый компромисс
2. Зафиксировать и отслеживать
Все запросы лучше хранить в одном месте: либо в документе, либо в таск-менеджере. Для каждого можно указать название, автора, дату, статус, ответственного за решение и итог.
Так проще понять, что происходит с запросом, кто должен принять решение и почему команда в итоге выбрала именно этот вариант. А ещё не придётся через месяц заново обсуждать вопрос, который уже однажды закрыли.
В Weeek можно создать отдельный проект по изменениям. Одна задача = одно изменение, двигай её по колонкам, чтобы всегда видеть статус.
В карточке задачи указывай приоритет изменения, добавляй ссылку на нужные документы и тегай ответственного.
Если изменение будет принято, внутри карточки задачи создай подзадачи. Их потом можно раскидать по другим проектам, например в разработку.
3. Провести анализ
Теперь нужно понять, во что изменение обойдётся проекту. Сначала посмотри на объём работ. Что придётся добавить, убрать или переделать? Например, экспорт в CSV — новая функция, а изменение текста на кнопке обычно остаётся в рамках текущего объёма.
Затем проверь сроки. Возможно, новая функция сдвинет релиз на неделю или заставит перенести менее важную задачу на следующий цикл.
После этого оцени затраты и ресурсы. Нужны ли дополнительные деньги, лицензии или облачные мощности? Есть ли у команды свободные специалисты? Если для экспорта нужны бэкенд-разработчик, фронтендер и тестировщик, а они уже заняты, придётся менять сроки или приоритеты.
Не забудь про риски и зависимости. Новая функция может затронуть безопасность данных или зависеть от другой команды, которая пока не закончила свою часть работы.
Мы посмотрели, где возникают задержки, и поняли, что проблема не в скорости команды, а в процессе управления задачами. Поэтому собрали проекты в одной системе, зафиксировали правила приоритизации, ответственных и статусы, а также договорились, какие задачи действительно считаются срочными
В результате стало меньше внеплановых переключений и ручных уточнений, а сроки стали предсказуемее. Для меня это хороший пример изменения, которое сработало потому, что команда стала тратить меньше времени на управление процессом и больше — на саму работу
4. Проанализировать и принять решение
Изменение стоит принять, если его польза оправдывает затраты и у команды есть ресурсы. Отклонить — если оно не помогает достичь цели, несёт слишком большой риск или пока сформулировано слишком размыто. Ещё один вариант — отложить хорошую идею до лучших времён.
Например, команда решает добавить экспорт в CSV в следующем релизе, а менее приоритетное улучшение — перенести. Так новая функция не сдвинет общий срок.
Само решение и его причину лучше зафиксировать. Через несколько месяцев не придётся вспоминать, почему команда поступила именно так.
5. Обновить базовый план проекта
Изменение нужно добавить в рабочий план. Иначе команда продолжит ориентироваться на старую версию.
Проверь, что изменилось в требованиях, сроках, бюджете, загрузке команды и рисках. Если экспорт перенесли в следующий релиз, он должен появиться в дорожной карте и плане цикла.
6. Внедрить изменения
Теперь изменение можно превратить в работу: разбить на задачи, назначить ответственных и сроки, добавить в нужный спринт или этап проекта. Например, для экспорта в CSV понадобятся отдельные задачи на API, интерфейс, права доступа, тестирование и документацию.
7. Подтвердить и закрыть
Когда работа закончена, проверь, соответствует ли результат договорённостям. Зафиксируй, что именно сделали и когда, как проверили результат и появились ли новые риски или задержки. Добавь ссылки на связанные задачи и документы. После этого запрос можно закрывать.
Как подготовить команду к изменениям
Допустим, команда уже работает над проектом, но клиент просит добавить новую функцию. После оценки оказалось, что объём работ вырастет, часть задач придётся перенести, а разработчикам — изменить текущий план.
Просто добавить новых задач не прокатит. Команда должна понимать, что изменилось, почему и как это повлияет на её работу.
Объясни, почему меняется проект
Сначала дай команде контекст. Недостаточно написать «клиент попросил добавить экспорт», по-хорошему бы объяснить, зачем это нужно и почему решили принять изменение.
Можешь использовать универсальный шаблон: что произошло → почему меняем план → что решили → что это значит для команды.
Покажи, что именно изменится
Команде важно понимать последствия для своей работы. Какие задачи добавились или исчезли? Поменялись ли сроки? Кто теперь за что отвечает? Какие задачи стали приоритетнее? Лучше сразу обновить план проекта, задачи, дедлайны и зависимости.
Не добавляй новую работу поверх старой
Если объём проекта вырос, нужно решить, чем команда за это заплатит: перенесёт часть задач, увеличит срок, подключит дополнительных специалистов или пересмотрит объём работ.
Дать безопасное пространство для вопросов
Даже небольшое изменение может сильно изменить работу конкретного специалиста. Поэтому после объявления нового плана дай команде возможность задать вопросы и обозначить риски.
🖍️ И главное — не оставляй команду в двух реальностях. Если проект изменился, старые приоритеты, сроки и задачи тоже нужно пересмотреть. Иначе новая работа просто добавится к прежней, а изменения закончатся выгоранием команды
Часто проблема начинается ещё на этапе обсуждения, когда решение принимают без тех, кого оно затронет напрямую. Если спустя несколько недель команда всё ещё больше обсуждает само изменение, чем работает по новым правилам, значит, оно так и не встроилось в процессы. Хорошо проведённое изменение, наоборот, со временем делает работу понятнее и снижает зависимость от руководителя
