Run & Change

Run & Change

«Run & Change» — это одна из моделей, которую применяют к бизнесу. Она делит все процессы и проекты в компании на 2 базовых класса (есть варианты с выделением 3-го, сейчас его опустим):
Run (рутинные активности) — активности, задачи и даже небольшие проекты, которые призваны поддерживать работу компании, ее процессы в их нынешнем виде. Эта работа понятна и предсказуема.
Change (проекты расширения и роста) — активности и проекты по преобразованию и масштабированию бизнеса, нацеленные на рост. Как правило, известны цели, которых необходимо достичь, но нет понятного плана, как это сделать, так как никто ранее в компании этого не выполнял.

Я люблю перекладывать эту модель на задачи тимлида.
👟К run отношу все действия, которые выполняются регулярно:

  • оценка кандидата на собеседовании
  • составление отчётности по бюджетам
  • планирование обучения команды
  • проведения 1-1 и т.д.
    ✨К change отношу проекты, которые запускаются в команде впервые:
  • создание матрицы компетенций
  • проведение митапа
  • создание онбординга в команде и др.

Со временем активность из change может стать для вас активностью из run. Например, запуская 10-ый митап вы уже хорошо будете представлять, что, когда, зачем и почему стоит сделать.

Делить активности таким образом полезно, чтобы применять к ним корректные подходы по достижению результата.
Ниже топ-3 особенности, которые я выделяю для себя.

👟 Для RUN

  1. Это повторяющая активность, для которой понятно, что надо предпринять, чтобы получить результат. Чтобы совершать меньше ошибок и тратить меньше времени на вспоминание особенностей, для таких активностей стоит составлять чек-листы и другую документацию. Я использую чек-листы для собеседования, для онбординга, для части типовых 1-1 и т.д.
  2. Так как мы выполняли эту активность много раз, мы знаем, сколько времени она занимает, поэтому можно составлять детальные пошаговые планы. Например, для 10-го по счету митапа вы с высокой точностью можете составить календарный план и действовать по нему.
  3. Подобные повторяющиеся активности можно дополнять KPI. То есть ставить количественные цели на поддержание определенного уровня качества этой активности. Например, KPI на количество звонков в отделе продаж. Предсказуемая активность с понятным результатом + это можно измерить.

✨ Для Change:

  1. Как правило, это проект, который выполняется вами впервые, поэтому вы не можете по нему составить инструкцию. Как правило, вы даже не знаете всех действий, которые надо будет предпринять, чтобы его реализовать. Зато вы знаете первый шаг, который точно надо сделать. Чаще всего это исследование конкурентов или интервью и сбор требований и т.д. Ставьте себе детальный план действий на первый шаг и не думайте обо всех остальных сразу. Слишком велик шанс, что вы сделаете ошибку. Например, нет смысла гадать, какие функции вы будете проектировать в системе, пока нет понимания исходных требований Заказчика.
  2. Проекты change нельзя планировать с точными временными рамками (нельзя, но это все делают в проектах разработки ПО, а потом эти сроки предсказуемо про… пропускают). Вы не знаете всех шагов, так как никогда этим путем не шли. Ставьте для себя временные рамки только на ближайший шаг. Например, создавая впервые матрицу компетенций, вы можете предсказать, сколько времени можно выделить на изучение матрицы компетенций других отделов или компаний, но не можете сходу сказать, сколько времени надо будет на подборку материалов для обучения в соответствии с вашей матрицей. На первом этапе матрицы ещё нет, не известно, какие будут темы, поэтому нельзя сказать, сколько это займет часов.
  3. KPI не применимы к change проектам. Зато применимы критерии достижения результата. Когда вы формулируете критерии, по которым определите, что проект успешно реализован. Тут есть соблазн использовать смарт, но это не всегда возможно. Опять же потому, что на старте вы ещё не знаете слишком многих деталей.

Например, для матрицы компетенций, это могут быть:

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

‼️Очень рекомендую подумать, какие из ваших активностей относятся к какому из 2 классов и проверить, выполняете ли вы топ-3 принципа работы с ними!

Вот так можно посмотреть на роль Тимлида как на бизнес 😊

Надежда Смирнова

Директор департамента бизнес-анализа в международной продуктовой компании. Вдохновляется всем, что касается работы команд и процессов. Ведёт канал @happyteamlead и @devan .Любит животных, в семье 10 кошек и собака. Основатель нескольких ИТ — сообществ.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *