Привет! Я Вика Педченко, деливери-менеджер в Т-Банке — настраиваю процессы на сквозном потоке создания ценности: от момента, как возникает идея реализовать новый функционал, до того, как им сможет воспользоваться клиент.
Профессия деливери-менеджера тесно связана с изменениями, и чаще всего они происходят потому, что есть запрос или проблема там, где вы работаете. В этой статье я расскажу, какие проблемы встречались в моей работе, а вы — поделитесь своими в комментариях
Три проблемы, с которым я столкнулась в продукте
Непонятно, какие есть этапы при реализации продукта. Продукт, с которым я работала, начинался как стартап, но в какой-то момент небольшая команда превратилась в отдел из ста человек. По мере того как мы росли и развивались наши процессы, инструменты тоже развивались и приходили новые люди. Но знание о том, как создается продукт, было лишь у основателей — у нескольких людей, и то в головах.
Недопонимание между бизнесом и ИТ. Каждая сторона считала, что она делает хорошо, а все проблемы на другой стороне. Например, бизнес говорил, что ИТ делает что-то медленно, а ИТ переживали, что бизнес хочет делать много и одновременно.
Нет вовлеченности в изменения. Возможно, кто-то сталкивался с ситуацией, когда вы приходите рассказать о проблеме, она для вас суперочевидна, а в ответ — ничего. Более того, кто-то даже считает, что проблемы нет.
Есть разные способы решения этих проблем — проводить one-to-one, опросы, S.T.A.T.I.K., value stream mapping и многое другое. Мы решили остановиться на инструменте value stream mapping, потому что у нас было три гипотезы, чем он нам поможет:
Отразит все этапы создания продукта, и мы сможем системно посмотреть на все наши проблемы, а не решать их локально.
Покажет, что у бизнеса и ИТ связанные проблемы.
Выявит проблемы самим участникам процесса. Когда мы сами их проговариваем — это первый шаг к их осознанию.
Если упростить, то value stream mapping — способ визуализации процесса реализации продукта. Google подсказывает, что VSM берет начало из практик Lean и там даже есть своя аннотация.
Представим для примера, что наша компания производит лимонад, то есть наш продукт — это лимонад. Для производства мы проходим некоторые этапы: закупка ингредиентов, приготовление напитка и доставка его клиенту. Карта создания продукта будет выглядеть так:
Это упрощенный пример, все этапы можно обогащать данными: добавлять проблемы, участников, время на выполнение каждого шага и так далее
Как мы делали value stream mapping
Я посмотрела разные представления VSM и решила упростить ее под наш контекст:
Затем я запланировала встречу, чтобы построить VSM. До построения карты было важно определить границы, по которым она будет построена. Для нас это были этапы от формулировки идеи на реализацию до анализа результатов по выпущенной идее.
В состав участников вошли представители от бизнеса и ИТ-продукта. Такой состав обусловлен тем, что все они были экспертами на разных этапах продукта, что могло бы позволить нам собрать полное представление о его реализации. Плюс уже на первой встрече мы хотели начать решать проблемы взаимодействия.
Фасилитаторами были два деливери-менеджера, и если бы я была там одна, было бы очень сложно. Встреча проходила в офлайне и длилась шесть часов — это куча стикеров, флипчарты, бумага, скотч. Было весело ?
В итоге получился наш поток создания ценности:
Мы проанализировали поочередно каждую проблему и осознали, что хотим не просто починить их, а хотим поменять процесс, потому что все этапы и проблемы связаны между собой. Очень много процессов было завязано на руководителе продукта, это объясняется длинным этапом анализа — он задействован на многих шагах процесса.
После первой встречи мы получили хорошую обратную связь от участников. Все отметили, что у нас действительно много проблем, но мы смогли о них поговорить и где-то даже найти решение.
Оглядываясь назад, я понимаю, что построить VSM — это 30% пути, потому что дальше его нужно развивать.
От планов к реальности
После того как мы создали VSM, я нарисовала вариант to be, раз уж мы собирались менять этапы:
Мы собрались тем же составом, что и в первый раз, и я показала участникам все, что у меня получилось. После нескольких корректировок мы сфокусировались на этапе анализа, потому что он очень сложный и долгий и требовал очень многих изменений.
Мы запланировали изменения этапа анализа со сроками и ответственными для каждого пункта плана. Договорились поменять ролевую модель, описать ее и сделать изменения в оргструктуре. Проговорили, как будем отслеживать наши идеи и где, какие должны быть описания, что на входе и на выходе. Запланировали еженедельную встречу по статусу изменений и представили их команде.
Результаты после всех нововведений:
VSM появился в общем доступе, и каждый может посмотреть, как выглядит наш процесс. Можно оставить комментарий, если в процессе что-то не так. На общих встречах мы рассказали всей команде продукта про процесс, и стало появляться понимание, как создается наш продукт.
Гипотеза оправдалась, и уже после первой встречи ИТ и бизнес увидели, что проблемы у нас общие. Мне даже пришла обратная связь, что встреча помогла найти общий язык для дальнейшего взаимодействия.
Люди захотели участвовать в изменениях, и это самое приятное для меня. Приходили коллеги и просили помочь, поменять что-то в их процессе или приносили свои идеи. Я связываю это с тем, что люди поняли, что могут найти поддержку и что мы действительно можем что-то поменять.
Жизнь после проведения изменений
После того как мы рассказали команде обо всех изменениях, мы ввели их, пожили немного с ними и собрали обратную связь по этим изменениям. Потом попали в такой круговорот: что-то сделали → собрали обратную связь→ еще раз поправили.
Со временем стали привлекать участников процесса. Если изначально VSM был верхнеуровневый, там могли быть большие пункты: дизайн, разработка, маркетинг, — то сейчас мы встречаемся с участниками этих процессов и расписываем их более подробно.
Дополнительно настроили сбор метрик, в частности time to market. Из-за того, что не было общего понимания, как создается продукт, не было и визуализации всех этапов, time to market считался некорректно. Мы могли только приблизительно посчитать, сколько времени реализовываем новый функционал для продукта. После того как данные накопятся, мы увидим, как изменения влияют на метрики.
Выводы и инсайты
Я поняла, что применять VSM нужно, когда мы хотим визуализировать свой процесс, разобраться, из каких этапов он состоит, найти проблемы и ограничения. Чтобы построить VSM, нужно:
Определить проблемы, которые в вашем контексте, и поставить цель.
Задать границы продукта или процесса, по которому планируется строить VSM. Это нам позволит сфокусироваться на определенной области и понять, кого привлекать к построению карты.
Определить состав участников. Необязательно это будут люди уровня C-level, зависит от контекста. Стоит звать участников тех областей, которые планируется разбирать.
Построить и проанализировать полученный VSM, по необходимости построить процесс TO BE, как может выглядеть улучшенный процесс.
Провести изменения и собрать обратную связь. По необходимости повторить четвертый и пятый шаг.
Еще один инсайт, что VSM можно применять для любого процесса. Например, мы составили VSM для полного процесса реализации продукта. В этом потоке есть шаг «дизайн», но дизайн — это не просто составить макеты. Шаг дизайна можно расписать подробно и выявить проблемы в нем, придумать, как их решить, и ввести какие-то системные улучшения.
На что еще я бы советовала обратить внимание:
Необходимы причины изменений. Если мы просто построим VSM и посмотрим на то, как проходит процесс, — это нам ничего не даст. Скорее всего, мы посмотрим и забудем. Нужны причины, почему мы хотим что-то изменить, «неудобства», которые вызывает текущая ситуация. Должно быть что-то, что позволит двигаться вперед.
Нужна поддержка менеджмента. У нас многие изменения идут сверху, и это очень помогает в их проведении. Скорее всего, мы не смогли бы поменять оргструктуру без поддержки руководства.
Нужен ответственный за поддержку и развитие карт текущего процесса. В нашей команде это деливери-менеджер. Я фасилитирую встречи, поддерживаю в актуальном состоянии VSM, организую и помогаю проводить изменения. Если никто не будет этим заниматься, есть риск, что коллективная ответственность превратится в коллективную безответственность.
Оставляю ссылку на телеграм-канал деливери-менеджеров IT’s Tinkoff Process Improvement, где мы собираемся комьюнити, делимся опытом и рассказываем, какие еще инструменты используем в нашей работе, — присоединяйтесь.