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

Допустим, в Jira прилетает «Доработать возвраты». Ты полез в API, менеджер ждёт кнопку в админке. До демо оба довольны. На демо: «Мы вообще не это имели в виду».

Срок поставили. Работу сделали. Договориться о результате почему-то решили в конце.

———

В «Пути джедая» Максим Дорофеев предлагает четыре критерия формулировки задачи. По ним удобно проверить и чужие тикеты, и свои.

1. Понятно, что нужно сделать

«Доработать возвраты» оставляет исполнителю слишком много трактовок. «Добавить в админку поиск возврата по ID платежа» задаёт конкретный результат. Можно проверить, появился поиск или нет.

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

2. Формулировка начинается с глагола

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

Но «улучшить» и «проработать» тоже глаголы. Добавить такое слово в заголовок и считать постановку готовой не получится.

3. Задача не требует лишних размышлений

Макет остался в личке. Договорённости — на прошлом созвоне. Ссылку на API «ты же вроде видел». Теперь коллеге предстоит собрать всё это заново.

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

Фраза «ты же сеньор, разберёшься» недостающих требований не добавляет. Голова нужна для решения задачи. На поиски твоего замысла её жалко.

4. Формулировка близка к физическому действию

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

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

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

———

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

До разработки верни свою трактовку: «Я понял задачу так. Сделаю вот это. Готовность проверим так. Всё верно?» Ответ зафиксируйте в тикете.

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

Береги своё время. На сложные решения оно ещё пригодится.