Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

По ту сторону изгороди: бизнес-аналитик о работе в роли продакт-оунера

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

Хочу поделиться с вами своим опытом работы в роли продакт-оунера в одной крупной компании. Подобные компании принято называть энтерпрайзами. Знаю, что у многих коллег есть опыт работы по такой схеме: бизнес-аналитик взаимодействует с представителем компании-заказчика, обсуждает с ним требования к продукту, детализирует их и передает команде. Представитель бизнеса в этой схеме принимает на себя роль продакт-оунера на время проекта. Однажды мне повезло самому побывать в шкуре такого продакт-оунера, и теперь полученный опыт помогает в работе «по другую сторону изгороди». Об этом и будет мой рассказ.

Статья будет полезна в первую очередь аналитикам, работающим на аутсорсе, особенно с энтерпрайз-клиентами. Надеюсь, что аналитики, которые трудятся в других условиях, также найдут в ней для себя что-то полезное.

С чего все началось

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

Я работал в украинском подразделении компании. Формально моя должность называлась финансовый контролер: я отвечал за координацию финансовой отчетности, а также за создание всевозможных бизнес-кейсов, сценариев и прочей менеджерской белиберды. По факту же примерно половина моего рабочего времени уходила на оптимизацию работы различных департаментов, процессный анализ, курирование внутренних «айти-попыток» (айти-проектами это назвать не решаюсь), а также на целую гору нетривиальных задач. Работал много. Гораздо больше, чем следовало, и эта деталь еще сыграет свою роль в моем повествовании.






История началась с того, что у моего руководителя открылся третий глаз, с помощью которого он увидел образ того, что непременно сделает работу нашей компании более эффективной, а жизнь ее генерального директора — легкой, как сентябрьский ветерок. Этот образ явился руководителю в виде некоего «инструмента» (так он его назвал), который должен был, во-первых, показывать, в каком состоянии находится бизнес; во-вторых, уметь отслеживать все KPI; в-третьих — давать возможность «проваливаться» в любые цифры и вытаскивать по ним детали, т. е. иметь функцию drill down (хотя мы тогда еще не знали, что это так называется).

Мне было поручено изучить лучшие практики на рынке и найти такой инструмент. Я взялся за эту задачу с присущим мне на тот момент рвением (т. е. не спеша) и выяснил, что нам нужна Business Intelligence. Мы изучили существующие в то время решения (Tableau, Dundas, Power BI, что-то еще), и нам все безумно понравилось. Не понравилась только цена. Прямо сильно не понравилась.

Сначала показалось, что это не проблема, так как речь шла о «всего лишь программировании». У нас на заводе есть программисты, почему бы им за свою заводскую зарплату не сделать точно такое же «Табло», только уже в соответствии с нашими нуждами? Сказано — сделано. Ну, вернее, не совсем сделано, так как программисты, как нетрудно догадаться, нам отказали: мол, не их профиль. Заводские программисты вообще не очень любят профессиональные вызовы.

Мы не стали отчаиваться и решили найти субподрядчика, который специализируется на подобных решениях и сделает для нас «Табло».

Появляется IT-компания

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

Мы встретились с представителями компании, обозначили свои пожелания, показали примеры продуктов, которые нам нравятся, и заключили контракт. Нас заверили, что все поняли и все сделают как нужно. Я был назначен представителем бизнеса и главным контактным лицом. Так я, сам того не ведая, стал продакт-оунером.

Мы ушли со встречи в полной уверенности, что все будет хорошо и что проект ожидает сокрушительный успех. В этом месте неплохо бы посмотреть на фото Большого каньона (Аризона), чтобы представить себе размер пропасти между нашими ожиданиями на тот момент и реальностью, которая обрушилась на нас в ближайшие месяцы.

К слову сказать, IT-компания предлагала нам и дискавери-фазу, и онсайт, и пользовательские интервью. Мы отказались. Потому что, во-первых, это долго и дорого, во-вторых, конфиденциальность и безопасность никто не отменял (нечего у нас по заводу шастать!), ну и, в-третьих, мы все сами расскажем, не нужно вам с этими пользователями говорить.

Пару слов об ограничениях

Они есть в любом проекте. В нашем случае мы были ограничены технологией, а именно SharePoint. Причина была тоже очень типичной для энтерпрайза. SharePoint кто-то когда-то купил без конкретной цели; скорее всего, у покупателя был неосвоенный бюджет, а у продавца — какая-то акция вроде «3 по цене 1» или «каждому третьему покупателю — SharePoint в подарок». Как бы там ни было, SharePoint у нас был, и его нужно было как-то использовать.

Ну и, конечно же, были бюджетные и временные ограничения. У любого департамента в энтерпрайзе есть точка во времени, после которой все происходящее теряет всякий смысл. Это дата, к которой нужно успеть освоить бюджет. Иначе в следующем году дадут меньше. Мы не были исключением.

Пони бегают по кругу

Я начал работу с бизнес-аналитиком. Наша первая встреча прошла отлично, я рассказал о нашем бизнесе, о том, как мы работаем, на какие цифры смотрим и каким образом. Показал нашу «эксельку» с формулами (конечно же, у нас была «экселька», тысячи их). Аналитик бодро кивал головой, задавал наводящие вопросы, в общем слушал активно. Ничто не предвещало беды. На нашей второй встрече я ощутил сильнейший приступ дежавю: аналитик задавал ровно те же вопросы, что и раньше, получал те же ответы и кивал еще бодрее. На третью встречу аналитик пришел не один. С ним была девушка, которая с ходу потребовала от меня «структурированных данных». На это я резонно, как мне казалось, заявил, что, мол, вон у вас наша «экселька», смотрим туда и не задаем глупых вопросов — там все структурировано.

Это небольшой, но очень показательный пример. Читатели, поймите, у бизнеса нет ни возможности, ни желания разбираться в том, что такое структурированные или неструктурированные данные. Также бизнесу непонятно, почему нельзя просто взять «эксельку», где есть формулы, и запрограммировать, чтобы работало по формулам, как в «эксельке», только лучше.

У нас было еще несколько встреч, где мы обсуждали одно и то же. Я понял, в чем была проблема: аналитик IT-компании банально не понимал того, что я говорю, потому что не знал языка, на котором я разговариваю. Это еще один показательный пример. Дело в том, что люди, которые долгое время работают в конкретном бизнесе и привыкают использовать определенную терминологию и жаргонизмы, искренне считают, что все вокруг разговаривают точно так же. Оказалось, что аналитик не особо понимал, что такое рабочий капитал или фри кэш-флоу. Когда я стал разжевывать каждый термин и объяснять его значение, дело наконец-то пошло быстрее. Мне же объяснили, что такое структурированные данные. Я выдал ребятам нужную табличку, конечно же, заполнив ее не реальными данными, а каким-то мусором, потому что конфиденциальность, безопасность, все дела. Это мне потом еще аукнулось.

Первое демо

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

Что-то пошло не так

Мне прислали на утверждение спецификацию, страниц 30–40 убористого текста. Я уже упоминал, что работал в то время довольно много и имел кучу параллельно идущих сложных задач. На этот проект я мог выделять не больше 10% своего времени, и, по правде говоря, мне не очень хотелось читать документ целиком. Поэтому просто просмотрел ключевые, как мне казалось, места, где были формулы, и завизировал спецификацию.

Это еще один маленький, но очень показательный пример. Дорогие читатели, продакт-оунеры далеко не всегда внимательно читают те требования, которые вы им высылаете на согласование.

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

В итоге

Проект занял в два раза больше времени, чем изначально планировалось. Дизайн лучше не стал. Пользоваться продуктом никто не хотел. Генеральный директор, наш главный стейкхолдер (тот, чья жизнь должна была стать легкой, как сентябрьский ветерок) о продукте даже не узнал.

Казалось бы, полная катастрофа! Но по факту никто сильно не расстроился. Да, были потрачены усилия и деньги, но эти деньги были в пределах допустимого бюджета. Сами по себе расходы в отчетности огромного холдинга были такими незначительными, что при любом drill down’е вряд ли вышли бы за пределы строчки «прочие расходы». Никого не наказали и не уволили.

Читатели, именно таким образом на просторах энтерпрайзов рождаются и гибнут сотни внутренних продуктов. И это нормально. Это жизнь.

Полученные уроки

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

Изучайте бизнес клиента

Подробное исследование бизнеса клиента поможет аналитику быть в теме и лучше понимать заказчика, что экономит время обоим. Далеко не каждый будет открыто делиться информацией о своем бизнесе, но это не тупик. Сайты crunchbase.com или owler.com помогут вам получить верхнеуровневую информацию о компании-клиенте, ее доходах, последних инвестициях, слияниях и поглощениях.

Чтобы углубиться, можно покопаться в статьях и пресс-релизах компании. Если предприятие достаточно большое и имеет форму акционерного общества, то на корпоративном сайте часто публикуются финансовые отчеты и стратегические планы — это отличный источник. Почитайте отзывы сотрудников на таких сайтах, как, например, glassdoor.com. Эта информация поможет вам понять культуру компании, а также обнаружить какие-то внутренние проблемы и боли, о которых клиент решит вам не рассказывать.

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

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

Создавайте глоссарий

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

Управляйте ожиданиями

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

Обучайте клиента

Клиент не обязан ничего знать об особенностях SDLC и прочих нюансах разработки. Важно постепенно и ненавязчиво знакомить его с основными шагами и фазами ваших процессов. Здесь все зависит от готовности клиента воспринимать эту информацию. Хорошим поводом рассказать о процессах и ролях в проекте является kick-off-встреча. Важно не просто произнести: «Это Петя, он бизнес-аналитик. А вот это Вася, он проектный менеджер». Расскажите, кто такой аналитик, чем и зачем он будет заниматься, за что отвечает и какова от него польза проекту. Также не мешает упомянуть, какие условия необходимы для того, чтобы польза была максимальной. Например, доступность ключевых стейкхолдеров, формат коммуникации, возможность ознакомиться с интерфейсом текущей системы (если она существует), изучить и описать текущие процессы в компании и т. д.

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

Предлагайте решения

Чаще всего в нашей практике клиент приходит с готовым решением, которое «осталось только реализовать». Мой опыт показывает, что в большинстве случаев «готовое решение» клиента не является таковым и не решает его проблем. Чаще всего энтерпрайз-клиент не знает, как создавать софт (несмотря на то, что сам он может думать иначе). И его «решение» — на самом деле просто попытка объяснить свою проблему языком, который, как ему кажется, вы поймете. На первых порах вашей работы с клиентом не концентрируйтесь на реализации решения. Разбирайтесь, почему клиент придумал именно такое решение. Не «как» и «что», а «почему». Не стесняйтесь предлагать решения, если видите в них ценность для бизнеса клиента: это ваша работа.

Допустим, клиент просит вас сделать ему «свой внутренний скайп», потому что обычный «Скайп» не является достаточно безопасным. Можно сразу приступить к анализу продукта, декомпозировать функциональность, зафиксировать ключевые требования по безопасности и начать делать «свой скайп». Но если задаться вопросами, зачем «Скайп» нужен клиенту и как он его использует, можно выяснить, что в 99% случаев с помощью этой программы сотрудники будут передавать друг другу файлы и совместно над ними работать, обсуждая правки по телефону. Тогда зачем нужна реплика «Скайпа»? Сделайте секьюрный аналог Google Docs с возможностью параллельной работы! Это решение будет гораздо больше соответствовать потребностям бизнеса. Но клиент может не знать о Google Docs, ему известно только о «Скайпе», поэтому о нем и говорит. Ваше видение шире: вы можете предложить лучшее решение и сделать клиента счастливым. Счастливый клиент вернется к вам еще не раз с новыми интересными задачами.

Заключение

В заключение позволю себе задать риторический вопрос: что же должен был сделать продакт-оунер в той истории, чтобы проект был более успешным? Мой ответ: ничего.

Я понимаю, что для большинства читателей это не очень комфортная мысль, и подчеркиваю, что это утверждение будет верным именно в случаях с энтерпрайзом. Для сотрудников в энтерпрайзе курирование одного или нескольких проектов может быть далеко не основной их деятельностью, да и в целом энтерпрайз не стремится разбираться в том, как работает это ваше IT, какие там процессы, что там можно и чего нельзя.

Задача бизнеса, как он ее понимает, — заплатить деньги и получить результат. И бизнес ожидает от нас, аналитиков, как от профессионалов своего дела, максимальной отдачи и ответственности за результат.

Здоровья нам!

Иллюстрация Уляны Патоки

LinkedIn

22 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Отличный рассказ о реалиях разработки в энтерпрайзе.
сам побывал в такой роли — одновременно бизнес аналитика и продакта.
И началось точно так же:
Генеральный:
Нам бы программку, я ж в институте тоже писал программки, которая по клику развернет состояние выполнение заказа,...
(дискретно-позаказное производство)

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

Интересный, честный и самокритичный рассказ.
Да, конечно, бизнес вправе приобрести на рынке уже готовый продукт, чтобы не тратить время и усилия на его разработку. Вот только такого приемлемого по цене предложения на рынке, очевидно, не было. И если уж заказчик желал и сэкономить, и получить эксклюзивные права на программный продукт, который стал бы информационным продолжением предприятия и позволил бы получить дополнительные конкурентные преимущества, стоило бы проявить больше заинтересованности и включиться в качестве полноценного участника процесса его разработки.
Для этого нужно было начать доверять разработчику, позволить ему общаться с непосредственными исполнителями, чтобы получать от них своевременную и ценную обратную связь. Быстрое появление базовой функциональности и начало её использования, частые выпуски обновлений и регулярное устранение замечаний, постепенное устойчивое расширение сферы использование продукта позволили бы успешно завершить работу.
К сожалению, мы не имели возможности услышать противоположную сторону. Наверное, бизнес-аналитик плохо ориентировался в предметной области. Но вряд ли можно сделать верный анализ бизнес-процессов предприятия на основе общей информации о корпоративной культуре, инвестициях и финансовом положении заказчика, случайных консультаций у коллег, субъективных отзывов сотрудников или изучением конкурентов. Вряд ли заказчику понравилось бы несогласованное использование информации от инсайдеров. И, конечно, ничто никогда не сможет компенсировать откровенный саботаж и непонимание сотрудников заказчика.

Классная статья, особенно для людей которые только начинают первые робкие попытки выстраивать диалог с клиентами выше уровня фриланса. Нашел конкретно для себя полезную информацию. Спасибо.

История интересная, спасибо что поделились. Действительно забавно, как роли могут меняться в одно мгновение :)

Соглашусь с некоторыми комментариями, что описанная роль больше похожа на Project Manager, особенно если судить по описанным ожиданиям и характеру нестыковок в вашей коммуникации с аналитиком.

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

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

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

Реноме на удаленке поддерживать конечно надо, но... Если убрать водичку, то о работе в роли продакт-оунера сказано что то в стиле: мы хотели придумать велосипед; потратили 10% времени; видели, что все идет не туда; потом все накрылось медным тазом, но никому ничего не было. А дальше пару абзацев техник из BABoK и какие то дискуссионные лайфхаки в виде lessons learned.
Хотя, может кому то и такой опыт будет полезен.

Читатели, именно таким образом на просторах энтерпрайзов рождаются и гибнут сотни внутренних продуктов. И это нормально. Это жизнь.

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

upd: заключение — хе**ня. Бизнес аналитк работает на интересы «своего домашнего» бизнеса, что там у клиента.... крайне вторично. И если заказчик «не хочет работать» — это его проблемы.

В «идеальном мире», обе стороны должны проявить профессионализм и заинтересованность результатом. Но пока превалирует — своя шкура ближе у каждого.

Классический риск, который должен был идентифицировать BA и PM подрядчика. И отработать. Поучиться тут особо не чему.
Но нужно отдать должное Кириллу, он набрался смелости признать свои ошибки и поделиться с широкой аудиторией. Возможно, начинающим BA это и будет полезно.

БІЗНЕС аналітик тому ж і називається так, бо повинен знати чи хоча б цікавитися бізнесом компанії, своєї,- якщо працює в ентерпрайз чи продуктовій компанії, та клієнтський — якщо в сервісній чи консалтинговій. Якщо не цікаво знати, що там у клієнта, при тому працює на того клієнта і вважає,що то клієнт має припіднести і розжувати все,чи «не хочет работать», то грош ціна такому БА. Хай просто називається іншим «титулом» (є system analyst, requirements engineer /manager/ analyst і т.д.)

После слов о том, что PowerBI и Tableau не понравились из-за цены и решили сделать свое «Табло», можно не читать.
Классическая история о том как люди не умеют считать деньги, а ИТ компании умеют красиво врать, что сделают за дешевле такой же только с перламутровыми пуговицами ©.

Спасибо, очень понравилась статья.

Спасибо за статью :)

Cтаття супер! Історія, структура, послідовність, lessons learned і поради — не відірватися. Особливо фрази типу «Я взялся за эту задачу с присущим мне на тот момент рвением (т. е. не спеша)», «Ничто не предвещало беды.» — це як спеції до вже ароматної паельї.

Кирилл, привет. Спасибо большое за историю. У меня один вопрос: а почему ты называешь свою роль на этом проекте — Product Owner?

Отвечу за Кирилла) Потому что роль того, кто контактирует с командой разработки со стороны бизнеса и отчитывается перед ТОП-менеджерами (или просто менеджерами, зависит от разветвленности иерархии и размеров самой организации), называется в разных методологиях Product Owner. К примеру, Product Owner рапортует перед Product Manager.

Вообще не рапортует, где так работают, откуда информация? Product owner рапортует перед stackeholders. Никогда вообще не встречал проэкт где есть продукт овнер и продакт менеджер: он попросто не нужен так как есть скарм мастер.

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

Не нужно привязываться к какой-то конкретной методологии. Это я по поводу присутствия скрам-мастера. Иерархически на стороне заказчика может быть так:
1. Product Manager. Это, как правило, руководитель высшего звена (ну может среднего, если компания большая) и обычно стратег. Отвечает за бюджет и выполнение «денежных» показателей. Фичи для него вторично. У него в линейном или функциональном подчинении PO и в крупных компаниях — не один.
2. Product Owner (должность особого значения не имеет) — чаще всего тактик: как достичь стратегию руководства. Его интересуют свойства и характеристики продукта.
Это вот обобщенное на стороне заказчика/бизнеса из разных методологий и литературы.
Дальше начинается разрозненная каша на стороне разработки) То IT Business Analyst иерархически выше Project Manager, то наоборот. Есть Scrum Master или нет. Разные роли у Team Lead и огромное подмножество всяких вариаций (я для себя логически расставил и упорядочил это всё, но всегда лучше уточнить зоны ответственности).

Привет Макс, я тебе ответил в линкедине, но продублирую здесь для истории. По сути я определял, что должно быть в продукте, принимал решения и отвечал за этот продукт — по сути это и есть Product Owner. Разве не так?

Кирилл, не совсем так. Коллеги, давайте не путать роли и фактические обязанности. Пусть даже вам и приходилось брать на себя определенные задачи, свойственные Product Owner’у и все было достаточно запутанно.

Роль Product Owner’а немного более широкая. Он находится на стороне разработки, т.к. очень плотно работает с командой реализующей продукт. Ключевым фактором, в большинстве случаев, является работа с несколькими клиентами по одному продукту, выработка единого решения.

А вы на данном проекты были классическим Project Manager, пусть даже и глубоко погружались в ход разработки продукта, участвовали в постановке задачи и сборе требований. Но вы были Заказчиком. И даже не брали команду в outsource. Иначе, получится, что в любом проектном решении заказчика нужно называть Product Owner’ом.

Название Product Owner как бы говорит само за себя: он на стороне заказчика. И это правильно: заказчика, который определяет что будет в продукте, называть владельцем продукта. Вот Project Manager может быть как на стороне разработки, так и на стороне заказчика: он реализует проект в рамках продукта (тоже название говорит об этом). А то, что начали замешивать одно с другим не вникая в исходную суть — это значения особого не имеет. Собственно, как и название. Как говорила классный кризис-менеджер: «да называйте хоть горшком, только в печь не ставьте»))

Продакт овнер может быть как на стороне заказчика так и на стороне разработки. На стороне заказчика это обычно кто-то из айти менеджеров. Но так как айти менеджмент на стороне заказчика часто вырожден в управление имуществом и людьми, а не разработкой, то история получается та же что и в статье.

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

Подписаться на комментарии