PMsoop: Глава №19: Про информирование Заказчика

В ролях - Менеджер Проекта, Заказчик

Артефакты – План Проекта, отчёт Заказчику

Суть – Менеджер Проекта информирует Заказчика о ходе разработки

О пользе постоянного и регулярного общения с Заказчиком на всём протяжении проекта написано немало статей и других материалов. Некоторые методики руководства проектами (agile) даже построены на основе ежедневного общения. Суть, в общем случае, сводится к тому что Заказчик должен быть в курсе всего происходящего в проекте. Чем меньше обманов и скрытой информации – тем больше доверия и выше шансы на успех проекта. Идеальный Заказчик поймёт любые возникшие трудности, и даже поможет в их разрешении.

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

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

Таковыми являются:

- незапланированное отсутствие ресурсов (реализация человеческих рисков) – болезни, отгулы, увольнения разработчиков

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

- недооценка трудозатрат (риски планирования) – разаботка функции Z потребовала не 40 а 80 человеко-часов

- срыв сроков поставки (риски взаимодействия) – например Заказчик не прислал во время дизайн из-за чего простаивает разработка и сдвигаются сроки

- реализация всяких других рисков

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

В таких случаях, Заказчик должен узнавать о переносе сроков сдачи версий чем раньше тем лучше. Один из вариантов обоснования – получение информации о переносе сроков обычно вызывает негативную реакцию, и чем раньше она «пройдет» - тем лучше, к моменту сдачи версии желательно чтобы Заказчик был «спокоен». Есть и другие варианты, например своевременное информирование о проблемах в спокойном и вежливом ключе увеличивает «вовлеченность» Заказчика в разработку и облегчает коммуникации. Кстати, кто из читателей предложит свой вариант?

Типичной ошибкой в управлении проектами является попытка «скрыть» от Заказчика реализованные риски которые приводят к срывам (особенно незначительным) сроков сдачи, и надежда «отыграться в овертаймах». Когда Заказчик узнаёт о том, что версия не готова, в день сдачи (или за день-два до сдачи) – он обычно расстриавается, и глубина расстройства растёт с каждым днём задержки, что приводит к сложным коммуникациям и проблемам с приёмкой готового функционала. Кроме того, «гонки» сильно утомляют и понижают мотивацию разработчиков. В целом, люди любят fair play – помните об этом.

Так что, повторюсь в очередной раз – если вы видите что сроки (почти) гарантировано «съезжают», пусть всего на 1 день – лучше сразу сообщить об этом Заказчику спокойным и вежливым образом, например так:

«Ув. Заказчик. Мы тут при разработке столкнулись с проблемой Х, по факту разбирательства с которой мы с высокой вероятностью ожидаем смещение сроков сдачи версий таким образом _табличка_. Надеюсь на ваше понимание и поддержку, мы со своей стороны делаем всё возможное для минимизации проблемы и постараемся сократить отставание при дальнейшей работе».

Неясность требований

Если во время разработки вдруг выяснилось, что описание некоторого функционала является недостаточно чётким для его реализации, либо противоречиво, либо может быть интерпретировано разными способами, и выяснение дополнительной информации обязательно требует участие (предствителей) Заказчика – фактически можно сказать что произошла реализация риска. Поступать рекомендую так же как написано выше – то есть не откладывая уведомить об этом Заказчика, и проакцентировать необходимость получения разъяснений для продолжения разработки. Также можно намекнуть про возможность сдвига сроков сдачи версий симметрично задержке в получении ответа. Но тут следует понимать, что если на этапе подготовки к старту Заказчик не ограничивал время на анализ документации, то наличие таких «непоняток» является скорее виной Разработчика, поэтому давить на Заказчика особо не стоит. А вот если Заказчик форсировал старт проекта и не дал достаточно времени на анализ документации, либо проект стартован с «сырой» документацией с согласия Заказчика, либо вы работаете по agile процессу – то в таких случаях ответственность Заказчика за сроки нужно подчеркивать без лишней скромности.

Текущее состояние выполнения задач

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

Хорошей практикой является еженедельная отправка Заказчику письменных отчётов о текущем прогрессе в разработке. В отчёте кратко описываем какие задачи были выполнены за прошедшую неделю, рисуем красивые картинки (актуальная диаграмма Ганта) или таблички (тасклист с отметкой выполненных и текущих задач). Если были проблемы – спокойно описываем что произошло и как порешали. Обязательно в отчёте должен быть представлен актуальный (на день создания отчёта) план сдачи версий (milestones).

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

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

Резюме главы:

1. Сообщать Заказчику о проблемах которые сдвигают сроки надо чем раньше тем лучше

2. Сообщать Заказчику об успехах нужно регулярно

3. Писать еженедельные отчёты Заказчику очень полезно