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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фаза дизайна

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RD (документ с требованиями)Должен быть. Должен быть четким, завершенным, непротиворечивым, а также согласованным внутри команды заказчика.
Изменение требований или объема проектаУвеличивает срок и стоимость.
SD (спецификация требований)Должен быть прочтен и согласован.
Информация от заказчика (примеры, настройки соединений etc.)Должны быть предоставлены вовремя.
Похожие статьи:
Привіт, мої любі сішники! Пропоную в цьому дайджесті розглянути embedded programming на Raspberry Pi та embedded Linux development. Почнімо? :) Raspberry Pi Raspberry Pi —...
Historically horseracing, in one form or another, has been around for thousands of years. Records exist from Ancient Egypt, Greece, Babylon, Syria, the Roman Empire and the list goes on. However, it wasn’t until the evolution of actual...
Компания «Связной» подводя итоги продаж на рынке смартфонов в 2015 году, отметила, что по её оценкам iPhone обеспечили розничным...
Пертурбации с ОС Windows 10 Mobile заставляют внимательно следить за судьбой ПО аппаратов, которые были обновлены доданной...
Международный музыкальный сервис Guvera объявил о большом обновлении своего приложения, которое, с его слов,...
Яндекс.Метрика