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

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

Нерешаемая задача

Исторически Почтатех — это классический вендор с более чем 50 full-stack-командами. Раньше они были замкнуты сами на себя и подчинялись напрямую только менеджерам продуктов, а те, в свою очередь, — заказчикам от бизнеса. Технологический стек, CI, архитектура — всё это находилось внутри команд.

На старте такая структура помогла быстро оцифровать бизнес. Но с дальнейшим его развитием это привело не только к расширению команд без соответствующего роста перфоманса, но и к повышению гетерогенности (разнородности) всего: требований, подходов, технологий, инфраструктуры. Как результат — time-to-market, который не устраивал никого. С ним невозможно быть конкурентоспособными ни на рынке логистики, ни на любом другом. Кому нужны ваши крутые фичи, если вы их пилите годами?

Новая команда нашего отдела начала собираться в Почте менее года назад. Необходимо было в сжатые сроки с нуля создать две крупные информационные системы, а также улучшить две существующие. Рынок — ЕКОМ и курьерская доставка. Задачу усложнял огромный размер Почты и её IT-ландшафта.

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

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

1. управление проектами и задачами;

2. проектирование;

3. разработка;

4. инфраструктура и CI.

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

Немного про гетерогенность

В двух существующих командах привыкли просто текстом описывать сквозные сценарии, протекающие через множество сервисов. Они не использовали ту же диаграмму последовательностей вызовов (sequence), потому что тогда не умели её читать. Хотя на самом деле это намного лучше ситуации, когда задача есть только в голове или блокноте, а описание логики — это description к ней. В итоге из всей документации остаётся только сумма описаний в баг-трекере и реализованный код. Конечно, так тоже можно жить, но не очень приятно.

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

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

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

Подготовка к изменениям

Мы начали с того, что полностью описали целевой процесс, чтобы понять, на каких этапах можно повлиять на него. Получилась компиляция накопленного опыта и того, что предлагает TOGAF. Затем мы описали каждую стадию: за что она отвечает, какими входящими и исходящими артефактами оперирует. Участники процесса стали точно видеть свою роль, у них появились чётко формализованные функции.

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

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

Стадия проектирования

На этом этапе зафиксировали списки артефактов с помощью набора UML-диаграмм последовательности, активности, структуры, классов и компонентов, а также swagger-спецификаций для подробного описания самого Contract API (контракт сервисов).

Благодаря этому результаты проектирования воспринимаются менее гетерогенно, и, конечно, это гораздо лучше, чем просто текстовое описание архитектуры.

Например, команды могли делать sequence: применять набор компонент, взаимодействующих друг с другом, и использовать Activity для отображения логики протекания процесса. Бывает, что сервис закрыт методом, в котором условно сложная бизнес-логика, порядок обогащения или что-то иное. Очень удобно ещё на этапе прототипирования понимать, получается довести это до конца или нет. Если описывать текстом, то восприятие целостности сценария не гарантировано, особенно если его читает сторонний человек — разработчик или тестировщик.

Составив списки артефактов, мы провели дополнительную стандартизацию и начали использовать единый Confluence для каждой информационной системы. Затем описали, какая у каждой из них должна быть структура, набор статей и раздел для E2E-сценариев, в которых она участвует. Обозначили раздел, где находится системная архитектура и набор её компонент, определили, какие методы они реализуют, определили их порядок работы и всё, что связано с командами и планированием. Также ввели единый шаблон java-приложения и базовый набор зависимостей для него. 

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

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

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

Помощь в адаптации

Чтобы всё поменялось, нужно было помочь людям перестроиться и преодолеть вероятное сопротивление изменениям. С инструментами работали и аналитики, и разработчики, и тестировщики, и у всех был разный бэкграунд. И если разработчикам чаще всего не составляло труда разобраться, как устроен тот или иной инструмент, — Git для них привычен — то аналитикам было сложнее. Они начали переиспользовать артефакты, и количество смежной работы у них увеличилось.

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

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

Если вы знакомы со swagger-спецификациями (yaml, OpenAPI 3.0 или 3.0+), то знаете, что их стандарт вполне гибок и не требует специального заполнения многих полей. Модели получились достаточно сложными. Не всегда можно было дать им адекватные названия, поэтому мы внедрили собственные требования к описанию элементов контрактов.

Кроме того, на базе одной из спроектированных с нуля информационных систем мы привели к целевому виду структуру пространств Git, Confluence и Jira. Затем добавили схему ожидаемого результата в Confluence, перенесли туда текущие результаты аналитики и соответствующие артефакты. При создании тасков в Jira мы сразу ссылались на ранее созданные статьи в Confluence, а также описывали, как заводить задачи и какие поля заполнять.

Это был показательный пример, который дал командам возможность «потрогать» UMLки, сиквенсы, активити и swagger-спеки. Мы поняли, как с ними можно работать, и это заняло около недели. А сама адаптация команд к новому процессу длилась около трёх месяцев.

Чтобы быстро подтянуть знания основных инструментов и артефактов, которые нужно применять в целевом процессе, для всех команд мы провели обучающий курс по проектированию. Разработчики изучили sequences, activity и swagger-спеки. Задача хоть и была полностью синтетическая, но базовый минимум усвоили все. Плюс остался накопленный материал, к которому можно было при необходимости вернуться.

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

Итог адаптации

В результате команды научились переиспользовать одни и те же инструменты для решения одинаковых задач. Они не распылялись, а вдумчиво концентрировались на чём-то одном. Экспертиза начала копиться концентрированно, и это заметно сократило сроки выполнения задач. В ходе проектирования появлялись артефакты всегда одинакового качества, что позволило разделить разработку и тестирование. Получив задачи, разработчик, QA и DevOps всегда знали, как себя должно вести решение на уровне реализации, интеграции и жизненного цикла.

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

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

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

Итогом стал сквозной автоматизированный процесс, связывающий все роли и компетенции в команде. Вместо распределения ресурсов по проектам Почтатех поставил на автоматизацию и стандартизацию всего процесса. За три месяца подготовки к изменениям удалось собрать команды со средним уровнем компетенций и сократить сроки конечной поставки продуктов с 1,5-2 лет до 6-12 месяцев.

Особенности подхода

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

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

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

Выводы

Это не серебряная пуля. Как и при любой работе с большим и сложным инструментом, нужно понимать, как применять и адаптировать его под ваши реалии.

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

Автоматизируйте  рутину. Отдельное внимание стоит уделять автоматизации рутины и избавлению от неё ваших коллег.

Обязательно запаситесь терпением!