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

В финтехе новичков обычно ломает не Scrum и не Яндекс Трекер. Ломает сюрприз: «фича готова» не значит «её можно выпускать». Можно сделать идеальную кнопочку, но если вы не провели оценку рисков, не описали обработку персональных данных и не оставили след в артефактах — релиз превращается в тыкву. И да, это тот самый момент, когда бизнес говорит «ну вы же айтишники», а комплаенс молча достаёт список требований.

Парадокс рынка: чем выше ставка на скорость (быстрее выкатить платежи, кредитный скоринг, KYC), тем дороже ошибка. В финтехе ошибка — это не только баг. Это блокировка релиза, предписание, штраф, репутационный удар, внеплановый аудит и «всем срочно переписать регламенты». Поэтому управление проектами финтех почти всегда про управление доказательствами и рисками: документы, логи согласований, трассировка требований, контроль доступа, отчётность. Скучно? Да. Вакансии обычно оплачиваются именно за это.

Что такое комплаенс в финтех-проектах и почему это не «юристы пусть сами»?

Тезис

Комплаенс — это набор правил (внутренних и внешних), который определяет: что можно выпускать, в каком виде, с какими проверками и как это доказать постфактум.

Обоснование (по практике рынка)

В российских финтех-командах комплаенс обычно связан с: 152-ФЗ (персональные данные), требованиями Банка России (в т.ч. по ИБ и управлению рисками через внутренние документы и контроль), 115-ФЗ (антиотмывочные процедуры: KYC/AML), внутренними политиками ИБ, моделью угроз, требованиями к логированию и хранению событий. Даже если вы не юрист, вы проектный человек — вы управляете тем, чтобы все эти штуки превращались в задачи, критерии готовности и отчётность, а не «мы потом допишем».

Практический вывод

Если вы ведёте проект в финтехе, ваш must-have навык — понимать, как внедрить комплаенс в процесс: где он живёт (артефакты), кто владелец (роль), когда проверяется (гейты), как измеряется (метрики), и чем доказывается (следы/логи/протоколы).

Подводный камень

Самая частая ошибка — пытаться «внедрить комплаенс» как один документ или одну встречу. В финтехе это не документ. Это система, встроенная в SDLC (жизненный цикл разработки).

Как выглядит «система управления проектами» в финтехе, если её не стыдно показать аудитору

Тезис

Система управления проектами в финтех — это связка процессов + ролей + артефактов, где каждое требование можно проследить от закона/политики до задачи, теста, релиза и пост-контроля.

Что должно быть в системе (минимально жизнеспособный набор)

• Реестр требований: функциональные + регуляторные (например, хранение согласий, сроки хранения данных, требования к логированию).
• Матрица трассируемости: требование → user story/задача → тесты → релиз → контроль.
• Риск-регистры: что может пойти не так, вероятность/ущерб, владельцы, меры.
• Гейты согласований: ИБ, комплаенс, юристы, DPO/ответственный за ПДн (если роль выделена), архитектура.
• Отчётность: регулярные отчёты по статусу, рискам, отклонениям, инцидентам, техническому долгу.
• Журнал решений (Decision log): почему выбрали так, а не иначе.

Практический вывод

Когда вы выбираете инструменты (Яндекс Трекер/YouTrack/Confluence/простые реестры), думайте не «чтобы было удобно», а «чтобы было проверяемо». Удобство — бонус, проверяемость — базовый тариф финтеха.

Подводный камень

«Всё в головах» и «в переписке в мессенджере». Для финтеха это означает: у вас нет системы. У вас есть коллективная память с амнезией.

Отчетность: какие отчёты реально нужны и кому (и как не утонуть)

Тезис

Отчетность в финтех-проектах — это не бюрократия, а способ управлять риском и скоростью: без неё релизы начинают тормозить хаотично и внезапно.

Кому что нужно (типовая раскладка)

Практический вывод

Секрет выживания: делайте отчётность «побочным продуктом» работы, а не отдельным проектом. То есть: настроили статусы задач, шаблоны страниц, обязательные поля (например, ссылка на требование compliance), — и отчёт собирается почти сам.

Подводный камень

Писать отчёты «красиво», но без исходных артефактов. Аудитору не интересно ваше вдохновение. Ему нужен след: задача, согласование, тест, релиз.

Как внедрить compliance в проект: пошаговая схема без религиозных войн

Тезис

Compliance внедряется не лозунгом, а гейтами и артефактами, встроенными в SDLC. Иначе он будет всплывать в конце, как неоплаченный штраф — внезапно и в самый неподходящий день.

1. Соберите карту требований: внешние (152-ФЗ, 115-ФЗ, требования ЦБ, договорные) + внутренние (ИБ-политики, архитектурные стандарты).
2. Назначьте владельцев: кто отвечает за трактовку требований (compliance), кто — за техконтроль (ИБ), кто — за доставку (PM/PO/BA).
3. Врежьте требования в бэклог: каждая эпик/фича должна ссылаться на compliance-требования, если они затрагиваются.
4. Добавьте Definition of Done (критерии готовности): «прошли security review», «обновлён реестр ПДн», «настроено логирование», «согласовано».
5. Сделайте релизные гейты: без чек-листа и подписей (электронных согласований) релиз не проходит.
6. Настройте хранение доказательств: протоколы, решения, результаты тестов — всё должно жить в одном месте и иметь версии.
7. Метрики: сколько требований закрыто, сколько исключений, сколько рисков «красные», сколько задач без трассировки.

Подводный камень

Внедрить compliance «после MVP». В финтехе MVP без compliance часто означает «мы сделали демку, которую нельзя запускать на живых клиентах». Вроде бы продукт есть, а бизнеса нет.

Кейсы из практики: как это ломается и как чинится

Кейс №1 (плохой): релиз остановили на финише

Команда делала новый сценарий выдачи виртуальной карты. Функционально всё ок, тесты зелёные. За два дня до релиза ИБ спрашивает: «а где журналирование критичных событий и модель угроз?» Ответ: «мы обсудим». Итог: релиз перенесли на месяц, потому что пришлось перепроектировать логирование, пересобрать пайплайн проверок и собрать задним числом протоколы решений. Цена ошибки — время всей команды и потерянная выручка от задержки. И да, виноватым назначили PM, потому что «управление проектами финтех» — это как раз про то, чтобы такие мины были разминированы заранее.

Кейс №2 (хороший): compliance как ускоритель

В другом проекте (KYC-процесс) команда с первого спринта завела реестр требований, чек-листы гейтов и шаблоны страниц для согласований. В результате к релизу не было «сюрприза» от комплаенса: все спорные моменты решались по мере разработки, а отчётность собиралась из артефактов. Релизы стали чаще, потому что каждый следующий проходил по понятной тропинке. В финтехе это почти роскошь.

Сколько это стоит на самом деле: скрытая цена compliance и отчетности

Деньги обычно утекают не в «бумажки», а в переделки. Когда compliance встраивают в конце, вы платите двойной тариф: разработка + переделка + простой. Если встроить в начало, вы платите в основном временем аналитики и постановки процесса.

• Скрытые расходы: дополнительные согласования, простои релизов, доработки логирования и хранения данных, пересмотр архитектуры, повторные тесты.
• Невидимый бюджет: время ИБ и compliance. Если их не планировать, они «вылезают» как блокеры.
• Командный налог: обучение команды базовым требованиям (что такое ПДн, что логируем, где храним).

Если вы хотите системно прокачаться в теме (без курсовых сказок), соберите себе библиотеку шаблонов и практик и ведите её как продукт. Кстати, похожие разборы и чек-листы периодически появляются на https://itokno.ru — удобно подглядывать, как оформлять мысли в артефакты, которые потом не стыдно показать.

Экспертный вердикт и инструмент: чек-лист «финтех PM/BA/PO и compliance»

• 1) Трассируемость есть? Я могу за 5 минут показать: требование → задача → тест → релиз → контроль.
• 2) Гейты определены? Кто и где ставит «ок» перед релизом: compliance, ИБ, архитектура.
• 3) DoD включает compliance? «Готово» = не только код, но и требования/согласования/логи/документация.
• 4) Реестр рисков живой? Есть владельцы, меры, сроки, статус. Или это файл «risk_final_v7.xlsx».
• 5) Отчётность собирается из системы? Если нужны ручные отчёты в ночи — процесс не настроен.
• 6) Исключения оформляются? Если что-то делаем «не по стандарту», есть решение, кто разрешил и на какой срок.
• 7) Вы знаете, что логируете и как храните? События, доступы, операции — и где это используется при разборе инцидентов.

Если вы «входите в IT» из другой сферы: сильная сторона — дисциплина и умение работать по правилам. В финтехе это внезапно козырь. Если вы уже Junior с опытом 1–3 года: ваш следующий шаг — перестать быть человеком задач и стать человеком гейтов, рисков и доказательств. Именно там начинается рост в деньгах и ответственности (и в количестве седых волос, не буду врать).

Частые вопросы