{"id":13506,"url":"\/distributions\/13506\/click?bit=1&hash=27fcb5113e18b33c3be66ae079d9d20078d1c30f1b468cdc86ecaeefa18446c2","title":"\u0415\u0441\u0442\u044c \u043b\u0438 \u0442\u0432\u043e\u0440\u0447\u0435\u0441\u0442\u0432\u043e \u0432 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438? \u0410 \u0435\u0441\u043b\u0438 \u043d\u0430\u0439\u0434\u0451\u043c?","buttonText":"\u0423\u0436\u0435 \u043d\u0430\u0448\u043b\u0438","imageUuid":"2c16a631-a285-56a4-9535-74c65fc29189","isPaidAndBannersEnabled":false}
Дима Курдюмов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0
2 комментария
Nikolay Amoseev

почему заказчики не ушли если очередь была в 8 месяцев?

Ответить
Развернуть ветку
Дима Курдюмов
Автор

потому что им уже пообещали что сделают, дав нереалистичные сроки, потом уже сроки ехали и уже уйти сложнее тк работа начата

Ответить
Развернуть ветку
Читать все 2 комментария
null