Как поставить задачу разработчику, чтобы получить то, что нужно

Разбор от команды разработки AmSales.

Большинство переделок в разработке рождаются не из-за слабых программистов, а из-за плохо поставленной задачи. Разработчик делает ровно то, что написано, а не то, что вы имели в виду. Разрыв между «имел в виду» и «написал» и есть источник срыва сроков, конфликтов и лишних затрат. Ниже — как этот разрыв закрывать.

Задача — это не «что сделать», а «зачем и как проверить»

Слабая постановка звучит так: «Сделай форму заявки на сайте». Сильная описывает три вещи: цель (зачем это бизнесу), поведение (что именно должно происходить) и критерий приёмки (как мы поймём, что готово).

Сравните. «Сделай форму заявки» против: «Нужна форма на странице услуги, чтобы менеджер получал лид в CRM за минуту. Поля: имя, телефон, комментарий. Телефон обязателен и валидируется. После отправки — заявка падает в Битрикс24 через вебхук и показывается экран "спасибо". Если CRM недоступна — заявка сохраняется и не теряется». Второй вариант почти невозможно понять неправильно.

Формула рабочей задачи

• Контекст — какую проблему решаем и для кого. Без этого разработчик не примет ни одного разумного решения на развилке.
• Ожидаемый результат — что пользователь увидит и сможет сделать. Описывайте поведение, а не техническую реализацию (её выбирает исполнитель).
• Граничные случаи — что делать при ошибке, пустых данных, недоступном сервисе, двойном клике. Именно здесь живёт 80% багов.
• Критерии приёмки — чек-лист, по которому вы примете работу. Если пункт нельзя проверить — это не критерий, а пожелание.

Пять ошибок, из-за которых вы получите не то

• Указываете решение вместо проблемы. «Добавь кнопку сюда» вместо «пользователь не находит, как оплатить». Вы отбираете у разработчика возможность предложить решение лучше вашего.
• Молчите про краевые случаи. Не сказали, что делать с дублями заявок, — получите дубли. Разработчик закрывает пробел так, как удобно ему.
• Смешиваете десять задач в одной. «Переделай личный кабинет» — это не задача, а проект. Дробите до атомарных единиц, каждую можно проверить отдельно.
• Не даёте доступов и данных. Задача без тестового аккаунта, ключей API и примеров реальных данных встанет на первом же шаге.
• Не фиксируете договорённости. Согласовали в устном созвоне — считайте, что не согласовали. Всё, что не в тексте задачи, будет понято по-разному.

Как формулировать критерии приёмки

Хороший критерий бинарен: либо выполнен, либо нет, без «более-менее». Плохо: «форма работает быстро». Хорошо: «заявка доходит в CRM менее чем за 3 секунды и при недоступности CRM показывает пользователю сообщение, а данные не теряются».

Удобный формат — сценарии «дано / когда / тогда»:

• Дано: пользователь на странице услуги.
• Когда: заполнил телефон и нажал «Отправить».
• Тогда: видит экран благодарности, а лид появляется в CRM с источником страницы.

Пять-семь таких сценариев на задачу закрывают большинство недопониманий и сразу становятся планом тестирования.

Про сроки, приоритет и «мелкие правки»

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

Отдельно про «пока делаешь, поправь ещё вот тут». Каждая такая правка на лету ломает оценку сроков и тестирование. Копите мелочи в отдельный список и отдавайте пакетом — это честнее и по деньгам, и по времени.

Мини-чек-лист перед отправкой задачи

• Понятно, зачем это бизнесу, а не только что сделать.
• Описано поведение и хотя бы 3 краевых случая.
• Есть проверяемые критерии приёмки.
• Приложены доступы, ключи, примеры данных, макет или референс.
• Задача атомарна — её можно принять целиком за один заход.
• Указан приоритет и реальный срок.

Итог

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