Примеры ТЗ для программиста: как ставить задачи и принимать работу

Большое ТЗ пишут один раз — на старте проекта. Дальше сайт живёт в режиме доработок и поддержки: поправить форму, добавить поле в карточку товара, починить выгрузку, ускорить каталог. Таких задач десятки в месяц, и именно на них заказчик теряет больше всего денег: программист сделал «не то», задачу переделывали трижды, часы списаны, а результата нет. Ниже — практика для владельца бизнеса или менеджера без технического бэкграунда: как коротко и точно поставить задачу программисту, какие примеры ТЗ для программиста считать хорошими, как проверить оценку и принять работу.

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

Почему задачи программисту выполняют «не так»

Программист выполняет не то, что вы имели в виду, а то, что написано. Всё, что не написано, он додумывает — и додумывает с позиции разработчика: как проще, быстрее или «правильнее» с точки зрения кода. Отсюда три типовых сценария потерь:

• Непонятно, что считать готовым. «Сделайте форму заявки» — форма появилась, но заявки не приходят в CRM, нет согласия на обработку персональных данных, на телефоне кнопка уехала за экран.
• Непонятно, зачем это нужно. Программист решает задачу буквально, хотя знал бы цель — предложил бы решение в два раза дешевле.
• Непонятно, где и как воспроизвести. «Сайт глючит» — первые два часа уходят на поиск проблемы, которую вы видели за 10 секунд.

Хорошая новость: чтобы ставить задачи правильно, не нужно разбираться в коде. Нужно описывать бизнес-результат и способ его проверить. Как именно сделать — зона ответственности исполнителя.

Анатомия хорошей задачи: шаблон из 7 полей

Любую задачу на доработку можно уложить в семь блоков. Не все обязательны для мелочи, но для задачи дольше пары часов пропускать их не стоит.

Шаблон для копирования в трекер:

1. Сейчас: что происходит и где (URL).
2. Нужно: что должно происходить после доработки.
3. Зачем: какую бизнес-проблему решаем.
4. Готово, когда: 3–7 пунктов, которые можно проверить глазами.
5. Не входит в задачу: что сознательно не трогаем (снимает споры на приёмке).
6. Проверить на: тестовые страницы, логины, товары.
7. Приоритет / срок: и причина срока.
8. Вложения: скриншоты, макеты, выгрузки.

Примеры ТЗ для программиста: плохо и хорошо

Шесть учебных примеров типовых задач на доработку сайта. Слева — как их обычно пишут, справа — как стоит.

1. Ошибка на сайте

Плохо: «Не работает корзина, срочно!»

Хорошо: «На странице /cart/ при нажатии «Оформить заказ» ничего не происходит. Воспроизводится в Chrome на Android и в Safari на iPhone, на ПК работает. Началось после вчерашнего обновления каталога. Готово, когда заказ оформляется на всех трёх устройствах и падает в CRM. Скриншот и запись экрана — во вложении».

2. Новая форма

Плохо: «Добавить форму обратного звонка».

Хорошо: «На всех страницах услуг добавить кнопку «Перезвоните мне» → всплывающая форма: имя, телефон (маска +7), галочка согласия на обработку персональных данных со ссылкой на политику. Заявка уходит в CRM в воронку «Звонки» с пометкой страницы-источника и UTM-метками, плюс письмо на sales@. Готово, когда тестовая заявка видна в CRM с источником. Капча — Яндекс SmartCaptcha, невидимая».

3. Изменение в карточке товара

Плохо: «Сделать нормальные характеристики в товарах».

Хорошо: «В карточке товара характеристики сейчас выводятся одной строкой через запятую. Нужно — таблицей в два столбца, первые 6 строк видны сразу, остальные под «Показать все». Данные уже есть в свойствах товара, новые поля не нужны. Проверить на арт. 1024 (30 характеристик) и 3001 (3 характеристики)».

4. Интеграция

Плохо: «Подключить сайт к 1С».

Хорошо: «Нужен автоматический обмен остатками и ценами из 1С:УТ 11 на сайт раз в час. Заказы с сайта должны попадать в 1С как документ «Заказ клиента». Номенклатура сопоставляется по артикулу. Доступ к тестовой базе 1С даст наш программист 1С (контакт во вложении). Готово, когда изменение цены в 1С отображается на сайте не позже чем через час, а тестовый заказ появился в 1С со всеми позициями». Такие задачи редко бывают «на пару часов» — сначала попросите оценку и план, подробнее про интеграции сайта с учётными системами.

5. Ускорение сайта

Плохо: «Сайт тормозит, ускорьте».

Хорошо: «Каталог /catalog/ открывается 6–8 секунд, особенно с фильтрами. PageSpeed для мобильных — 28 баллов (отчёт во вложении). Цель: страница каталога загружается быстрее 2,5 секунды на мобильном 4G, остальной функционал не меняется. Сначала нужен аудит: причины и оценка по каждому пункту, потом решим, что делать».

6. Выгрузка данных

Плохо: «Сделать выгрузку заказов в Excel».

Хорошо: «В админке нужна кнопка выгрузки заказов за выбранный период в XLSX. Колонки: номер, дата, клиент, телефон, сумма, способ оплаты, статус, источник (UTM). Одна строка — один заказ. Доступ — только у ролей «Администратор» и «Бухгалтер». Пример нужного файла во вложении».

Как описать баг: шаги воспроизведения и пример баг-репорта

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

• Где: точный URL, а не «на главной».
• Шаги воспроизведения: что вы нажимали по порядку.
• Ожидаемый результат и фактический результат.
• Окружение: устройство, ОС, браузер, авторизован ли пользователь.
• Когда началось и повторяется ли всегда или иногда.
• Доказательства: скриншот, запись экрана, текст ошибки.

Пример баг-репорта:

Заголовок: Не применяется промокод в корзине для авторизованных пользователей.
URL: site.ru/cart/
Шаги: 1) войти под тестовым аккаунтом; 2) добавить в корзину любой товар; 3) ввести промокод AUTUMN10; 4) нажать «Применить».
Ожидается: скидка 10%, новая сумма.
Фактически: сообщение «Промокод недействителен», сумма не меняется. Без авторизации работает.
Окружение: Windows 11, Chrome (актуальная версия); также iPhone, Safari.
Частота: всегда, с 17 сентября.
Вложения: запись экрана 20 секунд.

Запись экрана делается встроенными средствами: на Windows — Win+Alt+R (Xbox Game Bar) или «Ножницы», на macOS — Shift+Cmd+5, на телефоне — кнопка записи в шторке уведомлений. Если на странице появляется красное сообщение или белый экран — сфотографируйте его целиком: текст ошибки часто сразу указывает на причину.

Оценка задачи: как проверить часы и сроки

Прежде чем задача уйдёт в работу, попросите оценку. На поддержке и доработках чаще всего работают почасово — в студиях час разработчика обычно стоит от 2 500 ₽, но итог зависит от стека, квалификации и срочности. Отдельно о том, как устроена такая модель оплаты и где в ней риски, — в статье Fixed price или Time & Material.

Нормальная оценка выглядит так:

• Вилка, а не точка: «4–6 часов» честнее, чем «5 часов». Широкая вилка (например, «8–40 часов») — сигнал, что задача непонятна и сначала нужен анализ.
• Разбивка: для задач крупнее 8 часов — по этапам: анализ, разработка, тестирование, выкладка.
• Допущения: «при условии, что API 1С отдаёт остатки», «без изменения дизайна».
• Срок: когда начнут и когда закончат, с учётом очереди.

Что спросить, если оценка кажется завышенной или заниженной:

1. Из чего складывается оценка — какие этапы самые трудоёмкие?
2. Есть ли более простой вариант, который решает ту же бизнес-задачу?
3. Что может пойти не так и увеличить время?
4. Входит ли в оценку тестирование и выкладка на рабочий сайт?
5. Что будет, если в процессе станет понятно, что нужно больше времени?

Подозрительная оценка — не всегда накрутка. Слишком низкая часто означает, что исполнитель не понял задачу. Сравнивайте факт с оценкой на дистанции в 10–20 задач: если похожие по сложности задачи стабильно выходят вдвое дороже оценки, это повод для разговора.

Как принимать работу у программиста

Приёмка — это проверка по критериям готовности из задачи, а не «вроде работает». Порядок такой:

1. Проверка на тестовой копии. Доработки делают на копии сайта (dev- или stage-сервере), а не на живом. Вы проверяете там, и только после вашего «ок» изменения переносят на рабочий сайт.
2. Проход по чек-листу критериев. Каждый пункт «Готово, когда» — отмечаете да/нет.
3. Проверка на устройствах. Минимум: ПК, телефон на Android, iPhone. Большинство возвратов задач — из-за мобильной версии.
4. Проверка соседнего функционала. Не сломалось ли рядом: форма, корзина, поиск, меню.
5. Проверка после выкладки. Повторите ключевые шаги на рабочем сайте — окружение там отличается.

Если что-то не так, возвращайте задачу с той же структурой, что баг-репорт: что проверяли, что ожидали, что получили. «Не то» без пояснений гарантирует ещё один круг.

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

Трекер задач и коммуникация

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

Какой трекер выбрать — вопрос вкуса и того, в чём уже работает подрядчик: Яндекс Трекер, Kaiten, YouGile или другой. Важнее не инструмент, а правила:

• одна задача — одна карточка, без «и ещё заодно поправьте…» в комментариях;
• у каждой задачи есть исполнитель, приоритет и срок;
• у заказчика есть доступ к трекеру и видны часы по каждой задаче;
• вопросы и ответы по задаче — в комментариях к ней, а не в личной переписке.

Статусы и ритм работы

Минимальный набор статусов: «Новая» → «Оценка» → «Согласована» → «В работе» → «На проверке» → «Готово». Задачу в «Готово» переводит заказчик после приёмки, а не исполнитель после выкладки.

Ритм: при потоке задач — короткий созвон или письменный статус раз в неделю, демонстрация сделанного на тестовой копии раз в одну-две недели. Ежемесячно — отчёт: задачи, часы, отклонения от оценок. Если работаете по абонементу, объём и время реакции удобно зафиксировать в соглашении об уровне сервиса (SLA). На регулярной поддержке сайта такой ритм обычно прописан заранее.

Приоритеты: как не превращать всё в «срочно»

Когда всё срочно, ничего не срочно: исполнитель переключается между задачами, каждое переключение стоит времени, а действительно важное тонет в потоке. Договоритесь о простой шкале.

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

Типичные ошибки заказчика при постановке задач

• Задача голосом или в мессенджере. Через неделю никто не помнит, о чём договорились.
• Пять задач в одной. Невозможно оценить, принять по частям и понять, на что ушли часы.
• Решение вместо проблемы. «Поставьте плагин X» вместо «страница грузится 7 секунд».
• Нет критериев готовности. Приёмка превращается в спор о вкусах.
• Меняются требования по ходу. Новое требование — новая задача или новая оценка, а не комментарий «а ещё сделайте…».
• Задачу ставят несколько человек. Маркетолог просит одно, директор — другое. Нужен один ответственный со стороны заказчика.
• Нет обратной связи. Задача неделю висит «На проверке» — исполнитель переключился, контекст потерян.
• Приёмка без проверки на телефоне. Возвраты с мобильной версии — самые частые.

Если задач много и они требуют работы с чужим или устаревшим кодом, разумно отдать их команде, которая регулярно ведёт доработку сайтов и работает по описанному процессу: тестовая копия, оценка до старта, отчёт по часам.

Чек-лист: задача готова к передаче программисту

• Указан URL и описано, что происходит сейчас
• Описано, что должно происходить после доработки, глазами пользователя
• Написано, зачем это бизнесу
• Есть 3–7 проверяемых критериев готовности
• Указано, что в задачу не входит
• Для бага — шаги воспроизведения, устройство, браузер, запись экрана
• Приложены скриншоты, макеты или примеры
• Выставлены приоритет и срок с причиной срока
• Получена оценка вилкой и согласована до старта
• Договорён порог превышения оценки
• Проверка — на тестовой копии, на ПК и двух телефонах
• Задача закрывается заказчиком после приёмки по критериям

Итог

Чтобы контролировать разработку без технического бэкграунда, не нужно читать код. Достаточно трёх вещей: описывать результат и способ его проверить, получать оценку до начала работ и принимать задачи по критериям на тестовой копии. Шаблон из семи полей занимает 5–10 минут на задачу и возвращает часы, которые иначе ушли бы на переделки и переписку.