В нашей работе баги неизбежны, но как именно мы справляемся с этим вызовом — вот что нас отличает. Хочу поделиться с вами историей о том, как одна из платежных команд разработки успешно решала ошибки в продуктовой среде, повышала качество разработки, боролась с легаси кодом и техдолгом.
Вступление
Меня зовут Кристина. Я работаю в ИТ-блоке Почта Банка и являюсь ИТ-лидером команды сервиса дистанционного банковского обслуживания (ДБО). В ведении команды находится сервис 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» для инцидентов, с которыми можем справиться самостоятельно. Только с более оперативными сроками реакции и устранения, чем с внешними командами.
Работу с багами мы начали с высоко приоритетных, со сложными кейсами.
Классификация:
Блокирующий — полностью блокирует работу функционала.
Критичный — часть функционала не работает, но это не блокирует общий функционал.
Высокий — часть логики работает некорректно, но пользователь может решить проблему другим способом.
Обычный — не нарушает логику работы функционала.
Низкий — не влияет на качество функционала
Время реакции и время устранения ошибок можно увидеть в таблице ниже:
Приоритет | Время устранения |
Блокирующий | Часы |
Критичный | 1-2 дня |
Высокий | До 1 недели |
Обычный | До 1 спринта |
Низкий | До 1 месяца |
SLA также является показателем эффективности и согласованности работы команды. Если команда не успевает устранить баг в установленные сроки, она может один раз перенести срок по согласованию с владельцем продукта и руководителями, ответственными за систему. В течение месяца допускается один раз запросить сдвиг сроков багов, выбивающихся от целевого сценария устранения по той или иной причине. В дальнейшем это отражается в «карме» команды.
Так, SLA стал своеобразным «градусником» для оценки команды: если «температура» отклоняется от нормы, необходимо принять соответствующие меры. Разумеется, это не единственная метрика эффективности команды, но одна из наиболее важных для нас.
Оценка команды
У команды есть квартальные цели. Как по поставкам, по бизнес-показателям, так и по целевому уровню качества (т. е. по багам и их отсутствию). Закрытие инцидентов в рамках согласованных сроков — не менее 95% от уровня SLA на команду. Соблюдается регламент оценки сроков. Оценивается средневзвешенный срок отклонения закрытия ошибок за период от согласованных сроков (сроки изначально определяются по SLA, после планирования и при согласовании сдвига учитывается обновленная дата, отклонение считается по несогласованному сдвигу инцидента или отклонению от него).
Парадокс такой оценки эффективности: чем меньше ошибок в проекте, тем сильнее задержка в исправлении влияет на общую оценку продуктивности. Например, если исправление единственной ошибки задерживается, это приведет к потере 90% эффективности, в то время как задержка в исправлении одной из десяти ошибок приведет к потере не более 10% эффективности. Эту «несправедливость» нивелируем индивидуальным подходом к таким случаям, т.к. команда с низким уровнем ошибок по умолчанию находится на хорошем счету.
Контроль рисков при планировании спринтов
При планировании работ в каждом спринте нам пришлось не только научиться закладывать риски на реализацию новых задач, но и повысить свою экспертизу в определении специфических рисков связанных с устранением выявленных инцидентов: балансировать между задачами, направленными на развитие нового функционала, баг-фиксингом и задачами архитектурного/технического долга. Плюс научились закладывать время на «влётные» задачи. Отследили и вывели формулу идеального спринта – 30/30/40 (эта формула представлена выше).
Ниже на графике вы можете увидеть разбивку по спринтам за последний квартал.
Основные риски:
Риск, связанный с межкомандными коммуникациями. Ранее я уже упоминала о влиянии на работу нашей команды вендоров. Мы синхронизировали сроки и даты начала спринтов разных команд и наладили работу со смежными командами и вендорами. Это позволило нам обмениваться ресурсами и подменять друг друга в период отпусков.
Риск накопления «хвостов». Мы научились гибко делать аналитику и оценивать баги, поскольку они часто связаны с нюансами в работе бизнес-логики или особенностями обработки данных. В конце каждого квартала проводим «Технический спринт». В него не берутся никакие бизнес-задачи. Только баги, техдолг и архитектурные задачи.
Риск «Влётных» задач. Это не совсем контроль, это скорее стратегия принятия и учитывания вероятности возникновения подобных рисков. Именно по этой причине мы стараемся от 2 до 8 часов в спринт заложить на «влётные» задачи.
Культура командной работы
Является одной из ключевых задач для руководителя проектов и лидера команды, и в то же время одной из самых индивидуальных.
Когда я пришла на позицию РП, команда испытывала значительное давление из-за большого количества багов, что приводило к недовольству и частым ссорам.
Регулярная работа с членами команды (и с собой в том числе) над улучшением взаимодействия и повышением эффективности, стремление стать лучше и слаженнее, чем раньше, без использования исключительно авторитарных методов управления — это задача, требующая особого внимания и усилий. Для этого я использовала следующие методы (перечислю основные из них):
Временный запрет для тим-лидов специализаций на критику членов команды.
Были испробованы различные игровые форматы проведения Agile-церемоний (в основном ретро).
Тимбилдинг в реальной жизни , такие как походы в бар или на пикник всей командой.
Сознательно не касаюсь таких методов как перемена членом команды проекта, увольнение сотрудника или что-то еще, сосредоточившись на индивидуальных методах становления командной коммуникации и культуры.
Это те подходы к проектному менеджменту, которые нельзя масштабировать на весь ДБО Банка.
Системность
Для меня залог успешной работы — это системность. Поэтому я провожу еженедельные встречи с техподдержкой и аналитиком для разбора багов и контроля их устранения.
Раньше мы тратили два часа на разбор 10–15 инцидентов, потом стали разбирать половину за это время, а теперь разбираем все. Сейчас в команде минимальное количество багов, и актуализация занимает 15–20 минут. Но еженедельные встречи всё ещё проводятся.
Ниже представлен график результатов борьбы с багами в команде. По горизонтали недели, по вертикали количество багов (в шт). На графике можно увидеть динамику снижения количества инцидентов от недели к неделе.
Так же один раз в неделю баги обсуждаются на уровнях поддержки и руководства. В итоге у нас получился примерно следующий график встреч для обсуждения инцидентов.
Понедельник. Обсуждение багов внутри команды. Рассматриваем каждую ошибку пристально – проводим груминг инцидента. Анализируем, что сделано за неделю и что нужно сделать на этой неделе. Новые ошибки планируем в аналитику на ближайший спринт. Проставляем актуальный статус и по возможности сроки SLA. По итогу данной встречи мы имеем: актуальный статус SLA по каждому багу, план действий, при необходимости запланированные встречи для спорных или тупиковых вопросов. «Посидели, поговорили и разошлись» — это неэффективная модель работы, которая не приведёт к достижению поставленных целей.
Вторник. Обсуждаем на уровне руководителей команд. Ко вторнику коллеги из поддержки готовят презентацию, где указаны:
критичные и блокирующие баги на всем контуре ДБО
ошибки с истекшим сроком SLA
ошибки, истекающие в ближайшие 2 недели по сроку SLA
ошибки без сроков SLA
сводные отчеты/графики по динамике багов в командах.
Среда. На уровне руководства с привлечением руководителей поддержки, руководителей бизнеса обсуждается презентация, которая актуализируется во вторник на встрече руководителей команд.
Итоги
Чтобы успешно бороться с инцидентами, необходимо:
Регулярно и неукоснительно разбирать баги на разных уровнях: поддержка, команда, взаимодействие между системами, руководство. Для этого нужно создать или улучшить существующие площадки для взаимодействия: оперативки, дейли, недельные встречи, статусные совещания с руководителями.
Заниматься этим необходимо системно, регулярно и на всех уровнях.
Встречи должны приводить к конкретным решениям и действиям, чтобы избежать ситуации «посидели — поговорили — разошлись». Любые отвлечения специалистов стоят времени и денег.
Со временем можно сформулировать критерии критичности багов и под них определить срочность реакции команды и срочность решения (обходного или целевого). Так родится SLA.
Использовать SLA как индикатор темпа и сплочённости команды. Его стоит воспринимать как «градусник» или «барометр», который позволяет оценить действия команды: если «температура» (то есть эффективность) отклоняется от нормы, необходимо принять соответствующие меры.
Не стоит забывать о команде, взаимодействии и её внутреннем «здоровье». Команда зачастую является и причиной, и способом решения проблем. Когда «организм» болеет, ругать его в том, что он заболел, конечно, можно, но это не принесёт пользы.
В процессе решения проблем важно никого не критиковать (обращать внимание на причины/следствие ошибок можно и нужно).
Важно поддерживать открытую коммуникацию и устраивать офлайн-встречи, чтобы настроить команду на достижение общих целей.
Наша задача как руководителей команд — выстроить регулярный процесс работы, создать точки контактов и обеспечить эффективную коммуникацию. Необходимо транслировать и создавать безопасную среду, а также ориентироваться на сигналы и индикаторы «здоровья» команды, особенно в работе с инцидентами.
Самое главное — регулярно проводить «диагностику» команды и её участников. На основе полученных данных следует развивать и дополнять команду, учитывая сильные и слабые стороны каждого участника, его желание и готовность становиться лучше. Также необходимо периодически исключать слабые звенья, как это было бы ни печально.
