Команда может месяцами работать вместе и всё равно по-разному понимать свою главную цель, ответственность тимлида, допустимое время ответа на 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 мс при двукратном росте нагрузки.

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

Личные цели

У бизнеса есть цели. У команды тоже. Но у каждого участника остаются собственные профессиональные интересы: разработчик хочет глубже изучить 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 до момента, когда участники смогут говорить без риска для себя.

Практический план первой встречи

Если хочется попробовать инструмент без лишней подготовки, можно начать так:

  1. Откройте описание двух версий Team Canvas и выберите подходящую.
  2. Для новой команды запланируйте 45 минут на Basic. Для действующей команды запланируйте два часа на Complete.
  3. Объясните участникам конкретную проблему, ради которой проводится встреча.
  4. На каждый вопрос сначала собирайте независимые ответы, затем начинайте обсуждение.
  5. Не оценивайте личные цели и потребности голосованием.
  6. Переводите ценности в наблюдаемое поведение.
  7. Завершите встречу коротким рабочим соглашением и списком следующих действий.
  8. Назначьте дату пересмотра договорённостей.

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

Материалы