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