Как ставить задачи разработке: понятное ТЗ

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

Почему бизнес и разработка не понимают друг друга

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

Корень проблемы — разрыв в контексте. Вы знаете, зачем нужна функция и как ей будут пользоваться клиенты; разработчик видит только текст задачи. Ваша работа как постановщика — передать этот контекст, а не технические детали. Как именно писать код — забота исполнителя; что и зачем должно получиться — ваша.

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

Из чего состоит понятное ТЗ

Хорошее техническое задание не требует технического языка. Оно требует ясности. Что в нём должно быть:

• •Задача через результат. Что должно получиться с точки зрения пользователя, а не какую технологию применить. Не «прикрутите фильтр на React», а «клиент должен отобрать товары по цене и размеру».
• •Контекст и цель. Зачем это нужно, какую проблему решает, кто и как будет этим пользоваться. Без «зачем» исполнитель не примет верных мелких решений.
• •Сценарий использования. Как человек проходит путь шаг за шагом: зашёл, нажал, увидел, получил. Это снимает большинство недопониманий.
• •Ограничения. Что важно учесть: сроки, бюджет, связь с другими системами, чего делать нельзя.
• •Критерии приёмки. По каким признакам вы поймёте, что готово. Об этом — отдельно, это ключевой пункт.

Не обязательно оформлять это томом на 40 страниц. Для небольшой задачи хватит нескольких абзацев, где есть результат, цель и критерии приёмки. Важнее ясность, чем объём.

Критерии приёмки: как понять, что готово

Критерии приёмки — это заранее описанные условия, при которых вы считаете задачу выполненной. Без них приёмка превращается в спор «я имел в виду не это». С ними всё решено до начала работы.

Формулируйте критерии проверяемо, через конкретные факты:

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

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

Задача без критериев приёмки — это не задача, а пожелание. Разработчик сдаст то, что счёл готовым, а вы будете доказывать, что имели в виду другое. Договоритесь о «готово» до старта, а не после.

Как расставлять приоритеты

Когда всё «срочно и важно», не срочно и не важно ничего — исполнитель сам решит, что делать первым, и часто не угадает. Приоритеты — ваша ответственность, и их нужно проговаривать явно.

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

Коммуникация без технического языка

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

• •Говорите о проблеме, а не о решении. «Менеджеры тратят час на сверку» полезнее, чем «сделайте мне кнопку экспорта». Исполнитель предложит решение лучше вашего.
• •Задавайте вопросы, если не поняли. Не кивайте на непонятный ответ. «Объясните простыми словами, что это значит для клиента» — нормальный вопрос руководителя.
• •Договоритесь о точках проверки. Не пропадайте до дедлайна. Промежуточные демонстрации ловят расхождение рано, когда переделка дешёвая.
• •Фиксируйте договорённости письменно. Устное «договорились» через неделю каждый помнит по-своему. Короткое письмо после разговора экономит нервы.
• •Оставьте исполнителю пространство. Жёстко диктуя способ, вы теряете его экспертизу и берёте на себя ответственность за технические решения, в которых не разбираетесь.

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

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

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