Работа в заказной разработке часто связана с факапами, но признаваться в них почему-то считается моветоном. Мы в Mad Brains решили перешагнуть через этот стереотип и выложить карты на стол. Готовы поделиться, в какие переделки попадали и как исправляли баги. Аналитикам и разработчикам будет полезно.

Для начала немного вводных: а на каких этапах могут всплывать ошибки?

Интервью
Если после встречи с заказчиком становится ясно, что в логике приложения есть несоответствия или мы собрали недостаточно данных, надо вернуться к клиенту за уточнениями. Иногда его триггерит, но по факту — это самые безобидные потери. Факап во время проектирования ТЗ или разработки — намного хуже.

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

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

Ошибки после релиза
Самый худший сценарий: если проблема найдена после того, как проект выкатили в прод, значит аналитики сработали плохо. Ошибки исправляются за счет исполнителя.

Баги на практике, реальные кейсы Mad Brains

Кейс 1. E-commerce-проект

Дано: еком-проект, у которого есть сайт и мобильное приложение. Оба работают на одной базе данных, что и логично.

Задача: клиент попросил срочно поменять данные на сайте.

Решение: быстро переделали структуру базы данных под новый контент.

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

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

После ситуации стало очевидно, что «хотелка» заказчика — это, конечно, святое, но сначала надо проверять, как она может отразиться на проекте в целом.

Кейс 2. Мобильное приложение для бронирования отелей

Дано: заказчик, который хотел приложение для ведения гостиничного бизнеса.

Решение: приложение было создано, успешно протестировано, отправлено в прод.

Баг: не учтен запрет на букинг номера через мобильное приложение. То есть пользователь бронирует номер, но на деле он уже забронирован другим человеком.

Как исправляли: добавили блокировку кнопки «Забронировать» при созданной заявке на фронте. Если номер забронирован, на бэке больше заявок создано быть не может.

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

Кейс 3. Изменение API метода авторизации в мобильном приложении

Дано: мобильное приложение, вход в которое осуществляется по номеру телефона и паролю.

Задача: добавить вход по коду.

Решение: задачу выполнили, выпустили релиз, поменяли метод. Обновленное приложение работало, НО пользователи старых версий мобильного приложения «отвалились».

Баг: не указали требования к обратной совместимости, не учли, что прежние пользователи остались со старой авторизацией.

Как исправляли: добавили версионность методов и вернули поддержку предыдущего. Финансовые потери небольшие, но негативных отзывов от пользователей отхватили.

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

Кейс 4. Проект в сфере инвестиций

Дано: проект, связанный с безопасностью системы.

Задача 1: добавить интеграцию между двумя сервисами для последующей агрегации данных.

Её решение: добавили метод для одного из сервисов, откуда требовалось «забирать» операции.

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

Проблему решили, финансовых последствий удалось избежать, но были рядом.

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

Её решение: мы договорились передавать данные сообщениями в очередь, чтобы распределить нагрузку на систему. Очередь спроектировали в rabbit и проверили на тестовых данных.

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

Как исправляли: данные готовились вручную и передавались в архиве с письмом от руководителя. Очередь пришлось «выпилить», а данные маппились руками. Получили финансовые потери на реализацию фичи и её «выпиливание».

Кейс 5. Электронная площадка для проведения аукционов

Дано: электронная площадка для проведения аукционов, монолит, Git на проекте отсутствовал.

Задача: аналитик попросил разработчика сделать бэкап системы перед публикацией очередного набора функций.

Решение: аналитик сделал архив всей площадки и оставил ее в корневой папке.

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

Как показывает наш опыт, проблема может возникнуть там, где ты ее не ожидал. Пусть этот честный рассказ поможет вам быть начеку и во всеоружии!

Факапы аналитиков: где они обитают? Кейсы Mad Brains