Как мы улучшили прогнозируемость и управляемость проектов в IT-компании? Кейс30.09.2024 07:15

Меня пригласили как эксперта по внедрению гибких подходов управления в одну IT-компанию, занимающуюся разработкой решений в сфере B2B. Основная задача заключалась в том, чтобы настроить процессы управления проектами, сделать их предсказуемыми и управляемыми. До начала сотрудничества компания сталкивалась с множеством проблем: сроки регулярно срывались, клиенты были недовольны, проекты могли «висеть» в работе до 8 месяцев без завершения, а команда испытывала серьезные перегрузки из-за параллельной работы над несколькими задачами.

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

Этап 1: Визуализация работы

Первым шагом в решении задачи было создание прозрачности процессов. Мы начали с визуализации всей текущей работы на kanban-доске. Этот шаг оказался особенно важным, так как именно визуализация помогла быстро понять основные проблемы компании.

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

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

Этап 2: Ограничение одновременно выполняемой работы

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

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

Этап 3: Выравнивание потока задач с производительностью команды

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

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

Этап 4: Создание двух Kanban-досок

Для эффективного управления работой мы создали две отдельные kanban-доски:

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

• Вторая доска предназначалась для команд разработки и отображала пользовательские истории, которые необходимо было реализовать в рамках каждого проекта. На этой доске мы также ввели ограничение на количество задач, выполняемых одновременно. Ежедневные встречи команды проводились именно на этой доске, где обсуждался план на день и фокус команды. Это позволило оперативно видеть, где происходят задержки и какие задачи требуют вмешательства.

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

Этап 5: Сбор статистики и улучшение прогнозирования

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

Прозрачная система позволила нам сразу увидеть узкие места в процессе. Например, оказалось, что одно из главных узких мест было в тестировании. Разработка шла быстро, но многие задачи «застревали» на этапе тестирования. Это стало первым шагом к формированию списка улучшений, которые мы постепенно внедряли в процесс.

Результаты

В результате проведенных изменений удалось добиться следующих улучшений:

1. Прогнозируемость поставок. Удалось достичь предсказуемых поставок проектов с 90% вероятностью. Сроки завершения проекта теперь варьировались от 2 до 4 месяцев в зависимости от объема работы, но самое важное — команда могла с уверенностью прогнозировать дату завершения проекта. Раньше проекты могли «висеть» в работе до 8 месяцев, что приводило к недовольству заказчиков.

2. Прозрачность процесса разработки. Прозрачность процесса разработки выросла с 4 до 9 по 10-балльной шкале. Это было подтверждено срезом до и после, который я провел в виде опросов среди участников команды и менеджмента.

3. Упрощение внесения изменений. Благодаря регулярному подключению заказчиков каждые 2–3 недели, внесение изменений в процесс разработки стало проще и быстрее. Это позволило поддерживать гибкость и адаптироваться к изменениям требований без значительных сбоев в работе.

4. Улучшение взаимодействия внутри команды. Члены команды начали активно помогать друг другу на разных этапах работы. Например, если возникал «затык» на этапе тестирования, аналитик или разработчик могли подключиться и помочь с решением задач. Это не только ускорило выполнение работы, но и сплотило команду.

5. Удовлетворённость команды. Уровень удовлетворенности команды вырос с 3 до 8 по 10-балльной шкале. До внедрения изменений сотрудники были сильно перегружены, ощущали давление со стороны менеджмента и не видели результатов своей работы. В результате оптимизации они стали видеть результаты своих усилий чаще, а доверие со стороны менеджмента существенно возросло.

Заключение

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

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

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

Больше про управление разработкой эксперты OTUS рассказывают в рамках практических онлайн-курсов. С полным каталогом курсов можно ознакомиться по ссылке.

© Habrahabr.ru