Тендеры и лиды
Информация
Ни один подрядчик не знает ваш бизнес лучше вас. Поэтому техническое задание – это не формальность и не документ, который можно делегировать и забыть, а важный этап совместной работы и отличная возможность на берегу оценить подрядчика и его подходы.
Если подойти к ТЗ внимательно, разработка становится управляемой и предсказуемой, а вот размытые формулировки, недосказанность и спорные ожидания почти гарантированно приведут к правкам, доработкам и появлению дополнительных этапов, которые легко раздувают бюджет в полтора-два раза.
Стоимость разработки растёт, потому что резко увеличивается:
Самый дорогой сценарий всегда один и тот же: требования уточняются уже после того, как решение построено. В этой статье пошагово разберём все нюансы, которые нужно учитывать при составлении ТЗ.
Фраза «хочу как у конкурента, только лучше» не является требованием. В ней нет критериев, которые можно проверить.
Как правильно? Разберите «как у них» на конкретику: какие сценарии, какие экраны, какие ограничения, какие показатели важны. И обязательно добавьте, что именно должно стать «лучше», и как это измеряется.
Если в ТЗ нет ответа на вопрос «зачем», команда будет оптимизировать «чтобы работало», а не «чтобы приносило результат». Затем начинается бесконечное «давайте ещё добавим…», потому что непонятно, что уже достаточно.
Как правильно? Укажите цели и 3-7 метрик. Подробнее про бизнес-метрики читайте в нашей предыдущей статье Как заказать разработку сайта или цифрового сервиса в 2026 году и получить бизнес-результат
Когда в одном списке стоят «личный кабинет» и «тёмная тема», при планировании всё выглядит одинаково важным. Итог: расползание сроков, а бизнес-результат отодвигается.
Как правильно? Разделите на Must, Should, Could. И отдельно сформулируйте MVP: что должно заработать в первой версии, чтобы приносить пользу.
В ТЗ часто подробно описываются страницы, но не то, что человек на них должен сделать. Из-за этого получаются красивые экраны, на которых сложно выполнить задачу, которой заказчик сайта ожидает от пользователя.
Как правильно? Добавьте 5-15 ключевых сценариев в формате «кто → что должен сделать → какие шаги → что считаем успехом». Этого уже достаточно, чтобы продуктовые решения были осознанными.
Опасная формулировка для подрядчика в ТЗ «Сделайте сайт под ключ». Разработка не отвечает за привлечение к вам на сайт лидов или продвижение в поисковых сервисах. UX/UI-дизайнер не создаёт контент для наполнения страниц, макеты которых он собрал.
Как правильно? Прямо напишите, что должно по вашему мнению входить в список работ. Если нет понимания, кто за что отвечает – напишите все виды задач и попросите подрядчика оценить, что из этого он может закрыть полностью, что, например, получится сделать силами проверенных партнёров. Также оцените свои силы: кто в вашей компании может генерировать контент для сайта, есть ли у вас CRM, в которую будут падать заявки из форм, проводились ли SEO-работы по сайту, собиралась ли семантика или этот процесс нужно будет строить с нуля.
«Быстро», «удобно», «современно», «безопасно» звучит приятно, но очень субъективно. Быстро для кого, удобно по сравнению с чем, современно – это как, безопасно для чего?
Как правильно? Замените словами с цифрами и правилами. Примеры:
Интеграции могут «съесть» половину бюджета. Особенно если в ТЗ нет списка систем, типов данных и правил синхронизации.
Как правильно? Пропишите для каждой интеграции: что интегрируем, в какую сторону идут данные, какие статусы и ошибки возможны, как выглядит ручной режим, кто владелец доступа и ключей.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13590 тендеров
проведено за восемь лет работы нашего сайта.
«Контент потом» почти всегда означает, что релиз сдвинется. Поэтому его наличие или отсутствие влияет на сайт сильнее, чем кажется. Он определяет структуру, логику экранов, сложность разработки и даже то, насколько сайт потом будет продавать. Когда контента нет, команда вынуждена делать предположения и закладывать запас по часам. Это почти всегда дороже и дольше.
Как правильно? Опишите источники контента, объём, формат, ответственных. Если есть перенос со старого сайта, добавьте план миграции и что будет переноситься автоматом, а что вручную.
Что является контентом для сайта и к чему нужно быть готовым заказчику – расскажем в наших следующих статьях.
Изменения в разработке – это любые правки к договорённостям после того, как вы их уже зафиксировали и команда начала работу. Даже если фраза звучит безобидно – вроде «Добавим одну кнопку», для команды это часто цепочка действий из дизайн-работ, логики, работы с данными, а иногда их миграции, тестирования и обновления интеграций.
Как правильно? Зафиксируйте процесс change request. Что считается изменением, как оценивается влияние на сроки и бюджет, кто утверждает, как обновляется бэклог и спецификация. Также очень важно прописать в ТЗ всех, кто может инициировать изменения в проект, и в каком виде, в какой итерации.
Иногда ТЗ пишет только заказчик, иногда только подрядчик. И в обоих случаях есть риск перекоса: либо слишком абстрактно, либо слишком технически.
Как правильно? Лучший вариант – совместная работа. Бизнес описывает цели, ограничения, процессы и приоритеты. Команда разработки помогает формализовать, задаёт вопросы, выявляет риски, предлагает план релизов и архитектурные решения.
Не нужно делать 80 страниц ради объёма. Нужно закрыть ключевые вопросы. Если коротко, хорошее ТЗ обычно включает:
Если у Вас есть только часть из этого, можно стартовать с предпроектного этапа и вместе с командой разработки довести документ до рабочего.
На практике чаще всего участвуют несколько ролей:
Если Вы небольшая команда без аналитика – не страшно. Важно, чтобы у требований был владелец, и чтобы они были фиксированы в одном месте, а не потерялись в чатах. Если вы понимаете, что хотели бы обсудить ТЗ по вашему проекту – напишите нам, ответим на все ваши вопросы и поможем разобраться со всеми тонкими местами вашего будущего или текущего сервиса.
Ниже практичный подход, который можно взять за основу тем, кто не знает, с чего начать при составлении ТЗ на разработку сайта или сервиса.
Запишите 1-2 абзаца: какую бизнес-проблему решаем и что станет лучше через 1-3 месяца после запуска. Добавьте метрики.
Это самая «денежная» часть. Хороший список сценариев сразу режет пустой функционал и выявляет недостающий.
Пример формата:
Чётко ответьте:
Сразу выпишите, какие системы участвуют, и кто даст доступы. Это место, где чаще всего «вдруг» появляется +30 процентов бюджета.
Для каждой ключевой функции напишите «готово, когда…». Это экономит кучу времени на финале проекта.
Один документ или система управления требованиями, одна актуальная версия, все изменения фиксируются только в ней. Это простой организационный шаг, который реально экономит деньги.
С применением такого подхода ваш проект будет реализован прозрачно – и по договоренностям, и по срокам, и по бюджету. Больше полезного про разработку для бизнеса в нашем тг-канале Свои в IT – подписывайтесь, чтобы быть в курсе всего, что нужно знать заказчику!
