ТЗ без ХЗ: как банку и IT-разработчику найти общий язык на проекте

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

Мы попросили Александра — нашего IT-директора — рассказать, как выстроить работу с аутсорсом так, чтобы сервис вышел вовремя и без технических сюрпризов.

P.S.: будет полезно всем, кто работает с IT-подрядчиком на аутсорсе — не только банкам😉

Сегодня финтех-ландшафт меняется быстрее, чем большинство банков успевают обновлять свои ИТ-системы. Подключение к цифровому рублю, внедрение новой АБС или запуск онлайн-сервиса — это проекты, которые редко делаются силами только внутренней команды. Чаще всего банк работает с внешними подрядчиками: аутсорс-командами или специалистами на аутстафе.

И здесь сразу встает главный вопрос: как выстроить взаимодействие с внешней командой так, чтобы на выходе получился не очередной «пилот ради пилота», а продукт, которым будут гордиться и бизнес, и разработчики?

Если роли распределены правильно, задачи сформулированы ясно, а процессы прозрачны — проект движется вперёд. Когда этого нет, появляется то самое «ХЗ»: затянутые сроки, раздутые бюджеты, и продукт, который вроде бы есть, но бизнес-задачу не решает.

Внедрение ИТ-решений в банках — это не про «универсальную команду под ключ». Это всегда совместная работа: команда банка + команда подрядчика. Состав участников и границы ответственности зависят от конкретного проекта. Но есть минимальный набор компетенций, без которых процесс почти гарантированно буксует.

Чтобы не быть голословным, возьмем пример из практики: проект по подключению банка к платформе цифрового рубля. Задача подрядчика здесь вроде бы простая — взять готовое «коробочное» решение и встроить его в ландшафт банка. Но на деле «коробка» быстро теряет форму: у каждого банка своя архитектура, учетные системы, АБС, платежные хабы. И все это нужно учитывать.

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

На стороне разработки у проекта обычно есть несколько ключевых ролей:

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

Тимлид смотрит на всю систему целиком, оценивает риски интеграции, принимает решения по архитектурным компромиссам и следит, чтобы отдельные куски не «порвали» общую картину.

И, наконец, служба поддержки — те, кто остается после релиза: мониторят системы, объясняют банку, почему «все упало», и как быстро вернуть сервис в рабочее состояние.

Кто нужен со стороны банка-заказчика:

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

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

Далее идут эксперты по внутренним системам: администраторы ABS, специалисты платежных систем. Они показывают, как «у нас это работает», а не только как «должно работать по регламенту». И именно их ответы определяют сложность интеграции.

И, пожалуй, самый важный герой этой истории — проджект-менеджер со стороны банка. Проджект не просто координатор встреч и согласований; это входящее лицо для подрядчика, навигатор ресурсов внутри банка и человек, который формирует road-map проекта. Он не обязан быть экспертом в цифровом рубле, не обязан разбираться в жизненном цикле продукта (это наша задача!).

Но именно проджект — тот самый «золотой персонаж», вокруг которого складывается ядро грамотного ТЗ: он переводит бизнес-задачу в управляемый набор задач, собирает экспертов, согласовывает сроки. Без такого человека подрядчик рискует блуждать по коридорам банка в поисках решений и документов, а проект — съехать по срокам и объему.

«ХЗ» — когда на старте непонятно ни зачем мы делаем систему, ни какие задачи она решает, ни кто отвечает за результат. Такое ТЗ чаще всего превращается в набор абстрактных пожеланий, и итог — компромиссный продукт, который не радует ни бизнес, ни разработчиков. Как этого избежать? Коротко — фокус на «зачем», итерации и четкие зоны ответственности.

Разработчики могут спорить о реализации бесконечно, но главный вопрос — зачем. Бизнесу не нужно описывать алгоритмы или схемы интеграции, но важно чётко проговорить сценарии использования и ожидаемый результат: какие KPI меняются? какой пользовательский путь закрывается? какие операции должны происходить автоматически? Если бизнес не может ответить на эти вопросы — команда рискует топтаться на месте.

Типичная ошибка — «поверхностное ТЗ»: пара абзацев и слайд-схема. Это похоже на «хотим приложение для знакомств» — звучит, но не хватает деталей. Подрядчику приходится додумывать поведение, и это растит время и стоимость (бафферы в backlog, незапланированные user stories, баги в интеграции). Решение — минимум: четкие user stories, acceptance criteria и контекст интеграций (API, форматы данных, ограничения АБС/хаба).

Если бизнес «подписал roadmap и ушел до релиза», продукт часто выходит удобным технически, но бесполезным пользователю. Бизнес должен быть вовлечен, участвовать в sprint review и давать оперативную обратную связь на демо. Это сохраняет alignment между user needs и техническими trade-offs.

Не пытайтесь описать всю систему на этапе discovery в деталях. Формируйте MVP, проверяйте гипотезы на промежуточных демо, собирайте метрики и корректируйте backlog. Итеративный подход (MVP → feedback → iterations) позволяет держать контроль над результатом и снижает риск больших отклонений по scope и бюджету.

Бизнес определяет что нужно и почему (ценность, сценарии, KPI). Техническая команда выбирает как это реализовать (архитектура, интеграции, CI/CD, схему деплоя). Если обе стороны пытаются занять чужую зону ответственности, появляется конфликт и замедление. Ясные RACI-матрицы, SLA по интеграциям и соглашения по versioning/rollback помогают избежать этого.

Все, о чем говорили выше, сводится к 3 простым, но критически важным правилам.

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

Второе — доверие к экспертизе. Когда бизнес начинает указывать, на каком стеке писать код и как строить архитектуру, проект теряет темп. Техническая реализация — зона подрядчика и инженеров. Пусть команда выберет лучший путь, чтобы прийти к нужному результату — это и есть смысл партнёрства.

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

Когда три этих принципа работают вместе, появляется главное — предсказуемость результата. А это, пожалуй, самая ценная метрика для любого банковского ИТ-проекта.