Постановка задачи программисту. Как ставить задачу разработчику

Время чтения - 6 мин.

Дата публикации 15.12.2023 (обновлено 14.05.2026)

Постановка задачи программисту. Как ставить задачу разработчику

Введение: Почему программист не «слышит» вашу задачу?

Представьте: вы просите разработчика «сделать кнопку красивее». Через день получаете результат — кнопка стала ярко-розовой и мигает. Вы в ярости, программист в недоумении. Знакомо?

Я разработчик и каждый день вижу такие ситуации. Проблема не в лени или глупости программиста, а в том, как сформулирована задача. Мозг разработчика — это машина для обработки конкретных инструкций. Если на входе — «сделай, чтобы работало как надо», на выходе будет хаос.

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

Как думает программист?

Вот типичный алгоритм, по которому работает разработчик, получая задачу:

Анализ: Ищет «белые пятна» — то, что не описано. Если находит — задаёт вопросы.
Моделирование: Мысленно проигрывает сценарий: «Если пользователь нажмёт сюда, то...». Если логика рвётся — снова вопросы.
Подготовка: Создаёт структуру данных (базу данных, переменные). Это как заложить фундамент.
Реализация: Пишет код.
Тестирование: Проверяет по вашей постановке.
Сдача: Заливает код в репозиторий.

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

Как ставить задачу: 7 железных правил

1. Только «Что сделать?»

Задача должна звучать как приказ: «Сменить телефон на странице контактов». Никаких «наверное», «может быть», «я думаю».

Плохо: «А можете поправить наш телефон на странице контактов? Он вроде бы старый».

Хорошо: «Заменить номер телефона с +7 (111) 111-11-11 на +7 (222) 222-22-22 на странице https://site.ru/contacts».

Чем суше и конкретнее текст, тем меньше вопросов.

2. Детали окружения — ваша страховка

Всегда указывайте:

URL страницы
Логин пользователя (или роль)
Скриншот с пометками

Пример из жизни: Однажды менеджер написал: «Поправьте цены в каталоге». Программист полез в код, искал, где хранятся цены, потратил 2 часа. Оказалось, нужно было просто заменить число в админке на странице https://site.ru/admin/prices. Скрин бы сэкономил кучу времени.

3. Опишите весь путь пользователя

Не просто «нажать кнопку», а что происходит до и после:

Что видит пользователь?
Что происходит, если товара нет в наличии?
Что делать, если пользователь не авторизован?

Помните: если вы не описали ветку «товар закончился», программист сделает так, чтобы кнопка просто не работала. Это проще. А вам нужно, чтобы показывалось сообщение «Товара нет, но мы привезём через 3 дня».

4. Говорите на языке разработчика

Если в проекте есть согласованная терминология — используйте её. «Заявка» — это заявка, а не «проект», «заказ» или «запись». Путаница в терминах ведёт к ошибкам в коде.

5. Не забывайте про служебные действия

Кроме основной функции, пропишите:

Логирование: Какие данные записывать в лог?
Уведомления: Кого и о чём оповестить?
Проверки: Какие поля обязательны? Какой формат телефона?
Доступ: Кто может выполнять операцию?

6. Объясните «зачем» (но кратко)

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

7. Уберите воду

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

Типы задач: что важно для каждого

Ошибка (баг)

Главное — дать возможность воспроизвести. Лучший способ: видеоскрин с URL, временем, логином и консолью браузера (F12 → Console). Укажите, что должно было произойти.

Пример: «При нажатии на кнопку "Оплатить" на странице https://site.ru/cart вылетает ошибка "500". Ожидал, что откроется форма оплаты. Логин: test@test.ru».

Новая возможность

Используйте все правила выше. Добавьте скриншот с пометками — это снижает количество вопросов на 80%.

Оптимизация/доработка внешнего вида

Лучше всего — скриншот экрана со стрелками и текстом: «Вот эту кнопку сделать синей, а этот текст выровнять по левому краю». Текстовые описания без картинок — худший вариант.

Шаблон идеальной задачи

Название: «Сделать: [что именно]» (директивно).
Окружение: URL, роль/логин.
Как должно работать: Пошагово.
Служебные действия: Логи, уведомления, проверки.
Ограничения: Что делать в нештатных ситуациях.
Контекст: Зачем это нужно (1-2 строки).
Бонус: Скриншот с пометками.

FAQ: Частые вопросы

Что делать, если задача сложная и я не знаю всех деталей?

Опишите то, что знаете точно. Остальное — вынесите в отдельный раздел «Требуется уточнить». Программист сам задаст вопросы, но у него будет база для начала работы.

Как быть, если нужно срочно, а писать некогда?

Запишите видеоскрин на 30 секунд, где показываете проблему и говорите, что нужно сделать. Это быстрее, чем писать текст, и точнее.

Почему программист не может сам додумать очевидные вещи?

Потому что «очевидное» для вас может быть неочевидным для него. Например, для вас «кнопка должна быть красивой» — это синяя и круглая. Для программиста — это 20 вариантов реализации. Он выберет тот, который проще, а не тот, который вам нравится.

Как проверять результат?

По той же постановке. Если задача чёткая — проверку можно делегировать тестировщику или даже другому разработчику.

Заключение: выгода для вас

Хорошая постановка задачи — это не трата времени, а инвестиция. Она даёт:

Скорость: Задачи делаются в 2-3 раза быстрее.
Качество: Меньше переделок и ошибок.
Экономию нервов: Никаких бесконечных уточнений.
Документацию: Чёткие задачи можно использовать как основу для описания проекта.

Начните с малого — добавьте к следующей задаче скриншот с пометками. Увидите разницу.

Читайте также:

Теги продукт-менеджер (52)