Айтеко: от джуна до лида - растим собственных экспертов

 - Виктор, расскажите, как организован процесс разработки в Айтеко и какие методологии и подходы вы используете?

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

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

Директор по разработке ГК «Айтеко» Виктор Бурлаков
Фото: ГК «Айтеко»

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

 - Как устроена команда разработчиков в рамках структуры ГК?

 - У нас команды распределены по портфелям - есть заказчик или группа заказчиков. Это может быть крупный заказчик, под которого будет выделено какое-то направление, или отраслевое подразделение, либо группировка по типу систем. И эти категории объединяются с N-ым количеством проектов в один портфель, управляемый руководителем.

Соответственно, структура управления матричная: есть директор, которому подчиняются руководители направлений, в зависимости от размера проекта - руководителем направления может выступать РП, например, если речь об одном-двух проектах, а если говорим о группе проектов, объединенных в направление, то в них задействованы РП, администраторы и т.д.

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

 - Какие технологии и языки программирования наиболее востребованы?

 - У нас два основных направления. Фронт - Javascript, наверное, 85 % - React, оставшиеся - это Angular.

По мобильной разработке есть как Flutter, так и нативная разработка. Все зависит от предпочтений клиента, поэтому что в одном случае, что в другом, нам интересны такие команды. С точки зрения бэка у нас два основных языка и фреймворка - Java Spring и C# .NET Core.

Для баз данных мы используем, в первую очередь, PostgreSQL, Clickhouse, под хайлоад и большие данные - Hadoop.

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

 - На каких наиболее интересных проектах работает Айтеко?

 - Для нас основной фокус - это импортозамещение, переход на гостех, встраивание и обучение ИИ, работа с ML. Работа у нас интересна множеством разнообразных проектов, где нам удается успешно лавировать с точки зрения задач, тем самым избегая монотонности. У нас редко бывают проекты, которые длятся 5-8-10 лет, и специалисты сидят на них и не развиваются, потому что занимаются одним и тем же.

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

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

 - А что у вас с обучением, как оно устроено?

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

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

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

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

 - Расскажите о корпоративной культуре Айтеко.

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

С другой стороны, есть большой объем автономии. У нас действительно многие проектные команды могут жить, вообще не подозревая о существовании друг друга, то есть у нас есть некоторые сотрудники, которые приходят в офис и не знают, что за коллеги работают с ними (конечно, это может быть как плюсом, так и минусом одновременно). Специалисты работают в абсолютно разных рабочих графиках. Кто-то приходит к 8 утра, кто-то к 11-ти. Кто-то засиживается допоздна. Есть и те, кто полностью на удаленке. То есть это такая, в хорошем смысле, гибкая история.

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

 - Как компания поддерживает баланс между работой и личной жизнью сотрудников?

 - Мы гибкие в вопросе баланса. Человек сам предлагает комфортные условия, обсуждаем это на входе. Не контролируем тайминг. Если задачу, на которую выделено 4 часа, сотрудник закрыл за 2 - окей, он свободен. Но если постоянно не успевает - разбираемся. Либо корректируем планирование, либо понимаем, что человек медлителен или халявит. Подсказываем, что это не наш путь. Если не понимает - прощаемся с рекомендацией.

У нас среда роста, местами агрессивная. Либо растешь, либо уходишь. Редко остаются те, кто не развивается.

 - А как вы оцениваете результат, как контролируете процесс?

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

Также принятая в Айтеко практика – оперативно реагировать на риски и не тушить пожары собственными ресурсами. Крайне редко подключаем дополнительных специалистов просто так, а лишь тогда, когда выделен конкретный пул задач, который четко можно распараллелить, и мы понимаем, что подключение новой команды, новых специалистов однозначно закроет их быстрее, чем задействованные сотрудники. Мое субъективное мнение, как правило, подключение новых специалистов контрпродуктивно. Я даже могу сказать, что зачастую нужно некоторых специалистов убрать из команды для того, чтобы процесс пошел лучше.

 - Какие качества вы особо цените в разработчиках?

 - В первую очередь, порядочность, это качество я отношу к soft skills. Это отсутствие желания пускать пыль в глаза, рисоваться, предоставлять недостоверную информацию, например, при планировании. Второй момент – кичиться какими-то достижениями. IT позволяет получать крутые взлеты и точно такие же крутые спуски. И нужно понимать, что в какой-то момент придется много поработать, и к этому должна быть готовность.

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

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

 - Сейчас много молодых специалистов, недавних выпускников, замечаете ли вы отличия в подходах, идейной составляющей работы по сравнению с более старшим поколением?

 - Да, молодые специалисты отличаются. Старшее поколение пришло в IT, когда это было наполовину работой, наполовину хобби. Сейчас из-за рекламы высоких зарплат теряется энтузиазм. Молодёжь думает больше о деньгах, чем о системном развитии навыков. Вместо этого думают так: «Джависты зарабатывают больше дотнетчиков, пойду в Java». При этом не учитывают, что для сертификации информационных систем Java-машины дороже и сложнее, чем .NET Core. С точки зрения OpenSource-сообщества .NET Core даже более открыт, чем Java. Да, в Java можно зарабатывать на 20-30 % больше, но в перспективе 5 лет на российском рынке C# может оказаться интереснее.

Энтузиастов стало не меньше в абсолютных числах, но их доля уменьшилась. Раньше было 80 % энтузиастов, 20 % «бизнесменов», теперь наоборот. Среди молодых специалистов тяжело найти тех, кто горит делом.

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

 - Большое спасибо за беседу!