Привет!
Недавно запустили в работу новую фичу — еженедельные отчеты для клиентов. Суть такова: руководитель проекта каждый понедельник составляет письмо-отчет, в котором описывает текущую ситуацию по проекту. И отправляет клиенту. Особенность в том, что для отчета мы придумали особую форму. Сейчас расскажу по порядку.
Итак, структура письма. Первые две строчки — самые важные для клиента. Первая — это текущее состояние проекта, ответ на глобальный вопрос «Всё ли хорошо?». Вторая — это прогноз: «Всё ли будет хорошо?»
Рядом с каждой строчкой мы ставим цветную звездочку. Зеленая — проблем нет, желтая — есть проблемы, красная — проблемы критичны.
Таким образом, клиенту достаточно взглянуть на две звездочки в начале письма (ничего не читая) и за полсекунды понять, как дела на проекте. Например, сочетание 
означает «сейчас на проекте всё хорошо, но в будущем может стать хуже». А дальше идет подробный структурированный отчет (с объяснениями, почему может стать хуже).
Подробности подаются в такой последовательности:
- Сроки, бюджет, даты релизов (проекта и отдельных этапов), планы.
- Затем следуют проблемы, идеи, риски, вопросы клиенту.
- После отмечаем «информирующие» моменты, которые могут пригодиться клиенту. К примеру, запуск сервиса-конкурента.
Как к этому пришли?
Потребность клиента следить за состоянием проекта — присутствовала всегда. Поначалу мы тоже отправляли отчеты, текстовые, в «свободной» форме. Потом пришли к выводу, что мы сами хотели бы еженедельно отслеживать состояние проекта по некоторым показателям (важным для нас). Написали вот такой список:
Затем попробовали придать всему этому «визуальности», упростить восприятие. Сделали форму с подкрашенными участками (где зеленое — там всё хорошо, где красное — критические проблемы, требующие срочного решения). Сама таблица стала дико непонятной, но идея с цветами нам понравилась.
Так и появился отчет с цветными пиктограммами.
Для единообразия отчетов к ним были предъявлены вполне конкретные требования:
Отчет должен «читаться» с первого раза:
- «Пирамидная» структура отчета: сначала главное, потом — детализация.
- Активное использование пиктограмм и цветовых обозначений.
- Никаких прикрепленных файлов! Только само письмо! (На приложения иногда просто не обращают внимания)
Разграничение индикаторов в отчете на группы:
- Первостепенные (сюда относятся первые две строчки (состояние и прогноз), даты релиза проекта и текущего этапа, бюджет, важные для клиента моменты).
- Второстепенные (планы, возникающие проблемы, идеи, риски, и уточняющие вопросы к клиенту).
Наличие резюмирующей части, куда входит:
- Обратная связь.
- Информация о событиях, которые могут оказать воздействие на бизнес клиента.
В этом же отчете мы не просто обозначаем возникшие (или могущие возникнуть) проблемы, но и предлагаем возможные пути их решения. Клиенту остается отреагировать на письмо.
Зачем вообще нужен еженедельный отчет?
Он преследует несколько целей — как совсем очевидных, так и не очень.
Во-первых, он обеспечивает прозрачность процесса разработки. Цель стратегическая. Это удобно для самого заказчика (владельца бизнеса), так и для его представителя, формально «ответственного» за использование бюджета. Когда на руках имеется вся история процесса работы, за нее легче отчитываться.
Во-вторых, этот отчет управляет ожиданиями клиента. В отчете содержатся не только текущие статусы проекта, но и реалистичные прогнозы. А они-то и формируют адекватные ожидания и снижают риск того, что однажды возникнет конфликт интересов.
В-третьих, отчет уведомляет клиента о проблемах, возможных изменениях и рисках. Отчет пишется в начале каждой недели, а это значит, что у заказчика есть время принять решение относительно проблемы, а у нас — быстро ее устранить.
В-четвертых, отчет позволяет получить обратную связь от клиента. Когда заказчик активно и регулярно участвует в жизни проекта — выше вероятность того, что готовый продукт «попадет в ожидания».
В-пятых, отчет является «жопоприкрывательной бумагой». Мы намеренно пишем отчеты без какой-либо отсылки к конкретным людям, по вине которых что-то пошло не так (даже если действительно проблемы на проекте возникли по их вине). Только текущие проблемы, возможные проблемы (в прогнозе) и вероятные пути решения этих проблем. Таким образом, менеджер, представляющий заказчика, имеет на руках документ, на который всегда можно сослаться в случае возникновения конфликта и объяснить самому заказчику, что проблема возникла вот по этим конкретным причинам.
Кстати, есть такое незаметное, но сверх-полезное человеческое качество, как «умение сообщать о проблемах». Я не так давно даже проводил опрос на эту тему среди коллег. Если на стороне заказчика с вами работает менеджер, склонный к откладыванию проблем на потом, то отчет — не самое худшее средство лишить его такой привилегии.
Мы обозначаем проблему, предлагаем варианты решения, ответственный человек на стороне заказчика реагирует на отчет, проблема устраняется. Весь процесс задокументирован, так что в случае чего отчет защищает и нас, и представителя клиента.
Итак, что имеем:
Что: Отчет о текущем и будущем состоянии проекта.
Кто пишет: Руководитель проекта.
Как часто: Утром каждого понедельника.
Кому отправляет: На электронную почту менеджера заказчика + копия на мою почту.
Конечно, не обошлось без проблем. Главная сложность заключается в тотальной нелюбви людей писать отчеты. Вот с чем придется бороться:
- Руководители проектов постоянно будут откладывать такую рутинную задачу «на потом».
- Придется приучить не только своих, но и менеджеров клиента — своевременно читать отчеты и реагировать на них.
Если вы готовы лично всё мотивировать «забывающих» про отчеты менеджеров, то можете попробовать внедрить такое и у себя. Но небольшим компаниям я бы не рекомендовал.
Прошу высказать свое мнение по поводу таких отчетов. Насколько, на ваш взгляд, они полезны/вредны для общего процесса и почему.
Автор: zevvssibirix
