Команда может месяцами работать вместе и всё равно по-разному понимать свою главную цель, ответственность тимлида, допустимое время ответа на code review и способ принятия технических решений. Team Canvas помогает обнаружить такие расхождения до того, как они превратятся в повторяющиеся конфликты.

В Team Canvas важна не заполненная доска, а разговор об ожиданиях, которые каждый участник до этого считал очевидными. Форму нельзя просто разослать, собрать ответы и считать работу законченной. Команда должна одновременно открыть записи, увидеть расхождения и договориться, что изменит в работе.

Какую проблему решает Team Canvas

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

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

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

Team Canvas создаёт структуру для обсуждения таких вопросов. Авторы называют его аналогом Business Model Canvas для команд и предлагают использовать для прояснения целей, ролей, мотивации, ожиданий и правил совместной работы.

Basic или Complete

У Team Canvas есть две версии. Выбор зависит от задачи встречи.

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

Complete нужен, когда команда работает давно, появились расхождения, изменился состав или пора пересобрать договорённости. Он состоит из девяти блоков с общими и личными целями, сильными сторонами, рисками и ожиданиями. Полная сессия занимает 90–120 минут.

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

Дальше речь пойдёт о Complete. Чтобы не перескакивать между девятью блоками, сгруппируем их в четыре вопроса.

Кто мы и чего хотим добиться

Первая группа объединяет People & Roles, Common Goals и Personal Goals.

Люди и роли

Названия должностей почти ничего не говорят о реальной ответственности. Из записи «Владимир, Tech Lead» не следует, кто принимает финальное решение в архитектурном тупике, кто отвечает за развитие инженеров, кто координирует работу с другими командами и кто решает во время production-инцидента.

Поэтому рядом с ролью пишем две или три фактические зоны ответственности:

Владимир, Tech Lead. Отвечает за техническое направление, развитие инженеров и финальное решение, если команда не смогла договориться.

Расписывать ответственность по всем задачам здесь незачем. Ищем только места, где одну и ту же роль участники понимают по-разному.

Общая цель

Цель описывает результат, который можно проверить.

Слабые формулировки:

  • сделать хороший backend;
  • закрывать задачи спринта;
  • переписать сервис на Go.

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

До конца квартала сохранить p95 времени ответа API не выше 200 мс при двукратном росте нагрузки.

Теперь любую новую инициативу можно сопоставить с измеримым результатом: рефакторинг либо приближает к этим 200 мс, либо требует отдельного обоснования.

Личные цели

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

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

Личные цели не должны приниматься голосованием. Участник может объяснить свою мотивацию, но команда не решает, какая мотивация для него правильная.

Зачем существует команда и что для неё важно

В оригинальной форме эти блоки называются Purpose и Values. По смыслу они отвечают на два вопроса: «Зачем существует команда?» и «На какие принципы она опирается?»

Зачем мы это делаем

Цель описывает результат. Этот блок объясняет, зачем результат нужен пользователю, продукту или компании.

Например:

Цель: снизить p95 latency API до 100 мс.

Зачем: пользователь должен получать мгновенную реакцию системы и не замечать технических ограничений продукта.

Или:

Предполагаемая цель: перенести сервис с Ruby на Go.

Зачем: сохранить предсказуемую производительность при росте нагрузки.

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

Ценности как наблюдаемое поведение

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

Каждую ценность переводим в поведение, которое можно увидеть:

  • качество: не сливаем изменения без code review и зелёных обязательных проверок;
  • прозрачность: сообщаем о риске срыва срока в день, когда его увидели;
  • ответственность: обнаружив проблему, исправляем её или находим владельца;
  • уважение: критикуем решение и аргументы, а не человека.

Если участники не могут привести пример поведения, ценность пока остаётся лозунгом.

На что команда может опереться и что ей мешает

Третья группа включает Strengths & Assets, Weaknesses & Risks и Needs & Expectations. Здесь разговор становится чувствительнее, поэтому ведущему особенно важно не оценивать ответы и не превращать встречу в публичную оценку сотрудников.

Сильные стороны и активы

Команда фиксирует не только технологии, но и знания домена, связи с другими подразделениями и способы совместной работы: сильную продуктовую аналитику, умение быстро собирать прототипы, опыт разбора production-инцидентов, понимание предметной области.

Одна и та же запись иногда оказывается и сильной стороной, и риском. Если в Kafka разбирается только один инженер, у команды есть нужная экспертиза, но знания сосредоточены у одного человека. Следующее действие понятно: передать часть знаний другим участникам команды.

Слабые стороны и риски

Главное правило этого блока: каждый говорит о своих ограничениях и общих рисках команды. Недостатки коллег сюда не попадают.

Подходящие ответы:

  • только один человек понимает billing;
  • мы поздно подключаем QA;
  • архитектурные решения остаются в переписке;
  • мне трудно принимать решение при недостатке информации;
  • команда зависит от внешнего API без согласованного SLA.

Неподходящий формат: «Петя всегда затягивает review». Такой вопрос нужно обсуждать отдельно и с конкретными наблюдениями, а не записывать персональную претензию в раздел рисков.

Потребности и ожидания

Это один из самых практичных блоков. Вопрос звучит так: «Что мне нужно от команды, чтобы хорошо работать?»

Ответы инженерной команды могут быть конкретными: два часа focus time без встреч, первая реакция на pull request в течение рабочего дня, раннее сообщение об изменении приоритетов, прямая обратная связь при несогласии с решением, контекст задачи до начала реализации.

Потребность конкретного человека не требует общего одобрения. Вопрос только в том, может ли команда её поддержать: если человеку нужны два часа без встреч, регулярные созвоны с 10:00 до 12:00 можно не назначать.

Как команда будет работать

В последний блок, Rules & Activities, попадают конкретные договорённости из предыдущих обсуждений.

Слабое правило:

Быстро отвечаем на сообщения.

Проверяемая договорённость:

При production-инциденте пишем в рабочий чат с пометкой «срочно» и ожидаем первую реакцию дежурного в течение 15 минут. Несрочные вопросы фиксируем в задаче; ответ на них ожидается в течение рабочего дня.

Другие примеры:

  • pull request получает первую реакцию в течение одного рабочего дня;
  • значимые архитектурные решения фиксируются в ADR (Architecture Decision Record);
  • команда стремится к общему решению, но после 30 минут обсуждения его принимает заранее назначенный ответственный;
  • production-инцидент имеет приоритет над задачами спринта;
  • после серьёзного инцидента проводится разбор без поиска виноватого;
  • Product Manager сообщает команде об изменении приоритета и объясняет причину.

Каждое правило решает проблему, которую команда обнаружила в предыдущих блоках. Чужой список хороших практик копировать бессмысленно.

Как провести сессию

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

Подготовка

  1. Сформулируйте причину встречи. Не «нам нужно заполнить Canvas», а «мы по-разному понимаем приоритеты и хотим договориться о способе принятия решений».
  2. Выберите Basic или Complete. Не пытайтесь провести полную версию за 45 минут.
  3. Пригласите всех, чья ежедневная работа зависит от договорённостей команды.
  4. Подготовьте доску, таймер и отдельную область для вопросов, которые требуют отдельного обсуждения.
  5. Заранее объясните, что личные цели, потребности и ограничения не оцениваются голосованием.

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

Независимые ответы перед обсуждением

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

Если тимлид первым скажет: «Наша главная цель на квартал это надёжность», остальные участники могут подстроить свои ответы под эту формулировку. Независимая запись показывает исходную картину: тимлид написал про надёжность, Product Manager про конверсию, разработчик про долгие запросы, QA про снижение дефектов.

Так команда обнаруживает расхождение, которое обычный вопрос «все согласны?» мог бы скрыть.

Обсуждение различий

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

  • Эти записи описывают разные цели или разные стороны одной цели?
  • Какой результат важен к конкретной дате?
  • Что находится в зоне влияния команды?
  • По какому признаку мы поймём, что договорённость работает?

Если один вопрос занимает слишком много времени, переносим его в отдельный список. Авторы Team Canvas тоже советуют не позволять одной теме поглотить всю сессию. Вместе с вопросом записываем, кто организует продолжение и когда состоится следующий разговор.

Не всё требует общего решения

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

Завершение

В конце попросите каждого участника назвать одно главное наблюдение. Затем отдельно выпишите:

  • принятые договорённости;
  • открытые вопросы;
  • ответственных за следующие действия;
  • дату пересмотра Canvas.

Что должно остаться после встречи

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

  1. Наша цель на квартал: выдержать двукратный рост нагрузки без ухудшения SLA.
  2. Архитектурные решения принимаем сообща. Если за 30 минут не договорились, финальное решение принимает заранее назначенный ответственный.
  3. Первая реакция на pull request должна появиться в течение рабочего дня.
  4. Два часа с 10:00 до 12:00 оставляем без регулярных встреч.
  5. О риске срыва срока сообщаем сразу после обнаружения.
  6. Значимые решения фиксируем в ADR.
  7. Через шесть недель проверяем, какие договорённости работают, а какие нужно изменить.

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

Когда Team Canvas помогает

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

Для запуска проекта часто достаточно Basic. Для давно работающей команды с накопившимися расхождениями лучше Complete. Авторы советуют периодически возвращаться к Canvas, особенно после изменений состава; в полной инструкции также предлагаются регулярные встречи для сверки договорённостей.

Когда Team Canvas не поможет

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

Команда может честно записать, что постоянная смена приоритетов разрушает планирование. Если руководство продолжает менять приоритеты несколько раз в неделю и не объясняет причины, ещё одна командная встреча не устранит источник проблемы.

У инструмента есть и важное условие: участники должны чувствовать, что могут безопасно не соглашаться. Если несогласие с руководителем влияет на оценку человека, независимые стикеры помогут мало. Тогда зовём нейтрального ведущего, договариваемся о конфиденциальности ответов заранее или откладываем Team Canvas до момента, когда участники смогут говорить без риска для себя.

Когда считать, что сработало

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

Материалы