Чем занимается системный аналитик в продуктовой компании?
Выделим сперва направления разработки в рамках продуктовой организации:
◻️Клиентские сервисы, которые нацелены на удовлетворение потребностей конечного пользователя продукта.
◻️Внутренние сервисы, которые заточены под обработку данных, которые генерят клиентские сервисы. Такие сервисы служат интересам компании: маркетинг, продажи, поддержка, биллинг.
◻️Платформенные решения, как для улучшения клиентского опыта, так и в целях производственной необходимости (переход на новую архитектуру);
◻️Автоматизация бизнес-процессов компании: hr-процессы, бухгалтерия, процессы разработки и деплоя.
Мы поговорим сегодня о первом пункте, так как он больше всего вызывает вопросов.
🔷Синхронизация участников команды для наиболее точного соответствия реализации исходным требованиям. Основной фокус у владельца продукта (ВП) - генерить и проверять продуктовые идеи. Если его перегружать другими заботами, то рано или поздно ВП скатится в какую-то гибридную роль, что не добавит качества продукту. И здесь на помощь приходит СА, который лучше всего подходит на роль единой точки входа (в том числе - «прокси») для всех вопросов, возникающих по ходу разработки.
🔷Обеспечение эффективного планирования. Для того, чтобы можно было дать обещания стейкхолдерам и/или конечным пользователям, ВП требуется «точная» оценка затрат на разработку. И в его интересах получить это как можно раньше.
Поэтому, СА «встречает» продуктовую идею, прокапывает область возможных решений, взаимодействует с командой, и формирует постановку в той степени детализации, которая позволит команде дать оценку - обычно команды разработки придумывают критерии соответствия постановки возможности оценки, тем самым формируют контракт с системным аналитиком и защищают себя от лишнего стресса.
🔷Полезное влияние на «первичный» бэклог. СА - полноценный участник этапа исследования (Discovery), поскольку "что" делать в продукте зависит в том числе от текущей реализации и ограничений.
В качестве примера возьмем потребность добавить в систему отчет - казалось бы, что все данные для отчета хранятся (и это уже может понимать сам ВП на этапе формирования идеи), но механизмов в системе для обеспечения должного уровня качества (например, время ожидания клиентом) может не быть - например, сервиса асинхронной печати или подходящего представления в БД (view). Первичную валидацию проще отдать СА, особенно в условиях обсуждения идей на ранних этапах.
🔷Проектирование новой функциональности, где требуется пересмотр логической модели данных в сторону выделения новых сущностей или вовсе выделения новых субдоменов.
Подобные случаи возникают не часто в зрелом продукте, но они возникают. И далее происходит классическая история, когда ВП вместе с девелоперами тратят много ресурсов или делают костыли. В таких задачах СА может проявить себя на «все деньги».
Поскольку подобное возникает эпизодически, то эффективнее с точки зрения ресурсов может стать формат открытой гильдии СА, что предполагает привлечение аналитика по запросу к задаче (без закрепления за командой)
🔷Участие в разработке тестов для автоматизации.
Сперва описывать функциональную спецификацию, а затем переводить в формат под BDD (например), расточительно в условиях
гибкой и быстрой разработки.
🔷Поддержка базы знаний.
Кто-то должен успевать делать реверс-инжинирнг требований, и следить за целостностью и корректностью всей документации по продукту.
🔷Обеспечение кросс-командных взаимодействий. Если брать крупный финтех, то работу нескольких команд в рамках внедрения новой функциональности могут координировать выделенные роли, но к сожалению такое разделение труда не все могут позволить, поэтому подобное выпадает на ВП, которому нужна поддержка в части организации логической и технической декомпозиции и планирования последовательности выполнения работ. И снова СА.
Резюмируя, попав в продуктовую компанию вы найдете себе применение в ролях аналитика и проектировщика ИС - соотношение прежде всего будет зависеть от масштаба клиентских сервисов и обязанностей ваших коллег.
6
4February 25, 2024 480 6
