С каждым годом роль продуктового аналитика в ИТ существенно растет. По данным одной из ведущих платформ для поиска работы, рост вакансий в этой области только за последний год составил 30%. Это свидетельствует о том, что продуктовая аналитика существенно влияет на процесс разработки современных программных решений и ИТ-сектор нацелен на поиск квалифицированных специалистов.
Мы попросили Александра Антипова, главу отдела продуктовой аналитики в Comindware, рассказать о тонкостях работы продуктового аналитика. Он объясняет, почему коммуникативные навыки иногда могут быть более ценными, чем углубленные знания в области искусственного интеллекта, и почему важно учитывать не только новейшие технологии, но и реальные потребности пользователей, которые все еще в большинстве своем (76% по данным Gartner) предпочитают простые и эффективные решения.
«Процесс отслеживания пожеланий клиентов и обновление платформы происходят в реальном времени»
Какие основные обязанности и задачи выполняет продуктовая аналитика в Comindware?
В Comindware продуктовая аналитика выполняет ряд ключевых задач. Во-первых, она отвечает за сбор требований и использования функционала от наших внутренних и внешних клиентов. У нас есть отдел бизнес-аналитики, который взаимодействует напрямую с клиентами и реализует проекты на нашей платформе. Этот отдел прямо работает с клиентами, которые имеют свои функциональные потребности.
Основная работа сводится к сбору сценариев использования. Затем мы переходим к подготовке прототипов и анализу схожего функционала других решений, чтобы улучшить нашу платформу, объединяя лучшие идеи.
Кроме того, мы оказываем экспертную помощь при внедрении наших решений у клиентов и проводим презентации нового функционала для всех клиентов после окончания разработки. Наши обязанности также включают предоставление отчетов о проделанной работе руководству и подготовку глобальных планов для разработки. Это включает определение потребностей, какие прототипы мы хотим создать, визуальные и технические.
Могли бы вы рассказать подробнее о цикле отслеживания пожеланий клиентов и об изменении платформы? Накапливаются ли отзывы и затем превращаются в новую версию? Или отслеживание интересов клиентов происходит постоянно, в реальном времени?
Процесс отслеживания пожеланий клиентов и обновление платформы происходят в реальном времени. У нас есть несколько крупных активных клиентов, которые постоянно хотят добавить что-то новое или изменить существующий функционал. Как компания, которая ориентирована на потребителей, мы построили внутреннее общение команды так, чтобы ежедневно получать запросы от клиентов, например из отдела продаж. Продавцы часто сообщают нам, что определенный функционал востребован и его наличие могло бы сделать Comindware Business Application Platform еще популярнее. Мы проводим аналитику этих запросов, чтобы убедится в том, что они коррелируют с запросами рынка.
Точка входа может быть от продавцов, от существующих клиентов, или от наших бизнес-аналитиков, которые работают над клиентскими проектами. В реальности, мы получаем множество запросов и знаем, что бизнес хочет увидеть что-то новое и инновационное на нашей платформе. Но при этом, наша задача – правильно оценить эти запросы и принять решение о дальнейшем развитии платформы.
«Продуктовый аналитик всегда должен быть на связи и уметь быстро переключаться между задачами»
Как принимается решение о том, что идея пройдет в разработку?
У нас есть команда из сотрудников различных отделов, включая бизнес, управление проектами, а также приглашенных экспертов из BPM-сообщества, так как наш продукт - low-code BPM платформа . Мы собираемся вместе и оцениваем, насколько новый функционал важен для текущих клиентов, насколько он востребован отделом продаж, насколько он будет привлекателен для маркетинга, и каковы будут затраты на его разработку. После того, как определены приоритеты всех этих функций, принимается решение о том, стоит ли заниматься разработкой того или иного функционала.
Какие преимущества и сложности связаны с работой продуктового аналитика, на ваш взгляд?
В нашей компании продуктовый аналитик всегда должен быть на связи и уметь быстро переключаться между задачами. У нас есть внутренние бизнес-аналитики, которые постоянно настраивают что-то и ведут различные проекты.
Платформенные решения не ограничиваются только CRM или стандартными бизнес-приложениями. У нас много разноплановых нетиповых проектов, и нужно понимать, как интегрировать различный функционал в платформу, чтобы он был подошел как для базовой CRM, так и для HR, ЭДО, ITSM, PLM или любых других решений, которые может придумать клиент.
Преимущество этого подхода в том, что мы видим обратную связь от клиента, чего не происходит при разработке без прямого контакта с клиентом или при тестировании. Мы разрабатываем функционал, демонстрируем его клиенту, получаем от него обратную связь, и сразу же понимаем, что мы сделали правильно или неправильно. Поэтому работа с клиентами и получение от них обратной связи - очень важная часть нашей работы.
«Технические навыки являются критически важными»
Какие технические навыки и инструменты являются ключевыми для успешной работы в вашем отделе?
Поскольку мы разрабатываем low-code BPM-платформу, знание BPMN 2.0 нотации абсолютно необходимо. Также важны навыки программирования, так как нам часто приходится оркестрировать другие системы. То есть, нам нужно продумать модули интеграции нашей платформы с другими системами.
Быстрое принятие решений требует умения работать с API, JSON и XML форматами, а также быстро создавать тестовые заглушки для проверки направления разработки продукта. Это небольшое уточнение, но оно очень важно. В итоге получается, что роль аналитика включает в себя элементы работы программиста и руководителя проекта.
И хотя идеальный сценарий предполагает, что аналитик просто предоставляет входные данные и ожидает реализации, на практике мы постоянно контролируем проделанную разработчиками работу. Может быть, это связано с особенностями нашей компании, но разработчики иногда считают, что они лучше знают, что делать.
Как вы определяете и формализуете требования к продуктам Comindware на основе аналитических данных?
На самом деле процесс начинается с общения с заказчиком. Мы получаем от него пользовательские истории и сценарии, понимаем, какие потребности бизнеса он хочет закрыть. Далее мы обращаемся к нашим внутренним заказчикам – бизнес-аналитикам, а также к тем клиентам, которые предпочитают активно общаться и приходят к нам со своими историями. Мы собираем все эти пользовательские истории по функционалу и создаем прототип в дизайне.
Допустим, заказчик приходит к нам с задачей о том, что в ЭДО-системе нужно отправлять определенные уведомления. Мы смотрим на эту задачу с точки зрения платформы и пытаемся понять, как можно удобно отправлять уведомления не только для ЭДО, но и для других возможных проектов.
Когда мы проанализировали все требования и создали прототип, мы передаем его в разработку. После того как прототип создан, мы собираем обратную связь и совершенствуем функционал. Вот так в общих чертах выглядит наш процесс.
Как вы управляете своим временем и задачами, учитывая большое количество информации, с которой вы работаете каждый день?
Да, действительно, задач всегда много, и многие из них очень интересные. Всегда можно найти время для интересной задачи. В целом, мы приоритезируем все задачи и работаем над ними в соответствии с установленными приоритетами. Если количество задач начинает превышать доступное время, мы обсуждаем этот вопрос и рассматриваем возможность привлечения дополнительных ресурсов.
«Мы способны быстро адаптироваться и изменяться»
Какие задачи вы считаете интересными для себя?
Последним интересным проектом, над которым мы работали, было создание функционала для отображения DWG-файлов на нашей платформе. Это формат, используемый в AutoCAD для создания всевозможных чертежей - от планов зданий до деталей машин. У нас был заказчик, который хотел использовать этот функционал для управления зданиями в рамках продукта Comindware Моё здание, чтобы отображать заявки на обслуживание и клининг прямо на планах зданий. Мы подошли к этой задаче более широко и рассмотрели возможность использования этого формата для отображения, например, железнодорожных путей, требующих ремонта, собрали данные о том, как и кем этот формат может быть использован в связи с процессами, и подстроили под эти требования интерфейс и функционал всего продукта.
А как ваши аналитические отчеты и выводы влияют на стратегию развития продукта в Comindware?
Мы, как относительно небольшая компания, способны быстро адаптироваться и изменяться. Наши отчеты и анализ имеют прямое влияние на направление, в котором развиваются продукты. Последним ярким примером была работа над функционалом Kanban. Изначально, этот функционал предназначался для отображения непроцессных задач, так как в контексте процессных задач в нем нет смысла.
После создания прототипа и доработки задач, мы пришли к выводу, что дальнейшее развитие Kanban для процессной методологии нецелесообразно. Вместо этого, мы увидели, что более продуктивно будет сконцентрироваться на улучшении управления списками процессных задач, настройке параметров, добавлении возможности вывода дополнительных атрибутов и выполнения операций над задачами. Таким образом, мы больше сосредоточились на управлении процессными задачами, что лучше подходит BPM-платформе.
Как вы работаете с другими отделами компании, например, с отделом разработки, отделом маркетинга, для обеспечения точности и полезности ваших аналитических данных?
Мы тесно сотрудничаем со всеми отделами в нашей компании. С отделом разработки взаимодействуем на регулярной основе, поскольку продукт довольно сложен. Периодически они нуждаются в нашей помощи для понимания конкретных целей функционала и его корректной интеграции в продукт. Это может охватывать вопросы от размещения кнопок до направления данных.
С отделом маркетинга мы также на постоянной основе обмениваемся информацией. Мы обсуждаем текущие и будущие функциональные возможности продукта и ищем наилучшие способы их представления для привлечения клиентов. Также мы получаем от них оценку функциональности продукта. Мы также ведем активное общение с отделом продаж и отделом бизнес-анализа.
Можете ли вы рассказать о каком-нибудь примере, когда ваши аналитические выводы привели к значительным изменениям в продукте или стратегии компании?
Как пример, можно привести ситуацию с продуктом Comindware Architect, который изначально разрабатывался отдельно. Этот продукт предназначен для описания архитектуры и процессной структуры предприятия, и он обладает широким набором возможностей. Однако мы пришли к выводу о необходимости его интеграции с основной платформой.
«Коммуникативные навыки играют центральную роль для успешного продуктового аналитика»
Какие качества, на ваш взгляд, помимо технических навыков, важны для успешного продуктового аналитика?
На мой взгляд, коммуникативные навыки играют центральную роль для успешного продуктового аналитика. Умение находить общий язык и общаться с различными отделами и клиентами, не только помогает представить функционал правильно, но и донести разработчику конкретные задачи. Важно также объяснить клиенту, почему продукт разработан именно таким образом, а не иным, учитывая, что клиенты часто ожидают универсальные решения. В реальности, функционал часто подразумевает использование нескольких инструментов для удовлетворения различных потребностей. Умение эффективно донести это до клиента важно для его удовлетворенности продуктом.
Скажите, а вам часто встречаются продуктовые аналитики, которые хорошо подкованы технически и имеют высокие навыки в коммуникационной части?
Обычно, это два различных типа людей: те, кто любят общаться и неплохо разбираются в технике, и те, кто глубоко технически подкованы и предпочитают работу, связанную с системным анализом и описанием требований, но не так активны в общении с клиентами. Найти человека, который одинаково сильно развит в обеих этих областях, довольно сложно, но такие специалисты есть и они действительно впечатляют.
Встречались ли вам ситуации, когда аналитические данные противоречили интуиции команды или руководства? И как вы решали такие ситуации?
Да, такие ситуации бывали. При этом важным решением было использование коммуникативных навыков для обсуждения проблемы и нахождения поддержки в разных отделах компании. Принято было приводить убедительные аргументы и строить диалог с руководством, уже имея поддержку коллег. В таком случае, возникшие конфликты обычно разрешались.
На какую литературу стоит обратить внимание и какие скиллы развивать тем, кто планирует строить карьеру продуктового аналитика в ИТ?
Сейчас многие ориентируются на искусственный интеллект, это очевидно. Однако важно понять, что конкретно вы хотите достичь, работая продуктовым аналитиком. Ведь можно заниматься стратегическим анализом, техническими аспектами или, например, презентацией продуктов. В контексте нашего сегмента рынка , много интереса к AI, но реально пользователи еще не готовы к этому. Они хотят быстрых решений, большинство работает на системах вроде SAP, 1С или даже Excel. Поэтому я бы посоветовал изучить как можно больше различных продуктов на рынке, выбрать себе нишу, если вы уже работаете в компании, изучите конкурентов, включая зарубежных, оцените их стратегии развития и попытайтесь избежать их ошибок.