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

Давайте расскажу, как это выглядит изнутри. 

Итак, это не было осознанным решением. За несколько лет я сменил четыре компании, причем в одной из них сменил еще и три проекта. Дальше мы начали внедрять CRM в банке. Я тогда думал, будет несколько месяцев. Начинал на одном софте как интегратор, потом перешёл на другой как интегратор, побыл проектировщиком общим, потом функциональные решения проектирования. Потом, последние годы, архитектором. 

Несмотря на то, что я для банка внешний сотрудник из Джета, «на той стороне» меня считают своим работником. Ещё я очень хорошо понимаю требования заказчика (за десять-то лет!), и потому мне доверяют в плане принятия решений, как лучше сделать. Это важно, потому что обычно интеграторам не очень-то верят, они тяготеют к «своим» вендорам. А вот если это потом и поддерживать, и знать, что ты в ответе за архитектуру на годы вперед, — это все резко меняет. Я знаю, что я же буду развивать всё это спустя год или два, и не откатывать решение, не переделывать. 

Но всё равно десять лет — это, конечно, аномалия. Если об этом задуматься, становится страшно.

Как начинался проект

Для «Инфосистемы Джет» было очень важно сделать этот проект хорошо. Шел 2012 год, и тогда это был первый опыт в создании и развитии CRM для крупного банка — на рынке за ним пристально следили. На проект взяли профильную команду по софту, который мы с заказчиком выбрали, плюс в неё добрали тех, кто понимал в CRM. На стороне банка нас стало человек 20. По сути, кто что умел, тот за то и брался, поэтому большой проект «надгрызался» неравномерно, по кускам. 

Я на тот момент подключал банки к SWIFT — это совершенно было не похоже на то, чем мне пришлось в итоге заниматься на этом проекте. Думал, что просто буду курировать интеграцию на стыках с дополнительным ПО, и сделал первую интеграцию с AБС. Стык с ядром банковской системы, очевидно, был нужен, чтобы автоматизировать документооборот. 

За полгода мы переделали карточку клиента так, что вносить данные в нее могли сотрудники разных подразделений банка. И автоматизировали минимальный кредитный конвейер. В основном это всё работало для заявок на потребительские кредиты. Потом подключили автокредиты — это был второй этап. Чуть позже — кредитные карты. Дальше было создание в AБС открытия счетов для кредитов и кредитной сделки. А через год запустили оформление ипотеки. Это наиболее сложный процесс, работа с залогами: множество документов и разных этапов.

В этот момент на проекте установился порядок, большие куски в духе «о, это-то я сделаю быстро» закончились, появился чёткий план релизов. Ещё через год у «Инфосистемы Джет» появились и другие заказчики под это ПО, часть коллег перешла к ним на проекты. Да и у нашего банка объём работ чуть-чуть уменьшился. Тем не менее на проекте осталось человек десять. Всё время нужно было что-то доделывать и улучшать, чтобы стало хорошо, и всё время были нужны мои знания. 

Я ощущал, какую пользу приношу проекту.

Через 5 лет…

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

Где-то через пару лет релизы стали оформляться раз в месяц или даже чуть реже (с тех пор мы так и работаем: в год выходит примерно семь довольно больших релизов).

Потом пошла длительная автоматизация. Сами дописывали некоторые модули, например для анализа работодателей заёмщика и поручителя заявки.

По сути, именно на CRM держалась выдача кредитов: мы собирали в ней данные о клиенте, а решение во многом зависело от сотрудника банка. Затем банковское дело развилось до того, что роль сотрудника снизилась до минимума — скоринг стал делаться по общим признакам, переехал во внешние скоринговые системы. Появилась специальная система алгоритмов принятия решений с бизнес-стратегиями. 

Наш софт должен был в эту систему передать максимум всех собранных данных. Это был ещё один грандиозный проект, который на старте казался мне новым. Не продолжением того, чем мы занимались до этого, а как будто перешел на новую работу. Несколько лет делали стратегии: с помощью одной принимается решение, а другие, специальные, используются для работы с кредитной историей, со скорингом, с хантерами, для расчёта финансовых условий и так далее. 

Параллельно очень много документов переносилось из бумаги в системы банка. 

В 2018–2020 годах конвейер дошёл до полной автоматизации: даже когда заявка на кредит прилетала из внешнего для банка источника, она автоматически ложилась во все системы, автоматически собиралась информация про клиента и дальше без чьего бы то ни было участия шла по стадиям. Этот конвейер дополнялся: добавили личный кабинет на сайте, мобильный клиент, подключили партнеров вроде автосалонов. 

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

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

Сейчас

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

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

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

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

Моя экспертиза в АБС и широкое понимание банковской деятельности были нужны на уровнях всё выше и выше. Поэтому мне в какой-то момент такая позиция даже стала нравиться больше, чем погружение в различный инструментарий. Сейчас я в основном занимаюсь анализом сложных ситуаций, особенно где локализовать причину проблемы сложно.

Советы

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

У меня мотивация падала много раз. Но совет такой: переждите, это временно. Первая пара спадов интереса к проекту пройдет и сменится другим настроением. Надо помнить, что спады неизбежны даже на самых интересных проектах. Хорошо помогает смена ролей. Я так рос от инженера до архитектора и сейчас стал менеджером. 

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

Комфортно ли мне сейчас? Думаю, да. Я хорошо зарабатываю, я чувствую, что делаю крутые вещи, чувствую, что у меня реально сильные решения и огромная экспертиза. Нравится ли мне это в целом? Ну, если не думать, что я на этом проекте настолько давно, то да.

Сергей

Архитектор департамента разработки бизнес-систем в «Инфосистемы Джет»