Вашей команде нужна стратегия – вот как её написать
Обычно, если подойти к лидеру и попросить его показать документ о стратегии его команды, окажется, что такого документа просто нет. Многие считают, что время на его написание не пропорционально потенциальной пользе.
Такое мышление зачастую ошибочно, и вот почему:
Потратив время и силы на создание плана, который все (члены команды, партнёры, внутренние клиенты) смогут просмотреть, прочитать и прокомментировать, это настроит вашу команду на успех лучше, чем любая другая деятельность. Стратегический документ также помогает команде объяснить своё существование и то, как она вписывается в бизнес.
Вы должны написать стратегический документ для своей команды сегодня, если у вас его ещё нет.
Почему вашей команде нужен стратегический документ
Мы часто называем людей в команде или инструменты, с которыми они работают, ресурсами. Но только один ресурс имеет значение – тот, который невозможно восполнить – время.
Время – это всё, что имеет значение. В каком-то смысле время – абсолютная мера. У вас нет бесконечного времени, чтобы выпустить продукт в продажу. В конце концов, вы сталкиваетесь с ограничениями: датами выпуска, датами выполнения требований, датой повышения зарплат и так далее. Если вы работаете в стартапе и не поставляете продукт, ваш денежный поток может иссякнуть, и вы окажетесь на улице в поисках новой работы.
Но работаете ли вы над правильной работой? Да? Нет? Откуда вы знаете, что не тратите время впустую? На какой показатель вы можете указать и сказать: да, я иду в верном направлении?
Вот как вы можете это узнать:
У вас есть чётко сформулированное видение конечного состояния текущей итерации продукта/платформы/системы;
У вас есть чётко сформулированная система измерений для определения прогресса;
У вас есть цели, которые выходят за рамки «запланированных» – вы можете измерить изменения;
Вы можете разумно распределять время между измеримыми целями и неизбежными перерывами;
И вы знаете, где вы находитесь на линии прогресса между текущим моментом и видением конечной цели.
Понимание того, как и где вы проводите время команды и как вы оцениваете прогресс и успешность, имеет решающее значение для подготовки команды к успеху. Учёт всего этого — от технического долга до проблем с системой сборки и сосредоточения внимания на правильной работе — позволяет вам распределять свои ресурсы для решения наиболее приоритетных задач и экономить их, находя правильные компромиссы.
Ответы на эти вопросы даёт стратегический документ. Стратегия объясняет команде, почему, как и что. Итоговый документ:
Определяет направление работы команды;
Позволяет команде свободно придумывать решения хорошо сформулированных проблем без микроменеджмента;
Подчёркивает ответственность инженера за систему и возможные пути продвижения;
Позволяет командам устанавливать эффективные OKR;
Позволяет командам трезво оценивать свои временные затраты;
Обеспечивает согласованность действий с заинтересованными сторонами;
Помогает командам нанимать сотрудников;
Помогает удерживать талантливых сотрудников.
Но вы не сможете эффективно распределять ресурсы между самыми приоритетными задачами и делать разумные компромиссы, если не знаете, каковы эти приоритеты. Вы можете догадываться, и, возможно, будете в основном правы, но всё равно будете периодически тратить время впустую. А чем больше времени потеряно, тем меньше команда настроена на успех.
Враг: бездумные спринты
Вот что произойдет, если вы не выстроите эффективную стратегию.
Самый пагубный и высасывающий время антипаттерн Agile — бездумный спринт. (Бездумные спринты — это когда мы путаем прогресс с движением. Этот паттерн встречается постоянно.
В бездумных спринтах мы заполняем спринты инженерной команды работой, которая:
Не согласуется с общими целями бизнеса.
Поддерживает неправильные компромиссы.
Создаёт неправильные функции.
Работает вопреки бизнес-целям (например, дублирует работу, имеет неправильный объем).
Или (в большинстве случаев) имеет значение от низкого до предельного.
Из самых лучших побуждений вы можете заполнить спринты работой, которая выглядит как прогресс в течение года или более, но не соответствует ни одному приоритету команды, отдела, организации или компании и в итоге превращается в технический долг. Это легко сделать, потому что команде всегда есть, чем заняться.
Эта деятельность — движение. Движение заставляет команду выглядеть очень занятой. Со стороны кажется, что команда приносит пользу. Скорее всего, это не так. В лучшем случае вы просто теряете ту ценность, которую могли бы приобрести за потраченное время. Вы не можете сказать наверняка, потому что вы не применяете более комплексную стратегию и не оцениваете себя. Без видения конечного состояния, целей, стратегии достижения цели или измерений у вас нет никакого способа подтвердить свой прогресс. Вы просто предполагаете. Возможно, вы бежите сломя голову.
Смысл работы инженерной команды заключается в том, чтобы создавать то, что приносит пользу бизнесу. Вы тратите время на бездумное строительство без плана. Вы никогда не вернёте это время. Оно ушло, и ваша команда, движущаяся в неопределённом направлении, несёт очень мало реальной ценности для бизнеса. А, значит, находится под угрозой расформирования, если кто-нибудь когда-нибудь заметит это.
Анатомия стратегического документа
Настало время написать документ.
Записать стратегию одновременно и проще, и сложнее, чем кажется. Мы используем этот документ для количественного определения проблем, которые нужно решить, для кого мы их решаем, как мы собираемся их решать и как мы узнаем, хорошо ли мы справляемся с работой. Это план, который описывает приоритеты команды на самом высоком уровне и определяет её направление.
Стратегический документ очень полезен для привлечения внутренних клиентов, чтобы они понимали, чем занимается команда, в качестве документа по введению в должность, для расчета стоимости и планирования увеличения численности персонала, в питч- и рейк-деках, для руководства процессом планирования и для бесчисленного множества других целей. Как только вы его напишете, вы будете обращаться к нему снова и снова. Это будет горячая ссылка в вашей панели закладок.
Этот шаблон является образцом. Иногда вам понадобится больше разделов, чем представлено здесь. Иногда их нужно меньше.
Итак, приступим.
Какую проблему мы решаем?
Напишите как можно конкретнее общую бизнес-проблему, которую решает ваша команда, почему это проблема и как действия команды решат эту проблему. Иногда решение совпадает с формулировкой миссии, но не всегда. Понимание проблемы — лучший способ определить, что и зачем нужно создавать.
Если над одной и той же проблемой работают несколько команд, формулировка проблемы и миссии различаются.
Пример: Деловые поездки сложны, а бизнес-системы устарели, поэтому мы будем упрощать, модернизировать, устранять пробелы и интегрировать новые возможности.
Что мы делаем сегодня?
Запишите формулировку миссии команды. Это заявление — то, зачем команда существует сегодня. По возможности придерживайтесь одного предложения.
Пример: Мы предоставляем клиенту фронт-энд UI/UX для поиска авиабилетов, отелей и поездов. Мы также интегрируем систему упаковки в процесс оформления заказа для создания сквозной воронки.
К чему мы хотим прийти в итоге?
Запишите ваше видение. Это заявление — то, где мы хотели бы быть через 2-3 года. Оно не должно быть идеальным, но должно служить путеводной звездой. Высокоуровневая диаграмма поможет подкрепить заявление о видении.
Пример: Современная и эффективная сквозная воронка бронирования деловых поездок, ориентированная на клиента, которая предоставляет клиенту самую лучшую информацию, представленную в наиболее понятном виде в отрасли!
Для кого предназначена эта система?
Пропишите личности клиентов — тех клиентов, которые будут использовать продукт. Понимание личности клиента и его проблем помогает отточить правильные функции, показатели и приоритеты для определения основных этапов работы.
Пример: Отдельные бронировщики в известной компании должны бронировать для себя через простую в использовании воронку. Иногда за них бронируют администраторы или целые команды. Служба поддержки клиентов должна поддерживать клиентов, если они сталкиваются с проблемой.
Что мы хотим воплотить в жизнь?
Каких 4-6 крупных шагов мы хотим выполнить, чтобы воплотить наше видение в жизнь? Какие наиболее значимые функции мы должны предоставить клиентам? И почему нам нужны эти функции?
(Эти шаги позже превращаются в цели OKR).
Пример: Мы будем интегрироваться с ML-сервисами, которые обеспечат персонализированный поиск авиабилетов, отелей и поездов на основе ML для наилучшего сочетания пребывания, интегрироваться с пакетным рекомендателем, который будет автоматически подбирать наилучшее путешествие, и с системой покупки, которая позволит легко совершать покупки с интеграцией в сервисы управления поездками, такие как наш собственный.
Как понять, что мы на правильном пути?
Вот спорное утверждение: прежде чем написать строчку кода, определите 3-5 приоритетных направлений измерений. То, что вы измеряете, определяет ваш продукт, потому что вы будете ориентировать приоритеты функций на повышение этих показателей. Измерения — это как компас в темноте: они подскажут вам, приближаетесь ли вы к цели. Вы будете часто обращаться к своим метрикам.
Предварительное определение показателей также помогает определить стратегию науки о данных, стратегию бизнес-аналитики, стратегию ведения логов/ETL и общую стратегию хранения данных.
Некоторые идеи измерений:
TAM (общий адресуемый рынок), если он известен, или % от TAM, основанный на регистрации пользователей.
Количество пользователей и их принятие.
CAC — стоимость приобретения клиента.
Приобретение и активация — посещение сайта, пребывание на сайте, время в воронке, соотношение посещений и покупок.
Процент удержания — коэффициент повторных посещений сайта.
Доход — сумма, вырученная в рублях.
Любые другие метрики, которые вы хотите измерить — количество действий, совершённых в секунду, определённые действия и т. д.
Пример: Сначала мы будем измерять посещения сайта, время прохождения воронки и пребывания на каждой странице, матрицы разочарований, коэффициенты посещения/покупки и коэффициенты возвращения на сайт. Мы стремимся минимизировать время прохождения воронки от первоначального поиска до покупки. Мы также собираем все данные о поиске для целей разработки функций.
Что нам нужно сделать лучше?
Большие цели — самая важная часть вашей стратегии. Они определяют ожидания команды и её приоритеты. Понимание всеобъемлющих целей позволяет команде определить тактику и ход выполнения. Эти цели должны быть тесно связаны с вашими метриками.
Если вы определите первый набор основных метрик, вам будет гораздо проще определить рычаги, которыми вы хотите управлять в ходе проекта. Позже вы создадите систему измерений, но пока лучше что-то, чем ничего.
(Позже они превратятся в ключевые результаты в OKR).
Пример: Нам нужно обеспечить удобство работы, которое сокращает время прохождения воронки на 15% и увеличивает количество покупок на те же 15%. Нам необходимо оптимизировать наши ML-сортировки с помощью сбора данных, чтобы мы могли предлагать как персонализированные рекомендации с высокой стоимостью, так и увеличивать маржу на 10%. Время ожидания при покупке должно составлять 5-9 дней.
Что мы должны построить, чтобы добраться отсюда до места назначения?
В самом конце — детализация технических решений. Создаём ли мы платформу, на которой будем строить сервисы и API? Собираемся ли мы объединить платформы в один целостный продукт? Рефакторинг от монолита к микросервисам в рамках жизненного цикла? Будем ли мы создавать мобильные приложения?
Оставьте глубокие технические, операционные и инфраструктурные решения в документах по проектированию архитектуры.
Пример: Мы создадим веб-приложение на React/Typescript, потому что бизнес-пользователи предпочитают бронировать билеты онлайн (см. персоны!), а мобильные приложения — для регистрации, получения информации о выходе на посадку, билетах и оповещениях. Мы интегрируемся в платформу API для бронирования, которая будет управлять процессами поиска, сортировки и оплаты. Эта платформа, в свою очередь, будет интегрироваться с комбинацией новых, традиционных GDS и пользовательских алгоритмов AI/ML.
А разве это не работа менеджера по продукту?
Руководство команды, включая инженерного менеджера и технического руководителя, должно согласовывать с менеджером по продукту бизнес-стратегию команды. Чтобы команда работала, инженерный менеджер, технический руководитель и менеджер по продукту должны работать вместе как единое целое. В то время как PM будет определять бизнес-стратегию, EM и TL отвечают за её реализацию.
Вам никогда не гарантируют, что в вашей команде будет менеджер по продукту. Никогда. И если вы сидите за столом переговоров и думаете, кто будет PM, когда у вас его не будет... знаете почему? Потому что теперь это вы. Научиться мыслить бизнес-терминами — хороший жизненный навык, даже если всё, что вы хотите делать, — это разрабатывать массивные ивентовые системы.
Освежить стратегию
Итак, у вас есть стратегический документ, и я готова поспорить, что на его написание у вас ушёл месяц. Так что вы расслабляетесь и говорите, что это было трудно, но теперь дело сделано. Теперь можно приступать к планированию.
Вы используете стратегию для планирования! Фантастика! А потом вы заканчиваете кучу работы и снова планируете! Вот только вы перелопатили кучу стратегий и поняли, что некоторые из них верны, некоторые — нет, и вы хотите изменить все показатели! Ни один план не выживает после контакта с врагом, а вы только что встретились с ним.
Стратегический документ — это живой документ. Как и любой другой документ, он стареет со временем. Поэтому перед любым планированием на квартал вы должны обновить свой документ о стратегии. Пройдитесь по всему документу сверху донизу. Сохранилось ли видение? Завершены ли и поставлены ли основные цели? Узнали ли мы новые важные факты о том, как работают ваши клиенты? Возможно, у вас произошёл поворот, или ваши первоначальные показатели были неверными, и нам понадобилась новая система показателей.
Включите обновление в свой график планирования. Написание 3-го, 4-го или 10-го раза не займет так много времени. Но поддерживайте актуальность своей стратегии, чтобы она оставалась вашим руководящим документом.
Отдельно: OKR и метрики
Небольшое замечание по поводу OKR и метрик, не вдаваясь в механику: гораздо проще ставить цели и ключевые результаты для команды, когда вы уже движетесь к... целям и ключевым результатам (метрикам).
Определение стратегии и её периодическое обновление — вот как происходит магия OKR. Если у вас есть миссия, видение, набор клиентов, чётко сформулированные проблемы, большие «валуны» и техническая стратегия, вывести OKR гораздо проще. Конечно, разработка хороших, чётких целей иногда всё ещё остается сложной задачей, особенно по мере взросления продукта, но наличие написанной стратегии вносит ясность в процесс планирования.
Идти вперёд и побеждать
Команды с чётко сформулированной стратегией всегда оказываются успешнее тех, у кого её нет. Даже если стратегия похоронена в гигантской диаграмме GANTT, её наличие гораздо лучше, чем отсутствие.
Самое приятное в выполнении написанной стратегии — это то, что она часто высвечивает интересные возможности — области, в которые команда может вложить средства, которые принесут гораздо больше пользы, чем простое выполнение спринта за спринтом. Эти возможности гораздо легче увидеть, когда они записаны и представлены, а не хранятся у кого-то в голове.
Надеюсь, что-то из этого оказалось полезным для кого-то! Идите вперёд и побеждайте!
