«Сделайте красиво» — примерно так звучит половина задач, которые получает программист. И половина проблем на проекте начинается именно отсюда. Не потому что разработчик плохой, а потому что «красиво» у каждого своё, а «как у конкурентов, но лучше» вообще невозможно измерить. В итоге работа переделывается по кругу, сроки уезжают, а обе стороны раздражены.
Хорошая новость: поставить задачу — это навык, и ему легко научиться. Достаточно знать, что именно важно донести, и в каком виде.
Опишите, что должно происходить
Задача — это не про то, «как выглядит кнопка», а про то, «что происходит, когда на неё нажимают». Начните с описания сценария: посетитель открывает страницу, заполняет форму, получает письмо, заявка попадает в CRM. Чем конкретнее сценарий, тем меньше вопросов у исполнителя.
Плохо: «Нужна форма заявки на главной». Хорошо: «Форма на главной с полями имя, телефон и комментарий. После отправки человек видит сообщение «Спасибо, мы свяжемся в течение часа». Заявка приходит на почту и в Telegram». Разница очевидна.
Один запрос — одна задача
Частая ошибка — свалить всё в одно сообщение: «Поменяйте цвет кнопки, добавьте страницу с отзывами, поправьте меню на телефоне и почему-то не работает поиск». Программист берётся за первое, забывает про третье, а четвёртое вообще не воспроизводится. И никто не виноват.
Разбейте список на отдельные пункты. Каждый пункт — отдельная задача со своим описанием, сроком и приоритетом. Так и работать проще, и проверять результат понятнее: закрыли пункт — вычеркнули.
Что уже есть и что должно получиться
Перед постановкой задачи полезно ответить на два вопроса. Первый: как это работает сейчас? Второй: как должно работать после? Если задача новая, второго вопроса достаточно, но добавьте контекст — зачем это вообще нужно.
Например: «Сейчас заявки приходят только на почту, и мы их иногда теряем. Нужно, чтобы они дублировались в Telegram и там была отдельная ветка для каждой услуги». Здесь видно и проблему, и решение — разработчику не нужно угадывать.
Ссылки и примеры вместо описаний
Когда дело касается внешнего вида, слова почти бесполезны. «Сделайте современно» — это ни о чём. Покажите пример: сайт, который вам нравится, скриншот, референс. И обязательно скажите, что именно в нём нравится: расположение блоков, цвет, шрифт, поведение при прокрутке.
Так же и с поведением: если что-то должно работать «как в приложении банка», дайте ссылку и уточните, какой именно сценарий вы имеете в виду. Иначе программист посмотрит на одно, а вы имели в виду совсем другое.
Скриншоты и запись экрана
Если речь про ошибку, лучшее описание — это видео. Запишите, как вы открываете сайт, что нажимаете, и в какой момент что-то идёт не так. Пара минут записи часто заменяет полстраницы текста и несколько уточняющих вопросов.
Скриншот тоже хорош, но только если на нём видно, где именно проблема. Обведите место стрелкой или рамкой — не заставляйте разработчика угадывать.
Где и на чём воспроизводится
Ошибка может быть только на телефоне или только в Safari. Указывайте устройство, браузер и версию, если знаете. Это экономит время на поиск проблемы, которое иначе уходит на попытки воспроизвести её у себя.
С полезными задачами та же история: если изменение касается мобильной версии, так и напишите. Иначе разработчик проверит на компьютере, увидит, что всё работает, и закроет задачу.
Приоритет и сроки
Не все задачи одинаково важны. Скажите прямо, что нужно срочно, а что может подождать. Иначе разработчик возьмётся за то, что первым попалось на глаза, а критичное зависнет.
Сроки лучше обсуждать, а не ставить. «Нужно вчера» — это не срок, а эмоция. «Хотим к пятнице, потому что запускаем рекламу» — уже понятная причина, и разработчик сможет предложить, что успеет сделать, а что нет.
Что считается готовым результатом
Задача закрывается, когда выполнено то, о чём договорились. Поэтому критерии готовности лучше озвучить заранее. Например: «Кнопка есть на всех страницах, ведёт на форму, на телефоне отображается внизу экрана». Всё, что соответствует — готово. Что не соответствует — не готово.
Так не возникает споров в стиле «я думал, ты имел в виду другое». И у программиста есть чёткая точка, когда можно остановиться.
Обратная связь после выполнения
Получили результат — проверьте его и напишите конкретно, что не так. «Не работает» — плохая обратная связь. «При отправке формы пишет ошибку 500, вот скриншот» — хорошая. Уточняйте, а не критикуйте: программист не видит ваш экран и не знает, что именно пошло не так.
И не забывайте говорить, когда всё сделано хорошо. Это банально, но правда помогает работать дальше.
Красные флаги в постановке задач
- «Сделайте красиво» без примеров и уточнений.
- Десять разных правок в одном сообщении.
- Нет ссылок, скриншотов и описания сценария.
- Все задачи «срочные» и «на вчера».
- Нет критериев готовности — каждый понимает по-своему.
- Обратная связь ограничивается фразой «не работает».
- Задачи приходят в мессенджер и теряются в переписке.
Один пункт — не катастрофа. Но если так происходит постоянно, проект движется медленно и все устают.
Что в итоге
Поставить задачу программисту — это значит описать сценарий, показать примеры, уточнить контекст и договориться, что считать результатом. Хорошая задача не требует уточняющих вопросов: разработчик читает её и понимает, что делать. А вы получаете результат, который совпадает с ожиданиями — с первого раза, а не с пятого.
Если задачи ставите вы, а исполняете вы же — это тоже навык. Мы в своей работе всегда начинаем с уточняющих вопросов и не берёмся за «сделайте красиво». Нам важно понять сценарий, увидеть примеры и договориться о критериях готовности, чтобы результат совпал с ожиданиями. Если у вас есть проект и вы не уверены, как правильно его описать, — напишите или оставьте заявку. Поможем разложить задачу по полочкам и предложим решение, которое не придётся переделывать. Расскажите о своей задаче, и мы подскажем, с чего начать.