Плохое ТЗ дорого обходится обеим сторонам. Заказчик получает разброс оценок от «за неделю» до «за три месяца», исполнитель тратит время на созвоны, которые ни к чему не приводят.

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

Структура ТЗ на разработку: 7 пунктов

1. Контекст. Кто вы и зачем это бизнесу. Два-три предложения. «Интернет-магазин, хотим сократить ручную обработку заказов» говорит исполнителю больше, чем страница требований.

2. Результат. Что должно работать по итогу. Формулируйте через поведение: «менеджер видит новые заказы в CRM без ручного переноса».

3. Что уже есть. Стек, доступы, ограничения, ссылки. Исполнитель должен понимать, во что встраивается работа.

4. Границы. Что не входит в задачу. Этот пункт пропускают чаще всего — и именно он потом становится предметом спора.

5. Критерии приёмки. Как вы поймёте, что задача выполнена. Чем конкретнее, тем спокойнее сдача.

6. Этапы и сроки. Даже небольшую задачу полезно разбить на 2–3 проверяемые части.

7. Бюджет или вилка. Ориентир помогает исполнителю предложить решение под ваши деньги, а не идеальное и невыполнимое.

Как проверить ТЗ перед публикацией

Перечитайте текст глазами исполнителя, который ничего не знает о вашем бизнесе:

— понятно ли, зачем нужна задача; — можно ли по тексту оценить объём работы; — ясно ли, что в задачу не входит; — понятно ли, как будет проходить приёмка.

Если хотя бы на один вопрос ответ «нет», оценки исполнителей разойдутся, а созвонов станет больше.

ТЗ для вакансии: та же логика

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

Почему я сделал ИИ-архитектора

Признаюсь, сам я долго держал ТЗ «в голове» и удивлялся, почему исполнители понимают меня по-разному. Поэтому в xChangePro я сделал ИИ-архитектора: он задаёт уточняющие вопросы по этим пунктам и помогает собрать черновик брифа. Решения он не принимает — он помогает не забыть важное.

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

Какой пункт из списка в ваших ТЗ чаще всего остаётся пустым? Напишите номер в комментариях.

#ТЗ #техническоезадание #фриланс #найм #управлениепроектами