Team Working Agreements: правила команды, которые действительно помогают
Team Working Agreements: правила команды, которые действительно помогают
Рубрика: «Из жизни тимлида»
В понедельник писал про готовность задач.
Но даже хорошо подготовленная задача может застрять, если у команды нет общих правил работы.
Большинство команд живёт по правилам.
Просто эти правила часто нигде не записаны.
Кто-то считает нормальным поставить встречу на свободное место в календаре.
Кто-то ожидает ревью в тот же день.
Кто-то пишет обо всех блокировках на daily.
Кто-то молчит неделю, потому что «пока пытаюсь разобраться сам».
Кто-то уверен, что открытый PR кто-нибудь обязательно заметит.
В итоге получается распределённая система без протокола.
Что даже для людей несколько рискованно.
А потом команда удивляется конфликтам, задержкам и разным ожиданиям.
Team Working Agreements — это явные договорённости о том, как команда работает вместе.
Не корпоративный кодекс.
Не документ про ценности.
Не «мы уважаем друг друга и стремимся к excellence».
Это практические правила, которые уменьшают неопределённость в ежедневной работе.
Например, команда может договориться:
- где задавать несрочные вопросы;
- когда писать лично;
- что считается срочным;
- за какое время обычно отвечаем;
- какие решения обязательно фиксируем письменно;
- когда встреча действительно нужна;
- можно ли отказаться от встречи без повестки;
- кто назначает ревьюера;
- за какое время PR должен получить первый взгляд;
- когда спор в комментариях пора переносить в разговор;
- сколько задач можно вести одновременно;
- когда задача считается заблокированной;
- когда нужно эскалировать проблему.
Это не звучит как что-то великое и стратегическое.
Но именно на таких мелочах команда часто теряет больше всего времени.
Пример небольшого набора договорённостей:
- блокировка дольше четырёх часов поднимается в командном чате;
- PR получает первый отзыв в течение рабочего дня;
- решение после встречи фиксируется в задаче;
- срочная задача должна сопровождаться решением, что снимается с текущей работы;
- встречи после 16:00 не ставятся без явной необходимости;
- у разработчика одновременно не больше двух активных задач.
Цифры здесь не универсальные.
Их нельзя торжественно скопировать в каждую команду и ожидать наступления инженерного рая.
Смысл не в конкретных числах.
Смысл в том, чтобы у команды появилась общая версия реальности.
Плохая договорённость:
Звучит красиво, но непонятно, что делать завтра.
Рабочая договорённость:
Тут уже есть конкретное поведение.
Как такие правила создавать?
Лучше не писать их тимлиду единолично и не спускать команде сверху.
Я бы шёл так:
1. Собрать повторяющиеся проблемы команды.
2. Выбрать 3–5 самых болезненных.
3. Сформулировать конкретные правила.
4. Договориться, как замечать нарушения.
5. Через месяц пересмотреть договорённости.
Последний пункт важен.
Working Agreements — это не каменная плита с заповедями.
Это рабочий инструмент.
Команда изменилась, нагрузка изменилась, процесс изменился — договорённости тоже могут измениться.
Что делает такие правила бесполезными:
- слишком много пунктов;
- абстрактные формулировки;
- правила без конкретного поведения;
- отсутствие пересмотра;
- разные правила для руководителя и команды;
- документ, который никто не открывал после создания.
Working Agreements нужны не для того, чтобы контролировать каждый шаг команды.
Они нужны, чтобы люди не тратили силы на постоянное угадывание чужих ожиданий.
Потому что когда правила не проговорены, они всё равно существуют.
Просто у каждого свои.
А это уже не командная работа, а интеграция через сюрпризы.
Какая одна договорённость сильнее всего упростила бы работу вашей команды прямо сейчас?
Рубрика: «Из жизни тимлида»
В понедельник писал про готовность задач.
Но даже хорошо подготовленная задача может застрять, если у команды нет общих правил работы.
Большинство команд живёт по правилам.
Просто эти правила часто нигде не записаны.
Кто-то считает нормальным поставить встречу на свободное место в календаре.
Кто-то ожидает ревью в тот же день.
Кто-то пишет обо всех блокировках на daily.
Кто-то молчит неделю, потому что «пока пытаюсь разобраться сам».
Кто-то уверен, что открытый PR кто-нибудь обязательно заметит.
В итоге получается распределённая система без протокола.
Что даже для людей несколько рискованно.
А потом команда удивляется конфликтам, задержкам и разным ожиданиям.
Team Working Agreements — это явные договорённости о том, как команда работает вместе.
Не корпоративный кодекс.
Не документ про ценности.
Не «мы уважаем друг друга и стремимся к excellence».
Это практические правила, которые уменьшают неопределённость в ежедневной работе.
Например, команда может договориться:
- где задавать несрочные вопросы;
- когда писать лично;
- что считается срочным;
- за какое время обычно отвечаем;
- какие решения обязательно фиксируем письменно;
- когда встреча действительно нужна;
- можно ли отказаться от встречи без повестки;
- кто назначает ревьюера;
- за какое время PR должен получить первый взгляд;
- когда спор в комментариях пора переносить в разговор;
- сколько задач можно вести одновременно;
- когда задача считается заблокированной;
- когда нужно эскалировать проблему.
Это не звучит как что-то великое и стратегическое.
Но именно на таких мелочах команда часто теряет больше всего времени.
Пример небольшого набора договорённостей:
- блокировка дольше четырёх часов поднимается в командном чате;
- PR получает первый отзыв в течение рабочего дня;
- решение после встречи фиксируется в задаче;
- срочная задача должна сопровождаться решением, что снимается с текущей работы;
- встречи после 16:00 не ставятся без явной необходимости;
- у разработчика одновременно не больше двух активных задач.
Цифры здесь не универсальные.
Их нельзя торжественно скопировать в каждую команду и ожидать наступления инженерного рая.
Смысл не в конкретных числах.
Смысл в том, чтобы у команды появилась общая версия реальности.
Плохая договорённость:
Уважительно относимся ко времени коллег.
Звучит красиво, но непонятно, что делать завтра.
Рабочая договорённость:
Не ставим встречи без повестки и ожидаемого результата.
Тут уже есть конкретное поведение.
Как такие правила создавать?
Лучше не писать их тимлиду единолично и не спускать команде сверху.
Я бы шёл так:
1. Собрать повторяющиеся проблемы команды.
2. Выбрать 3–5 самых болезненных.
3. Сформулировать конкретные правила.
4. Договориться, как замечать нарушения.
5. Через месяц пересмотреть договорённости.
Последний пункт важен.
Working Agreements — это не каменная плита с заповедями.
Это рабочий инструмент.
Команда изменилась, нагрузка изменилась, процесс изменился — договорённости тоже могут измениться.
Что делает такие правила бесполезными:
- слишком много пунктов;
- абстрактные формулировки;
- правила без конкретного поведения;
- отсутствие пересмотра;
- разные правила для руководителя и команды;
- документ, который никто не открывал после создания.
Working Agreements нужны не для того, чтобы контролировать каждый шаг команды.
Они нужны, чтобы люди не тратили силы на постоянное угадывание чужих ожиданий.
Потому что когда правила не проговорены, они всё равно существуют.
Просто у каждого свои.
А это уже не командная работа, а интеграция через сюрпризы.
Какая одна договорённость сильнее всего упростила бы работу вашей команды прямо сейчас?