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