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

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

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

В решении этой задачи я выбрал Kanban метод, который позволял начать работать с изменениями уже на раннем этапе сотрудничества.

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

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

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

Команда пыталась успеть сделать все, а в итоге результата было мало.

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

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

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

Для управления работой мы создали 2 Kanban доски:

-одна с проектами

-вторая с пользовательскими историями, которые необходимо реализовать в проектах

И в обоих досках мы внесли ограничение на количество одновременно-выполняющейся работы.

В первой синхронизировались менеджерами и СЕО компании, обсуждали, что стопорит проект и где нужна помощь. Это ускорило коммуникации и решение проблем.

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

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

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

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

В итоге что получилось:

➡ Удалось достичь предсказуемых поставок проектов клиентам с 90% вероятностью. Срок проекта зависил от обьема и варьировался от 2 мес до 4. Но самое важное, что можно было однозначно сказать, когда проект будет завершен.

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

➡ Прозрачность процесса разработки выросла с 4 до 9 по 10 бальной шкале. Я снимал срез до и после в виде опросов

➡ Изменения стало вносить проще, тк в процесс разработки каждые 2-3 недели подключали заказчика

➡ Участники команды подключались друг к другу на этапы, чтобы помочь.

Например возникал затык на тестировании, тогда аналитик и разработчик мог подключиться и помочь с тестированием

➡Удовлетворённость команды выросла с 3 до 8. до этого люди были сильно перегружены, задавлены менеджментом и при этом не видели резульаттов своей работы. А теперь стали чаще видеть результат и улучшили доверие со стороны менеджмента.