Спешная разработка решения до согласования требований — здоровое ли это управление проектами?

Конечно, не выглядит здоровым, как описано :/. Я не могу говорить по всем пунктам, но один кусок:

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

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

Если вы не приступите к рабочему/демонстрационному программному обеспечению до того, как клиент или проектный менеджер попросят внести изменения, ИЛИ если изменения всегда имеют наивысший приоритет, то вы никогда не войдете в ритм поставки работающего программного обеспечения, и проект будет предсказуемо завершен. хрупкий и напряженный. :(

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

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

Команда практикует гибкую методологию (мой первый раз с agile)

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

Вероятно, вы следуете гибкой структуре, возможно, Scrum или Kanban ? Если вы работаете спринтами, то, скорее всего, вы используете Scrum. Было бы полезно узнать у вашей организации больше о том, какой структуре они придерживаются, так как это позволит нам более конкретно ответить на ваш вопрос.

Есть некоторые проблемы с текущим подходом:

PM поручил разработчикам кодировать решение (в соответствии с идеей/визуализацией PM)

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

Отзывы клиентов с изменениями (иногда незначительными, иногда серьезными), и PM просил команду внести изменения в соответствии с отзывами в течение следующих нескольких часов / дней.

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

ПМ всегда получает звонок от клиента

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

PM спросит, почему мы используем идею A, так как это неправильно, и попросит нас перейти на идею B.

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

«Хотите верьте, хотите нет, но в реальном мире ответ может быть – может быть, нет, но мы все равно должны это сделать».

«Аджайл» — это, прежде всего, идеал. (Ценная и полезная перспектива, но, тем не менее, «идеальная».) Как таковая, она содержит определенные упрощающие допущения — которые могут быть или не быть верными — как в отношении «клиента», так и в отношении обстоятельств, при которых клиент" может иметь дело. К счастью, в вашей команде есть продакт-менеджер с «8-летним опытом работы в этой компании». ("Аллилуйя.")

Компьютерное программное обеспечение очень требовательно, и его разработка занимает много времени ($$$!!) . Таким образом, команда может быть направлена ​​в определенном направлении до того, как это направление будет полностью понято, зная, что результатом будет доработка. Требования клиента могут быть выполнены до того, как клиент (!) полностью узнает, какими окажутся окончательные требования, или примет (или узнает) окончательные бизнес-решения, которые их определят.

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

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

Кроме того, «как только программное обеспечение будет завершено, оно будет исправлено в камне, и поэтому его будет намного сложнее изменить». Это еще один аргумент в пользу «текучести», которую методологиям программирования так трудно понять. Бизнес может взять на себя определенные аспекты всего проекта, так сказать, спекулятивно, зная, что некоторые части необходимо будет переработать, но не все.