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

Вступление

Меня зовут Кристина. Я работаю в ИТ-блоке Почта Банка и являюсь ИТ-лидером команды сервиса дистанционного банковского обслуживания (ДБО). В ведении команды находится сервис P2P (person-2-person) переводов. 

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

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

О командах ДБО

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

Про качество

В Банке применяются различные методики оценки качества сопровождения (управления) командами своими микросервисами.

Мы сосредоточились на интерпретации атрибута качества «Обработка ошибок продуктовой среды» и его количественной характеристике — число инцидентов в команде. 

Под багом или инцидентом мы понимаем ошибку в функционале на боевом контуре Продукта или несоответствие Продукта установленным требованиям.

Любая ошибка в клиентском приложении банка влияет на удобство клиентов и, как правило, на наши финансовые показатели, а значит,  важна по умолчанию. 

Начиная с 2021 года у нас усилился фокус на работу с багами: их «истребление» и недопущение. В настоящее время работа в этом направлении — приоритетная задача, а мотивация любого сотрудника ИТ-команды и руководства ИТ в целом зависит от показателей эффективности работы с уровнем качества и стабильности работы систем, в т.ч. нашего ДБО.

-------------

Отступление

Для сравнения, в e-commerce, где я работала ранее, багам не уделялось такое пристальное внимание, как в Банке. Мы использовали фреймворк управления проектами Kanban. На доске был установлен лимит в три инцидента — одновременно в работе могло находиться не более трех ошибок. Руководитель проекта добавлял баги на доску, следуя принципу FIFO (первым пришел — первым ушел), если не обнаруживалось никаких критичных проблем. В результате мы работали спокойно несмотря на то, что в бэклоге у нас скапливалось около 100 багов. Основной приоритет был отдан развитию нового функционала.

-------------

ПБ-Sсrum

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

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

Мы тесно сотрудничаем с коллегами из Клиентской службы (контакт-центр, операторы чатов, претензионная работа и поддержка клиентов). Это позволяет оперативно отрабатывать запросы, информировать клиентов и предлагать им наиболее удобные способы получения услуг.

Обычно наша команда состоит из:

• бизнес-лидер, 

• IT-лидер, 

• CJM эксперт, 

• бизнес-технолог (один на несколько команд),

• архитектор (один на несколько команд), 

• 1-2 системных аналитика, 

• 2-4 разработчика (бэк/фронт), 

• 1-2 тестировщика, 

• 1-2 эксперта поддержки. 

Оптимизация процессов и борьба с ошибками: опыт нашей команды

Позиция на старте

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

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

Выявленные проблемы производственного процесса

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

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

Однако ситуация резко меняется при появлении критичного бага: в этом случае команда активирует режим «красного флага» и необходимые ресурсы быстро находятся из других команд. Но выделяются они только для исправления инцидента до вывода в продакшн. 

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

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

Для ускорения процесса решения проблем в нашем банке мы согласовали оптимальные SLA (Service Level Agreement) с вендорами, создали совместные чаты и начали проводить еженедельные встречи, продолжительностью до 30 минут. Спустя год отметили положительные изменения: процесс решения инцидентов стал кратно быстрее и проще.

Про SLA и приоритеты

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

Работу с багами мы начали с высоко приоритетных, со сложными кейсами.

Классификация: 

• Блокирующий — полностью блокирует работу функционала.

• Критичный — часть функционала не работает, но это не блокирует общий функционал.

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

• Обычный — не нарушает логику работы функционала.

• Низкий — не влияет на качество функционала

Время реакции и время устранения ошибок можно увидеть в таблице ниже:

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

Так, SLA стал своеобразным «градусником» для оценки команды: если «температура» отклоняется от нормы, необходимо принять соответствующие меры. Разумеется, это не единственная метрика эффективности команды, но одна из наиболее важных для нас.

Оценка команды

У команды есть квартальные цели. Как по поставкам, по бизнес-показателям, так и по целевому уровню качества (т. е. по багам и их отсутствию). Закрытие инцидентов в рамках согласованных сроков — не менее 95% от уровня SLA на команду. Соблюдается регламент оценки сроков. Оценивается средневзвешенный срок отклонения закрытия ошибок за период от согласованных сроков (сроки изначально определяются по SLA, после планирования и при согласовании сдвига учитывается обновленная дата, отклонение считается по несогласованному сдвигу инцидента или отклонению от него). 

Парадокс такой оценки эффективности: чем меньше ошибок в проекте, тем сильнее задержка в исправлении влияет на общую оценку продуктивности. Например, если исправление единственной ошибки задерживается, это приведет к потере 90% эффективности, в то время как задержка в исправлении одной из десяти ошибок приведет к потере не более 10% эффективности. Эту «несправедливость» нивелируем индивидуальным подходом к таким случаям, т.к. команда с низким уровнем ошибок по умолчанию находится на хорошем счету.

Контроль рисков при планировании спринтов

При планировании работ в каждом спринте нам пришлось не только научиться закладывать риски  на реализацию новых задач, но и повысить свою экспертизу в определении специфических рисков связанных с устранением выявленных инцидентов: балансировать между задачами, направленными на развитие нового функционала, баг-фиксингом и задачами архитектурного/технического долга. Плюс научились закладывать время на «влётные» задачи. Отследили и вывели формулу идеального спринта – 30/30/40 (эта формула представлена выше). 

Ниже на графике вы можете увидеть разбивку по спринтам за последний квартал. 

Основные риски: 

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

• Риск накопления «хвостов». Мы научились гибко делать аналитику и оценивать баги, поскольку они часто связаны с нюансами в работе бизнес-логики или особенностями обработки данных. В конце каждого квартала проводим «Технический спринт». В него не берутся никакие бизнес-задачи. Только баги, техдолг и архитектурные задачи.

• Риск «Влётных» задач. Это не совсем контроль, это скорее стратегия принятия и учитывания вероятности возникновения подобных рисков. Именно по этой причине мы стараемся от 2 до 8 часов в спринт заложить на «влётные» задачи. 

Культура командной работы

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

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

Регулярная работа с членами команды (и с собой в том числе) над улучшением взаимодействия и повышением эффективности, стремление стать лучше и слаженнее, чем раньше, без использования исключительно авторитарных методов управления — это задача, требующая особого внимания и усилий. Для этого я использовала следующие методы (перечислю основные из них): 

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

• Были испробованы различные игровые форматы проведения Agile-церемоний (в основном ретро).

• Тимбилдинг в реальной жизни , такие как походы в бар или на пикник всей командой.

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

Это те подходы к проектному менеджменту, которые нельзя масштабировать на весь ДБО Банка.

Системность

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

Раньше мы тратили два часа на разбор 10–15 инцидентов, потом стали разбирать половину за это время, а теперь разбираем все. Сейчас в команде минимальное количество багов, и актуализация занимает 15–20 минут. Но еженедельные встречи всё ещё проводятся.

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

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

Понедельник. Обсуждение багов внутри команды. Рассматриваем каждую ошибку пристально – проводим груминг инцидента. Анализируем, что сделано за неделю и что нужно сделать на этой неделе. Новые ошибки планируем в аналитику на ближайший спринт. Проставляем актуальный статус и по возможности сроки SLA. По итогу данной встречи мы имеем: актуальный статус SLA по каждому багу, план действий, при необходимости запланированные встречи для спорных или тупиковых вопросов. «Посидели, поговорили и разошлись» — это неэффективная модель работы, которая не приведёт к достижению поставленных целей.

Вторник. Обсуждаем на уровне руководителей команд. Ко вторнику коллеги из поддержки готовят презентацию, где указаны: 

• критичные и блокирующие баги на всем контуре ДБО

• ошибки с истекшим сроком SLA

• ошибки, истекающие в ближайшие 2 недели по сроку SLA

• ошибки без сроков SLA

• сводные отчеты/графики по динамике багов в командах. 

Среда. На уровне руководства с привлечением руководителей поддержки, руководителей бизнеса обсуждается презентация, которая актуализируется во вторник на встрече руководителей команд. 

Итоги

Чтобы успешно бороться с инцидентами, необходимо:

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

2. Заниматься этим необходимо системно, регулярно и на всех уровнях.

3. Встречи должны приводить к конкретным решениям и действиям, чтобы избежать ситуации «посидели — поговорили — разошлись». Любые отвлечения специалистов стоят времени и денег.

4. Со временем можно сформулировать критерии критичности багов и под них определить срочность реакции команды и срочность решения (обходного или целевого). Так родится SLA.

5. Использовать SLA как индикатор темпа и сплочённости команды.  Его стоит воспринимать как «градусник» или «барометр», который позволяет оценить действия команды: если «температура» (то есть эффективность) отклоняется от нормы, необходимо принять соответствующие меры.

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

7. В процессе решения проблем важно никого не критиковать (обращать внимание на причины/следствие ошибок можно и нужно).

8. Важно поддерживать открытую коммуникацию и устраивать офлайн-встречи, чтобы настроить команду на достижение общих целей.

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

Самое главное — регулярно проводить «диагностику» команды и её участников. На основе полученных данных следует развивать и дополнять команду, учитывая сильные и слабые стороны каждого участника, его желание и готовность становиться лучше. Также необходимо периодически исключать слабые звенья, как это было бы ни печально.