Как обучать Заказчика: Часть 3

Как писать отчеты для Заказчика Продолжаю тему рассказов о том, как обучать Заказчика. В первом посте из серии «Обучение Заказчика» я рассказал о том, что существует 4 направления, в которых стОит обучать Заказчика:

Технологии проекта (смотри часть 1)
Промежуточные результаты работы (смотри часть 2)
Оперативная отчетность
Конечный продукт

Долго размышлял над мыслью: «Чему же обучить Заказчика, чтобы он стал правильно пользоваться отчетами, которые мы ему присылаем?». И пришел к выводу, что при всем желании единственный совет, который можно дать Заказчику: «Если хоть что-то вызвало сомнения в отчете – обязательно уточняйте!». Больше обучать нечему, так как отчет должен отражать состояние проекта с точки зрения команды, а значит нужно обучать не Заказчика, а команду.

Поэтому, вопреки заглавию поста, речь будет идти о советах команде. Буду говорить о тех приемах и подходах, которые помогут сделать отчеты в таком виде, чтобы Заказчик мог их использовать БЕЗ предварительного обучения. Как раз в случае с отчетами, это и будет показателем классного сервиса. И, на самом деле, это не так сложно, как кажется.

Хочу сразу обратить внимание, что речь пойдет о двух типах отчетов «регулярные» и «по запросу». Под первыми я чаще всего понимаю обговоренный механизм отчета по статусу проекта, который обычно происходит один раз в 1-2 недели. «По запросу» объяснять не буду

Вот несколько простых советов о том, как сделать отчеты намного улучшить качество и информативность ваших отчетов:

Узнайте у Заказчика как часто и когда он хотел бы получать отчеты. Например, есть «маньяки», которые хотят видеть ежедневные отчеты, а кому-то «достаточно» и одного раза в месяц. Тем не менее, существующие практики показывают, что лучше отправлять регулярный отчет как минимум раз в неделю. Также уточните день недели и время получения отчета, что может существенно улучшить отношение Заказчика к вам.
Писать отчет в терминах понятных Заказчику. Любые профессиональные словесные изыски уже обсуждались на страницах блога и были признаны не приносящими пользу для Заказчика.
Высылать Заказчику данные, которые соответствуют его уровню и его интересам. На самом деле самая распространенная ошибка, которую совершают менеджеры при составлении отчетов, является склонность к одной из двух крайностей: «Очень много технических и мелких деталей» или «Очень общие фразы и оценки, которые ни о чем не говорят». Обе эти крайности делают отчет бесполезным. На своих тренингах я рассказываю о пирамиде отчетности, которая помогает определить, насколько часто и с какой степенью подробности нужно формировать отчет для представителей Заказчика (инженеров, менеджеров, владельцев). Если в двух словах, то чем ваше позиция человека, тем более общими нужно делать отчеты (переходить на следующий уровень абстракций). Так программиста интересуют таски и код; ТехЛида – статусы по группам задач и сложностям интеграции; менеджера – отставание от графика, зависимость от внешних факторов, необходимость изменения команды и т.д.
Пишите только факты. Если команда не сделала то, что планировала, то отчет должен недвусмысленно содержать эту информацию. Можно дописать и причину, которая (по вашему мнению), привела к невыполнению планов. Но причины и «домыслы» не должны «вуалировать» четкий статус. Помните закон Мерфи: «Если фраза может быть двояко истолкована, то она будет понята НАИХУДШИМ для вас образом».
В отчетах необходимо рассказывать о том, как факты, отраженные в отчете (а мы обычно пишем о свершившихся фактах), повлияют на будущие события в проекте. Например, если вы пишете о том, что ушел кто-то из тестировщиков, то обязательно следует упомянуть, как это отразится на проекте (часть функционала будет «нестабильной»/качество не изменится/возможны крайне негативные последствия для качества, так как долго будем искать замену). Данная информация поможет Заказчику правильно сформировать ожидания и, как ни удивительно, предпринять действия со своей стороны.
Не выдавайте желаемое за действительное! Это будет дорого стоить в ваших отношениях с Заказчиком.

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