Всем привет! Меня зовут Александра Камзеева, я руководитель направления системного анализа в IT PMO в Lamoda. За полтора года мы выросли с 3 до 22 человек.
Такой стремительный рост и подтолкнул нас на вопрос: «Кто такой системный аналитик и какую роль он выполняет именно в Lamoda?» Мы поняли, что четкий ответ позволил бы нам эффективнее расширять команду, проводить собеседования и онбординг. Благодаря объяснению, кто мы такие, наши коллеги из разработки, QA, бизнеса лучше понимают, с какими вопросами и задачами стоит или не стоит к нам приходить.
Функции аналитиков могут отличаться от компании к компании. Сегодня я хотела бы поделиться опытом работы системных аналитиков в Lamoda. Из статьи вы узнаете, как системные аналитики помогают делать кросс-функциональные проекты, о разграничении ответственности между техлидом и системными аналитиками, о ценности для команды разработки и кто может в целом прийти на эту роль.
О бизнес-направлениях в Lamoda
Чтобы объяснить роль системного аналитика в Lamoda, сначала расскажу немного о компании. В нее входит 8 крупных бизнес-направлений, которые тесно связаны друг с другом:
склад,
доставка,
фотостудия,
контакт-центр,
сайт и приложение,
b2b-направление,
маркетинг,
финансы.
Кажется, что, например, отображение фотографий и описаний товаров на сайте — простой процесс. Но даже в нем задействовано 7 сервисов:
сайт или мобильное приложение отображает фотографии и описание товаров из Catalogue;
в Catalogue эта информация приходит из Content (система, которая автоматизирует процессы фотостудии) через RnD и Event-bus;
Content взаимодействует с системой склада WMS (Warehouse Management System), чтобы заказать нужные товары со склада в фотостудию. Еще сюда приходит информация о новых товарах из ERP-системы или B2B/ Marketplace-систем в зависимости от типа контракта товара;
также Content взаимодействует с ERP-системой в рамках товародвижения.
Схема ниже упрощенно показывает, как устроено взаимодействие бизнеса и IT в Lamoda. Бизнес-направления владеют системами, которые автоматизируют их процессы, а поддерживают и развивают их определенные команды разработки:
Если нужно локально внести изменения в систему, то с этим обычно нет трудностей: бизнес и команды разработки научились взаимодействовать и понимать, что и как нужно разработать, чтобы бизнес-процесс работал.
Сложности возникают, когда нужно сделать кросс-функциональный проект, который требует доработок в разных бизнес-направлениях, системах, за которые отвечают разные команды разработки.
Такие проекты требуют понимания «вида сверху» на все бизнес- и системные процессы. Конечно, есть эксперты, которые видят картину чуть шире, но все равно нужно обладать навыками и временем, чтобы разобраться во всех деталях кросс-функционального проекта для снижения цены ошибки при запуске. И здесь приходят на помощь системные аналитики.
Как мы делаем кросс-функциональные проекты
Рассмотрим, что такое кросс-функциональный проект, на примере возврата товаров партнеров через пункты выдачи заказов Lamoda (далее — ПВЗ). Раньше клиенты могли вернуть партнерские товары только через «Почту России», что не очень удобно для городов, где возможностей больше.
Как это выглядит с точки зрения клиента:
клиент приносит товар в ПВЗ и заявление на возврат;
менеджер ПВЗ фиксирует приемку товара в системе ПВЗ, которая оповещает систему процессинга заказа и ERP-систему об этом факте;
система процессинга заказов передает информацию через B2B-платформу в систему партнера и в систему возврата денежных средств;
товары передают партнеру через склад, фиксируя эту информацию в системе склада;
группа возврата денежных средств возвращает клиенту деньги через соответствующую систему.
Схематично процесс возврата партнерского товара через ПВЗ Lamoda можно показать так:
А в переводе на системные процессы он выглядит так:
Рассмотрим, чем занимается системный аналитик на каждом этапе проекта.
Этап идеи
На этапе идеи бизнес хочет понимать, стоит ли сейчас тратить свои силы на ее реализацию или нет. Для этого системный аналитик консультирует и помогает определить верхнеуровневый список задействованных бизнес-процессов в рамках всех бизнес-направлений, связанные проекты и риски.
Мы разделили проект из примера на такие процессы:
возврат товара через ПВЗ,
сортировка и отправка на склад,
возврат денег клиенту,
уведомление партнера.
Дальше помогаем определить список рисков. Конечно, он получится неполным, но мы подсвечиваем бизнесу информацию, которой владеем. В нашем примере мы получили следующее:
в системе доставки нужен рефакторинг процесса возвратов;
увеличится количество коробов отказов в зоне доставки, что критично, так как место ограничено.
После этого разрабатываем план действий, чтобы проект был взят в разработку.
Этап бизнес-анализа
Здесь аналитик максимально вовлечен в проект, потому что бизнес редко может написать идеальные для системного анализа требования. Мы помогаем ответить на вопросы и сформировать BRD (бизнес-требования). В нашем шаблоне BRD ключевыми разделами являются:
цель проекта;
границы проекта;
процессы AS IS («как есть»);
процессы TO BE («как будет»);
связанные проекты;
требования к отчетам;
требования к запуску.
Из перечисленных разделов я бы хотела обратить внимание на два последних.
Требования к отчетам — важный пункт, на который не всегда обращают внимание. У нас были случаи, когда о требованиях к отчетам не думали, а потом приходилось откатывать релиз и переделывать модели данных обменов между системами, таблицы в базе данных из-за того, что не предусмотрели необходимые поля для подсчета конверсии проекта. Из-за этого запуски проектов откладывались до 3 месяцев.
Аналогично с требованиями к запуску. Происходили ситуации, когда слишком поздно задумывались о том, как запускать проект не на 100%. Приходилось выкатывать релиз спустя 2 месяца после окончания всей разработки и тестирования по проекту.
Поэтому теперь эти два пункта включены в каждый BRD для обязательного заполнения.
Этап системного анализа
Его результат — спецификация, состоящая из следующих разделов:
описание архитектуры;
функциональные требования — требования к логике работы сервиса, обменам, UI;
нефункциональные требования;
требования к тестированию.
Требования к тестированию — необязательный пункт. Мы его заполняем, когда системный аналитик понимает, что нужно проверить еще какую-то связанную функциональность, которую изменения могли косвенно затронуть.
Также хочу обратить внимание, что архитектура и функциональные требования продумываются совместно с техлидом, так как ответственность за проработку архитектурного решения несет он. Но об этом я расскажу дальше.
Этап разработки и тестирования
На этапе разработки и тестирования аналитик активно консультирует разработчиков и QA. Несмотря на то, что за проработку тест-кейсов у нас в компании отвечает тест-лид, аналитик все равно подключается для их валидации. Ему необходимо убедиться, что процессы, о которых договаривались с бизнесом, будут проверены в рамках интеграционного тестирования. Иначе невыявленные ошибки могут быть неприятным сюрпризом в продакшене.
Еще системный аналитик принимает участие в пользовательском тестировании в продакшене вместе с бизнес-операциями. Совместно с продактом он составляет план проверок каждого прописанного сценария в BRD для каждого бизнес-процесса в реальных боевых условиях. В этот план мы включаем всех ответственных за те или иные бизнес-процессы. По сути, это и есть приемка нашего проекта реальными пользователями. Мы можем поехать на склад, ПВЗ, фотостудию, чтобы убедиться в том, что все работает, как мы ожидаем. Результатом такого тестирования является решение раскатывать проект на большее количество пользователей.
Этап стабилизации
После запуска проекта могут возникать разные инциденты, часть из которых попадают к системным аналитикам. Например, когда нужно проверить ошибки в бизнес-процессах, чтобы определить, есть ли ошибка вообще, или просто необходимо объяснить, почему это работает именно так, а не иначе. Результатом нашего участия на этом этапе могут быть:
согласованный план бизнеса и IT;
понимание, что проблемы нет;
задача на разработку;
все вместе.
Вернемся к примеру проекта с партнерскими возвратами через ПВЗ Lamoda. Когда мы его запустили, финальный статус возвратных товаров изменился, что привело к их непопаданию в определенные отчеты для бухгалтерии и группы, отвечающей за возврат денежных средств. Поэтому бухгалтерия и группа возвратов не могли корректно сверять данные по денежным операциям. Они обратились в поддержку с просьбой убрать этот статус, так как посчитали это ошибкой. Системный аналитик, подключившись к задаче, помог разобраться и остановить изменение статусов товаров. А для решения проблемы бухгалтерия и группа возвратов поставили задачи на изменение отчетов.
Если бы к проблеме не подключился системный аналитик, то ситуация развивалась по двум сценариям: либо к результату пришли позже, либо задачу взяли бы в работу и просто убрали статус. Это привело бы к серьезным последствиям, потому что наши системы перестали бы извещать партнера о возврате товара на его склад. Все бы сломалось и пришлось заново разбираться в причинах.
Как разделена ответственность между техлидом и системным аналитиком
А что же тогда делает техлид? Рассмотрим подробно, как поделена ответственность между системными аналитиками и техлидом на всех этапах работы над проектом.
На этапе идеи. Техлид не участвует, потому что здесь его роли еще нет. Если на этом этапе нужна экспертиза с точки зрения разработки, то с этим помогают эксперты систем.
На этапе бизнес-анализа. Системный аналитик погружается в проект, помогает писать BRD, описывает процессы AS IS, TO BE и бизнес-требования. Здесь он вовлечен максимально. Если нужна консультация по какой-то системе, то все вопросы задаются соответствующему эксперту.
Техлид подключается на финальном этапе бизнес-анализа: он только начинает погружаться в проект и пока активно не консультирует.
На этапе системного и технического анализа. Здесь результатом этапа является спецификация. Системный аналитик в команде с техлидом прорабатывает различные варианты решений для поставленной задачи, описывает архитектуру изменений в системах для верхнеуровневой оценки разработки проекта в разных системах.
Однако именно техлид несет ответственность за выбор технологий и составление архитектурной схемы. Системный аналитик может вовлекаться и предлагать логическую модель данных, бизнес-модель, писать требования. Но именно за техлидом остается последнее слово в принятии решения, которое он согласовывает с архитектурным комитетом.
На этапе декомпозиции и оценки. Системный аналитик актуализирует спецификацию и консультирует команду разработки и техлида. Техлид декомпозирует задачи в Jira.
На этапе разработки и тестирования. Аналитик продолжает актуализировать спецификацию, консультировать команду разработки и QA, валидирует тест-кейсы, составляет и согласовывает план UAT (пользовательское тестирование). Техлид тоже консультирует команду разработки и QA, но в более технических деталях. Зачастую он сам пишет код, и он же ревьюит готовые задачи.
На этапе релиза. Системный аналитик продолжает консультировать команду разработки и бизнеса. Техлид составляет план релиза и откатов.
На этапе стабилизации. Аналитик исследует бизнес-инциденты. Техлид разбирает абсолютно все входящие инциденты, помогает их решать или распределяет по командам разработки.
Если посмотреть на активность техлида и системного аналитика по этапам, то она будет примерно такой:
Аналитик больше занят на этапе бизнес-анализа, затем ответственность плавно перетекает к техлиду. На следующих этапах уже нужна огромная вовлеченность техлида, а системный аналитик почти не вовлекается. Мы закладываем 15% общего времени аналитика на эти этапы и называем это саппортом.
Самое важное отличие этих двух ролей — в направленности их работы:
Системный аналитик | Техлид |
отвечает за проект в контексте бизнес-процессов | отвечает за проект в контексте системных процессов |
предлагает архитектурные решения и спецификации обменов | отвечает за архитектуру и спецификацию обменов |
Это не означает, что им не нужно разбираться в процессах друг друга — просто они фокусируются на разном. Тандем системного аналитика и техлида очень эффективен. Такой подход позволяет посмотреть на проект под разными углами и уменьшить риск критичных ошибок благодаря двойной проверке.
Зачем нужен системный аналитик и за что его ценят в Lamoda
Экспертиза во всех бизнес-процессах и системных процессах от верхнего до детального уровня. В кросс-функциональных проектах системный аналитик видит всю картину сверху, но в том числе может опуститься до всех деталей. Это не значит, что он гуру и знает ответы на все вопросы. Скорее, он может быстро найти нужные контакты и источники данных, убедиться в их актуальности и правильности и передать эту информацию команде.
Возможность понять любой «черный ящик». То есть целые системы или часть их функционала, которые работают непонятно. Системный аналитик помогает разобраться с неизвестностью разными методами, структурировать полученную информацию. Это нужно, чтобы снова появилась экспертиза и стало понятно, что можно менять и какие последствия повлечет изменение той или иной функциональности.
Инициативная позиция и готовность разобраться в любой проблеме. К системному аналитику часто приходят с «просто проблемой»: непонятно, с кем связаться и где искать. Он помогает разобраться, найти контакты, посмотреть логи. Такого саппорта много у нас в команде и он ценится теми коллегами, которые его используют. Причем, речь идет не только о командах разработки, но и бизнеса.
Роль фасилитатора. Когда проекты пересекаются и очередность в работе непонятна, аналитики организовывают фасилитационные встречи. Мы собираем всех заинтересованных, говорим с ними о проблемах, фиксируем ключевые моменты в обсуждении. Результат — все довольны и понимают план действий каждый в своем проекте.
В заключении я хотела бы сказать, что в системный анализ могут приходить из смежных направлений: разработки, QA, продукта, технического писательства, а также других направлений анализа. Главное, чтобы человеку нравилось половину своего времени коммуницировать с коллегами, а другую половину — письменно структурировать информацию, одинаково интересно заниматься бизнес-анализом и системным анализом. Ну и, конечно, системный аналитик в Lamoda должен быть готов взламывать «черный ящик» каждый день.
