Эффективный системный анализ в больших продуктовых компаниях. Как появился системный анализ в Parimatch Tech

Я занимаю позицию Lead Systems Analyst в продуктовой компании Parimatch Tech (ранее — PMLAB) около года, в самой компании работаю около 4 лет. Также на сегодня я создал эффективную работу направления Systems Analysis в таких компаниях как Wirex, Betinvest, Terrasoft и других в сфере Fintech. Общий стаж работы в IT более 10 лет. Занимал в компаниях разные должности — РМ / РО / SA / BA, но всегда с уклоном в системный анализ. Руководящая позиция более 8 лет.

Кто такой SA? Зачем нужен SA?

SA — Systems Analyst.
Давайте обратимся за расшифровкой терминологии к Wiki:

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

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

Основным продуктом такого системного аналитика являются организационно-технические решения, оформляемые как техническое задание на систему или программное обеспечение.

SA — это довольно «молодая» профессия в украинской IT— индустрии, но формально эта профессия всегда существовала, «отвечая» в первую очередь за автоматизацию, постановку требований (ТЗ) и описание сложных технических процессов.
Но все же фактическое отсутствие SA на рынке Украины обусловлено тем, что эту роль выполняли другие сотрудники. Раньше системам не было присуще такое большое количество технических подходов и принципов, разноплановых интеграций, что позволяло комбинировать роль системного аналитика вместе с ВА / PM / PO.

6 лет назад я пришел в стартап, где хотели создать небольшой коммерческий банк, где требовалось создать весь Digital с нуля и где девиз был «как у Приват24». Мы работали так: утром согласовывали договоры, бюджеты и тендеры, а вечером переходили к системному анализу и проектированию архитектуры. За 2 года нам удалось создать конкурентоспособный интернет-банкинг с полным предоставлением услуг 24/7, сервисы Р2Р переводов, ESB для интеграции решений, свою сеть терминалов, пополнение банковских карт в АТМ без наличия пластиковой карты, виртуальные карты и личный кабинет дня них.

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

Но сегодня мир заставляет нас отдельно выделить SA для решения таких проблем:
— Выполнение декомпозиции работ на компоненты — мы можем иметь в различных MSA более 150 сервисов, которые имеют API и параллельно взаимодействуют c MQ и данная паутина сервисов между собой умудряется взаимодействовать, но чем больше архитектура, тем сложнее развивать такую архитектуру. Системный анализ позволяет учитывать особенности интеграций сервисов между собой и декомпозировать работы для избежания несогласованности той или иной доработки.

— Сокращение затрат на внедрение. Системный анализ — это дисковый сервис. Мы покрываем большинство проблем, накапливаем базу знаний и понимание архитектурных особенностей продукта.

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

— Поддержка актуальной архитектуры и знаний про сервисы компании. Это позволяет упростить:
* вхождение новых сотрудников в курс дел;
* аудиты и сертификации;
* анализ дефектов и поиск проблем;
* целостность и доступности информационной базы продукта.

Что делает SA в Parimatch Tech?

Все, что описано выше, но есть и особенность: у нас SA перерос в независимый сервис Pre-prod, в который входит BA / SA / Дизайн. Изначально SA были частью команд и это не позволяло выполнять комплексный анализ за рамками доверенного сервиса или продукта. Было принято решение создать кросс-команду SA, которая начала выполнять экспертно-аналитическую миссию по контролю всех компонентов компании и их интеграций, при этом ВА оставались частью конкретных стримов или команд и не выходили за рамки своего продукта, но часто взаимодействовали с SA.
Некоторое время мы выполняли работу в таком режиме, и подобный подход позволял работать эффективно, но все мы знаем, что если компания растет, требуется выполнять оптимизацию и адаптацию процессов, и анализ тому не исключение. Мы создали кросс-функциональную команду Pre-Prod, где объединили UX/UI, бизнес- и системных аналитиков.

Какую проблему решает Pre-Prod?

Мы получили внешний сервис, который используют РО для реализации своих проектов.
Сервис не является обязательным для прохождения через него всех задач компании, и это позволило сконцентрироваться на сложных и комплексных задачах.
Зона покрытия увеличилась — теперь все отвечают за продукт в целом, а не за компонент, и как результат, мы получаем максимальную вовлеченность и ответственность за фичу.
Мы смогли ускорить весь процесс анализа и передачи задачи в Delivery, чем снизили затраты компании на анализ, а также увеличили качество анализа за счет постоянной синхронизации дизайнеров и BA / SA.

Как Pre-Prod планирует свою работу?

Мы используем Scrum и двухнедельные спринты, которые начинаются и заканчиваются параллельно с Delivery, и наша основная цель — обеспечить Delivery на два спринта работы.

Почему вы обеспечиваете работой на два спринта?

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

Наша цель не хранить, утилизировать! Мы выполняем контроль и изучение наших бэклогов через компонент Jira — TimeStatus, и выводим все, что происходит на Dashboard. Если задача уже не актуальна — мы должны уточнить у РО, для себя разобраться в причинах и принять решение об утилизации.

Какой состав команды Pre-prod?
* SA — 5 человек;
* BA — 5 человек;
* UX / UI — 8 человек.

Parimatch Tech — это большая компания и потому у нас есть BA и SA, которые находятся за рамками Pre-Prod, и остались в функциональных стримах — это вызвано необходимостью и автономностью данных стримов. Пример: наша компания имеет внутренние продукты, которые предоставляют данные для наших платформ и эти продукты могут жить независимо, и оказывать сервис как В2С, так и В2В.

Как работал SA в других компаниях?

Ожидания у компаний всегда разные, но принцип работы одинаковый. SA отвечает за требования и декомпозицию. Многие компании привлекают SA как драйвера планирований команды, а также точку получения оценки.
Краткая формулировка — SA пишет техническое задание, ВА — пишет бизнес-задание, дизайнер — реализует визуализацию требований для конечного потребителя.

Получается, SA — это какой-то ботан?

Я думаю, что SA всегда должен иметь точку взаимодействия со всеми этапами жизненного цикла продукта, а это требует постоянной коммуникации и общительности. Есть стереотип, что системный аналитик — это ботан в очках, который не умеет разговаривать, но это не про нас : )
Я бы характеризовал SA так: это «несложившиеся» разработчики, но не потому что им не хватило знаний, а потому что SA дает в первую очередь возможность абстрактно мыслить и системно подходить к проектированию, мы выполняем роль «придумать и подумать». Также наши взгляды, скажем, более широкие, так как разработчик Backoffice не знает, как устроен логин на сайте для пользователя, но знает только логин Backoffice. Он не выходит за рамки своей работы, в то время как SA знают все про систему и платформу.

Какие подходы к документации системы вы используете?

Мы всегда анализируем мировые практики и пытаемся из них почерпнуть максимально полезную информацию для развития наших подходов, потому мы используем:

— индивидуальный шаблон BRD, который частично забрал рекомендации из IEEE 830 Software requirements specification/IEEE 1012 Software verification and validation;
— для моделирования бизнес-процессов BPMN 2.0;
— отображение интеграции сервисов и их архитектуры UML 2.0.

Имплементационная документация всегда доступна на Swagger при переходе на сервис, что позволяет отобразить структуру контроллера. Также мы используем интегрированную выгрузку данных в Postman.
Сама документация и архитектура всей платформы хранится на Confluence.

Если я хочу стать SA, что вы посоветуете?

Я сам проходил сложный, но интересный путь познания мира SA, и первое, что я учил, — это был SQL. Современный мир изменился и знаний SQL уже недостаточно, здесь нужно понимать:
— принципы ООП;
— Какие бывают архитектуры? Что такое MSA?
— Какие уровни модели OSI бывают и зачем они нужны?
— Что такое протокол прикладного уровня?
— Зачем нужна Json schema?
— Какое отличие между noSQL и SQL? Какие правила индексации?
— Как рисовать UML диаграмму последовательностей?
— Как использовать MQ?
— Зачем нужен подход в интеграции сервисов по принципу Event Sourcing?

Советую начинать свой путь с бизнес-анализа и плавно переходить в системный анализ. Когда вы научились слушать, чувствовать систему, понимать принципы интеграции и системного взаимодействия — вы уже SA. Достичь подобных знаний вам может помочь команда. Развивайте свои коммуникационные навыки и интересуйтесь у команды что и как работает, как FE ходит на BE. Научитесь говорить словами разработчиков и вы сможете стать SA.

Почему круто быть SA?

Вы становитесь независимым специалистом, так как SA может проектировать и проводить анализ на любом проекте и в любой системе. Нам все равно, это СRM или система платежей. Сегодня я анализирую процессинговый центр, а завтра работаю на платформе расчета рисков при строительстве мостов. Технические подходы практически одинаковые в разных сферах, а ваша ценность определяется знанием данных технологий и способностью их применить. Если мы сравним ВА — то бизнес-аналитики часто ограничены стажем работы в той или иной сфере. Существует фреймворк универсальности работы ВА, но чаще всего работодатель подбирает ВА, который уже имел опыт работы в его сфере, а с разработчиками, SA и архитекторами, как вы знаете, не так. Уровень компенсации SA выше, чем у ВА, и иногда равен позициям РМ / РО.

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

Я уже SA. Хочу работать у вас. Что сделать?

Ссылка на наши вакансии:
jobs.dou.ua/...​parimatch-tech/vacancies

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ну такое... Я-то ожидал что вы будете здесь про практики системного анализа (многокритериальное принятие решений, матмодели и тп) рассказывать, а получилось что-то вроде:

пипу-пупу SA это как BA, но знает что такое JSON и микросервисы

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

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

Статья нацелена на системный анализ и не рекламирует бизнес-домен платформы. Мы исключительно делимся своим опытом. Если Вам не нравится реклама — используйте adblock и посещайте авторизированные ресурсы. Youtube дает Вам возможность купить подписку без рекламы. Компании которые покупаю рекламное пространство не виноваты в том, что такая возможность предоставляется ресурсами которые Вы посещаете — так что Вам к ним.

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

наверно это надо предьявлять не пари матчу, а тем кто эту рекламу позволяет размещать. уже подавали жалобу в обл\гор совет на эту тему?

хорошая идея, подам) как будто они не знают кому заказывали размещение рекламы и локацию

Наверное реклама в метро не имеет отношения к ИТ? Причём в данной статье не упоминается ставки, игра. Я рассказал за наши паттерны и инструменты работы, которые являются унифицированным и используются не только в гембллинге. Метро рекламирует быстрые кредиты, forex, ломбарды и т.п. это решение рекламной площадки

Горшочек не вари!!!

Я б краще на сексуально-вмотивованому .it почитав :)

Богдан, це ви запостили статтю про себе, чи про свого колегу СА?(:

Нас много :) Мы все похожи! :)

Фабрика клонов? %)

«Играют они, побеждаешь ты»

с нетерпением жду топика от лица тараканов с кухни офиса этой гэмблинговой помойки

Я занимаю позицию Lead Systems Analyst в продуктовой компании Parimatch Tech (ранее — PMLAB) около года, в самой же компании он работает около 4 лет. Также на сегодня он создал эффективную работу направления Systems Analysis в таких компаниях как Wirex, Betinvest, Terrasoft и других в сфере Fintech. Общий стаж работы в IT более 10 лет.

Он — это кто?

>Мы используем постман, свагер, конфлюенс и джиру
>Scrum и двухнедельные спринты
>отдельная команда аналитиков.

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

По я/он синтаксису — очень похоже на артефакт редакции ДОУ. В моей статье тоже внесли несколько правок с подобными результатами.

Спасибо всем за Ваши замечания. Я обсудил данный момент и мы выполнили редактирование.

Погоджуюсь з попереднім коментарем про рекламу лайна

Вже була ваша тема як в Parimatch Tech працюють

Ви ж самі подібними темами, ще більше псуєте собі рейтинг

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