Приветствую всех! Позвольте представиться: я, руководитель команды разработки и частично PM, вышедший из мира системного проектирования и хардовой аналитики.

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

1. собрать команду с нуля, проработать под проект необходимые портреты сотрудников по компетенциям;

2. заложить архитектуру информационной системы, решения и проекта целиком, которая потом не должна координально измениться, а что ещё более важно - высоконагруженную со всеми нюансами надежности, быть готовыми не просто к каким-то парам сотен РПС на вход, а ждать в поток на порядок больше;

3. произвести реинженеринг существующего бизнес-процесса и переработать тонну кода батчевого решения;

4. подготовить команду к корпоративному производственному процессу;

5. сработать совершенно новую команду и перевести от шторминга к перформингу (вообще не просто).

Когда передо мной стоят задачи, будь то создание системы управления данными, автоматизация документооборота с применением функций искусственного интеллекта, создание решения по высокопроизводительной обработке данных в реальном времени или просто реализация программного обеспечения для бизнеса, я готов к действию, но начать всё с нуля и только с бизнес потребности - новый вызов! Ранее я создавал с нуля и проектировал графовые решения, системы по управление данными, поддерживал и развивал гео и ML платформу, поэтому опыт в разработке и проектировании далеко не один год и в совершенно разных компаниях. В моей системе координат любая потребность клиента — это не просто задача, а возможность реализовать потенциал технологий во благо бизнеса, поэтому я готов оценить любой запрос бизнеса от финансовых затрат и бюджета до необходимых ресурсов. Каждый проект — это сложное уравнение, где балансируются факторы времени, чёткости воспроизведения требований, финансов, скорости и ресурсов с учетом коэффициента риска проекта. Однако, в мире финтеха правила меняются, особенно в текущих реалиях, когда всё идет на импортозамещённом стеке, и требования к гибкости и адаптивности умножаются и порой многократно, а коэффициент риска заранее увеличен. ИТ-разработка в финансовой сфере и в мире больших корпораций — это не просто выполнение задач, это постоянное прохождение кругов ада (может это моё ощущение), где нужно уметь отвечать и быть готовым отвечать на вызовы, которые могут прийти откуда угодно.

А вообще хочу поделиться, что может ждать руководителя команды разработки (PM, PO) , если он начинает делать проект в большом интерпрайзе, я же буду описать финтех. Возможно на твоём пути этого не будет, тогда ты счастливый человек))

Круг 1 — Долгий найм сотрудников

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

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

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

Есть у меня знакомые руководители, которые по несколько месяцев ищут себе специалистов, ну, ребят, реально??? Лично для меня, почти всегда можно найти специалиста, достаточно оперативно, даже если корпоративный хантер не может помочь, то я иду в свой блог, статьи, мессенджеры, конференции, каналы, сообщества, знакомым и нахожу нужных ребят, это не просто "бахвальство", а факты. Поэтому, для того, чтобы поиск специалиста не проходил в авральном режиме — планируйте свой проект и процесс разработки. А если уж проблема появилась, то не брезгуйте применять разные подходы к поиску кандидатов и помните! Хантеры с их как бы "скоростью света" это не предел и будьте проактивны.

Когда у меня появилась задача срочно собрать высококвалифицированную команду разработки, я сначала сформировал для себя портрет каждого кандидата, стек и предварительную архитектуру, приоритет найма, далее пошёл искать людей всюду. Если мы с вами знакомы, то думаю вы не раз видели мои посты. По итогу, за 2 месяца и команда собрана, где корпоративные HR менеджеры помогли только с двумя. Более подробно рассказывал в докладах на конференциях HighLoad++ 2024 и Анализ и управление проектами 2024.

Круг 2 — Бюрократия и тонна документации

Как вы поняли безопасность и соответствие регуляторным требованиям стоят на первом месте, поэтому каждое изменение в системе должно быть строго документировано, одобрено соответствующими подразделениями, службами и органами управления. Это значит, что для того чтобы просто начать работу над проектом, приходится пройти через целый ряд формальных процедур и заполнить кучу бумажек, только не на физическом уровне, а виртуально, но это не умоляет сложность процедур и процессов. Далее следует составление документации по требованиям (БТ, ФТ, НФТ), архитектуре, тестированию и многим другим аспектам проекта в рамках процесса разработки, каждый из которых должен быть подробно и точно описан, а также обоснован. Время «пожирается» тут у всей команды, особенно у аналитиков и тестировщиков, а от руководителя команды требует умения работать в условиях повышенной ответственности и стресса, а также эффективно координировать работу всей команды, чтобы все документы были выполнены в срок и соответствовали корпоративным стандартам и правилам.

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

Если вы идёте в большие корпорации — ожидайте много документации (всё зависит от компании) и что она будет съедать в процессе разработки постоянно время и отнимать ресурсы команды.

Круг 3 — Заказчик с постоянными изменениями требований

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

Работа с заказчиком и бизнесом в целом, который постоянно меняет свои требования и показания, как вы поняли это следующий адский круг перед релизом. В условиях постоянных изменений везде и всюду, а также форматов планирования проектов, продуктов и их контрольных точек мы воле-неволе приходим к тому, что требования постоянно изменяются и порой координально, а что значит для проработанной архитектуры крайне сложного процесса резкое изменение? Франкенштейн, несостыковка требований и баги… .

Да, бизнес ведь ещё пересматривает свои планы и стратегии, но вот крайне редко контрольные точки, что может приводить к серьезным просрочкам со стороны ИТ, хотя ИТ тут не виновато вообще — жертвы по факту. От того кто ведёт процесс управления командой требуется гибкость, адаптивность, умение быстро реагировать на изменения и перенастраивать команду и процессы разработки, ведь надо соответствовать новым требованиям и ожиданиям. Благо дело сейчас большая часть ИТ мира живет по "скраму" и постоянные изменения — норма (не буду тут глубоко уходить в рассуждения, т.к. у всех точки зрения разные). Кроме того, лид, словно теннисист должен успевать парировать подачи вовремя, уметь убедить заказчика в необходимости определенных изменений и оценить их влияние на сроки и бюджет проекта, чтобы обеспечить его успешное выполнение в условиях постоянной неопределенности и нестабильности. А команде разработки подстраиваться под действительность и в случае сильных перегрузок уметь доносить лидеру команду о проблемах.

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

Круг 4 — Недостаток ресурсов и сложности

ИТ проекты частенько требуют значительных инвестиций как в оборудование и технологии, так и в персонал и процессы разработки. Не забывайте, что процесс разработки программного обеспечения подразумевает не только создание кода, но и комплексный тестировочный процесс. В мире финансовых технологий, где надежность и безопасность данных стоят с высочайшим приоритетом, этот процесс становится особенно важным и трудоемким и вместо двух контуров у вас становится 4, 5, 6… а дальше зависит от корпоративных подходов, правил и т.п. Возможно, вы слышали о таких контурах разработки, как:

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

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

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

• Предпромышленный и промышленный контуры — предназначены для подготовки продукта к релизу и его внедрению в производственную среду. Здесь проводят финальные тесты и проверки, а также обеспечивают поддержку и обслуживание продукта после его внедрения.

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

Круг 5 — Конфликты с коллегами

Чем больше взаимодействия с различными отделами и командами, где у всех свой интерес и приоритет, тем сложнее, а возможностей выйти на конфликт много. Просто представьте, что команда «А" разрабатывает корпоративный портал и у неё крайне сжатые сроки, а тут заходит команда "Б» и просит сделать для них АПИ и тут возникает вопрос, а когда? Поэтому не всегда интересы между командами совпадают, у всех планы и цели на унтри своего проекта или продукта и чем крупнее корпорация, тем сложнее, хоть компания и одна для компании. Поэтому ИТ лидеру приходится быть не только техническим экспертом, но и лидером, медиатором, который умеет находить общий язык с разными сторонами, находить компромиссы и решения, удовлетворяющие всех участников процесса.

Круг 6 — Интеграция в пайплайн

Как я уже упоминал ранее, работа команды разработки включает не только чистую разработку (см. выше))) , но и важные аспекты, такие как внедрение в пайплайн или автоматизация процессов деплоя до промышленного контура. Здесь важно понимать, что новая функциональность может оказаться заблокированной в ожидании создания или настройки пайплайна, возможно не на один спринт, особенно если ваш проект только начинает свой путь. Подготовка пайплайна и его тестирование могут занять недели, особенно в случае множества контуров от DEV до промышленного. Наша команда совсем недавно была первой в компании, кто поехал до продакшена на совершенно новом конвейере и процесс его отладки и настройки оказался чрезвычайно сложным и затратным по ресурсам. Если разработка заняла X времени, то встройка и настройка CI/CD pipeline порядка 20%. Как то так))

7 — Поддержка и обслуживание

Понимаете, что команда разработки ограничена доступом к старшим контурам, таким как предпрод и продакшн. Это означает, что они не имеют возможности вносить изменения и выпускать релизы самостоятельно. Для этого существует специализированное подразделение — техническая поддержка. Наверняка вы думаете, что в ТП работают профессионалы? Однако, увы, чаще всего там трудятся сотрудники, чьи навыки значительно ниже, чем у разработчиков. И вот здесь начинаются проблемы.

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

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

Заключение

Руководители команд разработки (PO, PM) в финтехе, особенно, если это большие финансовые организации сталкиваются с множеством вызовов и препятствий на пути к успешной реализации проектов и порой есть ощущение, что всё против того, чтобы ты что-то создавал. Но с правильным подходом, гибкостью, адаптивностью к процессам и умением принимать обоснованные решения можно преодолеть любые трудности и обеспечить достижение поставленных целей. Почему же крупные ИТ специалисты работают в финтехе и не уходят в другие, где адских кругов в разы меньше или они почти отсутствуют? Финансы, стабильность, интересный проект, технологии, команда, а дальше у кого что. Главное, что я хочу донести, если ты боишься всего этого, то даже не иди в такие компании, но если тебе не страшно, то подобный вид компаний сможет помочь тебе в серьезном росте, при условии, что ты будешь как электрон не стоять на месте и занимать проактивную позицию. Недеюсь статья получилась интересная и полезная. До встречи в следующих статьях, конференциях и канале Изнанка ИТ.

P.S. Спасибо моей команде - вы классные, без вас бы ничего не получилось!