Как общаться в команде: встречи, согласование, эскалации

Большинство рабочих проблем решается разговором, но не любым. Один и тот же вопрос в общем чате теряется, на часовом созвоне растворяется, а в письме застревает без ответа. Выбор формата, повестка и запись решения определяют, закончится ли разговор результатом. Разберём, как это работает, на примере одного созвона «Узелка».

Кейс: созвон без решения

Владелец «Узелка» хочет скидку 10% на второй заказ и собирает всех на созвон. Приходят владелец, разработчик, тестировщик и сотрудница поддержки. Разговор идёт сорок пять минут: разработчик называет две недели, поддержка боится путаницы со старыми заказами, владелец спрашивает, нельзя ли быстрее. Заканчивают словами «давайте подумаем». Через неделю выясняется, что каждый понял итог по-своему, а срок так и не назван.

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

Какая встреча для чего

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

Формат	Для чего	Кто нужен	Что остаётся после
Сообщение в чате	Короткий вопрос, на который можно ответить «да», «нет» или одной фразой	Один человек, который знает ответ	Ответ в переписке
Планирование	Решить, какие задачи берёт команда и в каком порядке	Команда и владелец	Список задач на ближайший период
Обсуждение требований	Разобрать, как должна работать новая функция	Аналитик, владелец, разработчик, тестировщик	Записанные решения и открытые вопросы
Демонстрация (демо)	Показать готовую работу и собрать отзывы	Команда, владелец и те, кому работа нужна	Решение: принято, нужны правки или нет
Разбор ошибки	Выяснить причину и решить, что делать	Поддержка, разработчик, тестировщик	Причина, владелец исправления и срок

В командах, которые работают по Scrum (одному из подходов с короткими периодами работы), планирование и демонстрацию проводят по расписанию: первая начинает период работы, вторая проверяет его результат. Подходы к организации работы разбирает статья 01-07.

Как провести встречу, чтобы остался результат

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

Повестку и письмо с итогами обычно готовит тот, кто ведёт встречу; на встречах про требования это часто аналитик. Типичная ошибка: решить на встрече и не записать. Через неделю каждый помнит свой вариант, и разговор начинается заново. Вторая ошибка: звать всех «на всякий случай». Чем больше людей, у которых нет роли в вопросе, тем дольше разговор, а решение всё равно принимает один человек.

Как согласовать решение

Согласование означает явное подтверждение решения теми, кто за него отвечает. Недостаточно, чтобы никто не возразил на созвоне: молчание не отвечает на вопрос «согласен ли вы». Хорошее предложение к согласованию содержит три части: один или два варианта с последствиями, рекомендацию и срок, до которого нужен ответ. Например: «Скидка 10% на второй заказ. Вариант А: считать от суммы второго заказа, две недели работы. Вариант Б: только для заказов после запуска, неделя. Рекомендуем Б. Нужен ответ до пятницы, иначе не успеем к выпуску». Ответ фиксируют письменно там, где его потом найдут.

Частая ошибка: согласовать с тем, кто не принимает решение. Владелец решает, что делать, разработчик отвечает за срок, а вопрос о правах доступа решает тот, кто отвечает за безопасность. Если спросить не того, ответ придётся переспрашивать. Как оформлять и хранить результаты согласований, рассказывает статья 08-03, а какие вопросы задавать, чтобы получить решение, статья 02-04.

Когда нужна эскалация

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

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

Где это встречается в работе

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

Итог

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

Что дальше

• 01-07. Методологии разработки: обзор
• 02-04. Уточняющие вопросы
• 08-03. Протокол встречи
• 01-06. От идеи до релиза: жизненный цикл разработки и путь задачи

Источники

• The Scrum Guide. Планирование как начало периода работы, обзор результата как его проверка.