К разработчику Ибрагиму пришёл заказчик — нужен сайт для турагентства. Требования такие: чтобы было красиво, современно, как у конкурентов, но круче, ну и быстро, конечно.
Уже спустя неделю заказчик томно дышал в трубку Ибрагиму по ночам и спрашивал: «Почему ещё не готово?» Когда бедный разработчик показал макет, то выяснилось, что всё как-то некрасиво, несовременно, некруто и не похоже на конкурентов. Пришлось Ибрагиму переделывать. А потом ещё раз. И ещё. И ещё.
В итоге Ибрагим остался без денег, а заказчик без нормального сайта. А ведь можно было избежать боли, миллиарда созвонов и переделок — нужно было просто составить нормальное ТЗ.
Рассказываем, как сделать техническое задание, что включить в ТЗ и как заказчику и разработчику разговаривать на одном языке.
Содержание
Что такое техническое задание на разработку и зачем оно нужно
Почему задачи возвращаются на переделку
Как составить техническое задание: структура простого ТЗ
Что обсудить с разработчиком до начала работы
Как проверить, что ТЗ понятно и готово к работе
Что такое техническое задание на разработку и зачем оно нужно
Техническое задание на разработку — это документ или структурированное описание задачи, которое помогает заказчику и исполнителю одинаково понимать результат. И главное здесь не количество букв, а отсутствие двусмысленности.
Хорошее ТЗ говорит не «как красиво сделать?», а «что должно работать?»
Главная задача ТЗ — перевести бизнес-цели на язык конкретных функций, которые может сделать разработчик. Идите к исполнителю не с просьбой и хотелками, а с требованиями — понятными и конкретными.
❌ Пожелание: «Хочу удобный сайт». Максимально размытая просьба. Разработчик и заказчик понимают удобство по-разному.
✅ Требование: «Пользователь должен оставить заявку за три шага, получить подтверждение, а менеджер — уведомление в CRM».
Почему задачи возвращаются на переделку
Задачи отправляются на доработку не потому что программисты плохие. Всё дело в неправильном техническом задании — это как если бы разработчик говорил на китайском, а заказчик на языке жестов.
Разбираем, почему без нормального ТЗ — результат так себе.
Фразы, из-за которых разработчик почти наверняка поймёт вас не так
Одна неточная формулировка — и привет, двусмысленность, бесконечные переделки, правки и драки. Собрали топ стоп-фраз при общении с разработчиком.
💬«Сделайте красиво»
У каждого своё понимание красоты. Для дизайнера это минимализм, для программиста — аккуратный код. А для вас — может, вообще вырвиглазные цвета.
💬«Сделайте как у конкурентов»
Вы видите только внешнюю часть чужого сайта и не знаете, как устроена их база данных, какая CRM подключена и какие функции там работают некорректно.
💬«Нужно срочно»
Срочно — это через неделю, месяц, год? Если ТЗ без конкретной даты, то и результат будет тогда, не знаю, когда. А когда нужно было вообще вчера, разработчику придётся делать всё хоть как, лишь бы успеть до дедлайна. И, скорее всего, сайт полетит после первого же релиза.
💬«Там просто кнопку добавить»
А это вообще не просто. Чтобы сделать одну кнопочку, придётся создавать новую таблицу в базе данных, настраивать права доступа, интегрировать её с внешними сервисами. Короче, за пару минут не управиться, на эту кнопку нужно закладывать дополнительное время.
💬«Чтобы всё работало»
Для разработчика всё работает, когда код запускается без ошибок. А для компании — когда бизнес получает прибыль. Так что лучше сформулировать точнее, что вы хотите получить в итоге.
💬«Сделайте современно»
Та же история, что и с «красиво» — понятие максимально абстрактное и для каждого означает своё. Может, для разраба «современно» — это в стиле 2013 года, когда он последний раз следил за трендами. А реально инновационные приколы он считает зумерским баловством.
Как заменить расплывчатые формулировки конкретными
При чтении ТЗ у разраба не должно возникать вопроса «А что хотел сказать автор?» Для этого любые свои «хочу» превращайте в сценарий с конкретными требованиями.
❌ «Сделайте форму на сайте»
✅ «Форма должна содержать поля: имя, телефон, email, комментарий. После клика на „Отправить“ данные уходят в CRM Bitrix24, а пользователю на экране показывается сообщение: „Заявка успешно принята“».
Как составить техническое задание: структура простого ТЗ
Писать трактат на 100 страниц и описывать каждую букву и каждую кнопку не надо. Для большинства проектов достаточно простой, но чёткой структуры, где каждый блок отвечает за свой кусочек пазла.
Цель и контекст задачи
Разработчик должен знать не только что сделать, но и зачем. Он и без ТЗ вам сайт наклепает за ночь, только эта страница вряд ли решит проблемы компании.
А вот когда разработчик понимает контекст, бизнес-задачу и портрет пользователя, он уже не просто исполнитель, а технический партнёр. И может предложить более простое, дешёвое или технически правильное решение, о котором вы даже не задумывались.
Например, разрабу дают задачу: добавить ещё пять полей в форму регистрации. Хозяин — барин, разработчик всё добавляет. А потом выясняется, что цель бизнеса — собрать больше данных клиента для персонализации. Опытный разработчик бы подсказал, что перегруженная форма только снизит конверсию, а данные лучше собирать постепенно и внутри личного кабинета.
А чтобы тоже стать профи в своей сфере, присмотритесь к курсам — у нас как раз есть промокод со скидкой на любую профессию в Яндекс Практикуме
Пользовательский сценарий
Пользовательский сценарий — это пошаговое описание того, как человек будет пользоваться системой.
Представьте, что вы снимаете кино, где в главной роли — ваш клиент. Вам нужно подробно расписать каждый его шаг: куда он нажал, что увидел на экране и что произошло дальше.
Сценарий пишется по простой схеме: Кто? ➔ Что делает? ➔ В каком порядке? ➔ Как реагирует сайт?
Требования к функционалу
Зафиксируйте техническую изнанку проекта: какие элементы видит пользователь, как система реагирует на его ошибки, где сохраняются данные и какие уведомления отправляются.
Если сценарий описывает путь клиента снаружи, то требования к функционалу объясняют программисту, какие шестерёнки должны крутиться внутри.
Критерии готовности
Критерии готовности — это список условий, по которому происходит приёмка работы. Простыми словами — что должно быть сделано, чтобы уже жать руки и платить деньги.
Это чек-лист, где каждый пункт можно проверить простым тестом: функция либо работает по условию, либо нет. Если хотя бы один пункт не выполняется, готовый результат не принимают, а задачу отправляют на доработку.
Что не входит в задачу
Это список вещей, которые разработчик по договору делать не будет. Если его не зафиксировать, на этапе приёмки начнутся выяснения отношений и вопросы шекспировского масштаба: кто, кому и что должен?
Вы будете ждать готовый сайт с текстами и картинками, а программист отдаст пустой работающий шаблон. Дизайн и текст — уже не его проблемы, для них нужны отдельные люди и отдельные ТЗ.
Список того, что не входит в задачу, защищает обе стороны
Заказчик: чётко понимает, за что он платит, и какие ресурсы (копирайтеров, дизайнеров, маркетологов) нужно привлечь со стороны, чтобы проект заработал.
Исполнитель: не делает бесплатно миллион новых мелких задач, которые рождаются у заказчика.
Пример ТЗ на разработку
Не pov, а real — вам нужна форма для заявки на сайте. Показываем, как сделать ТЗ для разработчика по красоте. А если форма для заявки вам не нужна, всё равно почитайте — потом адаптируете шаблон под себя.
Пример ТЗ для формы заявки на сайте
Цель
Добавить на посадочную страницу всплывающую форму, на которой посетители смогут быстро оставить свои контакты. Главная бизнес-задача — собирать контакты потенциальных клиентов и автоматически передавать их в отдел продаж.
Сценарий пользователя
Поля формы
Валидация и обработка ошибок
Отправка данных и уведомления
Сообщение об успехе
После успешной отправки данных содержимое всплывающего окна плавно меняется без перезагрузки всей страницы. Пользователю выводится уведомление: «Спасибо за заявку! Наш менеджер свяжется с вами в течение десяти минут».
Критерии приёмки
Задача считается полностью готовой и принимается заказчиком, если:
Что НЕ входит в задачу
Как адаптировать образец под свою задачу
Просто скопировать шаблон впустую не выйдет. Придётся напрячься и адаптировать блоки под проект: заменить цель, сценарии, поля, интеграции, ограничения и критерии готовности.
Что обсудить с разработчиком до начала работы
Плохие новости для интровертов — даже если вы составили идеальное ТЗ, обсудить его с исполнителем вживую всё равно придётся. Перед стартом пройдитесь с разработчиком по каждому блоку: уточните спорные места, ограничения, технические риски, сроки и порядок приёмки.
Вопросы, которые стоит задать до старта
❓Что непонятно в задаче?
Если программист спотыкается на описании функции, значит, в тексте есть общие слова вместо конкретных метрик. Дешевле переписать пару абзацев ТЗ, чем платить за замену тысячи строк в коде после релиза.
❓Есть ли в проекте технические ограничения или скрытые риски?
Часто программист может предложить более изящное, дешёвое и простое решение. Или сразу объяснить, что платформа не потянет все ваши хотелки.
❓Какие данные или доступы вам нужны от меня для старта?
Чтобы разработчик не бегал к вам за доступом к каждому хостингу, коду, макету или документу, соберите их заранее.
❓Какие факторы могут повлиять на итоговый срок проекта?
Это поможет поставить реальную дату дедлайна и сразу узнать, что может помешать в неё уложиться. Часто задержки вообще не зависят от программиста. Например, проверка документов в банке для подключения онлайн-оплаты может занять пару недель. Так что если исполнитель называет срок в 30 дней, закладывайте на запуск 40 дней.
❓Как именно мы будем проверять и принимать готовый результат?
Чтобы всё твёрдо и чётко: по какому чек-листу пройдёт приёмка, сколько дней даётся на бесплатное исправление багов и когда уже можно оплачивать работу и обмывать новый сайт.
❓Что из наших обсуждений уже считается дополнительной работой?
Защитите себя от внезапных доплат. Если вы в процессе созвона решили добавить маленькую галочку, уточните, входит ли она в текущий бюджет или на неё вы составите отдельное мини-ТЗ.
Как проверить, что ТЗ понятно и готово к работе
Перед тем как отдать ТЗ разработчикам, проверьте его на независимом читателе. Например, покажите текст коллеге или вообще любому человеку, который никак не связан с проектом. Если всё сделано правильно, то читатель должен ответить на четыре вопроса:
- Что нужно сделать?
- Где проходят границы задачи?
- Как проверить готовый результат?
- Какие вопросы остались?
Чек-лист хорошего ТЗ
Когда ТЗ лучше переписать до старта
Всё фигня, давай по новой, когда:
Много абстрактных слов: удобно, красиво, быстро, современный интерфейс. Как сказал бы научник: слишком много воды, убирай.
Результат невозможно проверить. Если из ТЗ непонятно, как именно будет проходить приёмка готового продукта, проект обречён на бесконечные споры. Разработчик просто подключит систему, как ему удобно, а вы не сможете доказать, что всё не так. В документе-то критериев не было.
❌ «Сделать удобную интеграцию сайта с CRM-системой».
✅ «Задача считается выполненной, если после заполнения формы на сайте в AmoCRM мгновенно создаётся новая сделка. В карточку сделки должны без ошибок передаваться три поля: имя, телефон и выбранная услуга».
Неясно, что делать при ошибках. Если ТЗ только про идеальный путь идеального пользователя — оно плохое. Представьте себе самого тугодумного человека на свете: он вводит данные не туда, у него тупит интернет, он создаёт по пять заявок в минуту. Вот такого пользователя обязательно нужно учитывать, и все возможные ошибки на сайте тоже.
Не описаны ограничения. Если в ТЗ нет технических рамок (какие браузеры поддерживать, под какие экраны верстать, какую нагрузку должен держать сервер), продукт сломается при первой же реальной проверке.
Нет примеров и аналогов. Если сложные элементы логики или интерфейса вы описали только текстом без скриншотов, ссылок на похожие решения или прототипов, то разработчик может не понять ваших гениальных задумок. И сделать всё на свой вкус.
ТЗ — не очередная фигня для галочки. Да, бесконечно лень поминутно расписывать, кто, что и где должен сделать. Но лучше так, чем миллион созвонов, переделок и драк с разработчиком. Хотя их отсутствие даже с идеальным ТЗ гарантировать всё же не можем. Но их точно будет меньше.
