Создать продуктовый проект вместе с SimbirSoft: что ждёт клиента

Мы любим проекты под ключ, потому что на них можем самостоятельно выстраивать оптимальные процессы разработки и напрямую влиять на результат. Делимся историей одного такого кейса: на пике проект насчитывал 20+ членов команды из 8 направлений. Рассказываем подробно о вызовах и лайфхаках разработки.

Вводные данные

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

Project Management

1. Чтобы упростить задачу и минимизировать ошибки в реализации, мы разбили пользователей на группы:

• тех, кто создает продукт,
• тех, кто работает с ним.

Так легче проработать требования к продукту и пользовательский опыт.

2. Также решили начать с MVP и базового набора функций. Хотя в нашем случае слово «базовый» носит весьма условный характер – продукт включает в себя несколько подсистем: 

• BPMN-движок – система создания и управления бизнес-процессами,
• UI-конструктор, в котором можно генерировать интерфейс системы.

3. Разбили работу на этапы, чтобы минимизировать риски, снизить неопределенность и убрать «белые пятна» в технологиях. Приняли решение сделать микросервисную архитектуру проекта.

4. Проанализировав практики прошлых проектов, в этом мы модифицировали процесс работы над новыми фичами (подробнее о причинах – в «Аналитике»). В стандартном процессе разработки после сбора требований аналитик уходит на детальную проработку ТЗ, после согласовывает с командой, редактирует и с результатом идёт к клиенту. Мы же добавили в этот процесс проработку «быстрого видения»: после сбора требований формируем этот артефакт, дополняем с командой и идем с документом к клиенту. После обсуждения с ним у нас есть понимание необходимых корректировок и дополнений. Так мы уменьшили возвраты задач на доработку – и получили экономию бюджета примерно 15%.

Аналитика

Немного важных фактов об этом проекте:

• У нас не было исходной системы, на которой могли бы базироваться функциональные возможности.
• Продукт состоит из подсистем – связанных между собой отдельных приложений. Для каждого из них необходимо было проработать свой набор артефактов по аналитике: пользовательские сценарии, прототипы, описание функциональных и нефункциональных требований, схему БД и описание API. 
• Продукт построен на абстракциях – это означает, что у нас нет знаний о конкретных бизнес-процессах конечных пользователей. Система наоборот должна предоставлять возможность создания бизнес-процессов, отчетов и экранных форм. В общем, быть максимально гибкой и конфигурируемой. 

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

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

Это позволило нам синхронизировать понимание с заказчиком на раннем этапе: в правильном ли направлении мы движемся, верно ли понимаем назначение и функциональность системы. Если представления расходились, мы корректировали их, не перерабатывая при этом огромное количество документации.

Несколько полезных внедрений, от которых мы получили позитивные результаты: 

1. Реестр открытых вопросов. Если при общении с заказчиком мы приходили к вопросу, который в тот момент не готовы были решать, мы стали заносить их в отдельный реестр в Confluence. Ввели практику еженедельных созвонов для того, чтобы проработать реестр: понять, что уже сейчас можно взять в работу, и определить ответственных.  

2. Реестр будущих фич. Например, во время проработки одной из подсистем мы понимаем, что мы должны или нам хотелось бы реализовать какую-то фичу в следующей подсистеме, к проработке которой мы пока не приступали. Заносим в документ. Позже, когда очередь доходит до той самой подсистемы, у нас собраны все связанные с ней заметки предыдущих этапов в одном документе. 

3. Структурирование документации. Вынесли в отдельные разделы Confluence: 

• документацию каждой подсистемы;
• документацию, которая относится к управлению, такую как roadmap, планы спринтов, ретроспективы;
• документацию, которая упрощает онбординг: карту коммуникаций, все видео и инструкции для погружения, code style, workflow, gitflow.  

Архитектура

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

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

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

Самая поверхностная мысль – склонировать все данные со всех серверов. Но это терабайты неупорядоченных данных: у кого-то БД  – PostgreSQL, у кого-то – MySQL. У всех разное все, ведь система абстрактная и непонятно: куда она будет внедряться, какие типы данных и в каком количестве будут. Поэтому кешировать у себя – это, конечно, плохая затея.

Самая большая проблема при реализации сложных задач – с чего начать. Верный способ – так мы и сделали и разложили задачу на несколько:

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

Каждый из этих пунктов мы проработали. В рамках протокола мы выбрали odata-протокол, так как использовали его и для других задач на проекте. В итоге решение выглядело так:

1. Разбиение odata-запроса на ноды. 

2. Определение порядка запросов на основе количества данных (count) с учетом фильтраций.

3. Получение данных, начиная от ноды с минимальным count.

4. Получение данных других нод на основе фильтраций по ключам.

Решение сложное, но оптимальное – это дало нам возможность не кешировать у себя и обрабатывать терабайты данных.

Разработка

Нам нужно было реализовать систему, которая позволяет конструировать и отображать формы любой сложности. Для этого мы создали собственную библиотеку и компоненты – они обеспечивают гибкий интерфейс для пользователей. Использовали функциональность динамических компонентов Angular. 

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

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

Обеспечение качества

Процесс тестирования был выстроен по классическому Waterfall: QA подключались на этапе ревью аналитики. Тестовая документация составлялась в процессе разработки, до передачи задачи в тестирование.

Одной из основных проблем являлось большое количество сервисов и их многочисленные взаимосвязи друг с другом. На начальных этапах это повлекло за собой пул багов, которые было сложно поймать. Для того чтобы нивелировать этот риск, мы внедрили систему отчетности о покрытии и качестве тестирования. Далее провели анализ наиболее критичной функциональности и усилили проверки на самые «вредные» сервисы. Также было подключено автоматизированное тестирование для приемочных кейсов по сценариям E2E. Интеграция таск-трекера с системой тест-менеджмента (AIO) позволила проводить первичные проверки по задачам еще на этапе разработки фич. Это дало возможность проанализировать, реализовал ли разработчик нужный функционал или что-то упущено.

Так как конструктор включает в себя множество комбинаций (элемент-событие-действие), для покрытия функциональности пришлось прибегнуть к технике тест-дизайна «попарное тестирование». Только для проверки действий и событий было получено более 350 комбинаций. Тестовые сценарии запускались автоматически на 3 стендах, ежедневно предоставляя отчет о состоянии критического функциональности.

Нагрузочное тестирование

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

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

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

DevOps

Наш пул задач можно разделить на два больших направления:

1. решение стандартных DevOps-задач для обеспечения разработки,
2. создание коробочного решения, при помощи которого заказчик сможет самостоятельно разворачивать окружение у конечных клиентов.

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

Обучение

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

Результаты

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

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

Что еще сделали:

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

Проект носил очень творческий характер – было интересно выстраивать бизнес-модель совместно с заказчиком. На каждом этапе и в каждом решении чувствовалась поддержка партнеров.