Обсудить проект
Выбор команды разработки

Как написать ТЗ на FinTech MVP без технического бэкграунда

9 минут чтения Выбор команды разработки
⏱ 9 минут чтения

Как написать тз для mvp — тема, которая определяет успех IT-проекта. Дмитрий написал в мессенджер: «Хочу сделать приложение, как Тинькофф, только для малого бизнеса. Берёшься?»

Это было всё ТЗ. Три строки. Без аудитории, без функций, без понимания что такое «как Тинькофф».

Студия взялась. Сделала, как поняла. Через два месяца Дмитрий получил продукт, который не решал его задачу. Переделки съели ещё 400 000 ₽ и три месяца. Отношения с командой испортились — каждый считал, что другой всё напутал.

Самое грустное: Дмитрий был уверен, что «подрядчик профессионал и сам разберётся». Подрядчик был уверен, что «клиент знает, что хочет».

Никто не разобрался. Никто не знал.

Хорошее ТЗ на FinTech MVP — это страховка от именно таких историй. И нет, оно не должно быть на 50 страниц.

Зачем вообще ТЗ, если подрядчик «и так всё поймёт»

Рассмотрим, как как написать тз для mvp работает на практике.

Распространённое заблуждение: хорошая студия должна «прочитать мысли» и сделать правильно. Опытная команда действительно поможет структурировать требования — но у неё нет доступа к вашей голове, к вашим пользователям, к вашей бизнес-логике.

Без ТЗ происходит следующее:

  • Разная картина у разных людей. Вы представляете одно, разработчик — другое, дизайнер — третье. Все работают на основе своих предположений.
  • Споры о scope. «Вы же говорили, что уведомления входят!» — «Нет, мы говорили про базовые уведомления, а не push в реальном времени». Без документа проверить это невозможно.
  • Перерасход бюджета. Студия оценила 350 000 ₽ по краткому описанию. По ходу выяснилось, что нужна интеграция с тремя банками, KYC-верификация и отчёты для регулятора. Итог: 750 000 ₽.
  • Поздние обнаружения. Требование к compliance (ФЗ-152, хранение данных в РФ) всплыло за неделю до запуска. Пришлось переносить инфраструктуру.

ТЗ — это не бюрократия. Это общий язык между вами и командой разработки. Документ, на который можно сослаться и сказать: «Вот что мы договорились делать».

7 обязательных разделов ТЗ на FinTech MVP

Вопрос как написать тз для mvp заслуживает детального анализа.

Хорошее ТЗ для MVP — это не технический документ на 80 страниц с UML-диаграммами. Это product brief: достаточно информации, чтобы команда поняла, кому вы строите, зачем и что именно.

Вот структура, которую мы используем в IT2BE на Discovery-этапе. Заполните эти 7 разделов — и у вас будет документ, достаточный для точной сметы и старта разработки.

1. Описание продукта

Один-два абзаца: суть продукта, проблема, которую он решает, и ваше решение. Пишите для человека, который ничего не знает о вашей отрасли.

Плохо: «Финтех-приложение для МСБ».

Хорошо: «Мобильное приложение для самозанятых, которое автоматически формирует чеки через ФНС, отслеживает доходы и рассчитывает налог в реальном времени. Целевая аудитория — фрилансеры и самозанятые с доходом 50 000–300 000 ₽/мес, которым не нужен бухгалтер, но нужно не нарушить закон».

2. Целевые пользователи

2–3 портрета с job-to-be-done: кто ваш пользователь, что он пытается сделать и почему текущие решения его не устраивают.

Формат: «[Имя], [описание], хочет [сделать что-то], но [проблема с текущим решением]».

Пример: «Аня, 28 лет, дизайнер-фрилансер. Хочет платить налоги как самозанятая, не разбираясь в налоговом законодательстве. Текущее решение — приложение "Мой налог" — неудобное, не показывает прогноз по налогу, нет истории платежей».

3. User Stories

Список действий, которые пользователь должен совершить в продукте. Формат: «Как [роль] я хочу [действие], чтобы [цель]».

Примеры для FinTech MVP:

  • Как самозанятый, я хочу зарегистрироваться через Госуслуги (ЕСИА), чтобы не вводить данные вручную.
  • Как пользователь, я хочу видеть баланс своего кошелька на главном экране, чтобы понимать, сколько денег доступно.
  • Как пользователь, я хочу получить уведомление о поступлении денег, чтобы сразу знать о транзакции.
  • Как администратор, я хочу видеть всех пользователей и их статус KYC, чтобы управлять верификацией.

Для MVP достаточно 10–20 user stories. Не пытайтесь описать всё — опишите основной пользовательский путь.

4. Функциональные требования (MVP scope)

Что входит в MVP — и что не входит. Второй список не менее важен первого.

Входит в MVP:

  • Регистрация и авторизация (телефон + SMS)
  • KYC упрощённая: ФИО, дата рождения, фото документа
  • Кошелёк: пополнение через СБП, вывод на карту
  • История транзакций (последние 30 дней)
  • Push-уведомления о транзакциях
  • Административная панель: управление пользователями, просмотр транзакций

Не входит в MVP (следующая версия):

  • Реферальная программа
  • Кредитный скоринг
  • Мультивалютные кошельки
  • Интеграция с бухгалтерскими системами

Чёткая граница scope — это защита от постоянного расширения задач по ходу разработки («раз уж делаем — добавьте ещё...»).

5. Интеграции

Какие внешние сервисы нужны? В FinTech MVP типичный список:

  • Платёжный шлюз: ЮKassa, Тинькофф Эквайринг, Сбер. Укажите конкретный или напишите «на выбор студии».
  • KYC-провайдер: IDX, Sumsub, ЕСИА (Госуслуги). Есть ли договор с провайдером?
  • SMS-шлюз: для верификации по телефону.
  • Аналитика: Mixpanel, Amplitude, или без аналитики в MVP?
  • Внутренние системы: нужна ли интеграция с вашей CRM, ERP, 1С?

Каждая интеграция — это время и деньги. Неизвестные интеграции в середине проекта — главная причина срыва сроков.

6. Compliance

Для FinTech это критически важный раздел. Укажите:

  • ФЗ-152: нужно ли соответствие? (Если собираете ФИО, телефон, email — нужно всегда.)
  • KYC/AML (115-ФЗ): требуется ли идентификация пользователей?
  • Хранение данных: только на серверах в РФ? (Yandex Cloud, Selectel — ок; AWS, Google Cloud — нет для персональных данных россиян.)
  • Регуляторные отчёты: нужна ли отчётность в ЦБ, ФНС?
  • Сертификации: планируется ли получение лицензии (ЭПС, МФО)?

Compliance, встроенный с первого дня, стоит в 3–5 раз дешевле, чем переделка после запуска. Подробнее о технических требованиях ФЗ-152 — в нашем гайде по compliance для FinTech стартапа.

7. Метрики успеха

Как вы поймёте, что MVP работает? Укажите 3–5 KPI:

  • Активация: % пользователей, завершивших регистрацию и KYC
  • Retention: % пользователей, вернувшихся через 7/30 дней
  • Транзакционная активность: % пользователей, совершивших первую транзакцию в первые 7 дней
  • Конверсия в платящих: % бесплатных → платных (если есть монетизация)

Метрики успеха определяют, что именно нужно измерять в аналитике. Без них невозможно понять: MVP работает или нет?

Что происходит без ТЗ — четыре реальных сценария

Именно как написать тз для mvp определяет результат для бизнеса.

Мы видели эти сценарии десятки раз. Они универсальные.

Сценарий 1: «Мы думали, это само собой разумеется». Клиент не упомянул, что нужна мультиязычность. Команда сделала только русский. Перевести интерфейс на английский за 2 дня до запуска — это 3 недели работы.

Сценарий 2: «А разве KYC входил?» Клиент написал «приложение с регистрацией». Студия сделала регистрацию через email. Клиент имел в виду полноценную KYC-верификацию с фотодокументом. Разница в оценке — 150 000 ₽ и 2 недели.

Сценарий 3: «Мы не знали, что нужна лицензия». Платёжный функционал потребовал лицензии ЭПС. Никто не обсуждал это в начале. Запуск отложился на 4 месяца.

Сценарий 4: «Данные оказались на AWS». Студия автоматически задеплоила на привычный AWS. ФЗ-152 требует хранение данных в РФ. Миграция — 2 недели и дополнительные расходы.

Все четыре сценария — следствие отсутствия явных требований на старте.

Мини-шаблон: заполните сами

При правильном подходе как написать тз для mvp становится конкурентным преимуществом.

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


Продукт: [одно предложение — что делает приложение]

Проблема: [какую боль решает для пользователя]

Аудитория: [3–5 слов: кто ваш основной пользователь]

Главный пользовательский путь: [опишите 5–7 шагов от регистрации до первой ценности]

В MVP входит: [список функций — 5–10 пунктов]

В MVP НЕ входит: [список — 3–5 пунктов «следующей версии»]

Интеграции: [платёжный шлюз, KYC, SMS, аналитика — что конкретно]

Платформы: [iOS / Android / Web / все три]

Compliance: [ФЗ-152 — да/нет, KYC/AML — да/нет, данные в РФ — да/нет]

Метрики успеха: [3 KPI, по которым будете оценивать MVP через месяц]

Бюджет: [вилка — от/до]

Срок запуска: [желаемая дата или «как можно быстрее»]


Это всё. Ни UML, ни wireframes, ни технические спецификации — подрядчик добавит их сам на основе вашего brief.

Когда ТЗ писать не нужно

Далее — о ключевых аспектах как написать тз для mvp.

Иногда продуктивнее не писать ТЗ самостоятельно, а пройти Discovery-этап вместе с командой разработки.

Discovery — это 1–2 дня структурированных интервью, где команда задаёт правильные вопросы, разбирает пользовательские пути, определяет риски и scope. На выходе — готовое ТЗ и точная смета, написанные профессионалами.

Это имеет смысл, если:

  • Продукт сложный и вы не уверены в правильной расстановке приоритетов
  • Есть неопределённость по compliance-требованиям
  • Вы хотите получить экспертное мнение по архитектуре до начала разработки
  • Первый опыт заказной разработки и нет понимания, что спрашивать

В IT2BE Discovery занимает один рабочий день. На выходе — ТЗ, смета и архитектурное решение. Это лучше, чем тратить несколько дней на документ, который команда всё равно будет переделывать.

О том, как выбрать правильную команду разработки для FinTech проекта — подробный гайд в нашем разделе «Как выбрать команду».

Главный принцип: ТЗ — это не технический документ

Лучшее ТЗ — это не технический документ. Это product brief.

Подрядчику важно понять три вещи: кому вы строите, зачем им это нужно, и что именно решает их задачу на уровне MVP. Технические детали — стек, архитектура, протоколы — это работа команды разработки. Ваша работа — объяснить проблему и пользователя.

Хорошее ТЗ на FinTech MVP — это 3–5 страниц, заполненных вдумчиво. Не 50 страниц с диаграммами, скопированными из интернета.

Если вы заполнили 7 разделов выше — у вас уже есть основа для продуктивного разговора с любой студией разработки. Если хотите пройти через Discovery вместе с нашей командой и получить готовое ТЗ и смету за один день — расскажите о вашем проекте через форму на сайте.

Сколько страниц должно быть в ТЗ на MVP?

Для MVP достаточно 3–7 страниц. Документ должен содержать описание продукта, портреты пользователей, основные user stories, scope (что входит и что не входит), интеграции и compliance-требования. Объёмные ТЗ на 30–80 страниц уместны для крупных корпоративных систем, но для MVP они избыточны — реальные требования всё равно уточняются в процессе разработки.

Можно ли написать ТЗ без технических знаний?

Да, и именно так правильно. Product brief — суть продукта, пользователи и их задачи, scope, интеграции, compliance — пишет основатель или продакт. Технические детали (стек, архитектура, API) — задача команды разработки. Если подрядчик требует от вас технической спецификации с нуля — это плохой знак: хорошая студия поможет структурировать требования самостоятельно.

Что такое user story и зачем она нужна?

User story — описание функции с точки зрения пользователя в формате «Как [роль] я хочу [действие], чтобы [цель]». Например: «Как самозанятый, я хочу пополнить кошелёк через СБП, чтобы не вводить данные карты». Такой формат фокусирует команду на ценности для пользователя, а не на технической реализации. Для MVP достаточно 10–20 user stories, покрывающих основной пользовательский путь.

Кто пишет ТЗ — заказчик или подрядчик?

Оптимально — совместно. Заказчик описывает проблему, аудиторию и бизнес-логику (это знает только он). Подрядчик помогает структурировать требования, задаёт правильные вопросы и добавляет технические детали. На практике многие студии проводят Discovery-сессию (1–2 дня), по итогам которой составляется ТЗ и точная смета. Это лучший вариант для первого проекта.

Нужно ли ТЗ, если у меня уже есть Figma-прототип?

Figma не заменяет ТЗ — она описывает интерфейс, но не бизнес-логику. В ТЗ нужно описать: user stories (зачем нужен каждый экран), compliance-требования (ФЗ-152, KYC), интеграции с внешними сервисами, scope (что входит в MVP, что нет) и метрики успеха. Без этого даже при наличии Figma команда работает на предположениях. Хорошая новость: при наличии прототипа составить ТЗ значительно проще.

Обсудите ваш FinTech или EdTech стартап

Бесплатная 30-минутная консультация. MVP за 22 дня, фиксированная цена до 900 000 ₽.

Обсудим ваш проект
Заполните форму — свяжемся в течение 2-х часов