Менеджер продукта vs. бизнес-аналитик
Перевод статьи из блога SVPG (Silicon Valley Produсt Group).
Ссылка на статью:
http://www.svpg.com/product-manager-vs-business-analyst/
——перевод——↓
В ряде компаний, в основном в тех, которые имеют ИТ-шное наследие (см. http://www.svpg.com/blog/files/moving-from-it-to-product-organization.html), иногда встречается роль, которая называется “Бизнес-аналитик”.
Не стоит путать эту роль с бизнес-аналитиком в продуктовой организации, где этот человек ответственен за анализ бизнеса и аналитику. Я имею в виду совсем другую роль.
В ИТ-компаниях (которые делают либо внутренний софт, либо заказной софт) бизнес-аналитик часто ответственен за сбор детализированных требований к продукту.
Представьте типовой проект по разработке заказного программного обеспечения, в котором заказчиком может быть кто-нибудь типа HR менеджера, которому нужно приложение, связанное с бонусами для сотрудников [benefits related application]. Может быть некоторое количество разработчиков, которые способны написать код, но кто будет переводить бизнес-требования HR менеджера в то, что могут сделать разработчики? В ИТ компаниях, занимающихся разработкой заказного программного обеспечения, почти никогда нет менеджеров продуктов и кто-то должен осуществлять работу по фиксации и определению требований. Один из общепринятых терминов для описания этой роли – бизнес-аналитик и по факту этот термин и эта роль были популярны в течение более чем 30-ти лет.
Проблема возникает, когда эта модель компании-разработчика заказного ПО используется в продуктовой софтверной компании, в которой обычно присутствует роль менеджера продукта, который отвечает за определение продукта.
Первая реакция большинства менеджеров продуктов, попавших в такую организацию, состоит в том, чтобы понять, кто эти люди и не выполняют ли они ту же работу, которую собираюсь делать и я?
Это обычная практика, если компания-разработчик выросла в связке со своими бизнес-аналитиками и в значительной степени полагается на них при определении детализированных требований к продукту.
К сожалению, это еще один пример проблемы двух людей и одной роли, которую я описал раньше (http://www.svpg.com/blog/files/product-management-vs-marketing.html). Это тот же самый вопрос, как и с разделением “бизнес менеджера продукта” и “технического менеджера продукта”, с теми же самыми ошибками.
Чтобы внести ясность скажу, что я против этого разделения в какой бы то ни было форме. Каждый продукт (или набор продуктов) должен иметь определенного владельца, который подотчетен и ответственен за все от высокоуровневых целей до деталей пользовательского интерфейса.
Хорошие новости заключаются в том, что часто бизнес-аналитики имеют потенциал стать прекрасными менеджерами продуктов.
Но есть одно исключение в том случае, когда бизнес-аналитики не фиксируют требования пользователей, а документируют внутреннюю спецификацию системы. Иногда встречаются и бизнес-аналитики, которые действительно играют эту роль документаторов. Я думаю, существуют отдельные вопросы с этим, но в данном случае, это на самом деле вопрос того, как компания-разработчик хочет организовать свою деятельность и не относится к сфере управления продуктами.
Если вы компания-разработчик программных продуктов и если ваши бизнес-аналитики хотят разделить ответственность определения продукта с менеджером продукта, я бы посоветовал вам хорошо изучить вопрос распределения ролей и должностей в вашей организации. Определите действительных менеджеров продуктов и дайти им полную власть над продуктом от высокоуровневого определения до деталей. Сделайте ясными ответственность и подотчетность.
Интересно, а как быть в том случае, когда продуктом является сервис, который компания предоставляет на рынок? Помимо самого “сервиса” в компании должна быть предусмотрена инфраструктура по его обслуживанию, например, техническая поддержка, система управления сервисом, аналитика и отчетность и т.п. Представим, что для каждого внутреннего процесса необходимо описать не только бизнес-процессы по обслуживанию и поддержке сервиса, но и требования к разработке специфичных систем. В таком случае помимо пользователей сервиса, существуют пользователи внутренние – сотрудники компании – чьи потребности тоже необходимо учесть. Причем если для сервиса “на рынок” нужно учитывать UX, сегментировать рынок и искать аудиторию с их потребностями и пр., то для сервиса “внутрь” нужно учитывать все нюансы ведения бизнеса.
Должен ли за все это отвечать менеджер продукта или он в первую очередь смотрит на рынок? И самое интересное – хватит ли его одного на все эти работы
Я знаю такую практику разделения ответственности между менеджером продуктов и бизнес-аналитиком: менеджер продукта отвечает за scope (общее описание) какого-то решения, а бизнес-аналитик описывает детальные, более технические требования.
Пример: менеджер продукта утверждает элемент скоупа: система должна делать выгрузку в AutoCAD, а бизнес-аналитик фиксирует множество ньюансов: какой именно AutoCAD, какие именно объекты, как замэпить объекты одной системы на объекты другой системы и т.д.
Одним предложением: бизнес-аналитик работает на более детальном уровне, нежели менеджер продукта.
В случае с сервисом, менеджер продукта отвечает за успешность всего сервиса в целом, а другие роли (вряд ли “бизнес-аналитики”) отвечают на более техническом уровне за успешное функционирование отдельных его элементов.