Снижаем Bus Factor в команде
Всем привет! В этой статье я расскажу о трансформации команды разработки в части состава по количеству человек и количеству продуктов на сопровождении.
Какие практики внедрили в нашей команде в Мир Plat.From (НСПК), сопровождающей 10 систем, чтобы снизить Bus Factor и уменьшить время входа для новичков.
Обзор реальных инструментов, которые работают в нашей команде, и могут применяться в вашей уже сейчас: от Wiki до сообществ внутри команды. Поехали! Начнём с вводных…
Команда 6 лет назад
3 небольшие фича команды, которые работали исключительно в своей предметной области;
Продакты (PO) выполняли роль бизнес/системных аналитиков. Документация оставалась на уровне требований от Продактов в 2-х фича-командах. Одной фича-команде повезло больше — в ее составе был системный аналитик;
внутри фича-команд происходило накопление знаний;
4 монолитных системы с нераспространенной интеграционной сетью;
релизы были в среднем 1 раз в месяц или реже.
Жизнь команды сейчас
20 человек в команде разработки, из них 4 системных аналитика;
5 инженеров сопровождения;
10 систем на поддержке у команды разработки и сопровождения;
более 50 точек интеграции;
в месяц в среднем 4–5 релизов.
На сопровождении нашей команды каждый год появлялись новые системы или сервисы в существующих системах. Вопрос качественного накопления экспертизы очень важен в такой конфигурации для команды.
Не буду рассказывать о пути и причинах, как мы оказались в такой конфигурации, это неважно для целей повествования.
Как построена жизнь нашей команды
Мы живем в гибридной водопадной модели.
Мы часто работаем в проектах, которые требуют строгих контроля и отчетности, как в водопадной модели. Но также нуждаемся в гибкости и адаптивности для удовлетворения меняющихся требований и приоритетов. Организуем фича-команды по приоритетным в конкретный момент времени стримам и проектам.
Коллега даже попытался потроллить chatGPT и попросил выдать основные практики «Скрамводопадбана». Оказалось, что на 80% это наша методология.
Оформленные системные требования всегда идут перед разработкой и тестированием бизнес-фич. Технические задачи не ждут завершения системной аналитики.
Накладывая все эти условия на конфигурацию нашей команды, мы пришли к следующим практикам.
Про стендапы и какие-то встречи-синки я не буду говорить в этой статье, все, плюс‑минус, в этом живут…
Wiki в Confluence
Если у вас есть хоть какая-то база знаний, поздравляю, вы уже активно лежите в направлении успеха! Наличие удобной в использовании и актуальной базы знаний — это, своего рода, Перчатка Бесконечности. Она позволяет команде управлять всеми аспектами реальности.
Так вот наша Wiki довольно близка к состоянию Перчатки с 4 камнями — архитектура, документация, спеклеты и релизы.
Для каждой из систем у нас на сопровождении мы ведем отдельный спейс в Confluence. Таким образом мы не перегружаем лишними деталями описание каждой системы.
Основные разделы каждого спейса с точки зрения ведения документации:
Архитектура;
Документация — описание системы, актуальное на состояние Релиз-1 (иногда — Релиз-2, когда очень загружены);
Спеклеты –дельта для новых релизов от состояния, описанного в Документации;
Релизы — release notes каждого релиза.
Наш подход к ведению Wiki делится на 3 активности:
1. Подготовка спецификаций к текущему/будущему релизу
Описание изменений функциональности под текущий релиз представляет собой дельту к текущему состоянию системы (берется из раздела «Документация») + изменения по новому релизу.
2. Ведение документации по системе
За максимальную актуальность документации мы долго боролись изменением процессов в команде и увеличением штата системных аналитиков.
Это один из столпов жизни нашей команды. В любой момент времени любой член команды или кто-то из соседней команды может почитать описание какой-либо фичи. С вероятностью 95% она будет актуальна текущему поведению системы.
Это отличительная черта нашей команды, как суперсила Супермена, скорость Флеша или деньги Брюса Уэйна у Бетмэна
Чем мы платим за такую актуальность, и куда делись 5%?
После каждого релиза дельта изменений в документации (Speclets) мерджится системным аналитиком в основной раздел Documentation. Так набегают условные 5% налога на развитие системы, так как между релизами проходит какое-то время.
На актуализацию документации выделяется отдельное время работы аналитика.
3. Подготовка интеграционных спецификаций для соседних команд
Подробности интеграционного взаимодействия, а часто и требования для команды, с которой мы интегрируемся, формируют так же наши системные аналитики.
Потраченное на это время мы в итоге получаем бонусом в актуальности документации в части интеграционного взаимодействия и единого описания с другой командой (в которое потом можно всех ткнуть…).
Данные принципы ведения Wiki всегда выручают и существенно экономят время на разбор вопросов по поведению системы.
В чем польза для команды, и какие вопросы закрывает:
Продакту нужно понять текущее поведение системы, чтобы знать, куда и как добавить новую функциональность.
Инженеру сопровождения нужно понять особенности интеграции или конфигурации системы.
Новичку легко погрузиться через описание системы.
Члену команды, не знакомому с данной функциональностью, но которому требуется сейчас работать над новой фичей в этом месте.
Вычитка спецификаций
В календаре команды забронировано 2 слота в неделю под встречи-вычитки спецификаций.
К этой встрече системные аналитики готовят проработанные требования, зафиксированные в виде спецификаций в Confluence.
Это командное мероприятие, где все заинтересованные люди, особенно те, кому планируется работать над этой задачей, собираются вместе. Обязательное присутствие РО и кого-то из команды сопровождения.
РО объясняет смысл задачи уже всей команде. Аналитик подробно объясняет и показывает в документации что именно меняется в рамках конкретной задачи. РО и аналитик отвечают на вопросы команды.
На этой встрече поступают дополнительные требования или уточнения от ребят из сопровождения.
Так как от момента проведения вычитки до старта тестирования может пройти достаточно много времени, то ведется запись встречи. Таким образом, можно всегда вернуться к подробностям по задаче, если ты подзабыл нюансы или тебя не было на встрече.
В чем польза для команды, и какие вопросы закрывает:
Фича-команда проходит подробное погружение в конкретную задачу.
Команда сопровождения получает место для высказывания своих требований к внедрению фичи.
Регулярность встреч, не нужно впихиваться в плотные календари. Если нечего читать — отменяем.
Команда получает общее представление об изменениях в функциональности.
Вычитка спецификаций для команды интеграционного тестирования
Эта встреча, по сути, частично дублирует предыдущую, но отличается целью, акцентами и составом участников.
Проходит эта встреча, когда релиз-кандидат готов для передачи на интеграционное тестирование.
Цель — погрузить команду интеграционного тестирования в контекст всего релиз‑кандидата.
На встрече уже не требуется вся команда, присутствие ограничивается только желанием.
Акцент по изменениям делается не на всей функциональности релиза, а только на той части, где затрагивается интеграция.
В чем польза для команды, и какие вопросы закрывает:
Еще раз посмотреть на состав релиза и осознать его масштабы.
Подсветить интеграционные особенности.
Выявить нюансы подготовки к PROD.
Архитектурное сообщество
Наверняка вы собираетесь на обсуждения и брейн-штормы, когда нужно решить, как проектировать какой-то новый сервис или выбрать лучший способ интеграции.
Раньше такие встречи у нас носили хаотичный характер по запросу. Возникает конкретная задача, собираемся каким-то составом, обсуждаем.
В таком подходе есть как и плюсы, так и минусы. Самым жирным минусом для нас было, что сложно было собрать всех нужных людей, кто-то не мог (привет календарям лидов и РО) или про кого-то важного именно для этой задачи забывали… Приходилось собираться еще раз, чтобы погрузить отсутствующего, и так по кругу…
В команде на 25+ человек это привносило много хаоса.
Так у нас родилась регулярная встреча — Архитектурное сообщество команды. Здесь мы собираемся, чтобы решать самые сложные архитектурные задачи и планировать будущее наших систем.
Принцип организации встречи аналогичен встрече по вычитке спецификаций:
по умолчанию приглашена вся команда, присутствие — по возможности;
заранее объявлена повестка вопросов для обсуждения на ближайшей встрече.
Обычно на встрече мы обсуждаем:
проект какого-либо архитектурного решения для наших систем;
идеи по существенным изменениям функциональности в наших системах;
презентуем результаты RnD по каким-либо задачам;
составляем план действий вокруг сложных задач.
По результатам обсуждения составляем протокол сообщества с повесткой и принятыми решениями. Выглядит очень формально и бюрократически, но для такого уровня вопросов протокол помогает позже вернуться к договоренностям и не дублироваться в обсуждениях.
Если во время работы всплывает вопрос, требующий каких-то обсуждений по теме сообщества, то мы не несемся собирать встречу и впихивать нужным людям в календарь. Мы фиксируем, что эта тема к обсуждению на следующей встрече сообщества. Тот, кто хочет обсудить тему, получает гарантированный слот времени всей команды и отвечает за подготовку необходимых артефактов и материалов ко встрече.
В чем польза для команды, и какие вопросы закрывает:
Регулярность встреч, не нужно впихиваться в календари.
Фиксация договоренностей и план действий в протоколе сообщества.
Комфортный режим для подготовки материалов к обсуждению.
При необходимости приглашаются коллеги из других команд.
Бизнес-смысл релизов aka обзор изменений
Когда релиз готов к установке в PROD или уже после обновления системы, РО проводит встречу по обзору изменений. На встрече отражается, как выбранная реализация конкретной фичи повлияла на бизнес-функциональность и контрагентов.
РО готовит презентацию, где объединяет техническую реализацию фичи, бизнес‑смысл, а также информацию, как новая функциональность будет эксплуатироваться.
Встреча проводится не только для команды разработки и сопровождения, но и для пользователей или контрагентов системы.
Получается своего рода вебинар, где РО отвечает на вопросы по релизу.
В чем польза для команды, и какие вопросы закрывает:
Еще раз погрузиться в фичи завершенного релиза уже на более высоком уровне.
Узнать, как реализовался закладываемый бизнес-смысл фичи в технике.
Остается артефакт в виде презентации, который после используется для передачи знаний.
Помогает нам эффективно доставлять знания о релизе всем заинтересованным сторонам.
Выводы
Описанные в статье практики позволили нашей команде эффективно масштабироваться, сохранять актуальность документации и знаний, а также вовлекать всех заинтересованных лиц в процесс развития систем.
Ключевыми преимуществами стали:
снижение Bus Factor за счет распределения знаний в команде;
ускорение вхождения новых сотрудников благодаря подробной документации;
повышение качества реализации за счет вовлечения всей команды в процесс;
улучшение коммуникации между разработкой, сопровождением и бизнесом.
Эти практики могут быть применены в любой команде, сталкивающейся с задачами масштабирования и поддержки множества систем как по отдельности, так и в применимой для вашей команды конфигурации.
