![](https://habrastorage.org/getpro/habr/upload_files/a85/fd4/c35/a85fd4c352a6b49b2921e9b6e1faa017.jpg)
Приветствую всех! Позвольте представиться: я, руководитель команды разработки и частично PM, вышедший из мира системного проектирования и хардовой аналитики.
Цель данной статьи - рассказать реальные проблемы с которыми сталкивается команда при создании нового продукта и её лидер в большом финтехе и да, не просто с чьих то слов, а прочувствовав всё на собственной шкуре. В прошлом году я взял достаточно большой и серьезный проект, где нужно было на старте:
собрать команду с нуля, проработать под проект необходимые портреты сотрудников по компетенциям;
заложить архитектуру информационной системы, решения и проекта целиком, которая потом не должна координально измениться, а что ещё более важно - высоконагруженную со всеми нюансами надежности, быть готовыми не просто к каким-то парам сотен РПС на вход, а ждать в поток на порядок больше;
произвести реинженеринг существующего бизнес-процесса и переработать тонну кода батчевого решения;
подготовить команду к корпоративному производственному процессу;
сработать совершенно новую команду и перевести от шторминга к перформингу (вообще не просто).
Когда передо мной стоят задачи, будь то создание системы управления данными, автоматизация документооборота с применением функций искусственного интеллекта, создание решения по высокопроизводительной обработке данных в реальном времени или просто реализация программного обеспечения для бизнеса, я готов к действию, но начать всё с нуля и только с бизнес потребности - новый вызов! Ранее я создавал с нуля и проектировал графовые решения, системы по управление данными, поддерживал и развивал гео и ML платформу, поэтому опыт в разработке и проектировании далеко не один год и в совершенно разных компаниях. В моей системе координат любая потребность клиента — это не просто задача, а возможность реализовать потенциал технологий во благо бизнеса, поэтому я готов оценить любой запрос бизнеса от финансовых затрат и бюджета до необходимых ресурсов. Каждый проект — это сложное уравнение, где балансируются факторы времени, чёткости воспроизведения требований, финансов, скорости и ресурсов с учетом коэффициента риска проекта. Однако, в мире финтеха правила меняются, особенно в текущих реалиях, когда всё идет на импортозамещённом стеке, и требования к гибкости и адаптивности умножаются и порой многократно, а коэффициент риска заранее увеличен. ИТ-разработка в финансовой сфере и в мире больших корпораций — это не просто выполнение задач, это постоянное прохождение кругов ада (может это моё ощущение), где нужно уметь отвечать и быть готовым отвечать на вызовы, которые могут прийти откуда угодно.
А вообще хочу поделиться, что может ждать руководителя команды разработки (PM, PO) , если он начинает делать проект в большом интерпрайзе, я же буду описать финтех. Возможно на твоём пути этого не будет, тогда ты счастливый человек))
Круг 1 — Долгий найм сотрудников
А теперь к проблемам - долгий и изнурительный найм — это, наверное, один из сложнейших и важнейших шагов, т.к. от будущей команды зависит успешность всего проекта. А нанимаемые сотрудники должны быть квалифицированными, иметь похожий или соответствующий опыт, а с учётом сжатых сроков — это челендж.
![Ждём, когда хантер приведёт нужного специалиста.... А нужно ли ждать? Не будь мистером Ожидай. Ждём, когда хантер приведёт нужного специалиста.... А нужно ли ждать? Не будь мистером Ожидай.](https://habrastorage.org/getpro/habr/upload_files/42c/5df/fb7/42c5dffb787226d9bee75a56d9d4fc4d.png)
То что найм квалифицированных специалистов в области ИТ — это сложно и трудно, я уже говорил, а особенно сейчас, ну вы понимаете о чём я, сейчас есть реальный дефицит высококвалифицированных кадров. А в нашей среде, где конкуренция за хорошие кадры особенно острая, найм становится весьма изнурительным, добавьте ещё пару щепоток бюрократии — ммм, что это за блюдо)))).
![Если нужно быстро, то только Яша)) Если нужно быстро, то только Яша))](https://habrastorage.org/getpro/habr/upload_files/9b5/9c3/45d/9b59c345d26f507aea47c9d0c92a0a1b.png)
Начиная с составления требований к вакансии и публикации объявлений, заканчивая проведением нескольких раундов собеседований и проверкой кандидатов на соответствие безопасности, каждый шаг этого процесса требует внимания, времени и ещё раз времени. Более того, в мире финтеха, где конфиденциальность и безопасность данных играют крайне важную роль, процесс проверки кандидатов может быть особенно тщательным и длительным, тут конечно не будут сидеть для обычных позиций с детекторами лжи, но тем не менее. Лидеру команды приходится буквально пробиваться сквозь лабиринты рекрутинга, чтобы найти тех специалистов, которые не только соответствуют требованиям проекта, но и готовы вложить свои силы и знания в достижение его целей, ещё и удостовериться, что этот человек тот самый. Это требует не только профессионализма и опыта, но и терпения, настойчивости и умения принимать решения в условиях неопределенности и нестандартных ситуаций.
Есть у меня знакомые руководители, которые по несколько месяцев ищут себе специалистов, ну, ребят, реально??? Лично для меня, почти всегда можно найти специалиста, достаточно оперативно, даже если корпоративный хантер не может помочь, то я иду в свой блог, статьи, мессенджеры, конференции, каналы, сообщества, знакомым и нахожу нужных ребят, это не просто "бахвальство", а факты. Поэтому, для того, чтобы поиск специалиста не проходил в авральном режиме — планируйте свой проект и процесс разработки. А если уж проблема появилась, то не брезгуйте применять разные подходы к поиску кандидатов и помните! Хантеры с их как бы "скоростью света" это не предел и будьте проактивны.
Когда у меня появилась задача срочно собрать высококвалифицированную команду разработки, я сначала сформировал для себя портрет каждого кандидата, стек и предварительную архитектуру, приоритет найма, далее пошёл искать людей всюду. Если мы с вами знакомы, то думаю вы не раз видели мои посты. По итогу, за 2 месяца и команда собрана, где корпоративные HR менеджеры помогли только с двумя. Более подробно рассказывал в докладах на конференциях HighLoad++ 2024 и Анализ и управление проектами 2024.
Круг 2 — Бюрократия и тонна документации
![А можно просто пописать код? Ну или принципами Agile воспользоваться... А можно просто пописать код? Ну или принципами Agile воспользоваться...](https://habrastorage.org/getpro/habr/upload_files/0cf/b71/dde/0cfb71dde0791f5cc538adfba3043344.png)
Как вы поняли безопасность и соответствие регуляторным требованиям стоят на первом месте, поэтому каждое изменение в системе должно быть строго документировано, одобрено соответствующими подразделениями, службами и органами управления. Это значит, что для того чтобы просто начать работу над проектом, приходится пройти через целый ряд формальных процедур и заполнить кучу бумажек, только не на физическом уровне, а виртуально, но это не умоляет сложность процедур и процессов. Далее следует составление документации по требованиям (БТ, ФТ, НФТ), архитектуре, тестированию и многим другим аспектам проекта в рамках процесса разработки, каждый из которых должен быть подробно и точно описан, а также обоснован. Время «пожирается» тут у всей команды, особенно у аналитиков и тестировщиков, а от руководителя команды требует умения работать в условиях повышенной ответственности и стресса, а также эффективно координировать работу всей команды, чтобы все документы были выполнены в срок и соответствовали корпоративным стандартам и правилам.
Если идете в крупные компании, то будьте готовы к большому количеству документации, я не шучу — тонне документации... Помню когда работал в одной из компаний производственного сектора, то нам достаточно было просто технического задания и описания как пользоваться клиенту нашим приложением — всё, а теперь шаг влево/вправо — пакет согласованной документации.
Если вы идёте в большие корпорации — ожидайте много документации (всё зависит от компании) и что она будет съедать в процессе разработки постоянно время и отнимать ресурсы команды.
Круг 3 — Заказчик с постоянными изменениями требований
Команду собрали, документацию почти побороли — успех?? А как же новые требования? Давайте чутка поправим спецификацию нескольких API методов, и совсем немножко изменим бизнес процесс, ну там пару действий заменим ))) Для бизнеса всегда все просто, а вот начнёшь исследовать и анализировать и да, понимаешь, что как бы за минорной правкой разработка в пару человеко-дней, функциональное и регрессионое тестирование....документация....
![Поздравляем! БТ обновленно и вам нужно за день всё перепилить! Поздравляем! БТ обновленно и вам нужно за день всё перепилить!](https://habrastorage.org/getpro/habr/upload_files/c98/d37/7e4/c98d377e40ec7b9832889262cc1c29bf.png)
Работа с заказчиком и бизнесом в целом, который постоянно меняет свои требования и показания, как вы поняли это следующий адский круг перед релизом. В условиях постоянных изменений везде и всюду, а также форматов планирования проектов, продуктов и их контрольных точек мы воле-неволе приходим к тому, что требования постоянно изменяются и порой координально, а что значит для проработанной архитектуры крайне сложного процесса резкое изменение? Франкенштейн, несостыковка требований и баги… .
Да, бизнес ведь ещё пересматривает свои планы и стратегии, но вот крайне редко контрольные точки, что может приводить к серьезным просрочкам со стороны ИТ, хотя ИТ тут не виновато вообще — жертвы по факту. От того кто ведёт процесс управления командой требуется гибкость, адаптивность, умение быстро реагировать на изменения и перенастраивать команду и процессы разработки, ведь надо соответствовать новым требованиям и ожиданиям. Благо дело сейчас большая часть ИТ мира живет по "скраму" и постоянные изменения — норма (не буду тут глубоко уходить в рассуждения, т.к. у всех точки зрения разные). Кроме того, лид, словно теннисист должен успевать парировать подачи вовремя, уметь убедить заказчика в необходимости определенных изменений и оценить их влияние на сроки и бюджет проекта, чтобы обеспечить его успешное выполнение в условиях постоянной неопределенности и нестабильности. А команде разработки подстраиваться под действительность и в случае сильных перегрузок уметь доносить лидеру команду о проблемах.
В общем, изменения будут всегда, будьте готовы к этому, тут надо просто четко светить бизнесу, что любое изменение требований — изменение сроков и если вы хотите попасть в контрольную точку проекта, то будьте готовы увеличить погрешность попадания в бизнес потребность, так как из-за некоторых требований приходится изменять кода по нескольку раз, а порой и переписывать полностью. Наличие на руках маршрутной карты проекта облегчит вам жизнь.
Круг 4 — Недостаток ресурсов и сложности
![](https://habrastorage.org/getpro/habr/upload_files/27f/837/e6d/27f837e6dbbd81704db909608f2a0125.png)
ИТ проекты частенько требуют значительных инвестиций как в оборудование и технологии, так и в персонал и процессы разработки. Не забывайте, что процесс разработки программного обеспечения подразумевает не только создание кода, но и комплексный тестировочный процесс. В мире финансовых технологий, где надежность и безопасность данных стоят с высочайшим приоритетом, этот процесс становится особенно важным и трудоемким и вместо двух контуров у вас становится 4, 5, 6… а дальше зависит от корпоративных подходов, правил и т.п. Возможно, вы слышали о таких контурах разработки, как:
Контур разработки и экспериментов — предназначен для создания и тестирования новых функций и возможностей продукта. Разработчики здесь могут свободно экспериментировать и исследовать новые идеи, чтобы улучшить пользовательский опыт и функционал продукта.
Контур системного и функционального тестирования — происходит тестирование различных аспектов продукта, включая его функциональность, производительность, безопасность и совместимость с другими системами. Иногда тут проводят и регрессивное тестирование, а вообще тут работают над выявлением и устранением ошибок и дефектов, чтобы обеспечить стабильную и надежную работу продукта перед его интеграционным тестированием.
Контур интеграционного тестирования — тестирование взаимодействия продукта с другими системами и сервисами, с которыми он должен взаимодействовать.
Контур нагрузочного тестирования — тестирование производительности и масштабируемости продукта под различными нагрузками и условиями использования, проверяется, как продукт работает при высоких нагрузках, стремятся оптимизировать его производительность и эффективность.-
Предпромышленный и промышленный контуры — предназначены для подготовки продукта к релизу и его внедрению в производственную среду. Здесь проводят финальные тесты и проверки, а также обеспечивают поддержку и обслуживание продукта после его внедрения.
Не всегда компания может выделить достаточно ресурсов на реализацию проекта, особенно если он предполагает использование новых технологий или разработку сложных систем, где требуется много железа и не на один стенд. Поэтому приходится искать компромиссы и альтернативные решения, чтобы обеспечить выполнение проекта в рамках ограниченных бюджетных и временных рамок. Так что готовьтесь оптимизировать расходы и использовать ресурсы эффективно, также будьте готовы принимать риски и нестандартные решения в условиях неопределенности и ограниченных возможностей.
Круг 5 — Конфликты с коллегами
![](https://habrastorage.org/getpro/habr/upload_files/fa2/6db/990/fa26db990596355936465e76054961b5.png)
Чем больше взаимодействия с различными отделами и командами, где у всех свой интерес и приоритет, тем сложнее, а возможностей выйти на конфликт много. Просто представьте, что команда «А" разрабатывает корпоративный портал и у неё крайне сжатые сроки, а тут заходит команда "Б» и просит сделать для них АПИ и тут возникает вопрос, а когда? Поэтому не всегда интересы между командами совпадают, у всех планы и цели на унтри своего проекта или продукта и чем крупнее корпорация, тем сложнее, хоть компания и одна для компании. Поэтому ИТ лидеру приходится быть не только техническим экспертом, но и лидером, медиатором, который умеет находить общий язык с разными сторонами, находить компромиссы и решения, удовлетворяющие всех участников процесса.
Круг 6 — Интеграция в пайплайн
![](https://habrastorage.org/getpro/habr/upload_files/59a/b50/400/59ab504005e60135edefee453ca9ed10.png)
Как я уже упоминал ранее, работа команды разработки включает не только чистую разработку (см. выше))) , но и важные аспекты, такие как внедрение в пайплайн или автоматизация процессов деплоя до промышленного контура. Здесь важно понимать, что новая функциональность может оказаться заблокированной в ожидании создания или настройки пайплайна, возможно не на один спринт, особенно если ваш проект только начинает свой путь. Подготовка пайплайна и его тестирование могут занять недели, особенно в случае множества контуров от DEV до промышленного. Наша команда совсем недавно была первой в компании, кто поехал до продакшена на совершенно новом конвейере и процесс его отладки и настройки оказался чрезвычайно сложным и затратным по ресурсам. Если разработка заняла X времени, то встройка и настройка CI/CD pipeline порядка 20%. Как то так))
7 — Поддержка и обслуживание
![Поддержка не обижайтесь, у вас другая картина мира) Поддержка не обижайтесь, у вас другая картина мира)](https://habrastorage.org/getpro/habr/upload_files/f63/82f/f72/f6382ff72908a1fb9ed2f6c88518c268.png)
Понимаете, что команда разработки ограничена доступом к старшим контурам, таким как предпрод и продакшн. Это означает, что они не имеют возможности вносить изменения и выпускать релизы самостоятельно. Для этого существует специализированное подразделение — техническая поддержка. Наверняка вы думаете, что в ТП работают профессионалы? Однако, увы, чаще всего там трудятся сотрудники, чьи навыки значительно ниже, чем у разработчиков. И вот здесь начинаются проблемы.
Поддержка часто не в полной мере понимает, что происходит в системе. Кроме того, один сотрудник технической поддержки обычно отвечает за несколько информационных систем. Это приводит к ситуации, когда он не в состоянии глубоко понимать каждую систему на уровне разработчика, что часто оказывается нереальным. В результате возникает вторая проблема: перегрузка поддержки. А вот третья проблема — это классическая история любой корпорации: бюрократия, я говорил о ней и снова затрону, т.к. чтобы решить даже маленькую проблему, вам придется составить обоснование и заполнить кучу документов, описаний, планов....
Из моего опыта работы с поддержкой могу сказать одно: стремитесь к взаимопониманию! Необходимо находить общий язык и договариваться. У меня был случай, когда один из моих руководителей поссорился с поддержкой, и это привело к серьезным последствиям: взаимные обвинения, более тщательное контролирование каждого шага в разработке — это было подобно аду, особенно учитывая значимость проекта. Сейчас я стараюсь максимально находить общий язык с поддержкой, ну иначе вы сами понимаете, что может быть!
Заключение
Руководители команд разработки (PO, PM) в финтехе, особенно, если это большие финансовые организации сталкиваются с множеством вызовов и препятствий на пути к успешной реализации проектов и порой есть ощущение, что всё против того, чтобы ты что-то создавал. Но с правильным подходом, гибкостью, адаптивностью к процессам и умением принимать обоснованные решения можно преодолеть любые трудности и обеспечить достижение поставленных целей. Почему же крупные ИТ специалисты работают в финтехе и не уходят в другие, где адских кругов в разы меньше или они почти отсутствуют? Финансы, стабильность, интересный проект, технологии, команда, а дальше у кого что. Главное, что я хочу донести, если ты боишься всего этого, то даже не иди в такие компании, но если тебе не страшно, то подобный вид компаний сможет помочь тебе в серьезном росте, при условии, что ты будешь как электрон не стоять на месте и занимать проактивную позицию. Недеюсь статья получилась интересная и полезная. До встречи в следующих статьях, конференциях и канале Изнанка ИТ.
P.S. Спасибо моей команде - вы классные, без вас бы ничего не получилось!
Комментарии (16)
atues
04.08.2024 07:27+4Двух разрабов (миддл и сеньор) на java/kotlin пилить бэкэнд искали 4 месяца. Телеком. Зарплаты конкурентные. Задачи разнообразные и нескучные. Хочешь - офис, хочешь - удаленка, хочешь - гибрид. Очень щадащий аджайл, без идиотских церемоний, приседаний и кришнаитства. Желающих караул сколько. Уровень караул какой. Сыпятся на элементарщине - совершенно базовые вещи, без которых просто невозможно обойтись.
Многие выпускники ВУЗ-ов с порога хотят зарплату минимум миддла, да и то, с таким выражением лица, будто делают мне одолжение. Приходится объяснять, что это не я тебе должен платить совершенно необоснованные деньги, а ты должен, по-справедливости, доплачивать, чтобы я тебя чему-то научил. Ибо знания твои недостаточны, фрагментарны и имеют весьма отдаленное отношение к практике.
Rive
04.08.2024 07:27+21) Сейчас почти все ходят по рынку с кислой миной и занимаются выбирательством, так что расширить знания и стаж кандидаты (без вранья) не могут даже попросту из-за того, что их вообще не зовут на собеседования. Полагаю, именно так и выглядит DDoS-атака, где вместо пакетов - люди.
2) Многие HR по неясной причине отсекают кандидатов с низкой желаемой ЗП, так что её приходится угадывать.
Приходится объяснять, что это не я тебе должен платить совершенно необоснованные деньги, а ты должен, по-справедливости, доплачивать, чтобы я тебя чему-то научил.
Если работодатель хочет чего-нибудь эдакого от рынка труда, но он ему этого не предоставляет за желаемый прайс, то значит - это ему придётся или заняться обучением произвольно выбранного по сообразительности кандидата до своих стандартов, или сидеть и ждать полгода, когда в этой гаче достанется человек с тремя-четырьмя звёздами из пяти, у которого случайно есть релевантный индустриальный опыт.
atues
04.08.2024 07:27ему придётся или заняться обучением произвольно выбранного по сообразительности кандидата до своих стандартов
Так и делаем. Если видим, что пришел пусть не вполне готовый, но желающий учиться за меньшую зарплату и, главное, увлеченный человек - берем. Конечно, есть риск, что он проучившись таким вот образом год-полтора, свалит на более вкусное место. Ну и ладно: свое мы по любому получим. Все равно: все когда-нибудь рано или поздно сваливают
vladimir_lov Автор
04.08.2024 07:27Бывает, поддержу, это как раз непросто из тонны резюме и желающих, найти реально нужных спецов, адекватных и реальными компетенциями.
Примеры: на одном из тех.собесов было слышно, как парень постоянно, что-то пишет и валится на базовой части java. Или вот, хочет больше 500к, а опыта чисто бэкендерского не более 3 лет, а мне нужен был специалист, глубоко знающий flink. С аналитиками, тоже беда, не понимают вообще основ... а денег просили больше разработчиков... и да были джуны с запросом 200к и более, ну тут совсем тяжело))) по итогу я провел более 100 собесов...., чтобы набрать команду, это было жёстко... классно, когда тебе кто-то может кого-то порекомендовать
atues
04.08.2024 07:27+1классно, когда тебе кто-то может кого-то порекомендовать
Тоже самое: в основном, по знакомым, да по прежним местам работы своим и своих ребят из команды. Однажды за раз "отхватил" сразу пару реально крутых ребят, но и то, только потому, что знал их до этого
vladimir_lov Автор
04.08.2024 07:27А как хантеры, помогают?
atues
04.08.2024 07:27+1Очень-очень редко. От хантеров в основном поток шлака. Не отказываемся, но и не надеемся
Rive
04.08.2024 07:27+1От хантеров в основном поток шлака.
Это эффект быстрых свиданий.
Когда можно получить быстрое знакомство с человеком для определённой цели (будь то работа или романтические отношения), то создаётся анонимная связь на основе шаблона "подозрительный незнакомец", т.е. отношение к случайному человеку из потока будет сильно более предвзятым, чем к знакомому знакомых с определённым социальным капиталом.
Если под микроскопом выискивать недостатки у людей и не иметь никаких зацепок к ним, то разумеется 99% пойдут в мусор.
vladimir_lov Автор
04.08.2024 07:27А тут зависит тоже от уровня хантеров, как им поставили тз. У нас хантеры могут быть загружены на два месяца вперёд, и твоя задача будет рассмотрена, но в общем скоупе. Почему я говорил, что не ждите хантеров, если ты ставишь им задачу в бэклог, они не могут её сделать ASAP вот и всё, так как перегружены.
Люди по рекомендации, от хороших знакомых, могут быть намного лучше, так как за их знания уже ручаются, а это дорогого стоит, конечно если ты доверяешь этому знакомому.
dryja
Ну простите, не все могут позволить себе нанять джуна за триста, коих сейчас пруд пруди, потому и ищешь пару месяцев в этой куче нормальных.
Автор в итоге тоже пару месяцев искал, кстати :)
vladimir_lov Автор
Формально 2 месяца, это от вакансии до оформления) по уровню мидлы и сеньеры
vladimir_lov Автор
А вот тема с джунами за 300к интересная, расскажи о чём это??
dph
А сколько относительно рынка добавляли? И сколько человек в команде?