Как превратить «бесит» в конкретное улучшение: 3 случая из моего опыта

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

⭐️ Бесячие мелочи

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

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

Это простое действие заняло у меня минут десять, но заметно упростило жизнь всем, кто занимался релизом. А ещё стало проще онбордить людей — вся информация по процессу релиза была под рукой, в одном документе.

⭐️ Системная боль

Давайте рассмотрим вещи посложнее, которые бесят большее количество людей.

В одной команде (вполне успешно работающей) возникали сложности на этапе интеграции фронта и бэка. Часто оказывалось, что бэк «пропустил» какое-то поле или фронту понадобилось что-то дополнительное, чего не было предусмотрено изначально. Иногда такие пропуски приводили к значительным переделкам.

Я в какой-то момент заподозрил проблему и провёл анализ: просто взял несколько последних эпиков и посмотрел задачи, которые заводились на доработку (примерно прикинул по датам заведения). Оказалось, что доработки могут доходить до 20% эпика. Просто подумайте: каждый пятый тикет — доработка! Да и разработчики раздражались из-за этого.

Я предложил следующее решение: внедрить API-first. Теперь спека API проектировалась на стадии проработки требований и согласовывалась обеими сторонами. Спека писалась после дизайна, так что было легко заранее продумать, что нужно получать фронту от бэка. В качестве аргументации использовал анализ, описанный выше.

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

⭐️ TBD: полгода работы ради стабильности

Одна из самых крупных проблем, которую я решал, — общий переезд нескольких команд на trunk-based development. Найти эту проблему было очень просто: бизнес постоянно был недоволен скоростью поставки, а из-за интеграции работы в большом монолите постоянно лезли баги.

Здесь я тоже провёл дополнительный анализ проблемы: взял несколько последних релизов и посчитал, сколько времени у нас занимает один релиз и сколько в среднем багов вылезает в зависимости от его объёма. Цифры получились страшные.

Следующим шагом я проработал вариант решения. Оно было сложным и требовало значительной переработки процесса CI/CD. Но любые идеи попроще были равносильны прикладыванию подорожника к открытому перелому.

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

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

⭐️ Итоги

Проблем и пространства для улучшений вокруг очень много. Важно развить в себе наблюдательность и научиться замечать их. «Придумывать» проблемы не рекомендую — вряд ли такие решения будут кому-то полезны (да, гениальные стартапы по выгулу собачек?). Просто внимательно наблюдайте, слушайте окружающих — и идеи не заставят себя ждать.