Привет-привет! Я Олег Филонов, лид продуктовой аналитики в Партнерских кэшбэках Тинькофф. Расскажу, как спасал свою команду от ad-hoc-задач, что у меня получилось, а что нет и как нужно было действовать. Делюсь своей историей внедрения изменений в команде аналитики.
Враги аналитиков — ad-hoc задачи
Главные враги аналитиков – ad-hoc задачи: выгрузки, нетипичные, но массовые отчеты, внезапные проблемы с данными, продуктовые процессы, которые делаются руками аналитиков.
Аналитики не всегда умеют управлять потоками ad-hoc задач и перенаправлять их. Это чисто менеджерская работа. В идеале хотелось бы, чтобы ею занимались менеджеры продуктов. Но в этой истории роль менеджера досталась мне, потому что моя команда больше всего страдала от устоявшегося положения дел.
В нашей компании менеджеров обучают. На одном из тренингов я познакомился с этапами изменений по Джону П. Коттеру и даже написал об этом пост на LinkedIn. Еще про управление изменениями можно почитать на сайте Института тренинга, откуда я позаимствовал полезный и понятный график с этапами изменений.
Каждый руководитель и сотрудник постоянно занят своей текущей работой, проектами и задачами. И если в моей части процесса проблемы, это не значит, что все должны броситься делать для меня автоматизацию. Но в моих силах процесс изменить. Придется конкурировать за внимание, доказывать ценность задачи для общего дела и если все пройдет успешно — получить в итоге желанную автоматизацию.
Успехи и провалы в процессе автоматизации
В самом начале мне не хватило веса и убедительности, поэтому программу спасения мы запустили с некоторым запозданием.
Шаг 1. Рассказывай о существующей проблеме, создавай у коллег ощущение срочности и неотвратимости перемен.
Что делал я: подошел к проблеме как аналитик. Ситуация с ad-hoc была мне полностью понятна, а другим участникам команды — нет. Я собрал фактуру, подробно все расписал, сделал говорящие графики. Увы, на всю эту аналитику ушло слишком много времени, а эффект был очень слабый.
Еще я обсудил проблему с одним из руководителей в надежде, что он запустит процессы. С моей стороны это было наивно. У руководителей всегда много важных и срочных дел, зачастую у них просто не хватает ресурсов реагировать на каждый сигнал. Пока я ждал его реакции, время шло, аналитики продолжали пилить ad-hoc.
Как нужно действовать: потратить минимум времени на подготовку и рассказать максимальному числу руководителей и заинтересованных лиц о проблеме. Я акцентирую внимание на руководителях, потому что у них есть ресурсы и рычаги влияния, которых нет у специалистов.
С поддержкой сверху вы не просто ворчите на сложности и ждете перемен, а становитесь инициатором улучшений с возможностью что-то изменить. Не бойтесь и не стесняйтесь усиливать и повторять свой сигнал, пока проблеме не посвятят:
— регулярную встречу;
— канал в корпоративном мессенджере;
— половину разговоров в коридорах и у кофемашины.
Шаг 2. Собери команду реформаторов = найди союзников.
Что делал я: провалил свою первую попытку поднять вопрос и донести проблему до руководства из-за маленького охвата целевой аудитории. После короткой передышки я снова начал кричать «волки»: рассказал о проблеме всем лидам разработки, менеджерам и владельцу продукта.
После первых откликов я собрал несколько встреч со всеми этими уважаемыми людьми. В ходе звонков мне посоветовали провести встречи one-to-one с лидом разработки и менеджерами продуктов, которые потенциально могли бы взять этот проект. И только на этом этапе пригодилась моя подробная аналитическая записка. Данных в ней хватило, чтобы убедить ребят в важности проекта. Так я нашел заинтересованных и вовлеченных людей, которые готовы были мне помочь.
Как нужно действовать: тут я все сделал правильно. Заинтересованные коллеги помогли мне сформулировать посылы, связали с ответственными людьми и в целом снизили нагрузку на меня по старту и лидерству изменений.
Шаг 3. Создай образ будущего или опиши его как проект.
Что делал я: несколько недель проводил встречи с будущей командой проекта. На встречах мы формулировали проблемы, думали о возможных решениях, писали заметки. Потом все это легло в основу документации по проекту. Документация помогает без встреч объяснить, почему и что делает команда изменений.
Как нужно действовать: тут я тоже все сделал правильно. Но есть совет: важно стараться увязать свое видение с целями команды или компании. Это поможет на следующих шагах получить дополнительные ресурсы. Успевайте «продать» свои идеи до того, как будут согласованы годовые или квартальные планы. Иначе переигрывать их будет очень тяжело.
Шаг 4. Расскажи о новом проекте и рисках его невыполнения всем.
Что делал я: начал с того, что ввел новые термины. Зачем? Я буквально дал названия проектам и процессам, у которых до этого названий не было или они были немодными, имели негативный контекст. Это помогло сфокусировать команду на определенных сущностях и продать ей проект впоследствии.
Например, у аналитиков есть задача сбора аудитории. Ее называли «сделать выборку», «собрать аудиторию», «подобрать таргетинг». Я назвал процесс launch-camp. Появился новый термин, удобный для разработчиков, менеджеров продуктов и других коллег. Получилось так, что название процесса стало названием проекта и все участники стали лучше понимать о чем речь, когда слышали о launch-camp.
Затем я завел страницы проектов на внутренней Wiki, написал десятки постов в каналы, провел до 10 встреч, на которых объяснял, зачем нам инвестировать ресурсы в эти проекты.
Как нужно действовать: использовать все доступные каналы — мессенджер, Wiki, регулярные встречи, большие встречи продукта, письма. Это действительно нужно сделать. Можно попробовать привлечь участников проекта, пусть немного поработают евангелистами нового видения.
Шаг 5. Привлеки как можно больше людей и ресурсов для старта изменений.
Что делал я: потерял везение. Команда аналитики включилась в работу вполсилы: кажется, ребятам не хватило опыта сориентироваться, а мне — настойчивости.
Основные пользователи отчетности, которую мы хотели автоматизировать, проблему проигнорировали. Возможно, потому, что аналитики продолжали самоотверженно поддерживать старый процесс.
Большую поддержку удалось получить от менеджеров продуктов, разработчиков и части аналитической команды. Очень благодарен, что они включились!
Как нужно действовать: бороться с барьерами, которые могут помешать переменам, как советует теория.
Я могу только предположить, что нужно пробовать более радикально встряхнуть пассивных коллег. Возможно, проводить больше личных встреч с потенциально готовыми помогать. Если у вас есть такой опыт — пишите в комментариях, как действовать на этом этапе!
Шаг 6. Продай первый результат команде и конечным пользователям, чтобы все почувствовали успех.
Что делал я: рассказал всем участникам процесса о MVP нового проекта — о нашем первом результате. Отчеты, которые раньше собирались вручную аналитиками, стали собираться системой. Они были не очень красивые и иногда с багами, но это уже было что-то.
MVP помог немного снизить нагрузку на мою команду, убедить разработку в том, что проект посильный. И лед тронулся!
Но мы вместе с командой упустили, что конечный пользователь, довольно консервативный и пассивный, пользоваться нашим MVP не стал. В итоге мы вовремя не получили ценную обратную связь.
Как нужно действовать: сосредоточиться на том, чтобы донести ценность первых «низко висящих фруктов» до конечных пользователей. Важно собрать с конечных пользователей обратную связь и убедить их переехать на MVP-решение как можно раньше.
Шаг 7. Закрепи успех и продолжай перемены.
Что делал я: грустил :(((
Новогодние праздники никогда не приходят вовремя к команде, которая работает над большим проектом. После длинных выходных начался «откат».
Планирование — сложный процесс со многими участниками и переменными. Там постоянно конкурируют инициативы, которые влияют на разные части процессов и бизнеса. Иногда даже самые важные задачи могут не попасть в бэклог с первым приоритетом. Так произошло с моей задачей.
Актуальность проблемы подзабылась, как и ее связь с достижением поставленных целей. Наш проект перемен заехал в годовое планирование, но со вторым приоритетом. Это сбило динамику.
Как нужно действовать: держать руку на пульсе во время всей работы проекта. Не ослаблять хватку, поддерживать напряжение — проводить статус-встречи, сделать дашборд с визуализацией процесса автоматизации.
Если понимаете, что темп перемен падает, сразу эскалируйте. Идеально, если получится переложить роль двигателя прогресса на кого-то, у кого больше веса в команде. Кстати, остаться вне команды перемен для инициатора абсолютно нормально. Например, вскрыть проблему и всем о ней рассказать может и начинающий специалист, но это не значит, что следующим шагом он должен возглавить проект, над которым работает 30 человек.
Шаг 8. Встречай новую нормальность.
Что делаю я: возвращаюсь на шаг 7, чтобы изменения состоялись.
К сожалению, в моей истории прекрасный момент новой нормальности еще не наступил. И чувствую, что мне предстоит еще много раз проговорить проблему и привлечь еще больше людей к ее решению. Но я уверен, что получится привести команду в новое состояние. Поэтому я начал придумывать и внедрять конкретные шаги, чтобы команда могла заниматься более интересными и полезными для бизнеса проектами.
Как нужно действовать (из теории): не расслабляться. Нужно обдумать и оценить пройденный путь. Обязательно отдохнуть и взяться за новый проект, чтобы изменения стали частью корпоративной культуры. В целом в Тинькофф так и работает.
И умная-веселая мысль на прощание.
Внедрение изменений, их масштаб и скорость — один из главных маркеров успешной команды. Не беда, если процессы несовершенны, но они меняются к лучшему. А если изменений нет, то нет и развития — ни корпоративного, ни профессионального.
Не бойтесь трудностей и изменений! Они делают нас, наши команды и продукты сильнее и лучше. А если у вас есть свои истории внедрения изменений — жду в комментариях для обмена опытом :)
