Сцена, в которой узнают себя обе стороны. Заказчик пишет: «Нужно доработать корзину, чтобы было удобнее». Разработчик прикидывает свою версию «удобнее», называет цену, делает. Приносит — а в ответ: «Я имел в виду совсем другое». Начинаются переделки, которых никто не закладывал, и виноватым каждый считает другого. А ведь оба правы: слово «удобнее» каждый прочитал по-своему. Техническое задание ровно для этого и существует — это договор о том, что считается сделанной работой. Разберём, что включать в ТЗ, какие ошибки дороже всего и как описать задачу так, чтобы её нельзя было понять двояко.
Почему «сделайте красиво» стоит дорого
Представьте, что заказываете торт и говорите одно слово: «вкусный». Получите лотерею — может, шоколадный, а вы его не любите. Кондитер не виноват, виновата формулировка, допускающая тысячу прочтений. Слова «удобно», «современно», «как у конкурентов» — это не задание, а настроение, и расхождение всплывает в самый дорогой момент, на сдаче. Бьёт это по обеим сторонам: заказчик получает переделки вне сметы, исполнитель делает работу дважды бесплатно. Кстати, на этапе ТЗ часто всплывает и более крупный вопрос: когда раскладываешь задачу по пунктам, иногда видно, что правок так много и они так глубоко лезут в фундамент, что честнее обсудить, доработать сайт или переписать заново.
Что обязательно включить в техзадание
Хорошее ТЗ держится на нескольких опорах. Первая — что должно получиться: не пожелание, а конкретный результат («в каталоге появляется фильтр по цене и бренду, мгновенно пересобирающий список без перезагрузки»). Вторая — где именно: на каких страницах, для каких пользователей. Третья — как это ведёт себя в разных ситуациях, особенно неудачных: что показать, если под фильтр ничего не нашлось, что будет с телефона. Именно пограничные случаи забывают описать, а потом из-за них ругаются. Четвёртая — что считается готовым, критерий приёмки. И самое сильное дополнение к словам — примеры: скриншот, ссылка на похожий сайт. Один пример «вот так, как здесь» снимает больше недопониманий, чем три абзаца текста.
Как писать ТЗ, если вы не технарь
Частый страх: «я не программист, как я напишу ТЗ». Хорошая новость — код описывать не надо, и даже не нужно. Ваша зона — поведение и результат, а его вы знаете лучше любого разработчика. Не «прикрутите асинхронную отправку через API», а «когда человек отправил заявку, страница не должна перезагружаться, и он должен сразу увидеть, что заявка принята». Техническую часть исполнитель придумает сам — это его работа. Удобный приём — рассказывать сценариями: «клиент заходит, выбирает товар, кладёт в корзину, и тут должно...» Сценарий от лица пользователя сам вытаскивает на поверхность все ситуации, которые надо описать. И не бойтесь показаться наивным: чем проще и человечнее описана задача, тем меньше места для двойных толкований.
Как не дать задаче расползтись
Есть тихий убийца бюджетов — расползание задач. Работа идёт, и заказчику приходит мысль: «давайте заодно ещё вот это, это же мелочь». Потом ещё одна. Каждая крохотная, но вместе они удваивают объём и ломают сроки. Лекарство честное для обеих сторон: договориться на старте, что всё, чего не было в ТЗ, оформляется отдельной задачей с отдельной оценкой. Не «заодно», а «отдельно». Новые хотелки — это нормально, просто у каждой своя цена. Когда правок накапливается постоянно, это уже повод подумать про регулярную поддержку сайта. А готовность исполнителя спокойно фиксировать объём — хороший тест на адекватность; как выбрать надёжного, разбираем в материале про то, как выбрать исполнителя.
Как платформа помогает договориться без споров
На Где.Эксперт работу начинают с обсуждения задачи, и разработчик помогает превратить пожелания в понятное задание ещё до старта. Видны история исполнителя и отзывы — в том числе про то, насколько чисто человек держит договорённости. Объём и результат фиксируются заранее, новые задачи обсуждаются отдельно и прозрачно, а оплата идёт по факту выполнения. Отзывы прошлых клиентов показывают, кто доводит до результата без скандалов вокруг доделок.
Часто задаваемые вопросы
Зачем нужно ТЗ на доработку?
Это договор о том, что считается сделанным. Без него стороны держат в голове разные картинки результата, и это вскрывается спором на сдаче. ТЗ переводит ожидания в проверяемые пункты и фиксирует цену с объёмом.
Как описать задачу, если я не технарь?
Описывайте поведение и результат, а не код. Не «прикрутите AJAX», а «после отправки заявки страница не перезагружается». Техническую часть исполнитель переведёт сам.
Что делать с новыми хотелками в процессе?
Оформлять как отдельные задачи с отдельной оценкой, а не вкидывать в текущую как «мелочь заодно». Это спасает и бюджет, и отношения.
Заключение
Техническое задание — это не бумажка для солидности, а самый дешёвый способ не переплатить и не переделывать. Расплывчатые «удобно» и «современно» оборачиваются переделками за чужой счёт, а проверяемые формулировки и примеры убирают пространство для спора. Описывайте результат и поведение, а не код, рассказывайте сценариями и держите границу: всё, чего не было в задании, — отдельная задача с отдельной ценой. А составить понятное ТЗ проще вместе с исполнителем, который умеет переводить пожелания в технику и не боится фиксировать объём.
Найдите разработчика на Где.Эксперт — составьте задание вместе, зафиксируйте объём и платите по факту выполнения.