Блог

Всеволод Фролов
Начальник отдела управления проектами

Почему важно иметь одного заказчика на проекте

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

Маколей Карсон Калкин (Macaulay Carson Culkin) / Кадр из фильма «Один дома» (Home Alone, 1990)

Рассмотрим вымышленный пример, когда эта роль размыта. К примеру, задачи по функционалу ставит руководитель проекта, а задачи маркетинга — маркетолог. Маркетолог заказал разместить баннер на сайте нашего продукта. Разработчик выполнил. Руководитель проекта увидел реализацию и пришел в недоумение: зачем мы показываем баннер Клиенту в платном продукте?

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

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

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

  • Заказчик недостаточно компетентен в технологиях и привлекает к проекту более продвинутого коллегу. Что делать в этом случае? Быстро прокачать заказчика невозможно. Решение: задача обсуждается между заказчиками, но озвучивается для разработчика одним заказчиком — владельцем продукта.
  • Заказчиком является топ-менеджер, и он не тратит время на то, чтобы разбираться в «низкоуровневых» задачах, поэтому делегирует некоторые второстепенные вопросы помощнику. Решение: помощник должен стать владельцем продукта и свои консультации с топ-менеджером оставить за рамками процесса разработки продукта.
  • Появляется новый заказчик, который вклинивается в процесс работы над продуктом со своей задачей. Например, отделу поддержки клиентов нужно добавить автоматизацию некоторых процессов, связанных с нашим проектом. Решение аналогично первому варианту: нужно выносить обсуждение доработки на уровень основного заказчика.

Таким образом, роль заказчика (владельца продукта) в разработке — это высокая ответственность. Это не только право решать, куда продукт двигается и как развивается, но и обязанности по интеграции в продукте потребностей соседних подразделений.