Участники проекта меняют фреймворк, клиент хочет новую фичу, а лид разработки уходит из команды. Всё это — изменения, которые влияют на ход работ, мотивацию людей и качество продукта.
Рассказываем, что делать, если возникли сложности при управлении изменениями в проекте.
Рассказываем, что делать, если возникли сложности при управлении изменениями в проекте.
Содержание статьи:
Что может пойти не так в ходе проекта?
Меняется объём или бюджет проекта
Изменения в команде
Технические проблемы и потеря качества
Пошаговый план управления изменениями
Какие существуют подходы к управлению изменениями
Инструменты для эффективного управления изменениями
Как работать с изменениями в проекте — главное
Меняется объём или бюджет проекта
Изменения в команде
Технические проблемы и потеря качества
Пошаговый план управления изменениями
Какие существуют подходы к управлению изменениями
Инструменты для эффективного управления изменениями
Как работать с изменениями в проекте — главное
Что может пойти не так в ходе проекта?
В теории работа над продуктом выглядит, как движение по прямой из точки А — начала — в точку Б — конечный результат. На практике уже на старте могут поменяться задачи, состав команды, цели и технические решения. Вот примеры изменений, которые встречаются чаще всего.
Меняется объём или бюджет проекта
Почему так происходит?
Пример. Компания разрабатывает фитнес-приложение, клиент внезапно просит добавить функцию трекинг сна, которой не было в первоначальном ТЗ.
Объём работ увеличился, а вместе с ним и расходы. С клиентом согласовали дедлайн и доплату, и специалистам пришлось перераспределить ресурсы. В итоге, разработчики, занятые другими задачами, переключились на эту задачу. План работ изменился, бюджет вырос, а сроки сдвинулись.
- Заказчик даёт общие формулировки вместо чётких требований, а коллектив интерпретирует их по-своему.
- Клиент запрашивает дополнительные фичи, которых не было в техзадании.
- Меняются условия рынка или стратегии компании: повышается приоритет проекта для бизнеса и появляются дополнительные задачи.
- Из-за кризисов, пандемий или других внешних событий дорожают технологии, необходимые для проекта.
Пример. Компания разрабатывает фитнес-приложение, клиент внезапно просит добавить функцию трекинг сна, которой не было в первоначальном ТЗ.
Объём работ увеличился, а вместе с ним и расходы. С клиентом согласовали дедлайн и доплату, и специалистам пришлось перераспределить ресурсы. В итоге, разработчики, занятые другими задачами, переключились на эту задачу. План работ изменился, бюджет вырос, а сроки сдвинулись.
Изменения в команде
Почему так происходит?
Пример. При создании интеграции для 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 (Желание).
Разработчикам рассказали, как настроить окружение и использовать встроенные библиотеки для тестирования (Знание). При миграции тимлид помогал разбирать ошибки и решать проблемы с совместимостью (Способность).
После внедрения команду похвалили, чтобы новые подходы закрепились в работе (Подкрепление).
Инструменты для эффективного управления изменениями
Собрали список полезных сервисов, которые помогут проджекту и команде адаптироваться к изменениям и эффективно работать в новых условиях.
Канбан-доски
Визуализируют процесс управления изменениями в проекте и помогают делать всё поэтапно. Каждая задача перемещается между колонками в зависимости от статуса.
Системы управления проектами
С их помощью можно разделить крупные задачи на несколько шагов, назначить ответственного, управлять сроками, ресурсами, зависимостями между задачами и вести аналитику. Есть системы, которые поддерживают использование разных подходов, например, 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, кривая изменения Кюблер-Росс. С ними вы построите поэтапный процесс интеграции и смягчите реакцию команды на перемены.
- Если в проекте планируются перемены, сначала оцените их необходимость и возможные риски. Подумайте, помогут ли они продукту или можно обойтись без них.
- При работе с крупными изменениями контролируйте работу в новых условиях: составьте чёткий план, распределяйте задачи, отслеживайте процесс выполнения. Во время регулярных встреч обсуждайте возникающие проблемы и решайте их прямо во время разработки, чтобы они не повторялись и продукт вышел в стабильное состояние.
Читайте также:
