Управление командой - Weekly встреча

Меня тут спрашивают, а какие практические инструменты я использую при управлении командами. Я сильно сомневаюсь, что у меня тут know how, но минимум несколько коллег эту практику скопировали, значит она не так плоха 😉

В нашем продукте принято называть такую встречу Weekly. По аналогии с другим agile ритуалом.

Как руководителю нескольких команд, мне доступен ряд способов получения и валидации данных об их работе:

Тут вроде бы все просто.

Мы участвуем в многих общих статусах — синках по ключевым направлениям, члены команды докладывают, я слушаю и валидирую.

Информация в этом случае чаще всего либо об успехах, либо о жалобах/запросах помощи.

Опасная иногда, почти всегда требующая осторожной обработки, но очень важная информация. И она почти всегда о рисках.

Дело в том, что люди регулярно стесняются или не видят необходимость приносить плохие новости. А еще, как говорил Доктор Хаус: «Все люди лгут» (с) 🤷🏻‍♂

Тут обратная связь идет от других команд (как продуктовых, так и сервисных), руководителей и много еще откуда.

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

Основной проводник истории про приоритеты в команды — это функциональный лидер: Product Owner или Service Delivery Lead. Это очень важная и непростая роль, куда не берут неопытных людей.

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

Weekly мешает лидерам команды (и мне в том числе) и ее всем участникам «переобуваться» или «забывать» проговоренное в потоках информации.

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

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

Что можем — решаем здесь и сейчас, что не можем — добавляем в календарь, уже не на всю команду, а на тех, кто нужен для deep dive.

Я со своей стороны стараюсь пропускать Weekly очень редко.

Я не просто записываю «логи аудита», но и стараюсь по ним проявлять эмоции:

- хвалить, если есть за что,

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

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

Или я, отвечающий по роли за видение «большой картинки», могу подсветить команде то, что они не замечают, например:

- Разницу в видении на общую активность с другой командой

- Отклонения по различным параметрам производственного процесса, которые собираются по цифровым следам команды.

Такой вот team tunning.

Можно смотреть на работу команды под огромным количеством углов наблюдения. Это иногда мешает сфокусироваться на главном.

Шаблон Weekly не отлит в граните, но я стараюсь делать акцент на трех вещах.

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

В качестве источника данных уже давно привыкли использовать скриншот с страницы в Confluence с соответствующими фильтрами по JIRA.

В Сбере это пресловутый Lead Timе. Я лучше метрики и не знаю, если честно, но с его расчетом часто любят спорить.

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

Тут особо регламента нет, могу записать любую тему.

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

Мы привыкли выделять желтым куски статуса, по которым не было изменений за неделю. Такое привлечение фокуса.

Также важную или опасную информацию — риски или проблемы — пишем просто красным текстом.

#командаСбера #практика #weekly #teamtuning