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