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