Conference for DevOps, Software Architects and Engineers. Regular price ends 27/09!
×Закрыть

Пожарная команда и бег на опережение: как мы строим 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 потребуются именно эти скиллы. И мы будем готовы.

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

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

LinkedIn

4 комментария

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

Отличная статья.

Рома , подскажи пожалуйста , а какая у вас матрица технологий на сегодняшний день.

И есть ли понимание какая она будет через год?

Привет, Аркаш, да матрица есть. Стратегически она включает в себя экосистему спринга (Pivotal), Scala + lightbend stack, немного JBoss, ну и ассорти различных опенсорсных библиотек и технологий.

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

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

Спасибо, очень содержательная статья.

Для каждого из них есть индивидуальное требование: примерно 80% времени он должен заниматься реальными проектами.

Полтора часа в день не на многое хватит. Предполагается, что энтузиасты занимаются активностями СС в свободное время, правильно? Примерно, как в предыдущей статье о центрах экспертизы — dou.ua/...​/centers-of-excellence-2 Может получится, что не все время на тушение пожара на важном проекте нужно отмечать исходя из альтруистической лояльности? Либо другой вывод, что обязательные 8 отмеченных часов для СС, возможно, на самое важное требование. Но тогда сложно совместить работу одного человека на проекте и в СС.

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

Согласен, что 80% это довольно много, это требование сейчас не высеченно в камне, мы эксперементируем с этим. С другой стороны это 1 день в неделю, за это время можно уже сделать что-то полезное. Еще один вариант для эксперта — выделение 1-2 месяцев в году на работу на развитие и перспективу.

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

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

Подписаться на комментарии