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

Бизнес-вызовы

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

Ситуация на проекте

Сложный продукт. Система имеет большой codebase, сложную интеграционную логику и множество кейсов по работе с данными различных типов в бесчисленном количестве комбинаций. Доменная область продукта также сложна для понимания: приложение выполняет функции передачи телеком-данных по специализированным протоколам над TCP/IP стеком.
Неконтролируемое и полностью самостоятельное погружение новых инженеров в проект. У команды, которая передаёт проект новым инженерам, нет ресурса на помощь с погружением. Новые специалисты разбираются в работе системы самостоятельно. При этом заказчик не может убедиться в том, насколько хорошо они поняли логику работы системы и способны ли развивать продукт без помощи прежней команды.
Без детального погружения разработчики не могут комплексно анализировать возникающие вопросы и принимать верные стратегические решения. В итоге возникают риски, что принимаемые решения приведут к деградации продукта.
Значительный bus-фактор. При уходе ключевых сотрудников с проекта возникает высокая вероятность того, что команда не сможет самостоятельно развивать архитектуру продукта.
Сжатые сроки. Полное погружение новой команды в проект должно занять не более 2 месяцев.

Основные проблемы на проекте

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

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

“Это типовая ситуация: в консультационной деятельности я часто сталкиваюсь с серьёзными IT-проектами, в которых не решён вопрос передачи знаний. Как показывает практика, даже у достаточно опытных инженеров могут уйти месяцы на погружение в специфику продукта и процессов. С одной стороны, разработчики в таком случае получают большой опыт. Но если цель заказчика — быстро погружать специалистов, создавать взаимозаменяемые команды, меньше рисковать, — то в таком случае без тщательной проработки процесса передачи знаний невозможно обойтись.

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

Дмитрий Горячко

Формат проведения консалтинга

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

Дорожная карта консультирования

Дмитрий выполнял функции супервайзера: курировал передачу проекта заказчика новой команде.
Чтобы добиться максимально возможного эффекта в сжатые сроки, к проекту также был подключён дополнительный менеджер (это типичная практика, которую мы используем в консультационных проектах, к примеру, посмотрите кейс Консультирование по выходу из технологического кризиса). В его обязанности входили фиксация, координирование и контроль выполнения поручений Дмитрия командой.
Важным элементом консультирования стало проведение стендапов команды совместно с Дмитрием. На один месяц время стендапов было намеренно увеличено (от 30 до 45 минут), чтобы все задачи и принимаемые решения проговаривались с командой. Это позволяло убедиться в том, что все участники проекта понимают поставленные цели и системно продвигаются по задачам для достижения результата.

Стратегия консультирования

Личные консультации

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

Анализ продукта и ситуации на проекте

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

Помощь в подготовке необходимых материалов

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

Подходы и решения

Создание комплексной диаграммы развёртывания

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

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

После этого было создано обучающее видео (длительностью 1 час), в котором Дмитрий лично комментировал каждый этап данной диаграммы и объяснял все детали работы ПО.

На основе созданной диаграммы команда разработки начала проводить реверс-инжиниринг и отладку приложения. Для этой задачи также привлекалась команда тестировщиков-автоматизаторов. Для успешного выполнения реверс-инжиниринга было крайне необходимо поддержать всевозможные режимы отладки системы: как локально в контейнерах, так и в облаках. Через реверс-инжиниринг была подтверждена правильность каждой связи в диаграмме.
Создание документа «Погружение в предметную область»

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

При создании документа команда консалтинга тщательно взвешивала, какая информация должна входить в него для формирования достаточного понимания у инженеров. По итогу было решено сделать упор на визуализацию и упрощённое определение основных концепций, которого достаточно, чтобы за 1 рабочий день понять основные принципы работы ПО.
Создание вспомогательных документов для процесса разработки
Параллельно с подготовкой диаграммы велись дополнительные активности по созданию следующих вспомогательных документов:
1. Описание задач в простом формате. Документ представляет собой простое описание задач, которые команде предстоит сделать. При этом сама постановка была максимально развернута.
2. Реестр вопросов заказчику, перечень нерешённых проблем. Документы созданы для фиксации всех нерешённых вопросов, которые могут повлиять на работу команды.
3. Гайды по развёртыванию системы: локально и в облаках. Параллельно велась работа дэвопсов по автоматизации установки и разворачиванию системы в Docker.
После погружения с помощью подготовленных материалов новые инженеры сразу же начали создание референс-проекта. Данная методика часто применяется Дмитрием для реализации механизма передачи опыта между разными поколениями разработчиков на проекте, а также для ускоренного погружения в сложные проекты с большим codebase и сложным сочетанием технологий. Суть референс-проекта заключается в разработке небольшого приложения с использованием всех технологий и инструментов, применяемых на реальном проекте. Кроме непосредственно разработки, во время подготовки референс-проекта инженеры также выполняют другие задачи: работают с архитектурой, создают диаграммы, пишут Unit-тесты, участвуют во внедрении Continuous Integration, проходит ревью кода.

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

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

Создана вся необходимая сопроводительная документация для погружения в проект. Используя подготовленные документы, диаграммы и гайды, а также руководствуясь процессами передачи знаний, новые инженеры смогли достаточно глубоко погрузиться в проект и чётко понять предметную область ПО.
У новой команды разработки появилась возможность провести весь комплекс подготовительных активностей самостоятельно и в максимально сжатые сроки: от понимания задач и предметной области до настройки, запуска и дебага системы.
Значительно сокращено время погружения новых сотрудников в проект. По результатам консалтинга время погружения специалиста в проект снизилось в 6 раз: с 2-3 месяцев до одной недели. При этом удалось сохранить фокус на продакшен-задачах.
Исключены серьёзные финансовые и репутационные риски. При этом удалось сократить затраты на погружение инженеров в проект.
Исключён bus-фактор. Благодаря созданному алгоритму погружения новых специалистов на проекте была минимизирована зависимость от конкретных специалистов.

Отзыв заказчика

Отзыв на консалтинг

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

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

Senior Project Manager сервисной компании (название компании под NDA)

Получите БЕСПЛАТНЫЙ чек-лист «Как понять, что ваш проект в опасности?»

Приветствую! Меня зовут Дмитрий Горячко. Специально для вас я подготовил чек-лист, который поможет определить, в опасности ли ваш проект, и предоставит чёткое количественное измерение сложности ситуации.

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

Также чек-лист содержит большое количество практических советов. Это поможет вам самостоятельно продвигаться по решению проблем.