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

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

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

Понятно, что блокеры и критикалы мы правили быстро и чисто. Но вот когда у вас в бэклоге багов накоплено штук так под сотню задач и они все вроде бы мелкие — либо не затрагивающие хоть сколько-нибудь значимое число пользователей, либо затрагивающие, но не сильно (типа сдвинутой на бесящий пиксель кнопки), их можно копить годами. Что, собственно, и произошло. Мы копили их годами, и настало время всё это разгребать.

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

Как вы уже можете догадаться по заголовку, кое-что пошло не так.

Начало подготовки: суммарный вес багов 4494 единиц

На момент начала подготовки в разных системах команд учтено примерно 1600 багов. Что-то правильно описано в Джире, что-то ведётся в собственных багбэклогах и так далее. Мы подозреваем, что не все баги заведены в системы правильно или достаточно описаны, чтобы понять, что именно происходит не так и как их воспроизвести.

Как довольно быстро выяснилось, описанным багам тоже нельзя доверять: некоторые из них заведены 2–3 года назад и в процессе развития продукта куда-то пропали. Например, их случайно исправили (ну, по крайней мере, они больше не воспроизводятся) или ветку кода с ними удалили. А висеть в виде задач они продолжают.

Каждый баг имеет вес.

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

Инциденты (вроде DDoS-атаки) к багам не относятся.

Вес бага нужен для понимания его приоритетности исправления. Нам же нужно как-то сравнивать баги между собой в одной категории. Понятно, что если сравнивать блокер с SLA 4 часа и минор, минор пойдёт в бэклог и останется там, скорее всего, навсегда. С блокером так не поступить. Но при выборе из двух мажоров нужно смотреть на их вес. Вес также помогает понять, насколько накопился техдолг: 80 багов одной команды могут иметь суммарный вес 15,2, а 3 бага другой — суммарный вес 25 единиц.



Развесовка такая: блокер имеет множитель — 200, критикал — 100, мажор — 10, минор — 1, есть также баги тривиалов с весом 0,5.

Итого около 1600 ошибок давали 4494 багвеса. Этот вес рос последние полгода. Именно его надо было скинуть.

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

Начало багатона: суммарный вес багов 2827 единиц

Все команды получили задания почистить багбэклоги. Уборка показала, что есть баги которые:

1. Уже кто-то закрыл, но не отметил этого в Джире. Потому что зачем возиться с Джирой, если главное сделано, правильно? Такие баги можно считать небольшим бюрократическим подарком, потому что они очень быстро уменьшали суммарный вес.
2. Бывает, что баг перестал быть актуальным. Например, относился к способу оплаты, которого уже нет. Способа нет, а баг есть, прекрасно! Убираем на чистке бэклога.
3. Некоторые просто перестали воспроизводиться сами собой. Мистическое спасибо.
4. Некоторые не были учтены в принципе и добавились к суммарному весу.
5. Некоторые были учтены не очень хорошо и требовали переоценки.

На переоценке надо остановиться подробнее. Во-первых, мы не всегда можем точно оценить процент влияния на пользователей. То есть если речь про баг, который затрагивает всех на главном экране iOS-приложения, доля вроде бы понятна. А если это один из 50 сервисов, которым пользуется только некоторая часть аудитории приложения?

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

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

2827 единиц веса давали примерно 900 известных багов.

Багатон: снижаемся до 1929

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

Ну и заодно более-менее синхронизировать по компании подходы к их оценке, приоритетам и так далее. Плюс расчистить всё то, что накопилось в виде бесящих красных уведомлений о просроченных SLA. Между прочим, если их в какой-то момент становится много, то команды просто перестают обращать на них внимание. Тут действует своего рода теория разбитых окон (но это только гипотеза). В общем, приятнее работать, когда требующих исправления багов нет. Или хотя бы мало.

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

Нужно сначала сделать генеральную уборку, а потом как-то меньше сорить. Или чаще делать поддерживающую уборку.

Сам по себе багатон легко способен навредить бизнесу — у него продукт, релизы, важные фичи с обещанными сроками и всё такое. Поэтому мы предложили участвовать командам добровольно. И тут нас ждало достаточно большое разочарование: из примерно 50 команд разработки в багатон официально вошло всего 18 команд. Мы-то рассчитывали на 80% хотя бы. Хотя бы!

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

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

Убрать 25–49% своих ошибок считалось хорошим результатом, 50–74% — выдающимся, 75–90% — космическим.

Условия были такими: участвуют команды, у которых актуализирован бэклог багов и ведётся регулярная работа над ошибками. Состав команды определят тимлид. Команды с 20 и менее ошибками соревнуются в своей категории, с более чем 20 — в другой. К зачёту принимаются ошибки, закрытые с изменением кода: для команд с пофичевой выкаткой — ошибки, выкаченные на прод. Для команд мобильной разработки — ошибки, переведённые в статус Ready for release, Resolved. Для команд с релизной выкаткой — ошибки, переведённые в статус Ready for deploy, Ready for release, Resolved. Спорные кейсы жюри рассматривает индивидуально. В багатоне учитываются только актуализированные ошибки.

Заодно мы выяснили следующее:

1. Оказывается, при решении багов легко и непринуждённо заводятся новые баги, потому что один тянет за собой местами два новых. Некоторые находятся при исследовании проблемы, а некоторые появляются при закрытии текущего бага. Мы сначала было чуть не подумали, что команды нашли отличный способ атаковать конкурентов, тестируя вручную их участки и увеличивая их бакбэклог, но нет, заводили в основном себе же.
2. Мог появиться эффект старого анекдота про проверку. Пожарный щит, 5 замечаний:
   
   
   1. Черенок лопаты короче стандартного.
   2. Насажен плохо, качается.
   3. Черенок лопаты не входит в держатели на пожарной доске, лопата плохо держится.
   4. Лопата не окрашена в красный цвет.
   5. На лопате отсутствует инвентарный номер.
   
   В результате вмешательства опытного специалиста количество замечаний снижено до допустимого уровня в 1 замечание:
   
   1. Отсутствует пожарная лопата.
   
   Поэтому мы ввели правило, что баг обязательно должен требовать для учёта в конкурсе внесения изменений в код и имплементации всего этого на прод.
   
3. Возник ещё ряд потенциально спорных ситуаций, и понадобилось жюри для их решения. Жюри у нас состояло из QA-лидов. За каждой командой-участницей мы закрепили QA-лида на время багатона, причём проследили, чтобы это был не их QA-лид из обычной жизни. Этим добились непредвзятости и заодно познакомились.
   
   На конец багатона мы снизили число багов в штуках с девятисот с лишним до семисот, закрыв 213 багов. То есть каждый третий баг багатона был найден во время багатона.

Счастливый конец истории, который так хорошо указывать в резюме

Итого суммарный вес багов спал с 4494 до 2827 реального и 1929 после фактического закрывания багов в течение недели.

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

Самое главное, переломился тренд на количество заводимых багов к исправленным. В рамках багатона просто график открытия пересёкся с графиком закрытия впервые за пару лет.

Тренд даже сохранился некоторое время.

Настоящий конец истории, который не надо указывать в резюме

Естественно, эффект довольно быстро растерялся в части команд, где не поменялись процессы работы с новыми багами. Но в части мы всё же внедрили Zero Bug Policy — принцип, когда при постановке задачи с багом она или решается почти сразу, или же принимается решение, что с этим багом ничего делать в принципе не надо. Но не откладывается больше, чем на спринт. Там тоже всё прошло не очень гладко и не без сюрпризов, но про эти весёлые факапы я расскажу чуть позже. А пока просто надеюсь, что наш опыт будет полезен.