Сегодня финтех-ландшафт меняется быстрее, чем большинство банков успевают обновлять свои ИТ-системы. Подключение к цифровому рублю, внедрение новой АБС или запуск онлайн-сервиса — все эти проекты редко делаются силами только внутренней команды. Чаще всего банк работает с внешними подрядчиками: аутсорс-командами или специалистами на аутстаффе.
И здесь сразу возникает вопрос: как выстроить взаимодействие с внешней командой так, чтобы на выходе получился не очередной «пилот ради пилота», а продукт, которым будут гордиться и бизнес, и разработчики?
Если роли распределены правильно, а задачи сформулированы ясно, проект идет вперед. Когда же этого нет, появляется то самое «ХЗ»: затянутые сроки, раздутые бюджеты, а продукт в итоге не решает ту задачу, ради которой всё начиналось.
В этой статье мы разберем, зачем банки обращаются за аутсорс-разработкой, кто нужен в команде с каждой стороны и как подходить к постановке задач, чтобы проект в финтехе приносил реальную ценность, а не становился головной болью.
Аутсорс vs аутстафф: с кем вы работаете — и почему это меняет правила игры
Прежде чем говорить о том, как составить техническое задание, важно четко понимать, с кем вы собираетесь работать. Потому что передача задач инхаус-команде, аутстафф-специалисту или целой аутсорс-компании — это три разные модели, и они предполагают разные риски, ответственности, способы коммуникаций и организацию ТЗ.
Сегодня речь про внешних подрядчиков, потому что банки часто начинают новые инициативы (новые продукты, пилоты, цифровые услуги) именно через аутсорс или аутстафф. Почему так?
- Так быстрее. Не нужно нанимать новых специалистов (а это время), строить внутренние команды (тоже время) и инфраструктуру.
- Можно гибко масштабироваться. Нужен дополнительный ресурс? Быстро нашли внешнего специалиста/подрядчика на точечные задачи через знакомые компании по аутстаффу или аутсорсу. Потребность пропала? Отпустили человека.
- Сложные финтех-проекты. Банки не всегда уверены в объемах работ, архитектуре и деталях — через внешнего партнера можно выяснить техдолг, нюансы инфраструктуры, интеграций и пр.
Влияет ли это на постановку ТЗ? Да. Когда вы сотрудничаете по аутстаффу или аутсорсу, способы и требования к постановке ТЗ меняются.
Что важно?
- Четкая бизнес-цель: особенно в аутсорс-модели, чтобы внешняя команда понимала, зачем и для чего они пришли на проект, какие метрики успеха у заказчика, что он хочет получить в итоге.
- Уровень детализации: важный этап, о котором мы будем говорить. С аутсорсом часто нужно глубоко проработанное ТЗ, либо описанные этапы разработки, чтобы подрядчик мог оценить риски, нагрузку, архитектуру.
- Коммуникация: в аутстаффе банк фактически управляет людьми напрямую: специалисты работают внутри команды заказчика, участвуют в его планерках, решают задачи вместе с инхаус-разработчиками.
В аутсорсе все устроено иначе — взаимодействие идет через проектных менеджеров подрядчика. Банк не руководит конкретными разработчиками, а получает результат по спринтам или этапам: отчеты, демо, промежуточные версии продукта.
- Контроль и корректировки: и в аутсорсе, и в аутстаффе важно регулярно сверять курс. Но если в аутстаффе это происходит естественно — через ежедневное взаимодействие, то в аутсорсе особенно важно не терять контакт. Здесь точки проверки должны быть заранее согласованы: статус-встречи, демо, обсуждения промежуточных результатов. Это помогает убедиться, что команда подрядчика правильно поняла задачу и движется в нужном направлении, пока правки еще можно внести без боли.
Совместная работа, а не «универсальная команда»
Когда речь заходит о внедрении ИТ-решений в банках, важно понимать: не существует универсальной команды «под все задачи». Это всегда совместная работа банка и внешней команды разработки. Состав участников и границы ответственности зависят от проекта. Но есть минимальный набор компетенций, без которых процесс почти всегда буксует.
Чтобы не быть голословным, возьмем практический пример: проект по подключению банка к платформе цифрового рубля. По сути задача подрядчика — взять готовое «коробочное» решение и аккуратно встроить в существующий ландшафт банка. Но банк банку рознь, и сложность проекта будет меняться в зависимости от инфраструктуры заказчика. У всех свои учетные системы, АБС, платежные хабы — и с этим нужно считаться.
Отталкиваясь от этого кейса, расскажем, кто и зачем нужен с обеих сторон.
На стороне разработки у проекта обычно есть несколько ключевых ролей:
Внедренец — это руки и опыт проекта; человек, который умеет зайти в тестовый контур клиента, прописать коннекторы к ABS, настроить обмены и пройти с банком все необходимые чек-поинты. В проектах, вроде цифрового рубля, где нет устоявшихся многолетних практик, именно внедренцы «прокладывают мост» между «коробкой» и реальной инфраструктурой, и от их практической сноровки часто зависит срок выхода в прод.
Тимлид смотрит на всю систему целиком, оценивает риски интеграции, принимает решения по архитектурным компромиссам и следит, чтобы отдельные куски не «порвали» общую картину.
И, наконец, служба поддержки — те, кто остается после релиза: мониторят системы, объясняют банку, почему «все упало» и как быстро вернуть сервис в рабочее состояние.
Кто нужен со стороны банка-заказчика:
Во-первых, бизнес-заказчик: тот, кто четко понимает, зачем банку цифровой рубль (или любой другой проект), какие бизнес-метрики должны измениться и какие сценарии для пользователей критичны. Если бизнес не может сформулировать результат — «что мы хотим получить», — то даже идеально написанное ТЗ рискует не решить нужную задачу.
Аналитик — переводчик между мирами: он садится с представителем бизнеса банка, вытаскивает истинные ожидания и преобразует их в техзадания, сценарии и acceptance-критерии. Хороший аналитик задаст те самые неудобные вопросы, которые сэкономят недели доработок. (Кстати, может быть и на стороне исполнителя!)
Далее идут эксперты по внутренним системам: администраторы АБС, специалисты платежных систем. Они показывают, как «у нас это работает», а не только как «должно работать по регламенту». И именно их ответы определяют сложность интеграции.
И, пожалуй, самый важный герой этой истории — проджект-менеджер со стороны банка. Проджект не просто координатор встреч и согласований; это входящее лицо для подрядчика, навигатор ресурсов внутри банка и человек, который формирует road map проекта. Он не обязан быть экспертом в цифровом рубле, не обязан разбираться в жизненном цикле продукта (это задача разработчика!).
Но именно проджект — тот самый «золотой персонаж», вокруг которого складывается ядро грамотного ТЗ: он переводит бизнес-задачу в управляемый набор задач, собирает экспертов, согласовывает сроки. Без такого человека подрядчик рискует блуждать по коридорам банка в поисках решений и документов, а проект — съехать по срокам и объему.
Постановка задач: как избежать «ХЗ»
Феномен, когда непонятно ни зачем мы делаем эту систему, ни какие задачи она должна решать, ни кто будет отвечать за результат, коротко и метко нахывают «ХЗ». Когда в момент постановки технического задания все сводится к набору абстрактных пожеланий, то на выходе вместо продукта часто получается компромисс, который не радует ни бизнес, ни подрядчика.
Так как его избежать? Что важно учитывать?
1. Бизнес-ценности задачи. Разработчики и подрядчики могут сколько угодно спорить о том, как именно реализовать ту или иную функцию, но ключевое слово здесь — зачем. Если бизнес не может внятно объяснить, какой результат он хочет получить, техническая команда рискует утонуть в догадках.
Это не значит, что подрядчик ждет от банка подробного описания алгоритмов или интеграций. Но ему важно понять, какие сценарии решают задачу бизнеса, а все остальное они проработают уже вместе.
2. Глубина проработки задач. Одна из частых ошибок в банковских проектах — поверхностное ТЗ. Оно вроде бы есть, но на деле представляет собой пару абзацев текста и схему на слайде. «Хотим приложение для знакомств» — это не ТЗ. Такое задание быстро разрушается о реальность, потому что разработчикам приходится додумывать детали. А это рост времени и костов.
Есть хорошая практика — написание технического задания на уже знакомую функциональность. То есть, например, если подрядчик уже внедрял цифровой рубль в банки, значит у него есть опыт того, что может пойти не так в самых неожиданных местах.
Поэтому важно 1) работать с опытной командой, у которой есть бэкграунд разработки вашего потребности, 2) показывать это техническое задание всем участникам процесса — неприятные сюрпризы могут появиться на разных этапах разработки.
3. Участие бизнеса в разработке. Если вы думаете, что бизнесу достаточно поучаствовать в формировании road map проекта и вернуться только на этапе сдачи — это большая ошибка. Когда задачи и требования формулируют и принимают только айтишники, велик риск, что продукт получится удобным для интеграции, но абсолютно бесполезным для конечного клиента банка.
4. Итеративное ТЗ. Не пытайтесь описать систему «раз и навсегда» в начале проекта, а собирайте требования по слоям, перепроверяйте каждую гипотезу на промежуточных демо, получайте обратную связь и двигайтесь дальше. Такой метод позволяет банку сохранять контроль над конечным результатом, а подрядчику — быстрее реагировать на изменения. Более того, регулярные встречи помогают бизнесу и разработчикам говорить на одном языке и синхронизировать ожидания.
Любое ТЗ должно пройти проверку на двух уровнях. Сначала его смотрят бизнес-заказчики и дают понять, соответствует ли документ их задачам. Затем подключаются разработчики и архитекторы — проверяют, можно ли это вообще реализовать в имеющихся системах. Если на одном из этапов выявляется противоречие, документ возвращается на доработку. Такая двойная валидация значительно снижает риск того, что команда окажется в ситуации «ХЗ».
5. Не «как», а «что». Бизнес должен описывать свой продукт и задачи, которые он будет выполнять. Но техническая реализация — прерогатива подрядчика. Задача банка — задать направление и сформулировать ценность. Когда этот баланс соблюдается, у проекта появляется шанс не только завершиться успешно, но и дать реальный эффект.
Что получается
Все, о чем мы говорили выше, можно свести к трем простым, но жизненно важным правилам.
Прежде всего — бизнесу важно самому для себя честно ответить: какой результат он хочет получить и по каким метрикам будет понимать, что проект удался. Без этой точки на горизонте любая работа рискует превратиться в бесконечное обсуждение деталей.
Второе — доверие. Когда бизнес начинает диктовать, какие именно технологии использовать и как писать код, проект стопорится. Пусть инженеры выбирают путь реализации, это их зона экспертизы.
И, наконец, третье — регулярная обратная связь. Не раз в квартал, когда уже все сделано, а по ходу работы: через демо, промежуточные показы, обсуждения. Именно там вскрываются ошибки на ранней стадии, когда их еще легко поправить.
Если собрать эти правила вместе, получается нехитрый рецепт: бизнес определяет цель, ИТ показывает дорогу, а весь проект движется вперед в постоянном диалоге. И тогда риск оказаться в ситуации «ХЗ» снижается почти до нуля.
