Septor.net.ua

В зaключeнии oчeнь xoтeлa дaть-тaки кaкoe-тo oпрeдeлeниe, oбoзнaчить грaницы oтвeтствeннoсти и рaсстaвить всe тoчки нa «и», нo тaк и нe смoглa. Яркий, xoть и примитивный примeр, кoгдa вмeстo прeдзaпoлнeния или сoxрaнeния ужe ввeдeнныx дaнныx, пoльзoвaтeля пытaются зaстaвить ввeсти иx пoвтoрнo. Нo я тaкжe aбсoлютнo тoчнo знaю, чтo выдeлeнный мaркeтoлoг сдeлaeт всe вышeпeрeчислeннoe лучшe и эффeктивнee. При этoм я видeлa и oбрaтную ситуaцию. Eсли сильнo-сильнo упрoстить и утрирoвaть, тo прoдaкт зaинтeрeсoвaн в мaксимaльнoм кoличeствe нoвыx фичeй, a прoджeкт — чтoбы фичeй былo пoмeньшe, тaк кaк нoвыe фичи нeизмeннo привoдят к нoвым бaгaм и удлинeнию срoкoв. Срaзу oгoвoрюсь, любoй спeциaлист, из пeрeчислeнныx нижe, мoжeт пeрeквaлифицирoвaться и стaть oтличным прoдaктoм. Бoлee тoгo, слoжнo нaйти кoгo-тo бoлee бoлeющeгo зa прoдукт, чeм eгo oснoвныe сoздaтeли — рaзрaбoтчики. Изучив прoдукт вдoль и пoпeрeк, тeстирoвщик кaк никтo другoй знaeт всe eгo слaбыe и сильныe стoрoны, a знaчит мoжeт увидeть тo, чтo нужнo улучшить в пeрвую oчeрeдь. В цeлoм xoрoший мeнeджeр с прoдуктoвым мышлeниeм впoлнe мoжeт сaм упрaвлять свoими прoeктaми дo oпрeдeлeннoгo прeдeлa. Нo любoй рaзрaбoткe нужeн прoдaкт, кoтoрый смoжeт сoсрeдoтoчиться нa пoльзoвaтeляx и изучeнии иx пoтрeбнoстeй, кoтoрый смoжeт выступить фильтрoм мeжду пoтoкoм идeй и рaзрaбoтчикaми, кoтoрый вoзьмeт нa сeбя юридичeскиe и финaнсoвыe вoпрoсы, прeдoстaвив рaзрaбoтчикaм дeлaть тo, чтo oни любят — писaть кoд. Возможно, кто-то найдет ответы на свои вопросы. Во многом виноваты в таком отношении сами продакт-менеджеры. Чрезмерное усложнение возникает, когда для решения простой задачи разработчик пытается применить новую интересную ему технологию просто ради ее изучения, читай — ради интереса. Или когда пользователя пытаются заставить угадать правильный формат ввода номера телефона вместо того, чтобы просто принимать любой введенный формат. На новичка смотрят как на диковинную зверушку и относятся к нему подозрительно: «раньше мы как-то справлялись, зачем он нужен?»

Я попробую сопоставить роль продакта с другими некоторыми ролями в команде. Почему продакт — не дизайнер

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

Подход продакта и тестировщика к процессу тестирования продукта должен радикально отличаться. В «СКБ-Контуре», например, вся команда по-очереди отрабатывала целый день в саппорте. Почему продакт — не проджект

Прежде всего продакт — не проджект, потому что в идеале они должны находиться по разную сторону баррикад. Люди редко любят тех коллег, чья деятельность и зона ответственности непонятна и непривычна. Этап отрисовки макетов и состояний требует от дизайнера дотошности, погружения и времени. При этом ему нужно быть достаточно жестким, чтобы вовремя сказать»нет», и гибким, чтобы своевременно изменить курс. Часто внутри команды отношение к продуктологам крайне отрицательное. Это в идеале. На практике чрезмерное упрощение выливается в то, что многие вещи перекладываются на пользователя. Если вернуться к этапам, описанным выше, то на мой взгляд, состав фичей — это экспертиза продакта, пользовательское взаимодействие с фичами — совместная работа, визуальное оформление — зона экспертизы дизайнера. Единственное, что на мой взгляд, продакт категорически не имеет права делегировать маркетологам — это презентацию своего продукта на крупных мероприятиях. В статье речь идет именно о совмещении ролей и разнице между ними. Я видела примеры таких трансформаций. Лично я уже отработала несколько модераторских смен, чтобы лучше понять модераторов — одну из ЦА продукта»Рамблер/комментарии». Продактом может стать любой член команды, готовый смотреть шире, видеть проблемы пользователей и чувствовать их потребности. На всех этих этапах требуется активное участие и продакта, и дизайнера, но в разных долях. Узконаправленные презентации с целью продаж делегировать можно и нужно. В случае, если продакт не до конца выполняет свои обязанности, у команды часто возникает резонный вопрос»А зачем этот человек вообще нужен?»

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

Сложно найти человека, который сможет полноценно закрывать собой обе роли и делать это эффективно. В случае с разработкой этот конфликт приобретает поистине колоссальные масштабы. При этом продукт только выиграет, если на всех четырех этапах продакт и дизайнер будут тесно взаимодействовать и прислушиваться друг к другу. Именно так например в один из периодов работала я. У разработчика может быть слишком велик соблазн смотреть на продукт не с точки зрения пользователя, а с точки зрения кода, пытаться его либо слишком упростить, либо слишком усложнить. «Продакт нужен», «Работать без продакта сложно или невозможно». Будучи изначально проектным менеджером, люди брали в руки и управление продуктом и делали это блестяще. Екатерина Текунова — преподаватель на очной программе обучения «Руководитель digital-продукта». Роль продакт-менеджера в команде обширна и может меняться в зависимости от особенностей конкретной компании. Тут важно понять, что никто из разработчиков не пытается навредить, ни в коем случае. А самое главное — продакт должен иметь достаточно смелости, чтобы взять на себя всю полноту ответственности за все, что происходит с его сервисом. Почему продакт — не разработчик

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

Продакт должен делать правильный продукт, а инженер должен делать продукт правильно. У него больше времени на то, чтобы создать не 10 объявлений, а 20, оценивать, таргетировать, менять, снимать и снова оценивать, подключать переменные и следить за ставками. Четкого определения этого предела я дать не могу, тут все зависит от способностей конкретного человека и организованности конкретной команды. UX-тестирование — совместная работа. Аналогичную ситуацию я, как выпускник факультета PR МГИМО, наблюдала по отношению к PR-специалистам. До сих пор на рынке нет четкого понятия, кто же такие руководители продукта. Задача продуктолога — даже не в проверке базовых сценариев, а в том, чтобы убедиться, что в условиях, максимально приближенных к боевым(а лучше в боевых), у реальных пользователей все работает, как ожидается. Как бывший маркетолог, я знаю, как работает Директ, что такое Минусинск, как организовать спонсорство целевого мероприятия, рассчитать CTR и сделать прогноз по трафику. По большому счету, именно во власти руководителя продукта закрыть баг, описанный выше, в таск-трекере с пометкой wont fix. Реальность, как обычно, довольно сурова. Продакт должен быть либо постоянным пользователем своего продукта, либо хотя бы периодически полноценно становиться на место пользователя и выходить в поля. Выпускники программы:

смогут претендовать на должности «Менеджер продукта» и «Product Owner» с зарплатой от 120 тысяч рублей;
получат диплом о профессиональной переподготовке по специальности «Руководитель digital-продукта». Например, два менеджера на трех разработчиков — это явный перебор. Кто же такой этот продакт? Налицо конфликт интересов, который в одном человеке может привести к раздвоению личности. Да и прогнозы его будут более точными и продуманными. При этом я знаю не один пример, когда тестировщики становились отличными продактами. Единственное, этот один менеджер все-таки должен прежде всего обладать продуктовым мышлением и работать над созданием и развитием продукта, вдоль дороги выстраивая процессы разработки. Если команда маленькая, то двух менеджеров на проекте быть не должно, иначе это может привести к недоумению среди разработчиков. Очень крупноблочно можно выделить несколько этапов, необходимых для создания хорошего дизайна продукта: состав фичей релиза, механика взаимодействия пользователя с интерфейсом, визуальное оформление, UX-тестирование, изменения. Он договорится о лучших условиях спонсорства и организует лаунж-зону так, что в ней кто-то захочет остаться жить. Гораздо лучше, если все-таки дизайнер будет полностью сосредоточен на визуальной составляющей, а продакт параллельно будет заниматься, например, формированием гипотез для тестов. Руководитель сервиса»Рамблер/платформа», преподаватель программы»Руководитель digital-продукта» в «Нетологии» в колонке рассказывает, чем менеджер продукта отличается от привычных ролей в команде. Когда-то в Яндексе было такое понятие как»менеджер Яндекса», и на странице вакансий даже подробно объяснялось, что это за роль: если представить проект, как отдельную фирму, то это её руководитель. Но рассказывать на мероприятии к запуску или условном РИФ+КИБ продакт должен лично.