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

• дизайнеры
• разработчики
• маркетологи
• студенты
• фрилансеры
• стажёры
• другие участники проекта

Такой состав позволяет смотреть на решение с разных сторон и объединять разные типы экспертизы.

Команду полезно рассматривать как продукт.
У такого «продукта» тоже есть:

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

Кто может быть «пользователем» команды:

• исполнитель
• заказчик
• сами члены команды
• лид
• целевая аудитория продукта

То есть качество командной работы влияет не только на самих участников, но и на всех, кто зависит от её результата.

Хорошо организованная команда позволяет получить:

• более устойчивое решение, потому что оно проверяется с разных сторон
• постоянство производства – работа не должна полностью зависеть от одного человека
• возможность создать более крупный результат, чем при индивидуальной работе
• опыт взаимодействия с другими специалистами

Работа команды всегда ограничена ресурсами и условиями.
К таким ограничениям относятся:

• время
• бюджет
• пространство
• знания
• состав команды
• интересы участников
• конфликты
• доступность информации

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

Четыре условия:
1) организация и координация общей работы
2) одинаковое понимание задач
3) распределение и работа над задачами
4) умение говорить о том, что что-то идёт не так
Вся дальнейшая логика командной работы строится вокруг этих четырёх блоков.

Координация включает:

• ведение задач
• отслеживание статусов
• организацию встреч
• проведение встреч

контроль того, чтобы договорённости не терялись
Важно понимать, что организация – это тоже работа дополнительно к основной содержательной работе над проектом.

Есть несколько вариантов организации роли координатора:

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

Последний вариант возможен, но обычно работает хуже и требует высокой самоорганизации всей команды.

Команда может быть организована по-разному:

• через более выраженную иерархию
• через горизонтальное взаимодействие
• через распределённую ответственность

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

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

• быстрее сделать самому
• проще не согласовывать
• другие участники мешают
• распределение задач только замедляет процесс

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

Обратная связь должна быть направлена на конкретное действие, а не на человека в целом.
Например:
не:
«Ты вообще безответственный».
а:
«Ты второй раз отправляешь часть работы после согласованного срока».

Основные принципы:

• обсуждать конкретное действие
• не начинать сразу со скандала
• если проблема повторяется, постепенно усиливать реакцию
• не ждать до момента, когда терпение полностью закончится

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

После встречи важно фиксировать принятые решения.
Meeting notes нужны, чтобы:

• синхронизироваться по договорённостям
• убедиться, что все одинаково поняли результат встречи
• иметь возможность позже вернуться к решению
• не зависеть от памяти отдельных участников

Принцип можно сформулировать так:
Нет meeting notes – не было встречи.

За фиксацию встречи желательно назначить конкретного человека.
Полезно:

• вести заметки прямо во время обсуждения
• выкладывать их в общий командный чат
• давать другим участникам возможность дополнить или исправить запись
• задавать вопросы, если что-то непонятно
• отмечать конкретного человека, если за ним закреплено действие

Например:
@Аня отправит таблицу до пятницы.
Тогда заметка превращается не просто в текст, а в зафиксированное распределение обязанностей.

Короткая встреча – около 20 минут.
На ней:

• сообщают статус
• задают вопросы
• быстро синхронизируются по прогрессу

Длинная встреча – около 1–2 часов.
На ней можно:

• обсуждать концепцию
• разбирать результаты
• совместно работать
• принимать более сложные решения

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

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

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

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

Для выбора времени можно использовать общую таблицу вроде «When we meet»
Каждый участник отмечает свободные слоты, после чего команда видит:

• когда свободно большинство
• какие активности можно при необходимости перенести
• где есть устойчивое общее окно

Ещё один удобный вариант – договориться о регулярном еженедельном созвоне. Тогда встреча заранее становится частью личного расписания и её легче учитывать при планировании.

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

Вариант 1. Компенсировать нагрузку позже
Например:

• сейчас сделать меньше
• в следующем этапе запланировать больше времени
• позже внести больший вклад

Вариант 2. Разный вклад – разные оценки
Если один человек объективно делает меньше остальных, команда может договориться о разном уровне участия и соответствующей разнице в оценке.

Вариант 3. Собственная договорённость
Команда может выработать другой вариант, если он устраивает всех.
Главное – не скрывать проблему с загрузкой.

В продуктовых командах часто работают люди с разными компетенциями.
Это помогает:

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

Большую задачу необходимо разбивать на более маленькие.
Основной принцип:
делить задачу до тех пор, пока каждая часть не станет понятной.
Например, задача:
«Найти эксперта для интервью»
на самом деле может включать множество шагов:

• определить нужный профиль эксперта
• найти потенциальных людей
• найти контакты
• составить приглашение
• написать
• получить согласие
• назначить интервью

Декомпозиция помогает увидеть реальный объём работы.

После декомпозиции важно определить зависимости.
Одна задача не может начаться, пока не выполнена предыдущая.
Есть параллельные задачи:
найти эксперта → написать ему → получить согласие → провести интервью.
Их можно делать одновременно.

Например, несколько участников могут искать разных экспертов независимо друг от друга.

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

Для обсуждения сложности можно использовать:

• story points
• голосование
• другие способы коллективной оценки

Story points позволяют сравнивать задачи не только по времени, но и по общей сложности.
Например, задача может быть сложнее из-за:

• неопределённости
• большого количества шагов
• зависимости от других людей
• необходимости новых знаний

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

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

Команда должна заранее договориться:

• из чего состоит задача
• какой результат считается выполнением
• как проверить, что задача действительно закончена

Это и есть Definition of Done – критерии готовности.

Можно определить:

• результат как конкретный артефакт
• формат
• место хранения
• объём
• минимум и максимум
• сроки
• кому передаётся результат

Например, формулировка:
«Найти эксперта для интервью»
слишком неопределённая.
Слабый вариант

1. Найти список экспертов.
2. Выложить его в чат.

Более конкретный вариант

1. Найти контакты подходящих специалистов.
2. Составить базу потенциальных экспертов.
3. Подготовить приглашения.
4. Написать экспертам.
5. Получить хотя бы одно согласие на интервью.
6. Добавить результат в общую таблицу.

Во втором случае гораздо понятнее, когда задача считается выполненной.

Команда не обязана постоянно работать всем составом.
Можно:

• делиться на подгруппы
• распределять цепочки задач между мини-командами
• назначать ответственных за отдельные направления

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

Кто-то (как правило, координатор) должен следить:

• какие задачи начаты
• какие завершены
• что заблокировано
• где появились задержки
• кому нужна помощь

В командной работе важно:

• реагировать на сообщения
• рассказывать о прогрессе
• говорить о проблемах по мере их возникновения

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

Ретроспектива – это формат, который позволяет обсудить командную работу и проблемы так, чтобы
не сводить разговор к взаимным обвинениям.
Она состоит из трёх частей.
1. Хорошее
Что получилось и что стоит сохранить?
Например:

• удачный формат встреч
• понятная таблица задач
• удобное распределение ролей

2. Проблемы
Что пошло не так?
Например:

• задачи распределены слишком поздно
• участники не отвечали в чате
• решения после встречи не были зафиксированы

3. Действия
Что изменить дальше?
Важно не остановиться на:
«Вот, что было плохо».
Ретроспектива должна закончиться конкретными решениями:
«В следующий раз после каждой встречи один человек публикует meeting notes в течение дня».

Если команда не может решить проблему самостоятельно, можно постепенно подключать внешнюю помощь.
Эскалация проходит в три этапа.

Шаг 1. Консультация
Обсудить с куратором:

• что происходит
• что можно попробовать сделать самостоятельно.

При этом команда продолжает решать проблему самостоятельно.

Шаг 2. Медиация
Попросить помочь организовать коммуникацию. Посредник помогает создать условия для разговора,
но участники всё ещё сами обсуждают проблему и принимают решение.

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

У участников одной команды могут быть совершенно разные приоритеты.
Например, у кого-то основной фокус:

• работа
• основная образовательная программа
• личные проекты
• другие обязательства

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

Участников также могут мотивировать разные вещи:

• проект для портфолио
• получение новых навыков
• знакомство с новой областью
• интерес к конкретной роли

Если мотивация снижается, можно попробовать:

• добавить интересующие человека задачи
• изменить его роль
• перераспределить ответственность
• иногда – скорректировать направление проекта

Команде не обязательно делать вид, что все участники вкладываются одинаково.
Можно договориться о:

• разном уровне участия
• разном объёме работы
• разделении оценок

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