Как ставить задачи разработчикам

Коротко

Хорошая задача описывает проблему и желаемый результат, а не решение. Разработчик знает больше вас о том, как сделать, — и часто предложит более простой способ, если понимает, зачем.

Шаблон

Что происходит сейчас. Факт, без оценки: «на странице услуги нет цены».

Почему это проблема. «Клиенты пишут с вопросом о стоимости, менеджер отвечает вручную по десять раз в день».

Что должно быть. Результат: «на странице видна вилка цен и что влияет на итоговую сумму».

Ограничения. Что нельзя менять, к какому сроку нужно, есть ли зависимости.

Как проверим. По какому признаку поймём, что задача выполнена.

Для ошибок — отдельный формат

Сообщение «форма не работает» без этих пунктов превращается в день переписки — просто чтобы выяснить, о какой форме речь.

Чего не стоит делать

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

Присылать правки порциями каждый день. Каждая порция — переключение контекста, а это дороже самой правки.

Требовать оценку сразу. «Сколько это займёт?» без описания задачи — вопрос, на который нет честного ответа.

Описывать решение вместо задачи. Вы платите за экспертизу — дайте ей работать.

Что это даёт

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