ТЗ на сайт или мобильное приложение: отличия

Коротко: Разница ТЗ заключается в архитектуре и способах доставки контента. Для сайта фокус идет на браузерную совместимость, SEO-структуру и локализацию данных в РФ. Для мобильного приложения критичны требования к версиям ОС, публикации в RuStore и работе с нативными функциями смартфона. Ошибки в обоих случаях ведут к юридическим штрафам и техническому долгу.

Кстати, в AmSales мы делаем разработку мобильных приложений и внедрение и настройку Битрикс24 под ключ. Если нужна помощь - напишите нам.

Функциональные различия ТЗ для веба и мобильных платформ

Когда бизнес решает, что ему нужно - сайт или мобильное приложение, многие совершают фатальную ошибку, пытаясь скопировать функционал одного продукта в другой. Это тупиковый путь. Разница ТЗ сайт и приложение заложена на уровне самой логики взаимодействия пользователя с интерфейсом. Сайт - это открытая среда, где пользователь приходит из поисковика, переходит по ссылкам и ожидает мгновенной загрузки страницы. Приложение же - это закрытая экосистема, требующая установки, авторизации и постоянного присутствия в памяти устройства.

В техническом задании на веб-ресурс основной упор делается на кроссбраузерность и скорость отклика страниц. Вам нужно прописать, как сайт должен выглядеть в Chrome, Safari или Яндекс.Браузере, как работают скрипты при слабом интернет-соединении и как устроена навигация. Здесь нет понятия "установка", зато есть понятие "индексация". Если вы не пропишете требования к мета-тегам и структуре URL в ТЗ, ваш сайт будет существовать, но его никто не найдет через поиск.

Разработка мобильного приложения требования к которой гораздо жестче в плане ресурсов устройства, диктует иную логику. В мобильном ТЗ вы не пишете про браузеры. Вы пишете про жизненный цикл приложения: что происходит, когда пользователь свернул программу, как она восстанавливает состояние после звонка, как работает push-уведомление. Здесь ключевым становится потребление оперативной памяти и заряда батареи. Если приложение "съедает" заряд за час, пользователь удалит его, и никакая маркетинговая стратегия не поможет.

Сравнение ключевых параметров проектирования

Важно понимать, что мобильное приложение позволяет создавать более глубокий пользовательский опыт. Например, если вам нужно отслеживать геопозицию курьера в реальном времени с высокой точностью, веб-версия будет работать нестабильно. В ТЗ на мобильный продукт вы обязаны заложить сценарии работы в офлайн-режиме. Сайт без интернета - это просто ошибка 404, а приложение может позволить пользователю просмотреть закэшированные данные, что критично для сервисов доставки или навигации.

Специфика требований к RuStore и версиям ОС в 2026 году

Сегодня планировать разработку мобильного продукта без учета локального рынка невозможно. Если ваш целевой сегмент - пользователи внутри России, то требования к ТЗ на мобильное приложение должны включать обязательную поддержку RuStore. Это уже не просто "одна из площадок", а ключевой канал дистрибуции. С 2026 года требования к качеству приложений в RuStore стали более строгими, чтобы конкурировать с глобальными сторами по уровню удобства публикации и модерации.

В разделе ТЗ, посвященном платформам, нельзя просто написать "Android и iOS". Нужно четко сегментировать версии ОС. Для Android в 2026 году критично поддерживать не только последние версии, но и учитывать популярность устройств со старыми прошивками, которые все еще массово используются в корпоративном секторе. Для каждой платформы прописывается минимально поддерживаемая версия ОС, ниже которой приложение просто не запустится. Это экономит бюджет на разработку, так как поддержка древних версий требует написания специфического кода-прослойки.

Особое внимание уделите процессу публикации. В ТЗ необходимо заложить время и технические требования для прохождения модерации в RuStore. Это включает подготовку скриншотов, описаний, иконок в нужных разрешениях и, что немаловажно, интеграцию с внутренними сервисами магазина, если вы планируете использовать их платежные инструменты. Игнорирование этого этапа приведет к тому, что разработка завершится, а продукт так и не попадет в руки пользователей из-за несоответствия регламентам площадки.

Кстати, стоит учитывать, что с 01.01.2026 для RuStore действует расширенный список из 19 категорий приложений для смартфонов и планшетов. Это значит, что правила модерации для игровых приложений, финансовых сервисов и инструментов продуктивности стали более дифференцированными. В ТЗ нужно четко определить категорию вашего продукта, так как от этого зависят требования к безопасности и типу запрашиваемых разрешений (permissions) на доступ к данным устройства.

Новые правила обработки персональных данных и трансграничной передачи

Юридический блок в ТЗ - это то, на чем чаще всего "горят" технические директора. В 2026 году правила игры радикально изменились. Если вы составляете ТЗ на сайт 2026, вы обязаны учитывать положения № 265-ФЗ, вступившего в силу 26 июля 2026 года. Этот закон существенно изменил статью 12 закона "О персональных данных" и правила трансграничной передачи. Теперь просто "согласия в футере" недостаточно, если ваши серверы или облачные сервисы обработки данных находятся за пределами РФ.

Если ваше приложение или сайт собирает ФИО, email, телефон или адрес доставки, вы попадаете под жесткое регулирование. Любая передача этих данных за рубеж теперь требует не просто уведомления, а соблюдения сложной процедуры проверки безопасности со стороны регулятора. В ТЗ на разработку необходимо заложить архитектуру, которая позволяет физически разделять хранение данных. Первичный сбор, запись, систематизация и хранение ПДн граждан РФ должны происходить исключительно на серверах, расположенных на территории России. Использование зарубежного хостинга для этих целей сегодня - это прямой путь к блокировке ресурса и огромным штрафам.

Не забывайте про обязательные элементы интерфейса. Для сайта это политика конфиденциальности, отдельное (не предустановленное галочкой!) согласие на обработку ПДн и четко указанные реквизиты компании в футере. Для мобильного приложения эти требования переносятся в экран регистрации или в первый запуск (onboarding). Пользователь должен иметь возможность отозвать согласие так же легко, как он его дал. В ТЗ нужно прописать не только наличие этих страниц, но и логику их работы: как данные удаляются из базы при удалении аккаунта пользователем.

Также важно помнить о необходимости уведомления Роскомнадзора через портал pd.rkn.gov.ru. Это не техническая задача программиста, но это задача процесса. В ТЗ стоит зафиксировать необходимость интеграции с системами логирования, которые позволят вам в любой момент доказать регулятору, когда, как и на каком основании были получены данные конкретного пользователя. Без этого аудиторская проверка превратится в кошмар.

Универсальный дизайн вместо версий для слабовидящих

Старый подход "сделать отдельную версию сайта для слабовидящих" официально и фактически признан устаревшим. В 2026 году стандартом является универсальный дизайн. Это означает, что доступность (accessibility) должна быть заложена в архитектуру продукта изначально, а не "наклеиваться" сверху в виде отдельного переключателя. Если вы заказываете разработку, требуйте, чтобы требования к доступности были частью основного функционального задания.

В ТЗ на сайт или приложение должны быть прописаны конкретные технические параметры:

1. Наличие alt-текстов для всех значимых изображений, чтобы скринридеры могли их озвучить.
2. Контрастность текста относительно фона должна быть не ниже 4.5:1 для обычного текста.
3. Возможность полной навигации с помощью клавиатуры (для веба) или внешних переключателей (для мобильных).
4. Корректная работа со скринридерами (VoiceOver на iOS, TalkBack на Android).
5. Возможность масштабирования интерфейса до 200% без появления горизонтальной прокрутки.

Такой подход не только помогает людям с нарушениями зрения, но и улучшает UX для всех. Например, высокая контрастность делает сайт читаемым на ярком солнце, а четкая структура заголовков помогает пользователям быстрее ориентироваться в контенте. При проектировании мобильного приложения важно учитывать области нажатия (touch targets) - они должны быть достаточно большими, чтобы по ним было легко попасть человеку с тремором рук или просто в движении. Это не "дополнительная опция", а стандарт качества современного цифрового продукта.

Интеграция универсального дизайна на этапе проектирования обходится в разы дешевле, чем попытка переделать готовый интерфейс. Если разработчик скажет, что "это сложно", значит, он не понимает современных стандартов верстки. В 2026 году доступность - это не благотворительность, а требование к качеству кода и удобству продукта для широкой аудитории.

Требования к хранению логов пользователей и русификации контента

С 1 января 2026 года вступило в силу важное требование: срок хранения сведений о действиях пользователей на интернет-площадках увеличен до 3 лет (ранее было 1 год). Это кардинально меняет нагрузку на серверную инфраструктуру и требования к проектированию баз данных. В ТЗ теперь нельзя просто написать "логируем действия". Нужно прописать объем хранилища, методы архивации и правила очистки данных по истечении трехлетнего срока.

Логирование должно быть детализированным, но при этом не нарушать закон о персональных данных. Вы должны хранить факт действия (например, "пользователь X совершил покупку"), но не должны хранить лишнюю чувствительную информацию в открытом виде в логах. В ТЗ на разработку необходимо заложить систему ротации логов и механизмы их защиты от несанкционированного доступа, так как эти данные могут стать целью хакеров или предметом изучения регуляторов.

Параллельно с техническими логами, существует вопрос контента. С 1 марта 2026 года вступили в силу поправки о обязательной русификации публичной информации. Если ваш сайт или приложение предоставляет информацию пользователям в РФ, она должна быть на русском языке. Использование иностранных слов теперь допускается только в том случае, если они идут рядом с русским вариантом, имеют тот же смысл и сопоставимое оформление. Это касается названий разделов, кнопок, подсказок и даже интерфейсных элементов.

Это правило бьет по компаниям, которые используют "западные" шаблоны интерфейсов. Вы не можете просто оставить кнопку "Checkout" или "Login" без русского эквивалента. В ТЗ на разработку интерфейса (UI) нужно закладывать работу с локализацией как с базовым процессом. Это касается не только перевода текста, но и адаптации форматов дат, валют и единиц измерения. Если вы планируете масштабироваться на разные рынки, закладывайте многоязычность в архитектуру сразу, чтобы потом не переписывать всю логику отображения данных.

Технические ограничения: от серверной локализации до кэширования

Техническое задание должно четко разграничивать зоны ответственности между фронтендом, бэкендом и инфраструктурой. При проектировании веб-сервисов одной из главных задач является серверная локализация. Как мы уже упоминали, первичная обработка ПДн должна происходить в РФ. Это накладывает ограничения на выбор облачных провайдеров и архитектуру распределения нагрузки (Load Balancing). Вы не можете просто использовать глобальный CDN, если он будет кэшировать персональные данные пользователей на серверах в Европе или США.

В мобильных приложениях технические ограничения связаны с кэшированием и синхронизацией. В ТЗ необходимо прописать стратегию кэширования данных: что должно быть доступно офлайн, как часто данные должны обновляться в фоновом режиме и как приложение должно обрабатывать конфликты версий при синхронизации. Например, если пользователь изменил адрес доставки в приложении, находясь в метро без связи, а затем зашел на сайт с компьютера, система должна корректно разрешить этот конфликт.

Еще один критический аспект - интеграции. В ТЗ на сайт часто прописывают интеграцию с CRM, системами аналитики и платежными шлюзами. В мобильном приложении список таких интеграций расширяется за счет нативных SDK (Software Development Kits) для работы с камерой, Bluetooth или биометрией (FaceID/TouchID). Важно указать, какие именно данные передаются через эти интеграции и как они защищены. Ошибка в проектировании API для мобильного приложения может привести к тому, что приложение будет работать медленно из-за избыточного трафика, или, наоборот, будет небезопасным из-за передачи данных в открытом виде.

Для коммерческих проектов важно также заложить требования к масштабируемости. Если ваш сайт или приложение внезапно получит в 10 раз больше пользователей (например, из-за рекламной кампании), выдержит ли серверная часть? В ТЗ должны быть указаны целевые показатели нагрузки: количество одновременных сессий, количество запросов в секунду (RPS) и время отклика сервера. Без этих цифр вы рискуете получить продукт, который "упадет" в самый ответственный момент.

Типичные ошибки при проектировании архитектуры цифровых продуктов

Самая распространенная ошибка - это попытка создать "универсальный продукт", который одновременно является и сайтом, и приложением, имея единый бэкенд без учета специфики платформ. Это приводит к тому, что мобильное приложение становится перегруженным функциями, которые не нужны на смартфоне, а веб-сайт теряет гибкость. Правильный путь - проектирование через API. Бэкенд должен быть независимым, а фронтенд (веб или мобильное приложение) - лишь разными способами визуализации этих данных.

Вторая ошибка - игнорирование юридических требований на этапе проектирования. Когда разработчики уже написали код, а юристы говорят: "Мы не можем так хранить данные, это незаконно", - переделка стоит в 5-10 раз дороже, чем если бы это учли сразу. Это касается и локализации данных, и правил русификации, и требований к хранению логов. Не пытайтесь "прикрутить" безопасность и законность к готовому продукту. Встраивайте их в саму структуру данных.

Третья ошибка - недооценка стоимости поддержки. Многие забывают, что мобильное приложение требует постоянных обновлений под новые версии iOS и Android, а также прохождения модерации в сторах. В ТЗ часто забывают прописать требования к инструментам мониторинга ошибок (Crashlytics и аналоги). Если вы не знаете, почему приложение упало у пользователя в другом регионе, вы не сможете его починить. А без оперативного исправления багов рейтинг приложения в RuStore быстро упадет, и вы потеряете органический трафик.

Наконец, типичная ошибка в части UX - отсутствие сценариев работы в условиях нестабильного соединения. Разработчики часто тестируют продукт в идеальных условиях офисного Wi-Fi. Но реальный пользователь может открывать ваше приложение в лифте или в зоне плохого приема 4G. Если интерфейс "зависает" при каждой попытке запроса к серверу, пользователь просто закроет его. В ТЗ должны быть четко прописаны состояния загрузки (skeletons), обработки ошибок сети и механизмы повторных запросов.

Как составить ТЗ для минимизации юридических и технических рисков

Чтобы ваше ТЗ стало рабочим инструментом, а не набором общих слов, следуйте проверенному алгоритму. Хорошее техническое задание для коммерческого проекта в 2026 году должно состоять из нескольких ключевых блоков. Помните, что для обычного коммерческого сайта использование ГОСТ не является обязательным, но следование логике профессионального проектирования - необходимость. Если же вы работаете над государственной информационной системой, вам придется соблюдать и постановление Правительства № 676, что накладывает еще более жесткие рамки.

Рекомендуемый порядок действий при составлении ТЗ:

1. Определите цели и роли: Кто пользователь? Какие задачи он решает? Какие права есть у администратора, а какие у обычного клиента?
2. Опишите функциональные сценарии: Не пишите "нужна корзина". Пишите: "Пользователь может добавить товар в корзину, изменить количество, применить промокод и перейти к оплате".
3. Зафиксируйте нефункциональные требования: Скорость загрузки, нагрузка, доступность (универсальный дизайн), требования к безопасности и локализации.
4. Пропишите требования к данным: Где хранятся ПДн? Как организован сбор согласий? Как долго хранятся логи?
5. Укажите ограничения и интеграции: Какие сторонние сервисы используются? Какие версии ОС поддерживаются? Какие требования к публикации в RuStore?
6. Определите критерии приемки: Как вы поймете, что задача выполнена? (Например: "Приложение проходит модерацию в RuStore и не падает при имитации потери сети").

При составлении раздела об интеграциях всегда требуйте документацию к API. Если вы интегрируетесь с CRM или платежным шлюзом, в ТЗ должно быть четко указано, кто предоставляет данные, в каком формате (JSON, XML) и как обрабатываются ошибки передачи. Это исключит ситуацию, когда разработчики говорят: "Мы не знали, что этот сервис может возвращать ошибку 500".

В завершение, всегда оставляйте в ТЗ место для этапов тестирования. Разработка - это не только написание кода, но и проверка его на соответствие вашим же требованиям. Пропишите, что тестирование должно включать не только функциональные проверки, но и проверку доступности (accessibility), нагрузочное тестирование и аудит безопасности данных. Только комплексный подход позволит вам получить продукт, который будет приносить прибыль, а не судебные иски.

Что запомнить:

• Разница ТЗ сайт и приложение в том, что веб-версия ориентирована на SEO и браузеры, а мобильная - на версии ОС, нативные функции и публикацию в сторах (RuStore).
• С 2026 года критически важна локализация ПДн в РФ (№ 265-ФЗ) и соблюдение правил русификации контента.
• Вместо отдельных версий для слабовидящих внедряйте универсальный дизайн (контрастность, alt-тексты, масштабирование).
• Срок хранения логов пользователей теперь составляет 3 года - это нужно учитывать при проектировании баз данных.
• Мобильное приложение требует обязательного учета требований RuStore и специфики различных версий Android/iOS.