×

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фаза дизайна

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




43 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Все так.

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

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

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

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

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

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

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

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

Customer collaboration over contract negotiation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как минимум,

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

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

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

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

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

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

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

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

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

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

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