Пожарная команда и бег на опережение: как мы строим Java Competence Center в EPAM

Уже несколько лет я занимаюсь развитием Центра компетенций Java в EPAM. За это время он успел поменять head-базу, стал частью внутреннего обучения, сформировал Java-экспертизу для работы над сложными проектами.

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

Как все начиналось, или Поиск идеальной формулы

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

Когда 8 лет назад я пришел в компанию, подобных структур здесь еще не было. Java Competence Centre (Java CC) начал свою работу в 2012 году и изначально базировался в Минске. Основная группа экспертов находилась там же. В какой-то момент Head Центра компетенций решил заняться другими активностями, а я предложил свою кандидатуру на эту позицию. К тому моменту я накопил немало инженерного и организационного опыта на проектах, поэтому давно хотел сделать подобную структуру, где можно было бы применить знания и поделиться ими. Прошел интервью с CTO компании, который утвердил меня на эту позицию. Так Head Java CC переместился в Харьков.

Конечно же, еще на старте в 2014 году мы анализировали опыт подобных структур в других компаниях. Я изучал примеры крупных компаний, например, Oracle и IBM, где центры компетенций по некоторым темам работают как выделенные структуры. Они накапливают опыт в своих направлениях и консультируют по ним клиентов.

На различных конференциях общался с ребятами из украинских компаний, спрашивая, как у них устроены центры компетенций. Максимум, о чем мне рассказывали: определенный фокус на развитие education, внутренние университеты и тренинги, построение скилл-матриц.

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

В поисках своей идеальной формулы в построении Центра используем два момента.

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

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

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

У нас Java охватывает широкий пласт. В сферу входит (и может потенциально входить) много технологий, поэтому построить Центр компетенции, который закрывает все вопросы только лишь тренингами или другими вариантами обучения, практически невозможно. Что-то из результатов своих поисков я брал за основу — это модели профессиональных сервисов Lightbend, Red Hat и Apache Ignite, которые фокусируются на накоплении практического опыта и предоставлении конкретных платных сервисов. В итоге многое приходится строить конкретно под нас.

Структура и организация

В Java CC несколько достаточно больших направлений деятельности.

Первое — организация комьюнити, которой занимается целая структура. Это комьюнити-менеджеры от HR бизнес-партнеров и комьюнити-драйверы от Java.

Второе — архитектурная команда, которая занимается пресейлом, customer engagement и SWOT-кейсами, в которых необходима серьезная инженерная поддержка. Стабильного состава у этой команды нет, но есть некий core. Это 5-6 архитекторов, с которыми мы постоянно работаем и знаем, что их уровень достаточно высокий для решения сложных кейсов.

Дальше мы привлекаем к активностям разработчиков или архитекторов с продакшна. С их помощью команда довольно легко расширяется, когда приходит RFP, RFI или случается какой-то SWOT-кейс. Тогда архитектор из core-группы возглавляет активность технически, подбирает разработчиков и архитекторов под конкретный кейс и выступает супервизором. Как руководитель центра компетенции, я возглавляю архитектурную группу. Так что большинство «красных», сложных и важных кейсов в итоге проходят через меня и эту группу. В некоторых из таких кейсов я тоже участвую как ведущий архитектор.

Третье направление — образование. Эта группа занимается созданием тренинговых и менторинг-программ. В ней есть люди, которые отвечают за определенные тренинговые направления по Java. А сама группа наиболее распределена и наименее управляема со стороны Java CC. Объясняется это просто: все education-программы индивидуально разрабатываются под конкретную локацию и ее потребности. И чаще всего — ресурсами этой же локации. Мы же помогаем с формированием программ тренингов, но не управляем ими и не навязываем их локациям. Здесь они ориентируются на свои потребности.

Всего в Центре компетенции примерно 30 человек, которые плотно вовлечены в его работу, более 1500 инженеров, активно участвующих в технических комьюнити, и более 5000 человек в самой компетенции.

Пожарная команда

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

В фокусе нашего внимания самые приоритетные проекты, которые стартуют в EPAM Global. Например, те, которые «на карандаше» у нашего Head of Global Delivery и Country Head-a. Эксперты Центра компетенций привлекаются и в SWOT-кейсы — проекты, которые попадают в красную зону, то есть в них присутствует риск потери денег или клиента. Поэтому часто Центр компетенций напоминает пожарную команду.

Чтобы «возгорание» даже не возникало, мы ищем разные практики, поэтому стараемся собрать вокруг Java CC людей с нестандартным мышлением. Готовой схемы нет, очень часто Центр экспериментирует. Что-то приживается, что-то — нет.

Реальность и продакшн

Как по мне, самое сложное — правильно совместить работу в Центре компетенций и на реальных проектах. Я с трудом представляю, что в какой-либо компании вдруг возьмут и снимут всю рабочую нагрузку с инженеров, отдав им только «красные» кейсы. Как минимум сложно сформировать и контролировать нагрузку. Особенно, если у компании множество локаций.

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

Поэтому на текущий момент мы пробуем выстроить Java CC как некую виртуальную группу. Людей, работающих на продакшене и обладающих определенной экспертизой, знаниями, best practices, мы привлекаем для решения проблем в похожих ситуациях на других проектах.

Есть возможности и для консалтинга. Мы привлекаем экспертов к работе с нашими клиентами и выстраиваем из этого индивидуальную billable утилизацию консультанта.

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

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

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

У нас есть общий по компании Portal Contribute. Все, кто контрибьютит в Центре компетенций, получают определенный денежный бонус. Дальше есть программа для лучших контрибьюторов Центра от самого Центра. Мы мотивируем какими-то уникальными подарками, которые можно получить только от нас. Если человек с нами сотрудничает на регулярных началах, участвует в консультировании, SWOT-кейсах и серьезных engagement, пресейлах, помимо контрибьюта получает проектный бонус и потенциальный годовой бонус от Центра компетенции.

Результаты работы Java CC

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

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

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

К результатам Центра я отношу и акселераторы. Они в компании были и раньше, но ярко не выстреливали. За 2 года мы сделали 2 достаточно успешных акселератора в рамках Java CC: EPAM Delivery Platform и EPAM Microservices Accelerator. Каждый из них помогает привлечь клиентов нашими разработками, быстрее стартовать проекту, упростить разработку или решить другие конкретные задачи.

Оглядываясь в прошлое

Всех этих результатов не было бы без ошибок. В работе Центра компетенций их было не так много, но по прошествии времени легче заметить «точки роста».

Как я уже говорил выше, драма Центра компетенций в том, что приходится заниматься им между другими рабочими задачами. Первый же «красный» кейс, который попал в Java CC, — проект для крупной логистической компании. На пике в нем состояло больше 120 человек. Одновременно делать архитектуру на такую команду и эффективно работать в Центре компетенций — практически нереально.

Если отмотать время на пару лет назад, я бы более грамотно распределил время в плане совмещения продакшн-проектов и Java CC — больше бы отдавал последнему. И более активно привлекал бы к Центру талантливых специалистов компании.

Заглядывая в будущее

Среди прочего наша команда разрабатывает continuous learning. Здесь нам предстоит отвечать на массу вопросов. Как определить, чему нужно обучать специалистов? Что будет востребовано с точки зрения скиллов разработчиков у заказчика? Как заранее подготовить тренинговые программы? Как это совместить с реальным бизнесом на стороне клиента?

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

Под эту скилл-матрицу мы и хотим организовать процесс continuous learning. Исследование новых технологий —> попадание их в матрицу —> по матрице строится образовательная программа —> по образовательной программе обучаются сотрудники —> сотрудники попадают на проект с новыми технологиями.

Каждая из инициатив Java CC — довольно большая. За каждую из них отвечает конкретный человек. Моя задача — подготовить список таких инициатив.

Здесь может возникнуть вопрос — а откуда я беру этот список? Часто — составляю исходя из своего понимания. Готовых решений и алгоритмов нет, кроме как следить за трендами и полагаться на интуицию и опыт.

Планы и рекомендации

Помимо нынешних проектов мы хотели бы заняться двумя основными векторами:

  1. Разработка рекомендаций и методологий. Хороший пример — микросервисный акселератор. Он появился так. В какой-то момент мы поняли, что в ближайшие 3-5 лет тема микросервисов будет очень востребована. Разработали референсную архитектуру для крупных клиентов, изучили несколько разных фреймворков в этой области, прикинули, какие из них будут наиболее востребованы в крупных предприятиях, с которыми мы работаем. Спустя полгода-год после этого спрос на микросервисные проекты вырос до такой степени, что мы не успевали ответить множеству некрупных проектов. Зато в некоторых ситуациях могли привлекать очень крупные. Кроме презентаций мы приносили на переговоры демопроекты и показывали, как это на самом деле работает. Это был наш джокер.
  2. Проактивное обучение технологиям, которые будут востребованы в обозримом будущем. У нас был интересный кейс, когда на базе R&D-лаборатории мы специально обучили группу студентов микросервисному стеку. Потом эта группа студентов попала на один из реальных проектов. И вышло так, что они изначально были подготовлены лучше и работали продуктивнее, чем зрелые специалисты, которые пришли неподготовленными по этому конкретному стеку.

В этом году мы делаем фокус на PaaS-решения — предполагаем, что рано или поздно они будут востребованы заказчиками. В частности, решение на Docker, Kubernetes, Open Shift и других подобных технологиях. После изучения стараемся эту экспертизу постепенно внедрять в реальных локациях. Кто знает, возможно, в следующем «красном» проекте в Java CC потребуются именно эти скиллы. И мы будем готовы.

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

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

Похожие статьи:
Гейміфікацію вже давно застосовують у навчанні. Наприклад, це може бути заробляння зірочок з переходом на нові рівні, якщо...
«Аеророзвідка» — волонтерська ініціатива 2014 року, яка згодом переросла у бойовий підрозділ і громадську організацію,...
Компания Astell&Kern представила на российском рынке новую модель Hi-Fi плеера AK320, который внешне сочетает флагмана линейки...
Сергій Пуріш обійняв посаду СЕО компанії ENESTECH Software, яка входить до холдингу TECHIIA. Він замінив на цій позиції Ельчина...
Во время очередного общения пользователей сети Facebook, и её основателя, Марка Цукерберга было сделано официальное...
Яндекс.Метрика