Постановка задачи это половина успеха. Звучит как банальность из методички, но за годы работы с командами разработки я убедился, что это ещё и очень дорогая банальность. Формулировка «сделай красиво» не работает. «Сделай как у конкурента» тоже не работает. «Ну ты же понимаешь, что я имею в виду» работает хуже всего, потому что программист в этот момент честно кивает и действительно понимает. Только что-то своё.
Я много раз видел одну и ту же сцену. Менеджер в пятницу вечером пишет задачу в одну строку, в понедельник программист приносит результат, менеджер смотрит на него с ужасом, программист с обидой, а клиент с калькулятором. Неделя работы ушла на то, чтобы выяснить, что все говорили о разных вещах. И виноватого тут нет, есть только плохо переданная мысль.
Программист не читает мысли, он их компилирует
Представьте, что Вы заказываете у кузнеца меч и говорите ему: «Нужен хороший меч». Кузнец сделает хороший меч. По своим представлениям о хорошем. Он может оказаться тяжёлым двуручником, а Вам нужна была лёгкая шпага для фехтования в зале. Кузнец не виноват, он сделал отличную вещь. Просто не ту.
С программистом всё ещё интереснее. Код это буквальная вещь. Компьютер не умеет «додумывать», он исполняет ровно то, что написано. И программист, переводя Вашу задачу в код, вынужден принимать десятки маленьких решений, о которых Вы даже не подумали. Что делать, если поле пустое? Что видит пользователь без прав? Что происходит, если заказ отменили на полпути? Каждое такое место без ответа программист заполнит сам, по своей логике, а не по логике Вашего бизнеса. Именно в этих щелях и живут потом баги, переделки и взаимные претензии.
Поэтому хорошая задача не та, в которой много слов. Хорошая задача та, в которой меньше всего места для чужих догадок.
Анатомия задачи, которую делают с первого раза
В заготовке этой статьи у меня был короткий чек-лист, и он по-прежнему правильный. Но за каждым пунктом стоит своя история, поэтому разверну.
Заголовок. Он отвечает на вопрос «что именно нужно изменить». Не «Проблема с заказами», а «Добавить отмену заказа клиентом до момента отгрузки». По заголовку человек должен через полгода найти задачу в трекере и понять, о чём она, не открывая её. Если заголовок нельзя прочитать вслух на планёрке без пояснений, он плохой.
Описание и контекст. Здесь пишется не только «что», но и «зачем». Это самый недооценённый пункт. Когда программист понимает, какую бизнес-проблему он решает, он сам замечает половину крайних случаев и предлагает решения проще и дешевле, чем Вы бы придумали. Однажды клиент попросил нас сделать сложный фильтр с двадцатью параметрами для отчёта. Мы спросили, зачем. Оказалось, бухгалтер раз в месяц ищет три конкретных типа платежей. Сделали три кнопки. Сэкономили клиенту две недели разработки, а бухгалтеру нервы.
Логика работы. Шаги сценария глазами пользователя: открыл, нажал, увидел, получил. Плюс развилки: что, если данных нет, если ошибка, если у пользователя другая роль. Это не нужно писать прозой на три страницы, достаточно нумерованного списка.
Критерии приёмки. Как мы проверим, что задача выполнена? Это пункт, который превращает спор «мне кажется, не готово» в проверяемый факт. Например:
- клиент видит кнопку «Отменить» только у заказов в статусе «Новый» и «Подтверждён»;
- после отмены менеджер получает уведомление в течение минуты;
- отменённый заказ не попадает в отчёт по продажам, но остаётся в истории клиента.
Если критерии приёмки написаны, программист сам может проверить себя до того, как отдать работу. Это дешевле любого тестировщика.
Макеты и скриншоты. Если у задачи есть визуальная часть, одна картинка заменяет страницу текста. Это не обязательно должен быть дизайн из Figma. Скриншот текущего экрана с красной стрелкой и подписью «сюда кнопку» уже работает лучше, чем самое подробное словесное описание. Я в своё время рисовал схемы шариковой ручкой на салфетке и фотографировал. Работало.
Ошибки, которые я вижу чаще всего
Первая: задача-матрёшка. «Сделать личный кабинет». Внутри регистрация, восстановление пароля, профиль, история заказов, уведомления и ещё пара вселенных. Такая задача не может быть оценена, не может быть проверена и никогда не заканчивается. Если задачу нельзя сделать за один-три дня, её нужно резать. Крупные куски живут в плане проекта, а в трекер идут маленькие, законченные и проверяемые кусочки.
Вторая: решение вместо проблемы. «Добавь в таблицу колонку с датой». Хорошо, добавим. Но зачем? Может, на самом деле нужно было сортировать по дате, и колонка не нужна вовсе. Описывайте, какую проблему Вы решаете, а способ предлагайте как вариант, а не как приказ. Программист с опытом часто знает путь короче.
Третья: задача в мессенджере. Голосовое сообщение на четыре минуты, потом три уточнения в другом чате, потом созвон, на котором «договорились», но никто не записал. Через неделю никто не помнит, о чём договорились. Задача должна жить в одном месте, а все уточнения дописываться в её описание. Это скучно. Это работает.
Четвёртая: молчаливая приёмка. Программист сдал, менеджер посмотрел, ничего не сказал, а через месяц выяснилось, что «вообще-то не так». Обратная связь нужна сразу. Иначе ошибка успевает обрасти новым кодом, как ракушками, и её исправление стоит в разы дороже.
Диалог вместо приказа
Есть ещё одна вещь, о которой редко пишут в инструкциях. Постановка задачи это не одностороннее действие, а короткий диалог. Хороший программист, прочитав задачу, задаёт вопросы. Если вопросов нет совсем, это не всегда признак идеальной задачи. Иногда это признак того, что человек стесняется спросить или уже придумал всё за Вас.
Я прошу свои команды после прочтения задачи пересказать её своими словами в двух-трёх предложениях. Это занимает минуту и отлавливает больше недопониманий, чем любой регламент. Если пересказ совпадает с тем, что было у Вас в голове, можно начинать. Если нет, Вы только что сэкономили неделю.
И ещё одно правило: оценку сроков даёт тот, кто делает. Менеджер может спросить, может поторговаться, может урезать объём. Но назначить срок сверху, не спросив исполнителя, это как назначить погоду на выходные. Можно, только ничего не изменится.
Что делать завтра
Возьмите последние пять задач, которые Вы поставили, и перечитайте их глазами человека, который не был на Ваших созвонах. Понятно ли из текста, что сделать, зачем и как проверить результат? Если хотя бы в одной из них нет критериев приёмки, допишите. Это самое дешёвое улучшение процесса разработки, которое я знаю.
Заведите себе шаблон задачи из пяти полей: заголовок, контекст, логика, критерии приёмки, макет. Не обязательно заполнять все поля в каждой задаче, но пустое поле должно быть осознанным решением, а не забывчивостью.
Мы в Ingello Systems пошли в этом ещё дальше: значительную часть типовых задач мы вообще не ставим словами, а описываем систему формально, схемами данных и экранов, и генератор Fractal превращает это описание в код. Когда описание точное, спорить о том, «что имелось в виду», просто не о чем. Но даже если до генерации кода Вам далеко, точная формулировка задачи уже на треть приближает Вас к этому миру. Код, как и меч, начинается с чертежа.
