Управление продуктом. Российская практика - страница 15

• Стоимость: включает бюджет, все ресурсы, необходимые для завершения задач, такие как рабочая сила, материалы, оборудование и накладные расходы. Увеличение бюджета может помочь уложиться в сжатые сроки или расширить объем работ, тогда как сокращение бюджета может потребовать уменьшения объема или продления сроков.

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

Итак, если команда отстает от графика, то допустимо сократить объем задач или перенести сроки запуска, однако это может плохо повлиять на бизнес-результат; добавить больше разработчиков (увеличить стоимость). Однако в последнем случае вы можете столкнуться с «мифическим человеко-месяцем» и законом Брукса – концепцией, которую описал Фред Брукс в своей книге «Мифический человеко-месяц: очерки по разработке программного обеспечения».

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

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

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

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

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

Я специально вынесла роль владельца продукта, а не менеджера продукта, в заголовок этого раздела. Между этими ролями есть существенная разница.

В команде выделяется роль владельца продукта, который должен отвечать за представление всех заинтересованных сторон и приоритизацию работ, уточнение требований и контроль сроков и бюджетов. Часто он берет на себя роль и Scrum-мастера, ответственного за соблюдение практик в команде и проведение мероприятий вокруг спринтов: планирование, обзор, ретроспективу, ежедневные статусы (стендапы). В подавляющем большинстве известных мне случаев владельцами продуктов становились системные аналитики, бизнес-аналитики и менеджеры проектов, которые и так выполняли функции планирования и администрирования задач, создания задач для разработчиков и тестировщиков.

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