Где мы теряем время: причины срыва сроков "по вине заказчика"

В жизни каждого менеджера проекта наступает момент, когда заказчик спрашивает, на что же было потрачено время и почему проект запаздывает. В статье речь пойдет о случаях, когда задержка сроков поставки и не оптимальная загрузка проектной команды происходит, с точки зрения менеджера проекта, по вине заказчика. «Следовательно, — думает некий менеджер, — заказчик осознает риски и берет ответственность на себя».

Почему эти ситуации важны? Если сообщить заказчику постфактум, что со сложностями с бюджетом и сроками проекта связана «сторона заказчика», то:
а) заказчик, скорее всего, будет отрицать свою «вину»;
б) заказчик согласится, но обвинит менеджмент в некомпетентности (не обсудили риски и ошибки своевременно);
в) это уже не поможет (вернуть демотивированных программистов, выполнить проект в срок etc.)
г) и, согласитесь, это незрелый менеджмент, если он замалчивает проблемах.

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

Итак, если кому-то лень читать весь текст, то основные причины — вот они:
— Отсутствие задокументированных требований или входных данных;
— Безалаберность в управлении изменениями;
— Изменение объема Service Pack, поставки посреди спринта.

Далее разберем более подробно.

Фаза анализа требований и оценки

Ситуация 1 — Отсутствие задокументированных требований.

Варианты сценария:
— Обсудили требования устно, каждый понял по-своему, так и сделали;
— Обсудили устно, пришли к общему решению, потом каждый забыл общее решение и помнил как-то по-своему.

Следствие: заказчик не доволен результатом. Получил не то, что хотел.

Ситуация 2 — Отсутствие входных данных, необходимых аналитику для начала работы или менеджеру для более точной оценки проекта.

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

Следствие: сдвиг сроков, демотивированный заказчик, возрастающее напряжение в команде (если сроки нужно наверстывать). И все эти последствия печальны, пусть даже и заказчик осознает свою вину.

Ситуация 3 — Постоянные изменение требований.

Изменения требований — это, в принципе, нормально. Но есть заказчики, которые непрерывно живут в состоянии изменения требований, и сами того не осознают. Если вы заметили такой синдром, сообщите о нем заказчику. Поясните, какие есть риски у этого непрерывного творческого полета.

Возможно, заказчик образумится и зафиксирует какой-то определенный вариант (хотя бы до времени запуска проекта и прочтения отзывов о продукте). Возможно, заказчик поймет, что он пока на фазе поиска идеи, и возьмет тайм-аут, чтобы прийти к какому-то определенному варианту. А может у него много времени, денег, и он хочет несколько вариантов реализации на выбор. Почему нет? Но пусть этого его решение будет озвучено и зафиксировано.

Какой бы не была причина, не забывайте оценивать и согласовывать с заказчиком новые сроки, вызванные изменениями.

Ситуация 4 — Обсуждение требований по Skype (телефону, почте), без актуализации документа с требованиями.

Следствие: это приводит к путанице на последующих фазах. Пишите хотя бы протокол совещания, это не сложно.

Фаза дизайна

Ситуация 1 — Изменение требований.

Следствие: дизайн не может быть завершен вовремя.

Кроме того, требуется:
— Актуализировать документ с требованиями;
— Выполнить анализ и оценку требований;
— Обеспечить временные задачи для разработчика, пока уточняются новые требования.

Ситуация 2 — Спецификация не согласована вовремя.

Следствие: разработка не может быть начата вовремя.

Ситуация 3 — Спецификация согласована (формально, чтоб начать разработку), но ее никто не читал.

Следствие: путаница и недопонимание на последующих фазах.

Фаза разработки

Ситуация 1 — Изменение требований.

Следствия:
— Процесс начинается сначала;
— Демотивация разработчиков;
— Нужны временные задачи, чтоб занять разработчика.

Ситуация 2 — Не предоставлены примеры данных.

Следствие: разработка не может быть завершена вовремя.

Фаза тестирования

Ситуация 1 — Изменение требований.

Следствие: процесс начинается сначала.

Ситуация 2 — Не предоставлены примеры данных.

Следствие: тестирование не может быть завершено вовремя.

Не будем терять время

Следует ли упоминать об добавлении задач посреди Sevice Pack? Да, следует. Многие заказчики не всегда осознают, какие у этого последствия. Надо им напомнить, что этого делать нельзя, лучше включить задачу в следующий SP. Иначе будет потеряно время не только на саму задачу, но и на создание нового плана проекта, а также на дизайн и согласование спецификации.

Как только вы замечаете описанные выше тенденции при общении с заказчиком на какой-либо из фаз, приводите доводы, предостерегайте.

Ну что, подсуммируем?