У соседней команды нет времени на вашу задачу

Например, команда личного кабинета магазина переделывает отмену заказа. Сейчас покупатель нажимает кнопку и иногда получает непонятное «Операция недоступна». Хочется заранее скрывать кнопку у заказов, которые уже нельзя отменить, а рядом объяснять причину.

Для этого команда просит разработчиков API добавить признак canCancel в ответ с заказом. Интерфейс уже свёрстан, выпуск намечен на следующую неделю. Но команда заказов занята изменением складского учёта и работу над новым полем не обещала.

Что нам нужно от другого API

Если прийти с вопросом «когда добавите поле», разговор будет идти о месте нашей задачи в чужой очереди. Я бы сначала объяснил, какое поведение интерфейса мы пытаемся исправить.

После ответа «Операция недоступна» покупателю непонятно, стоит ли попробовать ещё раз. Нам нужно объяснить, что произошло с заказом. Признак canCancel позволит заранее скрыть кнопку. Для объяснения причины одного булева значения недостаточно: её тоже придётся передать из API. Поэтому сначала стоит выяснить, почему заказ нельзя отменить.

Разработчики API могут рассказать то, чего команда кабинета пока не знает. Например, между началом упаковки и обновлением видимого статуса проходит время. Вычислить возможность отмены по одному статусу нельзя, поэтому предложение «мы сами напишем условие на фронтенде» здесь не поможет. А проверка при чтении заказа всё равно не заменит проверку в момент отмены: пока покупатель смотрел страницу, упаковка могла начаться.

Полезнее вернуться к тому, что сервер знает в момент нажатия. В нашем примере обработчик отмены уже различает начавшуюся упаковку и технический сбой. Однако клиенту оба случая приходят с одним общим кодом. Можно ли передать эту причину в ответе на отмену, не добавляя canCancel?

Это уже другой объём работы. Кнопка останется видимой до попытки отмены, зато после отказа покупатель увидит: «Заказ уже начали упаковывать. Отменить его в личном кабинете не получится». При сбое связи нельзя утверждать даже то, что отмена не произошла: ответ мог потеряться после её выполнения. В этом случае сообщение скажет, что результат неизвестен. В первом выпуске мы отказываемся от предварительного скрытия кнопки, но уже можем объяснить отказ.

Маленькая просьба тоже занимает время

Я бы не называл новый вариант мелочью за тех, кому предстоит его делать. Отдельный код ответа нужно провести до клиента и проверить на существующих потребителях API. Если за общим ответом скрываются ещё какие-то причины, их нельзя без разбора назвать начавшейся упаковкой.

Поэтому вместо «там же на час» получается более предметная просьба:

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

Так разработчики API могут сначала разобраться с технической стороной, не обещая срок. Возможно, причина уже есть в нужном месте и её остаётся передать наружу. А возможно, одинаковая ошибка приходит из нескольких обработчиков, и сначала придётся разбираться с ними.

Команда заказов посмотрела код и подтвердила, что отдельную причину вернуть можно. Теперь нужно найти время. Разработчик, который знает этот участок, на той же неделе готовит внутренний отчёт и проверяет изменения складского учёта. Если вся неделя уже занята, просьба сделать ещё и API «между делом» означает перенос другой работы или переработку, даже если никто не запишет это в плане.

Предложение помочь тоже стоит сделать конкретным. Команда кабинета может подготовить тестовые заказы и проверить поведение интерфейса со старым и новым ответом. Разработчикам API остаются изменение обработчика и проверка его совместимости. Если мы решим написать сам обработчик, его всё равно должны принять разработчики, которым предстоит сопровождать этот код. Помощь с кодом может сократить чужую работу, но не отменяет её.

Договорённость меняет оба плана

Допустим, после разбора команды нашли возможность сделать небольшой вариант. Руководитель команды заказов переносит подготовку внутреннего отчёта на день, не сдвигая запуск нового складского учёта. Команда кабинета убирает из ближайшего выпуска предварительное скрытие кнопки и освобождает время на совместную проверку. Теперь у изменения API есть место в плане, и можно обсуждать срок.

Я бы записал результат примерно так:

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

Последняя строка здесь нужна не для порядка. Иначе через неделю появится новая версия прежнего разговора: «Вы же обещали сделать отмену, где поле?» Мы договорились показывать причину отказа. Предварительную проверку возможности отмены отложили, и это тоже должно быть записано.

Если места всё равно нет

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

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

Если руководитель кабинета может изменить обещанную дату, он делает это сам. Если ради этой даты нужно сдвинуть складское изменение, выбор должны сделать руководители, которые отвечают за оба результата. Разработчики двух команд не обязаны решать за них, какой результат компания получит позже.

К этому разговору я бы принёс уже проверенные варианты и их последствия:

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

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

Если руководители отвечают «делайте оба», не объясняя, откуда возьмётся время, зависимость остаётся. Я бы прямо сказал, что подтвердить обе даты пока нельзя: ни одна из работ не стала короче и никто не освободился.

Когда можно продолжать работу

Вернёмся к варианту, в котором команды выбрали отдельный код отказа. В четверг они проверили начавшуюся упаковку и техническую ошибку, затем убедились, что прежние клиенты продолжают работать. Команда кабинета включает новые сообщения. Запрос на canCancel остаётся отложенным; его наличие в списке задач не означает обещания сделать поле в следующем выпуске.

В итоге покупатель получает понятную причину отказа, хотя от скрытия кнопки пришлось отказаться. Другая команда нашла время на API, а наша изменила объём выпуска и взяла на себя проверку интерфейса.