Цена ошибки — исправим позже? 📉

💼️️️️️️Ситуация

Описываю новую ручку API, этап предрелиза, аудитория больше 100 тыс. 👨‍💻👩‍💻 Вижу в схеме ответа, как я предполагаю, лишний параметр. Уточняю у менеджера продукта: да, действительно лишний, в ближайшем будущем не понадобится. Аналитик, разработчик — все в курсе, нужно убирать. Менеджер проекта нажимает на стоп🫸 и предлагает перенести в следующий релиз, чтобы не задерживать текущий⌛

Что будет, если оставить как есть

✔️Подготовка к следующему релизу: Завести задачу на доработку для разработчика, системного аналитика, техписателя.

✔️После релиза новой ручки Сценарий 1. Параметр не описан в документации 📄❓ Разработчики получают ответ с неожиданным параметром — пишут в поддержку, оставляют фидбек в документации. Трудозатраты техподдержки на выяснение, запрос в отдел документации на доработку, ответ разработчику. И так несколько циклов, если запросов много.

Сценарий 2. Пометили в документации параметр служебным (в новой-то ручке, что ж.. 🤷‍♀️) Разработчики получают ответ с этим параметром. Если всё удачно, идут в документацию, видят, что служебный, не обрабатывают. Если не замечают нюанса, пишут в поддержку, далее — сценарий 1 🔄 Про репутацию я молчу.

✔️ Следующий релиз 🔄 Аналитик, разработчик, техписатель вносят изменения. После релиза изменений разработчики, которые следят за changelog, учитывают изменения в схеме.

Итого: цена переноса, если не исправить сразу 🧮💲: Двойные трудозатраты аналитика, разработчика, техписателя, человекочасы поддержки и менеджера, который следит за бэклогом, а также время конечных пользователей, которые пользуются контрактом. Цена переноса, если исправить сразу 🧮💲: Два дополнительных часа работы разработчика и аналитика ⏳

А что вы думаете? 🤔

PS. К счастью, в итоге пошли по пути «Исправить сразу» — тут моей душеньке спокойно 😌