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

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

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

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

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

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

Можно считать, что размер компании – компромисс между производительностью и накладными расходами. Чем больше людей, тем больше задач можно выполнить, но тем больше общения и процессов необходимо для координации.

Например, для реализации одной пользовательской истории в интернет-банке может потребоваться интеграция минимум с тремя системами, за каждую из которых отвечает своя платформенная команда; сама интеграция в худшем случае может строиться напрямую между системами без какого-либо промежуточного слоя, на ресурсы может претендовать еще множество бизнес-заказчиков из бухгалтерии, операционного департамента и т. д. В итоге у нас получается не один, а множество бэклогов, тут возникает типичный вопрос: «Кто, когда, как, зачем сможет вставить эту историю в свой релиз?»

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

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