Выбери лишнее: груминги, дейлики, стендапы. Все про необходимость встреч от ментора Эйч Навыки

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

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang, а также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Вместе разбираемся, в чем польза ежедневных встреч и как их спланировать так, чтобы ни у кого не закатывались глаза.

Зачем нужны созвоны и какую роль они играют

Я недавно пришел в новую компанию, которая делает аналитический софт для корпоратов по всему миру, лидом команды Go-разработчиков. Процессы здесь были почти не выстроены — три синка в неделю, которые представляли собой часовой созвон с элементами скрамовского стендапа и возможностью задавать вопросы, однако они были малоэффективны. Получалось так, что несколько разработчиков просто ждали пока договорят другие два, и слушать разрешение вопроса им не было смысла — не их сфера.

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

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

Созвоны должны решать проблемы, отвечать на вопросы (быстрее, чем в переписке), заставлять не лениться, мотивировать, держать в курсе новостей продукта, компании. Другими словами, синковать и подталкивать, занимая минимальное количество времени (зачастую проблемы возникают тут) — работать ведь тоже нужно. Если ваши созвоны какому-то из пунктов не удовлетворяют, стоит задуматься, не нужно ли что-то оптимизировать.

Какие бывают созвоны

На самом деле видов созвонов немало — рассмотрим самые популярные из них, которые, пожалуй, были почти в каждой команде и компании:

• Стендапы/дейлики — базированная база, краткие созвоны по 15 минут с целью получения статусов каждого из исполнителей: что делал вчера? что сегодня?
• Груминги — это встречи, на которых вы собираетесь и вместе приходите к решению какой-то из проблем. К примеру: «Груминг по вопросу проектирования платежей»: собираетесь и вместе думаете над архитектурой платежей.
• Ретро — вы собираетесь вместе, чтобы обсудить хорошие и плохие моменты за последний период работы. В процессе обсуждения будет круто, если вы придете к каким-то Action Pointам — задачам, которые помогут устранить плохие моменты.

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

Стендапы и дейлики: фокус или отвлечение?

Первым делом Даниил с лидом QA приняли решение внедрить 15-ти минутные ежедневные встречи по утрам.

В Озоне у меня уже было такое, признаюсь честно. Мне как разработчику так не хотелось просыпаться на него по утрам, но когда ты лид — думаешь по-другому, потому что если твоя команда будет лениться и не давать результат, придут к тебе.

Для начала важно отметить, что дейлик = стендап. Оба термина используются в Agile-методологиях (особенно в Scrum) и означают одно и то же мероприятие.

Теперь давайте представим себя на моем месте и объективно подумаем, какие плюсы есть у стендапа, чтобы даже с утра пораньше они были оправданы:

• Явная точка старта рабочего дня. Особенно актуально на удаленке, где у каждого рабочий день начинается в свое время, плюс есть те, кто не обладает силой воли каждый день в константное время вставать с кровати — для них стендап будет той самой жесткой точкой, к которой они должны войти в фокус. 
• Мотивация на результат. Стендапы подстегивают думать: «А что я скажу завтра?» Это мотивирует завершать задачи и продуктивно использовать день.
• Напоминание о темпе. Работает в том случае, если в одной команде есть и нереально продуктивные сотрудники, и те, кто работают медленнее.  Вторые будут испытывать страх и волнение и думать: «Я работаю гораздо медленнее, чем Саша… А вдруг это не нравится руководству? А вдруг премию не дадут?» И как раз благодаря стендапам и наглядному прогрессу коллег ребята могут подкорректировать свой темп, чтобы не отставать и соответствовать ожиданиям. Но здесь не перегнуть палку, чтобы избежать выгорания.
• Для руководителей. Понимаешь, кто чем занимается, направляешь, ставишь приоритеты. В моем случае ситуация такова: задач много, исполнителей мало, так еще и стоят они дорого, каждый час дорог, нужно контролировать.
• Новости по продукту или про компанию. Это занимает обычно не более 5 минут, стендапы хорошо подходят для таких мини-сводок. 
• Решение вопросов, которые затрагивают большое количество людей. Если понимаете, что текстом решить какой-то вопрос не получится и важно мнение каждого, есть смысл обсудить его на стендапе. Главное избежать такой ситуации: два исполнителя общаются между собой, пока другие просто сидят и бессмысленно тратят время. В нашем случае желательная граница созвона — 25 минут (стендап классически длится 15 минут, но иногда этого не хватает еще и для ответа на вопросы и мини-синка). Если на это уходит больше времени, нужно оптимизировать. Локальные вопросы лучше обсуждать текстом — так сохраняется история размышлений и выводов, плюс не привлекаются другие сотрудники.

Внедрение стендапов прошло хорошо — после адаптации мы заметили хорошие результаты по каждому из пунктов.

Формат стендапа: наш отработанный план встреч

Мы пришли к такому формату стендапов — он, по моему мнению, реализует максимум из того, что возможно за короткий срок до 25 минут:

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

2. Даём слово исполнителю, задавая несколько вопросов:

• Что сделал вчера? (тут можно уточнить у разработчика про статусы по важным задачам — таким образом подтолкнуть и узнать, как идет работа)
• Что планируешь делать сегодня? (здесь можно скорректировать приоритеты)
• Есть блокеры или какие-то вопросы, которые можно вкратце обсудить сейчас? (важно вовремя остановиться, чтобы дейлик не превратился в груминг)

А еще можно напомнить про вопросы в чате, на которые еще не получены ответы.

3. Всем хорошего дня — всё.

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

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

Груминги: что это такое и с чем едят?

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

Вспоминая практики Озона, я параллельно с исследованием продукта решил организовать груминг по рефакторингу. Для этого попросил ребят в чате подготовить свое видение слабых мест — так мы могли выслушать все мнения и прийти к единой картине. Так и получилось: на встрече каждый разработчик рассказал проблему, с которой столкнулся, и потенциальное решение. Затем мы все обсуждали, подтверждали или опровергали.

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

Резюмируем: зачем нужны груминги

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

Груминги занимают мало времени — в среднем на него уходит час в зависимости от сложности вопросы. Но, поверьте, результаты вас удивят.

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

Довольно быстро я пришел к следующему довольно очевидному формату:

1. Ставим встречу в первый день недели (а лучше в пятницу прошлой недели), пишешь в чате о груминге и его теме и уведомляешь каждый день на протяжении недели на стендапах то, что у нас в четверг (ориентировочно) будет груминг. Просим подготовиться, немного подумать на тему — люди обычно ленятся, но если повторять много раз так или иначе будут результаты. А еще можно попросить поставить встречу коллегу — в ребятах тоже важно растить софты таким образом, чтобы найти себе преемника и двигаться дальше в будущем.
2. На самом груминге сначала отмечаем проблему, предлагаем свои теоретические варианты решения.
3. Потом поочередно спрашиваем каждого члена команды, чтобы уничтожить фактор стеснения — так люди вынуждены будут что-то сказать.
4. Готово — дальше вы обсуждаем вопрос и приходим к решению

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

Теперь о самом приятном — ретро

Ретро — пожалуй, лучший вариант созвона для членов команды. Это время, когда можно похвалить друг друга за успехи и честно обсудить, что можно улучшить. Но когда я внедрял эту идею к нам в команде, результаты были не очень позитивные — ребята просто не знали, что нужно писать, поскольку 2 недели в Kanban — это не очень много. Поэтому в случае ретро важно правильно продумать периодичность встреч. Наиболее оптимальная схема для меня — раз в один/два месяца по ситуации. В Озоне мы, однако, пришли к одному ретро в неделю, поскольку формат работы был совсем другой — слишком меняющийся и с моментами, где правда нужно собраться и обсудить и что-то улучшить.

Какие смыслы несет ретро

1. Во-первых, это желание становиться лучше, которое идет у нас с самого детства — оно тут реализуется сполна, вы анализируете и выявляете Action Points (моменты, которые нужно улучшить) и двигаетесь далее с понимание проблемы и желанием ее решить. 
2. Тимбилдинг. В момент ретро — если все правильно организовать и не уходить в негатив — можно укреплять дружеские связи между членами команды, что тоже весьма полезно. Дружеские связи повышают привязанность к компании и команде, поэтому можно будет меньше беспокоиться о том, что человек может в один прекрасный момент уйти и оставить все проблемы нам.
3. Способствует вовлеченности человека в продукт и компанию. Тут все очевидно: в позитивной форме мы по сути заставляем людей говорить о проблемах и вытаскиваем из них предложения на улучшение процессов. Может быть через некоторое время и вытаскивать не придется — проблемы сами будут выходить.
4. Самоутверждение. На ретро можно хвалиться тем, что ты уже сделал, и самоутверждаться за счет похвал других. Зачастую бывает, что успехи людей упускаются и им не придается особого значения — ретро исправляет эту проблему.

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

Принуждение к встречам: свобода vs. контроль

Во всех компаниях, где я работал, явно обязательность встреч не отмечалась, но она, конечно, подразумевалась. Но если ты физически не можешь ее посетить — например, стало плохо или нужно срочно куда-то отъехать, то мы не давим на человека, а отпускаем.

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

Как тимлидам оптимизировать встречи

• Не допускайте того, о чем я писал выше: стендапы не должны превращаться в груминги
• Не ленитесь устраивать груминги — это полезно, поскольку вы спрашиваете мнение каждого из команды
• В ретро важно выстроить доверительное отношение — пытайтесь максимально переходить на другие темы
• Внимательно слушайте каждого члена команды. Часто бывают ситуации, когда стендапы деградируют по уровню ответов следующим образом: делал X, вот сейчас делаю Y —  всё. Уточняйте, вежливо выводите человека на чистую воду, и тогда стендап не будет лишь формальностью

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

Делитесь в комментариях, как у вас проходят созвоны? И каких моделей вообще придерживаетесь?