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

Больше 15 лет работаю в финтехе, 10 из них развиваю банковские продукты. Больше 5 лет управляю IT-командами, которых было 7. Была продакт овнером расчетных продуктов в Банке Москвы, в ВТБ, в Открытии, в Альфа-банке. Люблю строить системы для своих команд и организовывать рабочий процесс так, чтобы все работало как часы.

Рабочих практик всего три. Соответственно, статья состоит из трёх глав (не считая того, что практики могут состоять из нескольких частей. Впрочем, обо всё по порядку.

Возвращаю команде ответственность на все деньги

Практика состоит из двух частей.

№1. Сроки реализации задач прописывает только команда, а не продакт.

Расскажу одну историю. Однажды (в другом банке) я подхватила команду уволившегося продакта. Команда оказалась проблемная: пришлось налаживать процессы, метрики, сходимость бэклога.

Но причина проблемы была не в команде. 

Оказалось, что мой предшественник вырос в этой же команде из аналитика в продакта. И, как это часто бывает, продолжал работать аналитиком, работая продактом. В одно лицо за команду продакт писал планы, вёл два таск-трекера со всеми задачами, разбирал баги, в онлайне отвечал на сообщения команды, водил их за ручку к смежным командам, даже если вопрос чисто по технике что-то обсудить и ревьюил ТЗ. 

Кажется, что продакт не занимался только…стратегией продукта, метриками и стейкхолдерами. 

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

А когда появилась я, то команда ожидала от меня того же и не понимала: «А как можно иначе?». Можно. И нужно.

Не надо работать за команду.

Как это делают многие продакты, которые накидывают план, а команде лишь показывают (и то не всегда:().

Постепенно я вовлекала команду во все этапы производства продукта, а не только в подготовку ТЗ, написание кода, тестирование (нужное подчеркнуть). И в первую очередь стала вовлекать в планирование. Метод таков: 

• Когда мы заполняли таблицу для плана, сначала я приносила левую часть — с задачами, описанием того, на что они влияют, приоритетами. 

• А правую часть, в разрезе каждого спринта и компетенций (дизайнер, аналитик, фронт, миддл, тестирование), девтим заполняли сами, разбивали и декомпозировали на подзадачи. Справа ребята прикидывали, что может пойти не так, возможные риски, и как нам с этими рисками можно бороться. 

Постепенно я объяснила, что только они сами могут корректно оценить сроки, отдала планирование, хоть им это и не нравилось. Они даже ходили жаловаться на меня CPO:)

Но, с помощью разговоров на ретро, примеров других команд, рассказов о том, чем я ещё должна заниматься как продакт, кроме работы с командой, нам таки удалось наладить процесс. 

Важно. На объяснения причин своих действий выделяйте 5-10 минут в течение недели или спринта.

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

Зачем? Чтобы они понимали, что может пойти не так, если этого всего не делать. Потому что не все понимают. Это действительно нужно объяснять. Ведь иногда я и сама об этом забывала за суетой срочных поставок. 

Продакту кажется, что это очевидно: «Это же моя работа. Я же продакт. Все это знают». Нет, IT-команда не знает. И про то, что происходит за пределами встреч с командой, они не в курсе.

В итоге бэклог стал сходиться. Мои ребята собирались на созвоне, сами шарили экран, сами заполняли таблицу плана и сами определяли сроки. А я перестала ощущать себя бессмертным пони, который всё на себе тащит. Появились метрики продукта. И основная моя метрика тоже была в порядке — я не выгорела.

Это очень важно. Когда сроки спускают сверху, всегда можно сказать: «Это вы там что-то напланировали, наобещали, сроки нереальные, ну вот сами и делайте». Ваши ожидания — ваши проблемы, по заветам «классиков».

А когда ребята сами оценили сроки, то дальше они сами и контролируют загрузку, чтобы уложиться в обещанные сроки. И даже если что-то там не учли, то стараются сдержать слово — никто за язык не тянул, сами сроки назвали. Такой простой психологический приём.

И больше нет соблазна сказать: «Это ты неправильно услышала, это ты не то в плане написала».

А вот и нет! Сами своими руками завели, сами потом это и контролируют. Отличное лекарство от тревожности и микроменеджмента.

№2. Команда презентует свои цели на спринт-ревью самостоятельно.

Этот процесс также можно и нужно делегировать на команду.

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

Все довольны, все замотивированы, все сплоченны вокруг продукта и вокруг того, что они делают. А я горжусь: «Ну моиии! Ну молодцы!»

Почему это работает и на результативность тоже? Когда разраб сам планирует и сам рассказывает о своей работе, то он чувствует сопричастность, важность. Здесь ты не просто исполнитель, ты сопричастен. 

Выращиваю преемников и экспертизу

По сути, я растила себе мини-заместителя (хоть его и не было в штатном расписании).

Если у меня была возможность нанять аналитика, то я выбирала среди тех, у кого есть интерес развиваться в сторону РО.

• С одной стороны, мне потом было с кем в команде обсудить продуктовые вопросы, «подумать об него».

• С другой — был человек, которому я могла передать бразды правления на время отпуска или больничного. Или вообще, когда позже я куда-нибудь соберусь, то могу аккуратно передать всё уже заранее подготовленному человеку. Фактически у меня уже есть преемник на роль РО.

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

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

Этот приём работает и в отношении всей команды, которая, например, сейчас не такая самостоятельная, как хотелось бы. В этом случае я старалась выращивать в команде неких «мини-директоров» по каждому направлению в девтим.

Каждый мини-босс отвечал под ключ за свою компетенцию: тестирование, аналитика, дизайн, фронт, бэк. С ними я советовалась, чтобы принять решения в этих зонах компетенции. И в своей части они решали, как будет сделан продукт. То есть я отвечала на вопрос «что?», они отвечали на вопрос «как?».

Например, надо катиться в бой, а тестировщик нашел некие баги. «По-классике» продакт говорит: «Катить/не катить». Я же спрашивала тестировщика: «А ты как думаешь? Можно катить с такими дефектами? И какие могут быть последствия?» И слушала, что он говорит. И решение мы принимали совместное.

Каждый отвечает за свою часть, а мне не требовалось заниматься микроменеджментом. Ребята работают спокойно, зная, что им доверяют и ценят за экспертизу. И я не буду так сильно, как раньше, переживать за результат, потому что уже могу на них положиться. 

Конечно, такая опция не включается по кнопке. Не получится, в один прекрасный день прийти и сказать: «Ну, всё, вы теперь самостоятельные. Дальше сами». От такого команда выгорит быстрее, чем ты.

Отгружать новые зоны ответственности нужно постепенно.

Сначала проводим тест: делегируем некритичные участки, подстраховываем, оставляем промежуточный контроль, а критичные функции первое время берём на себя. Например, ревью спринта. Потом потихонечку передаем. И то в начале стоит порепетировать перед тем, как девтим сами возьмуться докладывать.

Слежу, чтобы команда не выгорела от нагрузки

№1. Добавляю задачам смысла, фокусируя команду на пользе, которую они приносят.

Здесь помогает продуктовый вижен. Его ещё называют стратегией. Хотя, на мой взгляд, это слишком пафосно, и для цифрового продукта, к примеру, для выписки или платежей в интернет-банке, больше применимо понятие «видение развития продукта». Про то, что там должно быть и как его готовить можно написать отдельно целую статью.

Самый простой вариант с которого можно начать, например, с заполнения lean canvas и SWOT анализа и через них обосновать и продать (сначала себе, а потом команде) уже имеющийся бэклог.

№2. Морально поддерживаю команду.

Главное — не скипать ретро, а разбирать на них не только почему случился баг и как его не повторить, но и давать ребятам высказаться, как они вообще. Для этого в интернете полно всяких фреймов разминок для ретро, которые помогают порефлексировать и расшевелить даже самых интровертных. Типа выбери какой ты сегодня Ди Каприо из мемов и тд. 

Это база.

Если в команде достаточно доверительные отношения, полезно на ретро занести такой инструмент как Moving motivators (из менеджмент 3.0) и предложить каждому выбрать свои топ мотиваторы. Это удобный наглядный инструмент, который помогает увидеть, насколько разными в команде могут быть мотиваторы, и понять для себя на будущее как и кого лучше мотивировать. Кому-то может быть приятно, что их хвалят на большой встрече на 100 человек, а кто-то, наоборот, предпочитает похвалу на ламповых встречах с командой. 

Если с доверием в команде пока не очень, можно такое ранжирование провести самостоятельно, задав наводящие вопросы на 1-1 и, в целом, подмечая при общении. 

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

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

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

№3. Провожу неформальные активности: отмечаем дни рождения, долгожданные релизы и т.д. (если команда такое поддерживает).

Мы, например, с командой периодически после работы собирались в зуме с дурацкими масками и устраивали посиделки с чаем или чем покрепче. Можно ещё играть в онлайн игры (мы любим Codenames). Устроить такое несложно даже для команды на удаленке, которая находится за много километров друг от друга.

Уровень посложнее — встретиться очно и куда-нибудь сходить вместе или вообще съездить в туристическую поездку (и такое бывало). Конечно, совместные впечатления сближают команду. Пообщавшись хоть раз вживую, при удаленной работе после ребята уже лучше понимают друг друга и команда это прям Команда:)

Итого

Работа продакта — творческая.

Продакт:

• управляет климатом в команде и мотивирует ребят,

• анализирует метрики и делает выводы,

• генерирует гипотезы для развития продукта,

• исследует рынок, думает как догнать и перегнать конкурентов,

• управляет ожиданиями стекхолдеров и отношениями и договоренностями с смежниками,

• да и писать статьи, например, и заниматься PR тоже было бы круто...

На все это нужно что? Ресурсы и время. Но где же его взять, если работа с командой и поставками может занимать и 70, и 80, и 90% времени? Выход только один: не тащить всё на себе, а распределить то, что можно по команде, в том числе моральную нагрузку. 

Понимание, что всё тащить на себе вдолгую непродуктивно и что можно иначе, пришло ко мне, когда я выбиралась из выгорания. Стала замечать вокруг себя примеры не таких загруженных продактов. Но не потому, что у них бэклог маленький или продукт неважный, а потому, что они с командой — реально команда и вместе всё разруливают и поддерживают друг друга.

Команда дана не просто так. Делитесь с ней ответственностью, вытаскивайте из позиции «У нас лапки». Делегируйте. Да, так можно. И нужно (весь Scrum об этом).

В Альфа-Банке моя команда изначально была самостоятельной, а я лишь встроилась и поддерживала их самостоятельность: наладила Scrum-процессы, метрики, научила планироваться. В итоге:

• У нас взлетела сходимость бэклога.

• Ребята перестали работать в процессе «Просто делаем, что сказали», и «Таски тащатся из спринта в спринт».

• Стали планироваться.

• Задачи обросли прогнозируемыми и прозрачными сроками.

• Метрики росли, продукт рос, развивался, клиенты были довольны. 

Настроив процессы (как рассказано выше) на управление командой я стала тратить процентов 30 рабочего времени. И позже смогла запустить ещё одну такую команду в смежном продукте — параллельно. А потом ещё и третью подхватила — у продакта, который уволился.

Команды работают чётко. Без продалбывания сроков. Без микроменеджмента.

И с моей личной NSM все гуд — я не выгорела. Сейчас настроенные мною процессы уже подхватил новый продакт: мой бывший аналитик, которому я часто делегировала команду и продукт, пока занималась стратегией и PR-ом (см. главу «Выращиваем преемников»). А я стала СРО.

Продакты, «Всё чего касаются лучи солнца…» не нужно тащить на себе! Поделитесь с командой. И вам будет легче. И ребята ещё спасибо скажут за то, что их ценят.