Управление продуктом. Российская практика. Юлия БилинкисЧитать онлайн книгу.
растут в геометрической прогрессии. Каждый дополнительный участник увеличивает количество каналов связи и вероятность недоразумений или несогласованностей. И в целом не все задачи можно легко разделить между несколькими людьми.
Все это во многом исключает возможность реального варианта «сделать хорошо и быстро». В итоге приходится искать компромиссы, сокращать объем работ в угоду качеству, договариваться снова с заинтересованными сторонами.
Еще одним фактором, влияющим на сроки, становится задержка в работе другой команды, от результатов которой зависят ваши сроки. Часто она находится вне зоны контроля и влияния, и вопрос необходимо эскалировать.
Кто все вышеописанное будет делать и отвечать, если возникают сдвиги сроков, выпускается продукт, не отвечающий требованиям, и т. д.? Конечно, владелец продукта.
Я специально вынесла роль владельца продукта, а не менеджера продукта, в заголовок этого раздела. Между этими ролями есть существенная разница.
В команде выделяется роль владельца продукта, который должен отвечать за представление всех заинтересованных сторон и приоритизацию работ, уточнение требований и контроль сроков и бюджетов. Часто он берет на себя роль и Scrum-мастера, ответственного за соблюдение практик в команде и проведение мероприятий вокруг спринтов: планирование, обзор, ретроспективу, ежедневные статусы (стендапы). В подавляющем большинстве известных мне случаев владельцами продуктов становились системные аналитики, бизнес-аналитики и менеджеры проектов, которые и так выполняли функции планирования и администрирования задач, создания задач для разработчиков и тестировщиков.
Не стоит недооценивать ценность этой роли в контексте работы в разрозненных организационных структурах, на пересечениях зон влияния и ответственности. Организация представляет собой непростую систему, в которой степень сложности прямо пропорциональна количеству точек принятия решения.
Успешные владельцы продуктов часто помогают заказчикам конкретизировать видение и воплотить его в жизнь, работая со всеми заинтересованными сторонами.
Дело в том, что ресурс ИТ может быть общим (под ресурсом я понимаю сотрудников с необходимой специализацией и опытом: разработчиков, тестировщиков и т. д.) и делиться между множеством бизнес-заказчиков, а может быть выделенным под конкретного бизнес-заказчика.
Первая схема хорошо работает, когда потребность в ресурсе носит временный характер по проектному типу: например, у бизнес-подразделения возникает задача доработать систему под новые требования законодательства. Тогда претендентам на ИТ-ресурс нужно как минимум договориться о правилах его использования. В случае общего ресурса договориться всегда сложнее, поскольку претенденты имеют разные, а иногда и противоречащие друг другу цели.
Вторая схема эффективна, когда потребность в ресурсе