Команда меняет фреймворк, клиент хочет новую фичу, а лид разработки уходит. Всё это — изменения, которые влияют на ход проекта, мотивацию людей и качество продукта.
Рассказываем, что делать, если что-то пошло не по плану.
Рассказываем, что делать, если что-то пошло не по плану.
Что может пойти не так в ходе проекта?
В теории работа над проектом выглядит как движение по прямой из точки А, начала, в точку Б — конечный результат. На практике уже на старте могут поменяться задачи, состав команды, цели и технические решения. Вот примеры изменений, которые встречаются чаще всего.
Меняется объём или бюджет проекта
Почему так происходит?
Пример. Компания разрабатывает фитнес-приложение, клиент внезапно просит добавить функцию трекинг сна, которой не было в первоначальном ТЗ.
Объём работ увеличился, а вместе с ним и расходы. С клиентом согласовали дедлайн и доплату, и команде пришлось перераспределить ресурсы: разработчики, занятые другими задачами, переключились на этот проект. В итоге изменился план работ, вырос бюджет, а сроки сдвинулись.
- Заказчик даёт общие формулировки вместо чётких требований, а команда интерпретирует их по-своему.
- Клиент запрашивает дополнительные фичи, которых не было в техзадании.
- Меняются условия рынка или стратегии компании: повышается приоритет проекта для бизнеса, и появляются дополнительные задачи.
- Из-за кризисов, пандемий или других внешних событий дорожают технологии, необходимые для проекта.
Пример. Компания разрабатывает фитнес-приложение, клиент внезапно просит добавить функцию трекинг сна, которой не было в первоначальном ТЗ.
Объём работ увеличился, а вместе с ним и расходы. С клиентом согласовали дедлайн и доплату, и команде пришлось перераспределить ресурсы: разработчики, занятые другими задачами, переключились на этот проект. В итоге изменился план работ, вырос бюджет, а сроки сдвинулись.
Изменения в команде
Почему так происходит?
Пример. В проекте по созданию интеграции для e-commerce платформы ушёл ведущий бэкенд-разработчик. Это замедлило работу: новому специалисту нужно было время, чтобы войти в курс дела. Проджект-менеджер выделил самые важные задачи и перераспределил работу внутри команды, чтобы сократить задержки.
- Ключевые сотрудники переходят на другие проекты или увольняются.
- Нужно больше специалистов, чтобы сделать конкретную задачу.
Пример. В проекте по созданию интеграции для e-commerce платформы ушёл ведущий бэкенд-разработчик. Это замедлило работу: новому специалисту нужно было время, чтобы войти в курс дела. Проджект-менеджер выделил самые важные задачи и перераспределил работу внутри команды, чтобы сократить задержки.
Технические проблемы и потеря качества
Почему так происходит?
Пример. Компания разрабатывала облачную платформу и столкнулась с несовместимостью между базой данных и API. Для решения проблемы привлекли архитектора из другого проекта. Чтобы уложиться в сроки и выпустить продукт раньше конкурентов, пропустили несколько этапов тестирования.
Тимлиду пришлось перестроить рабочий процесс: одни специалисты исправляли ключевые ошибки, другие продолжали работу над основной функциональностью.
- Команда работает с новым или непроверенным оборудованием.
- В команде недостаточно специалистов с нужной технической экспертизой.
- Из-за сжатых сроков сокращают или пропускают этапы тестирования.
- Нет чётких процессов контроля качества.
- У сотрудников мало времени или ресурсов для устранения ошибок.
Пример. Компания разрабатывала облачную платформу и столкнулась с несовместимостью между базой данных и API. Для решения проблемы привлекли архитектора из другого проекта. Чтобы уложиться в сроки и выпустить продукт раньше конкурентов, пропустили несколько этапов тестирования.
Тимлиду пришлось перестроить рабочий процесс: одни специалисты исправляли ключевые ошибки, другие продолжали работу над основной функциональностью.
Пошаговый план управления изменениями
Мы создали понятную инструкцию управления организационными изменениями с этапами и распределением ролей. Её легко взять за основу и настроить под задачи вашей команды и подход к управлению проектами.
Взяли для примера ситуацию: компания разрабатывает приложение для доставки продуктов из супермаркета. Неожиданно клиент просит добавить новую фичу — голосового помощника для составления списка покупок.
Взяли для примера ситуацию: компания разрабатывает приложение для доставки продуктов из супермаркета. Неожиданно клиент просит добавить новую фичу — голосового помощника для составления списка покупок.
Этап 1: соберите и проанализируйте информацию
На этом этапе важно выяснить, обязательно ли принимать изменение или можно обойтись без него. А ещё оценить, как новые условия повлияют на проект.
Что делать?
Если реализация голосового помощника может сильно затянуть релиз, попробуйте предложить клиенту перенести функцию в следующую версию.
Обосновать это можно так:
Результат: если клиент соглашается перенести фичу, команда сможет сосредоточиться на основных работах. Если он настаивает на изменении, вы уже подготовлены: собраны данные, рассчитаны риски, и команда понимает, как встроить задачу в проект.
Что делать?
- Соберите данные о ситуации. Узнайте у клиента, зачем нужна новая фича, какой результат он ожидает и почему она важна сейчас.
- Опросите команду, чтобы понять их мнение о возможных сложностях, сроках и нагрузке.
- Рассчитайте затраты: сколько времени и ресурсов потребуется для реализации.
- Оцените технические риски: нужно ли менять архитектуру приложения или дорабатывать существующие модули.
Если реализация голосового помощника может сильно затянуть релиз, попробуйте предложить клиенту перенести функцию в следующую версию.
Обосновать это можно так:
- Покажите, как текущие задачи проекта влияют на сроки запуска и почему важно сначала выпустить основные функции. Например, объясните, что доставка продуктов — ключевая часть приложения, и задержка её релиза снизит конкурентные преимущества.
- Укажите на дополнительные затраты и риски, если изменения вводятся в середине разработки. Например, может потребоваться переработка кода и дополнительное тестирование.
- Подчеркните, что фича будет более ценной, если её проработать глубже и интегрировать в следующем релизе. Это даст время для анализа пользовательских запросов и улучшения идеи.
Результат: если клиент соглашается перенести фичу, команда сможет сосредоточиться на основных работах. Если он настаивает на изменении, вы уже подготовлены: собраны данные, рассчитаны риски, и команда понимает, как встроить задачу в проект.
Этап 2: обсудите изменения с командой
Если на предыдущем этапе вы выяснили, что от изменений отказаться нельзя, важно организовать обсуждение с проектной командой. На этом этапе нужно оценить, как новые условия повлияют на работу, и составить чёткий план действий.
Что делать?
Что делать?
- Проведите встречу с командой. Расскажите, почему изменения необходимы, какие задачи они решают и как повлияют на проект. Например, объясните, что клиент ожидает видеть голосового помощника в ближайшем релизе, потому что это может привлечь больше пользователей.
- Вместе с командой определите, какие шаги нужно выполнить для реализации фичи. Например, кто будет разрабатывать интерфейс, кто займётся интеграцией, а кто протестирует.
- Обсудите, потребуется ли перераспределение задач, привлечение дополнительных специалистов или изменение графика.
- Уточните, какие сложности могут возникнуть при добавлении фичи. Например, это может быть переработка существующего кода или увеличение нагрузки на тестировщиков.
- Согласуйте новые дедлайны для реализации фичи, чтобы не сорвать общий график проекта.
Этап 3: внедрите изменения
Здесь начинается реализация задачи. Важно следить за ходом работы, поддерживать команду и оперативно устранять проблемы, чтобы изменения не затягивали проект.
Что делать?
Что делать?
- Убедитесь, что, каждый знает, какую часть фичи он разрабатывает и как она интегрируется с остальными модулями.
- Проводите короткие встречи для обсуждения статуса задачи, выявления сложностей и предотвращения задержек. Например, если разработчики сталкиваются с проблемами в работе API, подключайте специалистов, которые помогут их решить.
- Если возникают препятствия, такие как отсутствие нужных данных или инструментов, решайте их как можно быстрее. Например, договаривайтесь о дополнительном времени с клиентом или предоставляйте доступ к необходимым ресурсам.
- Убедитесь, что команда регулярно тестирует новый функционал, чтобы избежать багов.
Этап 4: разберите ошибки и продумайте план улучшений
После завершения работы важно понять, что прошло хорошо, а что можно было улучшить. Это поможет избежать тех же проблем в будущем и сделать работу команды более эффективной.
Что делать?
Что делать?
- Проведите встречу с командой, чтобы обсудить, как прошёл процесс внедрения. Обсудите, что вызвало сложности и что можно было сделать лучше.
- Разберите ключевые ошибки и выясните их причины. Например, из-за чего возникли задержки или почему какие-то задачи оказались сложнее, чем ожидалось.
- Попросите команду предложить идеи для улучшения. Это поможет увидеть проблему с разных сторон.
- Составьте список шагов, которые можно внедрить в следующем проекте, чтобы улучшить процессы. Например, добавьте больше времени на тестирование или заранее уточняйте задачи с клиентом.
Кто может участвовать в процессе?
Вот общий список сотрудников, которые могут работать с рисками в разных проектах. Сколько людей должны вовлекаться и принимать решения, зависит от масштаба проекта и предлагаемых изменений.
Проджект-менеджер
Управляет всеми процессами, координирует связь команды с клиентом, анализирует информацию, контролирует выполнение задач и разбирает результаты.
Архитектор
Оценивает влияние изменений на архитектуру проекта, определяет технические риски (например, перегрузка серверов) и предлагает способы их минимизации. Создаёт архитектурный план, консультирует разработчиков и следит за ходом работ.
Тимлиды
Распределяют задачи в команде, контролируют рабочий процесс и помогают решать технические проблемы.
Scrum Master
Следит за соблюдением Agile-методов, помогает команде адаптироваться к новым процессам и закрепить их на практике. Эту роль привлекают, если компания использует фреймворк Scrum в рамках подхода Agile.
Управляет всеми процессами, координирует связь команды с клиентом, анализирует информацию, контролирует выполнение задач и разбирает результаты.
Архитектор
Оценивает влияние изменений на архитектуру проекта, определяет технические риски (например, перегрузка серверов) и предлагает способы их минимизации. Создаёт архитектурный план, консультирует разработчиков и следит за ходом работ.
Тимлиды
Распределяют задачи в команде, контролируют рабочий процесс и помогают решать технические проблемы.
Scrum Master
Следит за соблюдением Agile-методов, помогает команде адаптироваться к новым процессам и закрепить их на практике. Эту роль привлекают, если компания использует фреймворк Scrum в рамках подхода Agile.
Какие существуют подходы к управлению изменениями
Есть много готовых моделей, которые помогают команде принять изменения в несколько этапов и встроить их в рабочий процесс. Расскажем кратко о самых популярных из них.
Модель Джона Коттера
Она состоит из восьми шагов:
Пример. Компания внедряет новый сервис для управления проектами, чтобы лучше контролировать сроки и бюджет. На старте провели анализ процессов и показали команде проблемы, чтобы создать ощущение срочности.
За процесс отвечали проджект-менеджер и тимлиды, которые поддерживали изменения на каждом этапе. Они сформулировали цели и создали пошаговый план. Затем рассказали сотрудникам, почему новый сервис будет полезен для проекта. На этапе тестирования отметили первые победы — сокращение времени на планирование, и это повысило мотивацию команды.
После внедрения программу начали использовать во всех проектах и процессах, и вскоре им стали пользоваться большинство отделов компании.
Модель Курта Левина
Модель Джона Коттера
Она состоит из восьми шагов:
- Создание чувства срочности — объяснить, зачем нужны перемены, и показать их важность.
- Формирование команды лидеров — собрать инициативных сотрудников, которые поддержат изменения.
- Разработка видения и стратегии — создать план изменений и определить их цели.
- Донесение видения — чётко и понятно объяснить цели и стратегию всем сотрудникам.
- Устранение преград — убрать барьеры, которые мешают внедрению изменений.
- Закрепление краткосрочных побед — зафиксировать первые успехи, чтобы мотивировать команду.
- Укрепление достигнутых изменений — перенести изменения на другие процессы и закрепить успехи.
- Закрепление изменений в культуре — сделать их частью повседневной работы.
Пример. Компания внедряет новый сервис для управления проектами, чтобы лучше контролировать сроки и бюджет. На старте провели анализ процессов и показали команде проблемы, чтобы создать ощущение срочности.
За процесс отвечали проджект-менеджер и тимлиды, которые поддерживали изменения на каждом этапе. Они сформулировали цели и создали пошаговый план. Затем рассказали сотрудникам, почему новый сервис будет полезен для проекта. На этапе тестирования отметили первые победы — сокращение времени на планирование, и это повысило мотивацию команды.
После внедрения программу начали использовать во всех проектах и процессах, и вскоре им стали пользоваться большинство отделов компании.
Модель Курта Левина
Суть модели в том, чтобы разделить управление изменениями в организации на три этапа. Первый — Размораживание: подготовка команды к переменам; второй — Изменение: процесс введения нового; и третий — Замораживание: укрепление произошедших изменений.
Пример. Тимлид решает улучшить процесс код-ревью, чтобы ускорить работу команды и повысить качество кода. Во время «размораживания» он анализирует проблемы: проверки занимают слишком много времени, а комментарии бывают непонятными.
Затем он объясняет команде, почему нужно это исправить. На этапе «изменений» вводятся новые правила: срочные задачи нужно проверять быстрее, а комментарии оставлять по единой структуре.
На стадии «замораживания» новый процесс закрепляется в команде, и он становится частью повседневной работы. Сотрудники следуют новым правилам, и процесс код-ревью проходит быстрее.
Модель ADKAR
Состоит из пяти шагов:
Пример. Команде нужно перейти на новую версию фреймворка. Лид объяснил, что старая версия тормозила при больших объёмах запросов (Осознание). Затем показал, что обновление ускоряет обработку данных и добавляет удобные инструменты для API (Желание).
Разработчикам рассказали, как настроить окружение и использовать встроенные библиотеки для тестирования (Знание). При миграции тимлид помогал разбирать ошибки и решать проблемы с совместимостью (Способность).
После внедрения команду похвалили, чтобы новые подходы закрепились в работе (Подкрепление).
Пример. Тимлид решает улучшить процесс код-ревью, чтобы ускорить работу команды и повысить качество кода. Во время «размораживания» он анализирует проблемы: проверки занимают слишком много времени, а комментарии бывают непонятными.
Затем он объясняет команде, почему нужно это исправить. На этапе «изменений» вводятся новые правила: срочные задачи нужно проверять быстрее, а комментарии оставлять по единой структуре.
На стадии «замораживания» новый процесс закрепляется в команде, и он становится частью повседневной работы. Сотрудники следуют новым правилам, и процесс код-ревью проходит быстрее.
Модель ADKAR
Состоит из пяти шагов:
- Осознание (Awareness) — объяснить, почему изменения необходимы, и показать их значимость.
- Желание (Desire) — мотивировать сотрудников принять изменения и участвовать в их реализации.
- Знание (Knowledge) — обучить людей, что нужно делать и как работать по-новому.
- Способность (Ability) — помочь команде применять полученные знания на практике.
- Подкрепление (Reinforcement) — закрепить новые привычки и процессы, чтобы изменения стали частью повседневной работы.
Пример. Команде нужно перейти на новую версию фреймворка. Лид объяснил, что старая версия тормозила при больших объёмах запросов (Осознание). Затем показал, что обновление ускоряет обработку данных и добавляет удобные инструменты для API (Желание).
Разработчикам рассказали, как настроить окружение и использовать встроенные библиотеки для тестирования (Знание). При миграции тимлид помогал разбирать ошибки и решать проблемы с совместимостью (Способность).
После внедрения команду похвалили, чтобы новые подходы закрепились в работе (Подкрепление).
Инструменты для эффективного управления изменениями
Собрали список полезных сервисов, которые помогут проджекту и команде адаптироваться к изменениям и эффективно работать в новых условиях.
Канбан-доски
Визуализируют процесс управления изменениями в проекте и помогают делать всё поэтапно. Каждая задача перемещается между колонками в зависимости от статуса. To do (Сделать) — отправная колонка задачи, где она находится до того, как над ней начали работать. In progress (В работе) — колонка с задачами, которые выполняют сейчас. Review (Проверка) — колонка для сделанных задач, ожидающих утверждения либо того, кто её поставил, либо лида направления. Done (Сделано) — колонка для завершённых задач.
Системы управления проектами
С их помощью можно разделить крупные задачи на несколько шагов, назначить ответственного, управлять сроками, ресурсами, зависимостями между задачами и вести аналитику. Есть системы, которые поддерживают использование разных подходов, например, Agile и Waterfall, что делает работу с ними гибкой.
Тайм-трекеры
Помогут оценить воздействие новых условий на работу. Например, с их помощью можно понять, сколько времени команда потратила на устранение багов при работе над новой функцией. Или сравнить, как быстро выполняются одни и те же задачи в старых и новых условиях, допустим, если проект перешёл на обновлённый фреймворк.
Ещё тайм-трекеры позволяют отследить, кто из команды больше загружен, чтобы перераспределить ресурсы и освободить сотрудника от части задач или дать ему ментора в помощь.
Система контроля версий — для IT-проектов
Эти инструменты помогают управлять изменениями в коде: сохранять историю, откатываться к предыдущим версиям и работать над проектом всей командой.
Для чего нужны:
Пример. Разработчики создают отдельную ветку для новой функции, тестируют её, а потом объединяют с основной. Если функция не работает, её можно легко удалить и вернуть всё как было.
Популярные системы: Git, Mercurial, Subversion.
Системы управления знаниями
Minerva Knowledge — система управления знаниями, пространство для совместной работы и создания контента. В ней команда может вести чёткую и понятную документацию по проекту, которая в дальнейшем станет основой для базы знаний службы поддержки. Это поможет специалистам быстро находить нужную информацию и давать пользователям точные ответы.
Также на платформе есть свой редактор, который поддерживает разметку Markdown, диаграммы Draw.io, PlantUML и макросы. С помощью этих инструментов документация становится не только понятной, но и функциональной: они помогают анализировать данные, планировать процессы и делиться информацией внутри команды.
Канбан-доски
Визуализируют процесс управления изменениями в проекте и помогают делать всё поэтапно. Каждая задача перемещается между колонками в зависимости от статуса. To do (Сделать) — отправная колонка задачи, где она находится до того, как над ней начали работать. In progress (В работе) — колонка с задачами, которые выполняют сейчас. Review (Проверка) — колонка для сделанных задач, ожидающих утверждения либо того, кто её поставил, либо лида направления. Done (Сделано) — колонка для завершённых задач.
Системы управления проектами
С их помощью можно разделить крупные задачи на несколько шагов, назначить ответственного, управлять сроками, ресурсами, зависимостями между задачами и вести аналитику. Есть системы, которые поддерживают использование разных подходов, например, Agile и Waterfall, что делает работу с ними гибкой.
Тайм-трекеры
Помогут оценить воздействие новых условий на работу. Например, с их помощью можно понять, сколько времени команда потратила на устранение багов при работе над новой функцией. Или сравнить, как быстро выполняются одни и те же задачи в старых и новых условиях, допустим, если проект перешёл на обновлённый фреймворк.
Ещё тайм-трекеры позволяют отследить, кто из команды больше загружен, чтобы перераспределить ресурсы и освободить сотрудника от части задач или дать ему ментора в помощь.
Система контроля версий — для IT-проектов
Эти инструменты помогают управлять изменениями в коде: сохранять историю, откатываться к предыдущим версиям и работать над проектом всей командой.
Для чего нужны:
- Вносить большие изменения без риска повредить основной код.
- Быстро возвращаться к стабильной версии, если что-то пошло не так.
- Находить ошибки, сравнивая текущий код с предыдущими версиями.
Пример. Разработчики создают отдельную ветку для новой функции, тестируют её, а потом объединяют с основной. Если функция не работает, её можно легко удалить и вернуть всё как было.
Популярные системы: Git, Mercurial, Subversion.
Системы управления знаниями
Minerva Knowledge — система управления знаниями, пространство для совместной работы и создания контента. В ней команда может вести чёткую и понятную документацию по проекту, которая в дальнейшем станет основой для базы знаний службы поддержки. Это поможет специалистам быстро находить нужную информацию и давать пользователям точные ответы.
Также на платформе есть свой редактор, который поддерживает разметку Markdown, диаграммы Draw.io, PlantUML и макросы. С помощью этих инструментов документация становится не только понятной, но и функциональной: они помогают анализировать данные, планировать процессы и делиться информацией внутри команды.
Как работать с изменениями в проекте — главное
- Управление изменениями это то, с чем сталкивается каждый проект на пути к результату. Только в теории работа над продуктом — прямой путь без форс-мажоров. С проектом произойти может что угодно, от увеличения масштаба до потери качества и ухода ключевых сотрудников. Важно использовать основные методы управления изменениями и встраивать их в процесс.
- Эффективно работать с новыми условиями помогут готовые модели, такие как модель Джона Коттера, модель Курта Левина, ADKAR, кривая изменения Кюблер-Росс. С ними вы построите поэтапный процесс интеграции и смягчите реакцию команды на перемены.
- Если в проекте планируются изменения, сначала оцените их необходимость и возможные риски. Подумайте, помогут ли они продукту или можно обойтись без них.
- При работе с крупными изменениями контролируйте работу в новых условиях: составьте чёткий план, распределяйте задачи, отслеживайте процесс выполнения. Во время регулярных встреч обсуждайте возникающие проблемы и решайте их прямо во время работы над проектом, чтобы они не повторялись и продукт вышел в стабильное состояние.
- Используйте полезные сервисы, которые помогут проще справиться с форс-мажорами на проекте и организовать работу команды в новых условиях. Например, канбан-доски, системы управления проектами, тайм-трекеры, системы контроля версий, системы управления знаниями.
