PMsoop: Глава №23: Обработка комментариев Заказчика

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

Артефакты – “wishlist”, changes

Суть – Принимаем комментарии Заказчика, обсуждаем, устраняем дефекты, готовимся к ченджам

При проверке версии Заказчик может обнаружить дефекты, придумать изменения либо просто задавать вопросы «почему так?». На вопросы следует отвечать быстро, без задержек – это помогает Заказчику быстрее закончить проверку. А вот дефекты и запросы на изменения рекомендуется принимать списками, с целью упрощения обработки и отсечения противоречивых данных на самых ранних этапах. Поэтому, как только получаем первые дефекты/изменения – сразу просим Заказчика формировать их в список и прислать все вместе по окончанию проверки. Как это аргументировать – зависит от фантазии и опыта менеджера проектов, обычно удобство обработки является достаточно весомым аргументом. Исключение стоит делать только для критичных дефектов, наличие которых затрудняет дальнейшую проверку версии – такие дефекты падо принимать и исправлять незамедлительно (вообще их быть не должно после внутренних проверок и тестирования – но все мы не совершенны…). А вот если Заказчик наставивает на срочной реализации изменений – такие попытки следует пресекать сразу. Все изменения должны проходить согласно общей процедуре – сверка с текущими требованиями, оценка трудозатрат, планирование, согласование изменений сроков и бюджета. Даже если изменения совсем незначительные – буквально на 5 минут работы – всё равно, не стоит их делать сразу. Такие пятиминутные изменения имеют свойство накапливаться и в результате выливаться в часы и дни работы, не учтённые в плане и бюджете проекта, что совсем не есть хорошо…

Итак, для начала сразу приучаем Заказчика к хорошему тону – все дефекты и заросы на изменения присылать сводным списком, мгновенно разбираются только критичные дефекты.

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

Теперь переходим к разбору списка запросов на изменения. Для каждого изменения – change – чендж – следует провести приблизительную оценку трудозатрат. Затем, делаем сводную таблизу ченджей с указанием для каждого ченджа оцененных трудозатрат (лушче даже сразу указывать насколько изменятся сроки, например +1 день к общей длительности) и, отдельно (для наглядности), изменение бюджета проекта вызванное данным ченджем (особенно актуально для fixed cost проектов). Добавляем в сводную таблицу отдельную, пока пустую, колонку под названием «приоритет». И отправляем результат Заказчику с просьбой утвердить необходимость реализации данных изменений (с учётом влияния на сроки и бюджет конечно), а также проставить приоритеты – что нужно сделать в первую очередь (в данной версии), что можно реализовать в следующей версии, что может подождать до конца проекта (расшифровку значения приоритетов разумно объяснить Заказчику). После чего – ждем ответа.

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

Менеджер Проекта – будь бдителен!

PS: Учитывая важность грамотного Changes Management для успешности проекта в целом – ему будет посвящена отдельная следующая глава.