Привет! Сейчас я CTO стрима в Газпромбанке, но начинал, как и все, в небольшой компании, где из ИТ-отдела было только два программиста. Мы же были аналитиками, тестировщиками и архитекторами, только ещё не знали таких слов. Надо было писать код для автоматизации — мы писали, он работал. Часто даже правильно. Если что-то шло не так — к нам приходили пользователи объяснять лично.

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

В 2021 году «завтра» тоже пропало: все захотели аджайла, нулевого TTM и чего-то странного. Мы выстроили диалог с бизнесом так, чтобы у них реализовывались их хотелки, а у нас не копился техдолг. Пришлось пересмотреть очень многое в подходах. Тут уже понадобились программы развития руководителей.

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

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

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

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

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

В то время, когда начинался мой профессиональный путь, я и предполагать не мог, что в 2022 году стану СТО продуктового стрима в Газпромбанке. Потому что СТО стрима — это не только человек, который следит за разработчиками и отвечает за них, но и тот, кто помогает развивать продукт технологически и инженерно. Сейчас у меня сложилось понимание тех ключевых моментов, которые важны для роста компетенций и карьеры в крупной компании. И весь предыдущий опыт мне в этом очень пригодился.

Никогда не останавливаться в развитии

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

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

Так постепенно я становился T-Shape-специалистом: постоянно общался с различными экспертами, изучал, что и как они делали. Сейчас это сильно помогает, потому что я знаю, чем занимается аналитик, что делает тестировщик, как работает бизнес в банке.

Накопленные навыки связаны не только с моими непосредственными обязанностями как разработчика или как лида команды, они шире и очень пригодились в работе СТО стрима. Я вижу, как лучше реализовать какую-то фичу, в чём её ценность для клиентов и для бизнеса, и могу всё это доступно объяснить команде. А когда сотрудник чётко понимает цель, это повышает его мотивацию сделать работу качественнее и быстрее.

Уметь адаптироваться к обстоятельствам и развивать Soft Skills

Условия, в которых мы работаем, постоянно меняются: цели, KPI, ТЗ, фокусы внимания да и вообще множество аспектов жизни, и не только в работе. Умение быстро адаптироваться к новым вводным позволяет оставаться конкурентоспособным в непрерывно меняющейся среде. Гибкость мышления и готовность к изменениям становятся ключевыми качествами, которые помогают не только справляться с вызовами, но и находить новые возможности для роста и развития. Важно не только реагировать на изменения, но и предвосхищать их, чтобы оставаться на шаг впереди.

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

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

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

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

Разбираться в бизнес-процессах и понимать потребности клиентов

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

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

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

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

Стать инженером, а не только программистом

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

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

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

Фундаментальное образование — основа всего

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

Если уметь и хотеть учиться — можно освоить любые необходимые знания и начать в короткие сроки их применять.

Стать вовлечёнными в то, что происходит вокруг

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

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

Понимать бизнес-цели компании

Современный банк сейчас невозможно представить без IT. Теперь банк, по сути дела, — это IT-компания, которая специализируется на финансовых продуктах. Я считаю: чтобы добиться успеха, сотрудники организации должны понимать цели бизнеса, методы достижения этих целей и совместно действовать в этом направлении. IT-разработчики — не исключение.

Теперь нам важно не вести разработку просто по ТЗ, а понимать смыслы и делать бизнес вместе со всей компанией, своим внутренним заказчиком. Именно поэтому так важно развивать рабочий кругозор, выходить из уютной ниши, где «только я и мой компьютер», становиться T-Shaped-специалистом. Необходимо глубже понимать бизнес своей компании, начать осознавать себя частью её продукта, нарабатывать инженерную экспертизу и быть готовыми взять ответственность за результат, не деля её между командами.

Как мы работали

Ещё пару лет назад наш процесс разработки включал в себя такие понятия, как бизнес-заказчики и IT-сотрудники. Т. е. у нас была «каменная стена» между бизнесом и айтишниками: существовали две отдельные группы людей, каждая из которых могла тыкать пальцем в другую и утверждать, что, мол, такого в бизнес-требованиях не было, мы так не договаривались и т. д. А в ответ слышали: «Как мы с вами всё согласовали, так всё и сделали».

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

Переход на Agile-стримы

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

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

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

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

Компонентное тестирование и автоматизация

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

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

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

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

Импортозамещение

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

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

Как добиться профессионального роста в команде

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

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

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

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