Как вести коммуникацию на проекте: держим в курсе заказчика и контролируем исполнителей

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

Управление коммуникацией лежит на плечах менеджера — он выступает как лидер продакшн-команды, лицо компании и эксперт. 

Менеджер находится на стыке всего:

1. команды, которой хочется выполнять задачи в спокойном темпе и не работать сверхурочно;
2. руководства, которому важно, укладывается ли разработка в бюджет;
3. заказчика, который хочет получить релиз вовремя без неприятных сюрпризов.

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

Как информировать заказчика о ходе проекта

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

Для этого можно использовать отчёты по задачам, созвоны и демо-презентации.

Отчёты

С их помощью команда говорит и показывает, что всё под контролем и идёт по плану. А заказчик чувствует, что держит руку на пульсе.

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

Важные правила:

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

Звонки и презентации

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

Это:

1. позваоляет демонстрировать проделанную работу и её прогресс;
2. даёт дополнительную точку коммуникации;
3. позволяет держать команду в тонусе, двигаться чётко от точки к точке.

Важные правила:

1. Включать при звонке камеру. Серые квадратики всегда отталкивают и обезличивают контакт.
2. НИКОГДА не опаздывать. Если случаются непредвиденные обстоятельства, всегда предупреждать заранее и ориентировать, на сколько задержитесь. Если опоздание больше 15 минут — предлагайте перенести, но это крайний случай.
3. Любой звонок должен заканчиваться обменом договоренностями, которые дополнительно нужно закрепить письменно. Это может быть краткое резюме доработок и срок их готовности, или дата обратной связи от заказчика, или дата следующего созвона. Без этого звонок бесполезен, потому что вы ни к чему не пришли.

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

1. Назначить звонок, согласовать время с заказчиком. Сразу в календарь себе создаём задачу на созвон, генерируем ссылку. Средний тайминг на брифы 1,5–2 часа, на демо 1–2 часа.

2. Менеджер должен выделить себе время на подготовку к звонку. Хорошо подходит текстовый формат в виде повестки: участники звонка, их роли, план обсуждения в порядке приоритетности и цели созвона/дальнейшие контрольные точки. Менеджер — модератор для серьёзных встреч или для встреч по разбору конфликта.

3. За 10-15 минут до звонка написать заказчику, уточнить, все ли в силе.

4. В ходе звонка фиксируем основные тезисы. Если сложно писать и слушать — записываем разговор. Всегда нужно записывать ключевые пункты беседы на ходу. Абсолютно нормально сказать: «Коллеги, минутку, я зафиксирую то, что мы только что обсудили».

5. Обязательно планируем 10-30 минут на резюме звонка (зависит от объема обсуждаемого). Формат: важные тезисы + план дальнейших действий.

6. Менеджер ставит в календарь себе и сотрудникам задачи на встречи и контролирует договорённости.

Демо

Демонстрация проекта (или просто демо) — это представление итогов работы клиенту в конце спринта.

Кто участвует

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

Рекомендации

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

Важные правила:

• Демонстрирующему нужно отключить все уведомления, чтобы никто не видел личные сообщения. Это очень частая ошибка.
• Перед демонстрацией проверить технику: связь, показ экрана, звук, дополнительные инструменты. Это нужно, чтобы не заставлять всех присутствующих ждать, пока вы с этим разберетесь на месте. Чаще всего на демо сидит много важных людей, у которых каждая минута — это большие деньги.
• Подготовьте нужные логины, пароли и ссылки. Бывает, что нужно показать функциональность и со стороны админа, и со стороны пользователя. Или продемонстрировать взаимодействие двух типов пользователей, например, врача и пациента в медицинском приложении. Для каждого из них нужен отдельный профиль.
• Подготовьте тестовые данные. Наполните страницы данными, приближенными к реальности, а не откровенной рыбой. К примеру, заказчик сказал, что все товары в его интернет-магазине — конвекторы. Можно назвать страницы товара «Конвектор 1», «Конвектор 2», «Конвектор 3» и так далее. Но не называть «Тест 1». Очень часто создают юзеров Тест Тестович. Лучше сделать что-то нейтральное, вроде Иванов Иван Иванович, или использовать любые другие имена, похожие на настоящие.
• Демонстрирующему нужно предварительно проверить все материалы, которые он будет показывать. Внимательно посмотреть, какие могут быть вопросы, шероховатости, всё уладить и только тогда выходить на созвон с клиентом.
• После демо фиксируйте резюме и отправляйте всем участникам. В нём нужно отразить вопросы и решения по повестке: что одобрено, что нужно доработать, в какие сроки, кто ответственный. Иначе это будет просто выстрел в воздух.

Критерии успешного демо

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

Как часто нужно проводить демо

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

Если разработка просто идёт по этапам, тогда демо проводят после каждого этапа — проектирования, дизайна, разработки и так далее. 

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

Стендапы

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

План стендапа:

1. Менеджер предварительно изучает статусы по задачам, отвечает на вопросы от специалистов с прошлого стендапа.
2. Ставит всем членам команды встречу на стендап в одно и то же время. 
3. На встрече менеджер включает демонстрацию экрана и получает ответы на три вопроса от каждого спеца: Что сделано за вчера? Что планируется на сегодня? Есть ли вопросы, проблемы, блокеры?
4. Менеджер фиксирует резюме стендапа в комментарии задачи.

Чек-лист успешного стендапа

1. Время стендапа заранее проставлено у каждого участника команды в календаре.
2. На стендапе присутствуют все участники этапа. 
3. Запланированные вчера задачи выполнены.
4. У выполненных задач и тех, что в работе, не превышены запланированные оценки.
5. Всем задачам на текущий день были проставлены исполнители, даты выполнения задачи, внесена оценка, актуализирован статус.
6. Блокеры и вопросы вынесены в отдельную задачу. Задача запланирована менеджером на обработку и дальнейшее включение в план работ.
7. Зафиксированы договоренности по итогам стендапа в комментариях задачи.
8. Все исполнители понимают план работ на текущий день.

Что делать если:

Нужно идти на следующий стендап, а по текущему вопросы не решены

Менеджер не может покинуть стендап проекта, пока не будут выполнены пункты из чек-листа выше.

Вы не уложились в тайминг стендапа

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

Менеджер не может прийти на стендап

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

Исполнитель говорит, что задача готова, но есть нюансы

Задача не является готовой в этом случае. Нужно донести это до специалиста. Получить информацию:

1. Описание того, что нужно доделать до готового результата.
2. Оценку по доработке задачи.
3. Проанализировать необходимость доработок.
4. Запланировать задачи по доработкам.

Итого

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

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