Как мы пишем еженедельные отчеты для клиентов

Привет, Хабр!

Недавно запустили в работу новую фичу — еженедельные отчеты для клиентов. Суть такова: руководитель проекта каждый понедельник составляет письмо-отчет, в котором описывает текущую ситуацию по проекту. И отправляет клиенту. Особенность в том, что для отчета мы придумали особую форму. Сейчас расскажу по порядку.

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



Рядом с каждой строчкой мы ставим цветную звездочку. Зеленая — проблем нет, желтая — есть проблемы, красная — проблемы критичны.

Таким образом, клиенту достаточно взглянуть на две звездочки в начале письма (ничего не читая) и за полсекунды понять, как дела на проекте. Например, сочетание означает «сейчас на проекте всё хорошо, но в будущем может стать хуже». А дальше идет подробный структурированный отчет (с объяснениями, почему может стать хуже).

Подробности подаются в такой последовательности:

• Сроки, бюджет, даты релизов (проекта и отдельных этапов), планы.
• Затем следуют проблемы, идеи, риски, вопросы клиенту.
• После отмечаем «информирующие» моменты, которые могут пригодиться клиенту. К примеру, запуск сервиса-конкурента.

Как к этому пришли?

Потребность клиента следить за состоянием проекта — присутствовала всегда. Поначалу мы тоже отправляли отчеты, текстовые, в «свободной» форме. Потом пришли к выводу, что мы сами хотели бы еженедельно отслеживать состояние проекта по некоторым показателям (важным для нас). Написали вот такой список:



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



Так и появился отчет с цветными пиктограммами.

Для единообразия отчетов к ним были предъявлены вполне конкретные требования:

Отчет должен «читаться» с первого раза:

• «Пирамидная» структура отчета: сначала главное, потом — детализация.
• Активное использование пиктограмм и цветовых обозначений.
• Никаких прикрепленных файлов! Только само письмо! (На приложения иногда просто не обращают внимания)

Разграничение индикаторов в отчете на группы:

• Первостепенные (сюда относятся первые две строчки (состояние и прогноз), даты релиза проекта и текущего этапа, бюджет, важные для клиента моменты).
• Второстепенные (планы, возникающие проблемы, идеи, риски, и уточняющие вопросы к клиенту).

Наличие резюмирующей части, куда входит:

• Обратная связь.
• Информация о событиях, которые могут оказать воздействие на бизнес клиента.

В этом же отчете мы не просто обозначаем возникшие (или могущие возникнуть) проблемы, но и предлагаем возможные пути их решения. Клиенту остается отреагировать на письмо.

Зачем вообще нужен еженедельный отчет?

Он преследует несколько целей — как совсем очевидных, так и не очень.

Во-первых, он обеспечивает прозрачность процесса разработки. Цель стратегическая. Это удобно для самого заказчика (владельца бизнеса), так и для его представителя, формально «ответственного» за использование бюджета. Когда на руках имеется вся история процесса работы, за нее легче отчитываться.

Во-вторых, этот отчет управляет ожиданиями клиента. В отчете содержатся не только текущие статусы проекта, но и реалистичные прогнозы. А они-то и формируют адекватные ожидания и снижают риск того, что однажды возникнет конфликт интересов.

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

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

В-пятых, отчет является «жопоприкрывательной бумагой». Мы намеренно пишем отчеты без какой-либо отсылки к конкретным людям, по вине которых что-то пошло не так (даже если действительно проблемы на проекте возникли по их вине). Только текущие проблемы, возможные проблемы (в прогнозе) и вероятные пути решения этих проблем. Таким образом, менеджер, представляющий заказчика, имеет на руках документ, на который всегда можно сослаться в случае возникновения конфликта и объяснить самому заказчику, что проблема возникла вот по этим конкретным причинам.

Кстати, есть такое незаметное, но сверх-полезное человеческое качество, как «умение сообщать о проблемах». Я не так давно даже проводил опрос на эту тему среди коллег. Если на стороне заказчика с вами работает менеджер, склонный к откладыванию проблем на потом, то отчет — не самое худшее средство лишить его такой привилегии.

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

Итак, что имеем:

Что: Отчет о текущем и будущем состоянии проекта.
Кто пишет: Руководитель проекта.
Как часто: Утром каждого понедельника.
Кому отправляет: На электронную почту менеджера заказчика + копия на мою почту.

Конечно, не обошлось без проблем. Главная сложность заключается в тотальной нелюбви людей писать отчеты. Вот с чем придется бороться:

• Руководители проектов постоянно будут откладывать такую рутинную задачу «на потом».
• Придется приучить не только своих, но и менеджеров клиента — своевременно читать отчеты и реагировать на них.

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

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