Привет! У SM Lab есть ключевой заказчик, как вы понимаете — это Спортмастер. В Спортмастере используют информационную систему Client Service Management (далее по тексту – CSM), предназначенную для обеспечения необходимой информацией сотрудников операционного центра (далее – ОЦ) и сотрудников контактного центра (далее – КЦ). Кроме сотрудников ОЦ и КЦ, к нашей системе имеют доступ различные подразделения компании, а также сотрудники розничных магазинов. В общей сложности у нас около 1000 уникальных пользователей ежедневно.

Меня зовут Павел Жилкин, я ведущий аналитик Департамента системного анализа SM Lab, и в этом посте я расскажу про работу системного аналитика и организационный подход в продуктовой команде, которая и занимается разработкой CSM.

Вот из каких частей сейчас состоит основная функциональность системы:

1. Регистрация и процессинг обращений от клиентов: претензии, благодарности, консультации.

2. Просмотр и редактирование заказов: способы получения, логистика, клиентские данные, клубная программа.

3. Просмотр карточки клиента клубной программы, редактирование анкетных данных, коммуникации, история начислений и списаний бонусов, покупки.

4. Регистрация новых клиентов клубной программы.

5. Поиск и просмотр подарочных карт и многое другое.

6. Просмотр и возврат оплаты по заказу.

О продукте, интеграциях, технологиях

Если верить Jira, первая задача в нашем проекте была создана 10.07.2013, так что CSM развивается уже более 9 лет. В 2020 году было решено переписать код приложения CSM, так как в первой версии функционал был реализован с использованием старого фреймворка GWT (свободный Java-фреймворк, который позволяет веб-разработчикам создавать приложения) и Oracle PL\SQL (PL/SQL — язык программирования, процедурное расширение языка SQL, разработанное корпорацией Oracle).

Изначально логика CSM была реализована в хранимых процедурах, а монолитная архитектура не позволяла реализовывать требования от бизнеса в установленный срок. На данный момент приложение можно разделить на 2 версии: CSM1 и CSM2. В новой версии реализована микросервисная архитектура, логика переносится в Java, проводится редизайн системы и переход на новый фреймворк vue3. Количество интеграций приблизилось к двадцати, уникальность приложения заключается в том, что мы интегрированы как с бэкофисными системами, так и с фронтофисами, кроме того, имеются интеграции с внешними сервисами. Из-за большого количества интеграций и разных по специфике систем наше приложение использует разные интерфейсы для интеграции начиная от веб сервисов REST API, WSDL и заканчивая интеграциями Oracle to Oracle, что в свою очередь требует от аналитиков умения использовать различные инструменты. В нашей команде мы работаем с SoapUI, Oracle SQL Developer, Postman, Swagger, Elasticsearch и другими.

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

Из-за отсутствия своих пользователей и ролевой модели возникало много проблем, что привело к переносу пользователей в базу данных CSM и переделке авторизации в приложении. Была спроектирована с нуля ролевая модель, перенесены старые пользователи. Помимо пользователей работа велась и по переносу старого функционала.

Основная проблема при переносе раздела была в том, что наше “производство” нельзя было остановить, и зачастую задачи приходилось делать параллельно в старом и новом приложениях, так как на перенос одного раздела уходило достаточно много времени. Часто приходилось искать компромисс и изобретать, например, был реализован новый метод для второй версии, а в первой версии стек технологий был другим. Чтобы хоть как-то сэкономить ресурсы разработчиков и не дорабатывать хранимые процедуры, первую версию тоже переводили на новый метод.

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

Команда и организационный подход

Параллельно с разработкой и переносом пользователей началась трансформация команды в период Covid-19 ограничений, поэтому выстраивать новые процессы приходилось в онлайне. Как вы знаете, в период ограничений наши розничные магазины были закрыты, продаж тоже не было, многие команды работали 24\7, чтобы запустить онлайн-выдачу заказов, а тут еще и новые члены команды, которые требовали погружения в проект.

Новый состав команды предполагал наличие следующих ролей:

1. Product Lead,

2. системных аналитиков,

3. разработчиков Oracle,

4. Backend,

5. Frontend,

6. тестировщиков,

7. дизайнера.

В процессе становления продуктовой команды мы проработали основные этапы развития команды.

Первое, что нам было необходимо выбрать — подход к управлению рабочим процессом Scrum или Kanban. После недолгих обсуждений выбрал Kanban. Начался процесс выстраивания потока создания ценностей, для каждого этапа необходимо было определить ответственного исполнителя и итоговые результаты. Вместе с этим выстраивался процесс проведения ежедневных и еженедельных каденций: ежедневный дейли митинг, еженедельный статус с заказчиками, проработка очереди задач, собрание по пополнению бэклога и ретроспектива.

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

1. Правила работы с jira – документ описывает типы задач, которые использует команда в пространстве jira.

2. Шаблоны задач – для каждого типа задачи проработана статусная модель и подготовлены типовые шаблоны, для ускорения процесса оформления задачи. Подготовлены шаблоны критериев приемки.

3. Правила работы по задачам эксплуатации – регламент для ведения сопровождения ИС, группой эксплуатации и команды CSM.

4. Правила декомпозиции задач.

5. Правила совместной работы над задачами – были прописаны критерии завершенности DOD и критерии готовности задачи к взятию в работу DOR.

6. Правила ведения документации и запросов на изменения.

7. Для каждого департамента были оформлены страницы с всей необходимой информацией для ускорения процесса адаптации новых сотрудников в команде.

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

Затем нужно было выстроить процесс запросов на доработки. Если раньше в любое время можно было прийти в команду и попросить срочно сделать задачу, даже если срочность была условной, то новый процесс не позволял вносить хаос в работу. Была формализована схема запросов на доработку, задачи аккумулировались в одном месте. Если задача требует участия нескольких команд, то обязательно заводится Cross Team Epic (далее – CTE), задачу берет в работу одна из команд архитекторов и прорабатывает архитектурное решение, команда участвует в защите и формализует задачу в своем пространстве. Департамент клиентского сервиса или операционный центр работают с продуктовыми эпиками, в случае если продуктовая задача требует работ смежных систем, то она должна заводиться как CTE. Мелкие доработки, технический задачи и баги поступают от разных источников. Группа эксплуатации может заводить задачи на консультацию, которые после разбора проблемы преобразуются в баг или в мелкие доработки. Технические задачи могут поступать от смежных команд или заведены участниками команды в случае, если есть необходимость таких работ.

На сегодня команда достигла зрелости и самоорганизованности, процессы непрерывно совершенствуются и развиваются. В команде:

• 1 PL

• 4 аналитика.

• 1 дизайнер.

• 3 backend-разработчика.

• 2 frontend-разработчика.

• 2 database-разработчика.

• 5 тестировщиков.

Члены команды активно принимают участие в жизни продукта, развивают t-shape, делятся опытом и знаниями, открыты к любому сотрудничеству и развитию. В команде выстраиваются процессы ревью аналитики, добавлен новый этап ревью требований отделом обеспечения качества. Команда отказалась от релизных циклов, двигается в сторону непрерывного потока поставки ценности, за AW23 команда выпустила 35 релизов и 305 задач.

Системный аналитик в команде

В нашей команде системный аналитик работает с разными задачами. При проработке задачи Cross Team Epic на несколько команд аналитик может выступать в качестве эксперта по системе, помогает описать список изменений в системе. Участвует в проработке и защите архитектурных решений.

Если задача продуктовая, то аналитик детализирует задачу на продукт. При проработке продуктовой задачи нужно уметь:

1. Работать с бизнес-требованиями.

2. Проводить сбор требований с product owner`ом.

Если требования собраны и все встречи проведены, тогда аналитик приступает непосредственно к проработке запроса на изменение (CR – Change Request). Этот документ включает в себя:

1. Описание постановки для разработчиков.

2. Работа с диаграммами (UML, BPMN) описание взаимодействия Backend, Frontend. Описание интеграционного взаимодействия.

3. Работа с базой данных, описание новых таблиц, выборка тестовых данных.

4. Подготовка REST, SOAP-запросов. Описание полей.

5. Описание маппинга полей, если интеграционное взаимодействие.

6. Проектирование интерфейса.

7. Описание пользовательских путей.

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

1.       Менеджер сервиса запросов – отвечает за управление потоком запросов, проводит собрания по пополнению.

2.       Менеджер сервиса поставки – отвечает за поставки запросов, оповещает пользователей об установке обновлений, включает фичатоглы.

3.       Тестировщик – если есть необходимость, то участвует в приемочном тестировании.

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

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

1. Просмотр записей экранов пользователей, если они есть.

2. Просмотр логов в Kibana.

3. Воспроизводят ошибку на тестовых окружениях используя инструменты: SoapUI, Oracle SQL Developer, Postman либо интерфейс приложения.

По результатам разбора заводится дефект либо проводится консультация пользователей.