Comments 3
Спасибо за статью. Интересный пример.
Не до конца понял про сам конфликт. В качестве причин недопонимания между заказчиками и PO в статье перечислены ключевые области проектного управления:
Скрытый текст
Заказчикам не всегда понятно, как формируется оценка больших проектных задач.
Заказчикам не всегда понятно, какие риски команда закладывает и почему.
Заказчики не верят, что команда загружена на 100%, и хотят пруфы, ведь они ее финансируют.
РО считает, что его работу обесценивают и ему не доверяют.
Управление человеческими ресурсами;
Управление стоимостью и финансированием;
Управление рисками.
Судя по описанным действиям, ситуацию удалось стабилизировать за счет внедрения ряда проектных практик:
Распределение ролей и ответственности между участниками (например, через RACI), стандартизация процессов разработки;
Усиления функциональной области управления коммуникациями;
Усиление и стандартизация управления изменениями продукта/проекта;
Использование инструментов управления качеством: как на уровне продукта (обратная связь от пользователей, добавление метрик), так и на уровне процесса разработки (внедрение DoR, DoD).
В связи с этим вопрос: как Вы считаете, почему на старте развития направления не использовались стандарты и лучшие практики проектного и продуктового управления, которые впоследствии помогли улучшить ситуацию? Если бы процессы разработки, постановки задач, оценки требований, согласования бэклога и взаимодействия с заказчиком изначально были более стандартизированы и прозрачны (как для команды, так и для заказчика), позволило бы это избежать или хотя бы минимизировать негативные последствия возникшего недопонимания?
Пока автор раздумывает над ответом рискну предположить, что для использования эффективных практик необходимо знать эти практики и уметь их применять. То есть обладать тем, что называют профессиональной компетенцией. Да ее приобретения обычно прибегают к соответствующим образовательным программам, построенным с учётом педагогических требований к образовательному материалу. Сейчас же часто можно наблюдать убеждённость отдельных личностей в том, что для управления людьми и процессами достаточно своей решимости и самоуверенности. Очень показательно заблуждение у таких специалистов, что гиперактивность равна эффективности. И это как раз исключает для них необходимость в профессиональных компетенциях.
Таймлайн, конечно, интересный:
- набрали команду
- начали перформить
- набрали ещё команд
- начались конфликты и непрозрачность
- внедрили VOC и какие-то метрики
- внедрили процессы
- учитесь прорабатывать обратную связь
Мне кажется, это проблема онбординга и стандартизации, сиречь, активного найма. Ведь и год, и три года назад эти процессы и стандарты в банке наверняка уже были. Можно сказать, перформить команды только начали. До этого был storming.
Вечные вопросы любого Product Owner, или Как начать с драконом сотрудничать