×Закрыть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фаза дизайна

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RD (документ с требованиями)Должен быть. Должен быть четким, завершенным, непротиворечивым, а также согласованным внутри команды заказчика.
Изменение требований или объема проектаУвеличивает срок и стоимость.
SD (спецификация требований)Должен быть прочтен и согласован.
Информация от заказчика (примеры, настройки соединений etc.)Должны быть предоставлены вовремя.

44 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Отличная статья. Восхитительная статья. Просто вот в груди болит, насколько автор прав. Честно, плакать хочется от счастья, что есть люди, понимающие важность, нужность и функцию ТЗ. Елена, вы прекрасны. Толику бы вашего понимания нашим директорам и руководителям проектов.

Спасибо!

Все так.

И главная проблема порождающая такие вывихи в течение проекта — заказчик это фиктивный субъект, а не действительный. В действительности это частенько это плохо слаженное стадо людей с разными интересами и полномочиями. Когда фичу хочет один, утверждает что она нужна другой, смету подбивает третий, а четвертый является ответственным за проект и поэтому ведет переписку. От такой он заказчик, многоголовый. И о какой из этих голов речь в фразе «заказчик ведь тоже заинтересован в результате»?

Я вот иногда думаю что спеки, протоколы и прочее нужно писать всем сторонам в общей вики проекта. Дабы все эти головы заказчика думали головой и отвечали " за базар" не приватным емайлом или в скайпе, войсом тет-а-тет. Когда правка в вики навсегда останется в истории...

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

Исключения конечно бывают. Только вот ПМы нужны как раз для обычной ситуации

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

По-моему, вполне распространенная практика. Удивительно, что некоторые до сих пор так не делают, а потом ожидаемо тонут в хистори скайпа и цепочках емейлов.

Зато потом хрен концы найдешь.

Добавлю, что в реалиях и вики не панацея :)

От такой он заказчик, многоголовый. И о какой из этих голов речь в фразе «заказчик ведь тоже заинтересован в результате»?
Именно. И во всех подобных заметках об этом забывают.

Как раз из проблем вроде этой, насколько я понимаю, появилась эта строка в agile manifesto:

Customer collaboration over contract negotiation

Те, кто по уши погрязли в фиксации требований, эстимейтах, спецификациях и прочих способах управления рисками в схеме «заказчик-исполнитель» обнаружили, что все это занимает массу времени, но не добавляет ценности. Это, конечно, прикрывает чью-то жопу, но фактически, это waste, это делает всю разработку менее эффективной, масса усилий уходит не на фичи, не на создание продукта. Это, в принципе, не худший вариант в сравнении с приемом рисков (изменения в fixed price проектах, например), но это ТОЧНО не тот путь, который ведет команду и проект к максимальной эффективности. Это лишь защищает исполнителя. Так что в мире исполнителей — это может казаться клевой и продуктивной идеей, но в мире разработки компаний и продуктов — это ну такоэ. Лучше чем совсем уж полный голяк, но совсем не предел мечтаний.

Была у меня в начале этой статьи строка, что все это в наименьшей мере про agile, но потом я её убрала :-)
В эджайле ведь тоже есть требования, user stories, есть правила не добавлять посреди спринта задачи, так ведь? И каждый спринт начинается с обсуждения US и оценки каждой из них.
Я не сторонник вдаваться в крайности, но есть разумная грань между «все жёстко фиксировать» и «полный голяк». Есть зона ответственности менеджера. Он должен позаботиться о том, чтоб у программистов были задачи (и зарплата, соответственно). Чтоб заказчик не был неприятно удивлён сроками и количеством выполненных задач. Как ни крути, а менеджеру нужен план проекта. Нужно регуляторе общение с заказчиком. Нужно записывать договорённости, пусть хоть в протоколе совещания. Не потому что я такая недружелюбная, а чтоб никто из нас не забыл. И если заказчик хочет что-то такое рискованное, его надо предупредить о последствиях. Если согласится — его дело.
А ещё — заказчики разные, конечно. У меня был такой вот заказчик и проект, где надо было «прикрывать 5-ю точку» и фиксировать договорённости, хотя бы письмом. Не из вредности, в чтоб потом директор импульсивного менеджера со стороны заказчика таки оплатил работу моей команде. И чтоб ребята смогли поехать в отпуск тогда, когда задумали.

Не спорю, в документах против слов есть много пользы. И agile вовсе не против документов. Принцип-то не говорит «don’t negotiate contract» — он говорит, что за этими контрактами легко потерять собственно то, ради чего все, несмотря ни на что: проект. И что важно говорить и понимать заказчика, а не ловить и фиксировать все на свете.

Хороший момент, спасибо Вам.

У нас на проекте все понимают и принципы аджайла и то, что стори посреди спринта добавлять не надо, но все делают. Самый лучший момент был, когда за два дня до конца спринта и за месяц до релиза какой-то менеджер со стороны заказчика обнаружил, что у нас нет регрессионных тестов на старый функционал. Продукту 10 лет и вдруг регрессионные тесты оказались очень нужны, надо делать. Ок. добавили стори, начал писать тесты. Через 4 дня подходит тимлид и говорит: забудь про это, им уже не надо, там договорились, что кто-то приемочное тестирование руками сделает.
В итоге за месяц до релиза собирает митинг продакт овнер и говорит, что будет очень дорого перенести релиз на чуть подальше(сравнимо с их месячным бюджетом на команду) и поэтому никто не идет в отпуск в марте. Даже на три дня не может пойти.
Вот вам и типичный бодишоп...

Всё вроде бы верно, слова правильные, но... Иногда заказчик просто не хочет слушать.

А вы пробовали объяснять? Терпеливо, с пониманием, с примерами и паттернами, как ребенку...
(Dmitriy Nizhebetskiy)

Тут недавно один манагер писал, что высшая эволюционная ступень менеджмента это пониманя того, что самая главная задача манагера удовлетворять заказчика. При таком раскладе заказчик не может быть не прав, это все команда подвела

Так и есть — если менеджер не учёл риски, не предупредил риски, не предложил альтернативные сценарии — то менеджер не прав. Я описала некоторые внешние риски, связанные с заказчиком. Они очень типичны и их всегда надо учитывать.

Статья хорошая. Она широко описывает ключевые проблемы, но решения этих проблем дает одним предложением.

В то время, как проблемы на проектах примерно одинаковые, подходы их решения всегда разные. И вот этого опыта решения проблем народу и не хватает.

Мне кажется, здесь есть и первичная проблема. Многие менеджеры проектов (и скрам мастера) считают, что заказчики базово знают, как правильно делать проекты, разрабатывать софт и тем более вести бизнес. На самом деле это не так.

Чаще всего они не знают, как эффективно потратить свои деньги и использовать купленную команду.

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

Хороший менеджер должен учить и воспитывать заказчиков. Объяснять и доказывать что и как работает.

Например, пункт из таблицы в статье

Информация от заказчика (примеры, настройки соединений etc.) — Должны быть предоставлены вовремя.

«Должны быть предоставлены вовремя» означает:
1. Вы заранее заявили об этой потребности
2. Вы заранее объяснили что и в каком виде вам нужно и предоставили инструкции.
3. Вы заранее описали, как повлияют задержки поставки на разработку.
4. Вы переодически напоминали об этом.
5. Вы предлагали свою помощь для решения проблемы (если есть возможность).
6. Вы эскалировали проблему до того, как она начала влиять на сроки поставки.
7. Вы учли возможность задержки поставки (во время определения рисков) и заложили резервы;)
8. У вас есть план Б.
9. Вы уверены, что у вас налажена эффективная коммуникация с заказчиком и он понимает серьезность проблемы.
10. Вы детально объяснили, как вы будете управлять проектом, какие есть связи между работами и поставками со стороны заказчика. И он с этим согласился.
11. И только где-то тут заказчик становиться «заказчиком из реальной жизни» :)

Согласна с вами, надо учить заказчика. Я об этом писала (наверно, кратко): "

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

Половину тобой сказано заказчик не поймет и будет просто кивать головой. Так что нужно быть готовым повторим 7 раз, причем еще уговорить заказчика осознать сказанное тобой.
А последствия. Типичный человек негативные последствия воспримет негативно и есть большой шанс с ним потерять контакт. А рассказывая только позитивные, провалишь проект.

А вы пробовали объяснять? Терпеливо, с пониманием, с примерами и паттернами, как ребенку...

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

Да, бывают и такие клиенты. Надеюсь, что вам в будущем повезет больше и вы еще поработаете с «хорошими» заказчиками.

Не бывает хороших заказчиков. У всех людей свои тараканы и их нужно учитывать и срабатываться с ними.
Но бывают плохие — это те, с чьими тараканами ты просто не сработаешься.

Не бывает хороших заказчиков
бывает :)

Ты не внимательно прочитал:

У всех людей свои тараканы и их нужно учитывать и срабатываться с ними.

Я же не говорю о плохих и хороших вообще. Такое вообще бесмысленно. Но для конкретного человека есть разные. Но найти такого с тараканами которого подружаться твои — это выйгрыш миллиарда в лотерею.

8. У вас есть план Б.
9. Вы уверены, что у вас налажена эффективная коммуникация с заказчиком и он понимает серьезность проблемы.
Вот эти 2 пункта я бы поставил первыми.
Хороший менеджер должен учить и воспитывать заказчиков. Объяснять и доказывать что и как работает.
Ага, причем часто выступать таким супер умным учителем, психологом, чтобы заказчик не предположил, что его учат и не обиделся.
Еще 10 лет назад оное так меня задолбало уже, что после я стал категорически отказываться от всяких руководящих работ. Осточертело до чертиков. Гораздо спокойнее быть просто исполнителем и не сильно хуже по деньгам.

Согласен. Руководящая должность — это осознанный выбор. Человек должен захотеть двигать вещи и людей в нужном направлении. Иначе это реально задалбывает решать чужие проблемы и дружиться с чужим тараканами.
Так что вы сделали правильны выбор.

“Sevice Pack”

Честно, осточертела банальщина и сказки про сферических заказчиков с исполнителями в вакууме.
В жизни же чаще всё происходит с точностью до наоборот.

Почему же сказки? Я писала статью на основании своего опыта, из своей жизни. Вы пишите, что в вашей жизни все наоборот. А наоборот — это как? Добавили задачи посреди спринта/проекта, требования поменялись несколько раз, примеры появились на фазе тестирования — но все в срок и все довольны? Приведите примеры из своей жизни, Виктор.

Не хочу, ибо они уже банальны. Нынче требования бизнеса меняются чаще, чем ты пройдешь одну итерацию по водопаду. Я работал и по водопаду и в варианте вообще без ТЗ. И в том и в том варианте можно работать, если заказчик хочет получить результат.
И кстати при чем тут спринты, если у тебя описан водопад.
Все эти скрумы не от хорошей жизни появились, а из требований бизнеса (заказчиков). Как механизм реакции на изменения требований. И вообще я на стороне всех этих итерационных подходов к разработке, но у них есть ахилесова пята — необходим ответсвенный представитель заказчика в проекте, кто уполномечен быстро принимать решения.
Ну и по

RD (документ с требованиями) Должен быть. Должен быть четким, завершенным, непротиворечивым, а также согласованным внутри команды заказчика.
SD (спецификация требований) Должен быть прочтен и согласован.
Информация от заказчика (примеры, настройки соединений etc.) Должны быть предоставлены вовремя.
Часто это просто невозможно и нужно работать с тем, что есть и быть готовым к внесению неожиданных изменений. В начале проекта (пусть даже водопад) все эти требования не известны никому, кроме Бога, даже заказчику.

Все правильно написано. Вообще с такими кастомерами, которые не понимают, что посреди спринта не стоит требовать все бросить и добавить ему вот тут вот 10 кнопкок, или требующих что-нить поменять в утвержденной логике, потому что ему кажется, что это быстро, или считающих, что как только пришел мокап например, стоит все бросить и садиться верстать — нужно

1. Все хотелки документировать, вообще все, ставить эстимейты везде. Если хочет внезапно поменять логику работы — эстимейт. Пришли новые требования — обновляем эстимейт. Хочет новую фичу — эстимейт. Если ему кажется, что «долго делают» — тыкать лицом в естимейт. Очень часто кастомеры перестают хотеть новую фичу, если слышат, что эстимейт Х дней, а не 10 минут.

2. Никогда не соглашаться включить в спринт еще пару фич, даже если он начинает ныть, как ему очень надо. Ситуации, когда действительно нужно asap бывают относительно редко, а если пару раз повестись на такое нытье — кастомер привыкнет, что «нельзя добавлять таски в спринт» на самом деле значит «можно если громко плакать». Если реально нужно asap — делаем нужную фичу вместо какой-то другой.

3. Нет требований — не начинаем разрабатывать. Если ждем файла «на днях» — то и разрабатывать начинаем «на днях».

4. Жестко стоять на позиции по срокам и нежеланию разрабатывать что-то без требований. Почти всех перечисленных проблем в статье можно избежать, если каждую просьбу кастомера эстимейтить и не давать себя прогнуть.

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

Отличный ответ (and I mean it), но, увы, слабо применимо, если твой заказчик — стартап.

Как минимум,

Ситуации, когда действительно нужно asap бывают относительно редко

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

Да, согласна. Если стартап совсем стартап и надо колбасить, потому что конкуренты вчера выкатились на прод, то классический Scrum с итерациями по 2 недели не совсем в тему.

Да причем тут стартап. В продуктовых все то же и даже у аутсосрсеров.
У продуктов типичная картинка — выйграть тендер.

У продуктов типичная картинка — выйграть тендер

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

Сам участвовал, когда на RECIF работал. Порвали Тошибу — у них еще хуже всё оказалось.

Небольшое дополнение, скорее из психологии, чем из SDLC. По сути, разработка — это не война, не «кто кого прогнёт», а симбиоз. Заказчик не может написать софт, ему нужна команда, но и команда не может написать софт — ей нужны требования и деньги. Нет задачи «учить», «прогибать» и т.д. — это приведёт к росту напряжения отношений и, даже если софт будет написан идеально и с точным соблюдением дедлайнов — осадочек всё равно останется. Лучше действовать аккуратнее, но с той же эффективностью.
Например:

Никогда не соглашаться включить в спринт еще пару фич, даже если он начинает ныть, как ему очень надо.
Можно решить гораздо проще. Оки, ты хочешь вотпрямща добавить вот эту фичу. Не проблема. Мы её заэстимировали в X SP. Вот тебе доска текущего спринта. Выбрось отсюда неначатых задач на X SP и работаем дальше. Ты нашёл задачи, которые выбросить? Молодец, значит, эта фича тебе реально важна и мы её сделаем. Мы ничего не потеряем в эффективности, ведь capacity спринта не изменился. Нет, все фичи в спринте для тебя очень важны? Или ты спохватился слишком поздно? Не вопрос, тогда ставь эту фичу в бэклог там, где ты считаешь, её место по приоритету. Когда мы до неё доберёмся, мы её сделаем.

Вот только заказчик хрен знает где и будет N неделm согласовывать, но в конце твоего спринта спросит о реализованном его пожелании.
Вообще все это туфта, а главное вот:

9. Вы уверены, что у вас налажена эффективная коммуникация с заказчиком и он понимает серьезность проблемы.
10. Вы детально объяснили, как вы будете управлять проектом, какие есть связи между работами и поставками со стороны заказчика. И он с этим согласился.
И не просто согласился, а еще осознал и действует в соответствие со своим согласием.

Тёзка, это, увы, работает только с вменяемыми и адекватными заказчиками. Остальные внезапно устроят вам истерику, будут угрожать эскалацией топ-менеджменту, и даже ходатайством об увольнении лично вас.

В особо тяжёлых случаях — вам будут говорить одно, а вашему руководителю — совершенно противоположное (например, с вами согласятся, что фича в спринт не влазит, а вашему руководителю «настучат», что вы не customer-friendly и за что он вообще вашей конторе деньги платит)

Не хочу сгущать краски и говорить, что все заказчики такие. Просто имейте в виду, что логика и здравый смысл далеко не всегда работают :)

Та не, тёзка. Оно работает, проверено лично :) Принцип прост — всё, что я сказал, подаётся заказчику в письменном виде с копией на своего менеджера и (если известен) с копией на его менеджера. И тогда вместо истерики получаем осмысленный диалог. ;)

(например, с вами согласятся, что фича в спринт не влазит, а вашему руководителю «настучат», что вы не customer-friendly и за что он вообще вашей конторе деньги платит)

Логи разговоров храним (а еще лучше на email), в случае чего форвардим начальству (или вообще во все письма ставим его в CC).
Но имхо если кастомер слабоадекватен, то лучше, когда ситуация будет эскалирована ПМ-ом до того, как произойдет какой-нить серьезный факап в деливери. Тогда уже есть шансы, что разговор с кастомером будет совсем другой :) Начальство тоже не заинтересованно, чтобы из-за неадеквата, все время вопящего ASAP, уволилась вся команда.

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

Елена, формально с Вами нельзя не согласиться. Но столь жесткая позиция в отношении спонтанных запросов заказчика будет работать до первого прокола со стороны команды исполнителей ;-) Бизнес строится на взаимной лояльности, в разумных рамках конечно :)

Подписаться на комментарии