Comments 10
У нас срыв по задаче Y. Мы проанализировали и видим три пути: Вариант А: Увеличить бюджет на N, чтобы нанять еще одного разработчика и успеть в срок. Вариант Б: Перенести срок на неделю....
Вы ведь не предлагаете вариант А на полном серъёзе? Не предлагаете же?
Я думаю это скорее абстрактный вариант, дело же могло быть и на стройке, где найти дополнительного разнорабочего не трудно и не долго
На самом деле хорошая статья :)
Самое смешное, когда они нарушают сроки, которые сами же и предложили и никто их не сокращал от заказчика. Но теперь они просят денег, это же естественно, как дышать
У срыв по задаче Y. Мы проанализировали и видим три пути: Вариант А: Увеличить бюджет на N, чтобы нанять еще одного разработчика и успеть в срок. Вариант Б: Перенести срок на неделю....
Мне ещё ни разу положительно никто не ответил на подобное из заказчиков в такой ситуации, обычно говорят "это ваша проблема, не успеете - с вас штраф за просрок сдачи"
Я хз что за заказчики, которые с этим соглашаются вообще))))
Это стандартный пример из базовых принципов проектного менеджмента. Актуален он или нет - не так важно.
Понимаем ли мы бизнес‑цель задачи или просто бездумно реализуем ТЗ?
Очень странный вопрос для команды. Если вы его задание команде, значит с требованиями большая проблема. Логично, что команда должна понимать предметную область. Но в процессе работы команды, в спринте например, требования должны быть выверены и согласованы и должны соответствовать целям спринта. Цели спринта должны коррелировать с целями релиза (если вы не поставляется каждый спринт). В рамках спринта 100% будут уточнения и вопросы, но это не изменит цели спринта глобально. Proxy product owner в кооперации с product owner являются SME (subject matter experts) и должны подготавливать требования, в соответствии со стратегией развития продукта).
Вовлечение заказчика в процесс разработки, это не только обновление его статуса (отчёты, демо ...). Это также и ответственность за продукт: если команда сделала не то, что он хотел, значит это и его провал тоже.
Важно не только то, что вы перечислили. Ибо не решает ваших проблем, если заказчик имеет свое видение, но, например, не участвует в планировании и не может внести коррективы в поставленные задачи. Вы конечно отправите ему список задач из Jira, но это не очень эффективно.
Если кратко, суть проблемы в том, что руководство проектов замыкает решение проблемы внутри команды. Но это только часть решения, нужно еще вовлечение заказчика как части команды с совместной ответственностью.
В идеальном мире с выверенными требованиями и активным PO - так и есть. Но на практике (особенно в аутсорсе или с незрелыми продуктами) PM часто получает от заказчика ТЗ в виде разрозненных хотелок и его же - постоянно недоступного для уточнений. Эта статья - первый шаг: как нам, исполнителям, создать условия для этого вовлечения через прозрачность. Чтобы у заказчика не было оправдания «я не в курсе», и он сам захотел стать тем самым ответственным субъектом-экспертом, о котором вы говорите.
Абсолютно согласен, идеального мира не существует. В своих проектах вовлекаю заказчика с первых дней, стараюсь прописывать в договорах зоны ответственности и SLA на ответы/согласования. Все решения обязательно письменно фиксируются и дублируются в трекинг системе и почте. Да, это бюрократия, но очень помогает в критичных ситуациях.
Статья в целом неплохая, но вопросов больше чем ответов:
По какой методологии идет работа?
На сколько детальные были даны требования?
Уделили должное время проработке архитектуры?
Сходили к смежникам заранее за оценками?
Как выстроена в принципе система статусов с Заказчиком
А управление рисками и запросами на изменения это отдельные области которые к сожалению как правило ведутся слабым образом.
Клиент вечно недоволен: инструкция по выживанию для PM