Владелец продукта со стороны заказчика: кто принимает решения в проекте разработки и сколько времени это занимает

Короткий ответ: product owner по-русски — владелец продукта. В заказном проекте это человек со стороны заказчика, который решает, что делать и в каком порядке, отвечает на вопросы, принимает работу и подписывает решения об изменениях. Это не менеджер студии и не «контактное лицо»: менеджер исполнителя отвечает за то, как и когда сделать, владелец продукта — за то, что и зачем. В небольшой компании роль чаще всего берёт собственник или руководитель направления; по времени это 1–5 часов в неделю в зависимости от этапа.

Кто такой product owner простыми словами?

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

Термин пришёл из Scrum. В Scrum Guide 2020 владелец продукта отвечает за максимальную ценность продукта, ведёт и упорядочивает список задач и при этом остаётся одним человеком, а не комитетом. Часть работы он может поручить другим, но ответственность сохраняет за собой. Ещё одна важная мысль оттуда: решения владельца продукта должна уважать вся организация — иначе роль превращается в должность «передатчика сообщений».

В заказной разработке Scrum в чистом виде встречается редко, но сама роль нужна в любом формате. Даже если проект идёт по ТЗ с фиксированной ценой, кто-то с вашей стороны утверждает прототип, решает спорные вопросы логики и подписывает акт. Подробно о том, как формат работы влияет на договор, — в статье «Agile или waterfall».

	Владелец продукта (заказчик)	Менеджер проекта (исполнитель)	Эксперты заказчика
Главный вопрос	Что делаем и зачем, что важнее	Как и когда сделать согласованное	Как это устроено в их участке работы
Отвечает за	Ценность результата, приоритеты, приёмку	Срок, качество, команду, отчёт о ходе работ	Точность правил: цены, скидки, статусы, документы
Принимает решения	Да: объём, порядок, правки, акт	Да, но только технические и внутри ТЗ	Нет, дают ответ и проверяют свой участок
Время	Регулярно весь проект	Регулярно весь проект	Точечно: 1–3 встречи и проверка перед запуском

Чем он отличается от менеджера проекта?

Менеджер проекта со стороны исполнителя отвечает за процесс: сроки, команду, качество и регулярный отчёт о ходе работ. Владелец продукта со стороны заказчика отвечает за содержание: что делаем, зачем и в каком порядке. Менеджер предлагает и предупреждает, владелец выбирает.

Путаница возникает, когда заказчик ждёт, что менеджер студии «сам разберётся, что нужно бизнесу». Менеджер может предложить вариант по опыту — например, как обычно устроена корзина магазина или статусы заявки. Но он не знает, какие скидки вы реально даёте оптовикам, кто из менеджеров видит чужих клиентов и какую ошибку в документах ваш бухгалтер считает критичной. Такие ответы есть только внутри вашей компании.

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

Решение	Решает	Согласует	Информируют
Цель и состав первой версии	Владелец продукта	Руководитель, если бюджет не в полномочиях владельца	Эксперты, исполнитель
Порядок задач и что отложить	Владелец продукта	Исполнитель — по техническим зависимостям	Эксперты
Правила расчёта, статусы, тексты документов	Эксперт участка (бухгалтер, юрист, продажи)	Владелец продукта	Исполнитель
Выбор технологий, структура базы, хостинг внутри ТЗ	Исполнитель	Владелец продукта — если меняются расходы или сроки	Ваш IT, если он есть
Изменение объёма, цены или срока	Владелец продукта вместе с подписантом договора	Исполнитель	Бухгалтерия
Подписание акта или мотивированный отказ	Владелец продукта и подписант	Эксперты — каждый по своему участку	Исполнитель

Какие решения должен принимать заказчик?

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

Удобно разложить решения в матрицу «решает / согласует / информируют». Это упрощённый вариант того, что в управлении проектами называют матрицей ответственности. Достаточно одной таблицы на первой встрече — и на середине проекта не возникает вопроса «а кто это утвердил».

Что нельзя делегировать ни эксперту, ни исполнителю:

• Приоритеты. Если всё «важно», команда сама выберет порядок — по удобству разработки, а не по выручке.
• Границы версии. Решение «это в первую версию, это потом» — бизнесовое, оно определяет срок и бюджет.
• Приёмка. По нашему договору у заказчика 5 рабочих дней, чтобы подписать акт или направить мотивированный отказ с перечнем замечаний; если не сделать ни того ни другого, работы считаются принятыми.
• Изменение объёма. Всё, что сверх ТЗ, оформляется отдельно, а изменение объёма и цены — дополнительным соглашением. Подписать его должен человек с полномочиями, и владелец продукта должен понимать, зачем это нужно.

Отдельно о правках. Число раундов правок в тарифах студии ограничено: обычно до 2 на прототипе или макете и после сборки, точное число указано в тарифе. Владелец продукта собирает замечания всех участников в один список и сам снимает противоречия, иначе раунд уходит на споры между вашими сотрудниками. Как сформулировать правки, чтобы их поняли с первого раза, — в статье о правках по дизайну и сайту.

Сколько времени это занимает по этапам?

Ориентир для небольшого проекта — 3–5 часов в неделю на старте и при приёмке и 1–3 часа в неделю во время разработки. Главное не общее число часов, а скорость ответа: рабочий вопрос — в течение дня, согласование этапа — за 1–2 рабочих дня.

Разложим по этапам. Цифры — наш ориентир для сайта, кабинета или бота небольшой компании, а не норматив:

1. Бриф и уточнение задачи — 2–4 часа. Заполнить бриф, ответить на вопросы, один созвон. Здесь же решаете, кто от вас владелец продукта.
2. Прототип и ТЗ — 3–6 часов за этап. Пройти по экранам и сценариям, позвать экспертов на их участки, утвердить. Это самый дорогой по ошибкам момент: то, что пропущено здесь, всплывает на приёмке.
3. Разработка — 1–3 часа в неделю. Отвечать на вопросы, смотреть промежуточные показы, решать, что делать с неожиданностями: например, в выгрузке из 1С не оказалось нужного поля.
4. Приёмка — 3–6 часов. Пройти сценарии самому, раздать участки экспертам, собрать замечания одним списком, подписать акт или направить отказ с перечнем.
5. Первые недели после запуска — 1–2 часа в неделю. Собрать обратную связь от сотрудников и клиентов, отделить ошибки от новых пожеланий. Гарантия по договору — 30 календарных дней с даты акта, и ошибки удобно передавать в этот период.

Для коротких проектов картина сжимается. Корпоративный сайт по прайсу делается за 3–4 дня (от 56 000 ₽), бот — за 1–2 дня (от 16 000 ₽). Здесь часов немного, но каждый день без ответа почти целиком добавляется к сроку. В веб-приложении (от 160 000 ₽, от 10 дней) этапов больше и показов несколько, поэтому роль растягивается на недели.

Кому поручить роль в небольшой компании?

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

Как выбрать на практике:

• Сайт или магазин — руководитель продаж или маркетинга, если он отвечает за заявки. Тексты документов и цены согласует собственник.
• Кабинет клиента или CRM — руководитель отдела, чьи сотрудники будут работать в системе каждый день. Он знает реальный процесс, а не тот, что в регламенте.
• Интеграция с 1С или складом — тот, кто сейчас страдает от ручного переноса данных: главный бухгалтер или руководитель склада, вместе с вашим специалистом по 1С как экспертом.
• Новый сервис или продукт на продажу — собственник или будущий руководитель продукта. Здесь решения о составе версии напрямую определяют деньги, делегировать их рано.

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

Ещё одна деталь — замена. Отпуск владельца продукта в середине проекта — частая причина простоя. Назначьте заместителя заранее, передайте ему историю решений и предупредите исполнителя. Список того, что ещё стоит подготовить до старта, есть в статье «Что подготовить заказчику до старта разработки»; здесь речь только о роли и её границах.

Что происходит, если владельца продукта нет?

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

Как это выглядит на практике:

• Простой. Исполнитель задал вопрос о логике скидок, ответа нет три дня. По нашему договору срок считается с момента предоплаты и предоставления исходных материалов, а своевременное согласование этапов — обязанность заказчика, поэтому дата сдачи сдвигается вместе с ответом.
• Решения по умолчанию. Чтобы не стоять, команда выбирает самый простой вариант. Потом выясняется, что он не подходит, и это уже новая задача.
• Правки по кругу. Маркетолог просит одно, директор — обратное, бухгалтер вспоминает о своём требовании на приёмке. Раунды правок уходят на согласование внутри вашей компании.
• Спор о приёмке. Никто не проверил сценарии в срок, акт подписан автоматически, а через месяц обнаруживается, что выгрузка в 1С работает не так, как привыкла бухгалтерия.

У этого есть и юридическая сторона. По ст. 718 ГК РФ заказчик обязан оказывать подрядчику содействие в случаях, объёме и порядке, предусмотренных договором; если он этого не делает, подрядчик вправе требовать возмещения убытков, переноса сроков или увеличения цены. А ст. 719 ГК РФ позволяет подрядчику приостановить работу, если нарушение заказчиком своих обязанностей препятствует исполнению договора. На практике до этого почти никогда не доходит, но смысл понятен: молчание заказчика — не нейтральная позиция, а часть срока.

Типичные ошибки при назначении владельца продукта

Большинство проблем возникает не из-за отсутствия роли, а из-за того, что её назначили формально. Вот что встречается чаще всего:

• Роль у секретаря или ассистента. Он аккуратно пересылает сообщения, но не может ничего решить, и каждый вопрос идёт по цепочке к директору.
• Роль у комитета. «Решаем вместе на планёрке» превращает вопрос на час в вопрос на неделю. Совещание может советовать, решать должен один человек.
• Роль у исполнителя. «Вы профессионалы, сделайте как надо». Студия сделает аккуратно и по опыту, но приоритеты вашего бизнеса будут угаданы, а не выбраны.
• Нет времени в календаре. Владелец продукта назначен, но проект у него десятый по важности. Поставьте два слота в неделю заранее: на ответы и на показ.
• Нет истории решений. Договорённости разбросаны по звонкам и чатам. Через месяц никто не помнит, почему отказались от функции. Решения стоит фиксировать письменно — в задаче, письме или в документе проекта.

Когда отдельный владелец продукта вам не нужен?

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

Но даже в этих случаях полезно ответить себе на три вопроса до старта. Кто говорит «да» прототипу и подписывает акт? Кто отвечает на вопросы студии в течение дня и кто его заменяет? К каким сотрудникам он пойдёт за ответами по ценам, документам и учёту? Если на все три ответ один и тот же человек с реальными полномочиями — роль закрыта, как бы она ни называлась.

Чек-лист для первого созвона с исполнителем:

1. Назван владелец продукта и его заместитель.
2. Определены эксперты и их участки: цены, документы, склад, юридические тексты.
3. Согласован срок ответа на вопросы и на согласование этапов.
4. Известно, кто подписывает договор, допсоглашения и акт.
5. Выбран канал, где фиксируются решения, и он один.
6. В календаре владельца продукта стоят слоты на показы и приёмку.

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

Короткие ответы на частые вопросы

Product owner — кто это по-русски?

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

Может ли студия взять роль владельца продукта на себя?

Частично: исполнитель предлагает варианты, раскладывает задачу на этапы и предупреждает о рисках. Но выбор между вариантами, приоритеты и приёмка остаются за заказчиком — это его деньги, его клиенты и его ответственность по договору.

Сколько времени владелец продукта тратит на проект?

Ориентир — 3–5 часов в неделю на старте и при приёмке и 1–3 часа в неделю во время разработки. В короткие проекты на несколько дней нагрузка сжимается: нужно быть на связи каждый рабочий день, пока идёт работа.

Можно ли назначить двух владельцев продукта?

Не стоит делить роль: по Scrum Guide владелец продукта — один человек, а не комитет. Можно назначить заместителя на время отпуска, но с теми же полномочиями и с одной общей историей решений.

Что будет, если заказчик долго не отвечает?

Работа встаёт, срок сдвигается: по договору срок отсчитывается с момента предоплаты и передачи материалов, а заказчик обязан своевременно согласовывать этапы. Гражданский кодекс позволяет подрядчику приостановить работу, если заказчик не выполняет встречные обязанности.

Услуги и кейсы по теме: заказная разработка · цены и сроки