Более 6 лет внутри EPAM развивается собственный Центр компетенции Java. Изначально он стартовал в Минске, где и находилась основная группа экспертов. Со временем головная база переехала в Харьков, а Java Competency Center масштабировался на всю компанию. И стал при этом некой виртуальной “пожарной” командой.
О том, как формировалась структура Центра, сложностях и достижениях, рассказывает Роман Шрамков, Director of Technology и глава Java CC. А также объясняет, зачем вообще компаниям и IT-специалистам подобные внутренние проекты, и с чего начинать их построение.
Назначение Центра компетенции вытекает из его названия — он помогает усилить те точки компании, где есть специфическая нужда в технологической экспертизе. К примеру, в определенных стадиях проекта или сложном пресейле с заказчиком. Или если разработчик взялся за самоапгрейд и ищет, где почерпнуть самых востребованных знаний по Java. В идеале Центр должен концентрировать все best practices в своем сегменте.
Java CC работает в EPAM с 2012-го года, а я возглавил его в 2014 году. Тогда мы проходили организационную развилку, и было большое искушение взять за образец подобные образования у техногигантов. В IBM и Oracle это некие выделенные структуры, которые концентрируют опыт в определенной тематике и консультируют клиентов. Но информации по таким центрам крайне мало. Правда, кое-какие результаты “раскопок” я заложил в фундамент. К примеру, это модели сервисов Lightbend, Red Hat и Apache Ignite. Они накапливают практический опыт и предоставляют платные экспертные сервисы.
Параллельно мы пробовали понять, что там у наших коллег по рынку. Ребята из украинских IT-компаний рассказывали, что у них подобные центры — это, в основном, внутренние образовательные направления или скилл-матрицы.
К образовательной части нам необходимо было присоединить проектную. В частности, собирать экспертов, которых можно привлекать на переговоры с клиентом для обсуждения технической части. Плюс Java у нас охватывает широкий пласт — одними тренингами это не закроешь.
В итоге от какого-то жесткого, а уж тем более привязанного к локации формата мы отказались. Ведь в каждой точке присутствия компании — свои задачи. Поэтому в поисках нужной формулы опираемся на два принципа.
Мы стремимся сконцентрировать вокруг Java Competency Center нестандартно мыслящих специалистов. А потому приходится экспериментировать.
Костяк Центра — около 30 человек. Это люди, которые плотно задействованы в его работе. Кроме них есть 1500+ инженеров, которые активно участвуют в технических комьюнити, и 5000+ человек вообще в Java-компетенции.
Основные “узлы” Java CC такие.
Если в общем, то Центр компетенции — это распределенная группа специалистов, которая решает сложные вопросы в разных локациях. И мы не ограничены ни какой-либо страной, ни тем более отдельным бизнес-юнитом.
Один из самых сложных моментов для Центра: мы не можем забрать лучших инженеров полностью для работы с “красными” кейсами или только для обучения, сняв с них остальную рабочую нагрузку. Это усложнит контроль и частично оторвет их от реальности.
Требование для любого из наших экспертов: около 80% времени он должен заниматься реальными проектами. Преимущество — нет зацикливания на теории. Очевидный минус — при таких нагрузках сложно обеспечить эффективную структуру Центра компетенции. А команда, напомню, и так распределена.
Поэтому пока что мы выстраиваем Java CC в виде виртуальной группы. Люди работают на продакшене, прокачивают экспертизу. Мы же привлекаем их, чтобы они поделились знаниями и best practices в проектах, подобных тем, с которыми они уже сталкивались. Также они помогают нам в консалтинге клиентов, а мы формируем из этого billable утилизацию. Главное, чтобы вхождение эксперта в кейс было целесообразно.
Есть несколько моделей взаимодействия с центром компетенции:
Мотивация контрибьюторов — важный момент. Да, круто поработать в сложных проектах и дополнительно прокачать себя. Но нужны и материальные поощрения. Это денежный бонус, от компании для тех, кто контрибьютит в Центре компетенции. От Центра предусмотрена отдельная мотивация: лучшим контрибьюторам мы дарим подарки от Java CC. А для тех, кто нам помогает постоянно, участвует в консалтинге, пресейлах, “красных” кейсах, также предусмотрен бонус за проект и, потенциально, годовой бонус от Центра компетенции.
Достижения Центра можно условно поделить на два типа. Внешние — это, конечно, список сложных проектов, полученных, решенных или вытянутых с участием экспертов Центра. О каждом кейсе можно писать отдельную историю. Что важно: Java CC помог в большой распределенной компании сформировать круг экспертов, заинтересованных в Java-компетенции. А без такого сосредоточения специалистов, пусть даже “облачного”, ничего бы не получилось. Это уже внутренние позитивные эффекты.
В рамках Центра было создано несколько акселераторов, которые помогают привлекать клиентов, упростить запуск или текущую разработку. К примеру, за два года наша команда экспертов сделала два успешных акселератора: EPAM Delivery Platform и EPAM Microservices Accelerator.
Кроме того, рождаются проекты для обучения сотрудников: запустились учебные инициативы, новостные рассылки о Java-технологиях, группы по обсуждению апдейтов. Есть постоянный поток полезной информации для инженеров.
Continuous learning — еще одна большая задача Центра. Это то поле, где мы пытаемся прицелиться в будущее, а потому постоянно спрашиваем сами себя:
Для ориентира мы используем скилл-матрицу. В нее проставляем навыки, которые, как мы считаем, должны быть у разработчика от Junior до Chief. Матрица — точно не истина в последней инстанции, скорее, опора для разработчиков. Ребятам, развивающимся в Java, она помогает ориентироваться, на изучении чего лучше сосредоточить свои усилия на каждом уровне.
Отталкиваясь от скилл-матрицы, мы и хотим наладить continuous learning. Алгоритм такой: исследуем новые технологии —> они попадают в ячейки матрицы —> согласно матрице формируется образовательная программа —> по программе учатся сотрудники —> сотрудники попадают на проект, уже ориентируясь в новых технологиях.
Хотя сейчас наша структура распределена, в будущем хотелось бы выстраивать группы компетенций в разных локациях. Но пока мы укрепляем нынешнюю структуру.
Java CC двигается по двум основным векторам.
1. Разработка рекомендаций и методологий.
Так у нас стартовал микросервисный акселератор, который я упоминал выше. Мы спрогнозировали, что в ближайшие 3-5 лет микросервисы станут популярной темой. Сделали на это акцент: разработали референсную архитектуру для крупных клиентов, изучили ряд фреймворков, выделили из них те, которые больше всего востребованы на крупных предприятиях, с которыми мы сотрудничаем. И не прогадали — вскоре микросервисные проекты действительно взлетели по спросу. Благодаря акселератору мы шли на встречи к крупным клиентам хорошо подготовленными и сразу с демопроектами.
2. Обучение технологиям, на которые будет спрос в ближайшем будущем.
Как пример — на базе R&D-лаборатории мы целенаправленно обучили команду студентов-стажеров микросервисному стеку. На проекте, куда их направили, ребята работали продуктивнее, чем их коллеги — более опытные, но не имевшие подготовки именно по микросервисам.
Сейчас делаем акцент на PaaS-решениях — в частности, на Docker, Kubernetes, Open Shift, Cloud Foundry и подобных. Думаем, что спрос на них вскоре вырастет. Изучаем, пробуем поэтапно интегрировать экспертизу в живых задачах — готовимся к следующим проектам наших клиентов.
Если вы решили создать центр компетенции, то, как и при старте чего бы то ни было, важно определиться с проблематикой и кейсами компании, которые вы ему поручите. А также понять/подумать/посчитать, какую ценность он может вам принести.
Допустим, у вас в компании работает группа людей с определенной экспертизой. Как потенциально они могут улучшить ваш бизнес? Что в сравнении с конкурентами даст вам такой ресурс? И, разумеется, сколько вы готовы инвестировать в эту структуру: времени, денег, нематериальных поощрений?
Ответы на эти вопросы дадут вам основания для первых шагов. А дальше — только действовать, экспериментировать и быть начеку.
О том, как формировалась структура Центра, сложностях и достижениях, рассказывает Роман Шрамков, Director of Technology и глава Java CC. А также объясняет, зачем вообще компаниям и IT-специалистам подобные внутренние проекты, и с чего начинать их построение.
Как это выстраивается
Назначение Центра компетенции вытекает из его названия — он помогает усилить те точки компании, где есть специфическая нужда в технологической экспертизе. К примеру, в определенных стадиях проекта или сложном пресейле с заказчиком. Или если разработчик взялся за самоапгрейд и ищет, где почерпнуть самых востребованных знаний по Java. В идеале Центр должен концентрировать все best practices в своем сегменте.
Java CC работает в EPAM с 2012-го года, а я возглавил его в 2014 году. Тогда мы проходили организационную развилку, и было большое искушение взять за образец подобные образования у техногигантов. В IBM и Oracle это некие выделенные структуры, которые концентрируют опыт в определенной тематике и консультируют клиентов. Но информации по таким центрам крайне мало. Правда, кое-какие результаты “раскопок” я заложил в фундамент. К примеру, это модели сервисов Lightbend, Red Hat и Apache Ignite. Они накапливают практический опыт и предоставляют платные экспертные сервисы.
Параллельно мы пробовали понять, что там у наших коллег по рынку. Ребята из украинских IT-компаний рассказывали, что у них подобные центры — это, в основном, внутренние образовательные направления или скилл-матрицы.
К образовательной части нам необходимо было присоединить проектную. В частности, собирать экспертов, которых можно привлекать на переговоры с клиентом для обсуждения технической части. Плюс Java у нас охватывает широкий пласт — одними тренингами это не закроешь.
В итоге от какого-то жесткого, а уж тем более привязанного к локации формата мы отказались. Ведь в каждой точке присутствия компании — свои задачи. Поэтому в поисках нужной формулы опираемся на два принципа.
- постоянно тесно общаемся с другими центрами компетенции внутри компании — для обмена ценной информацией и идеями по организации;
- все время мониторим проблематику Java-направления — делаем стратсессии, обсуждаем вызовы и ищем решения.
Мы стремимся сконцентрировать вокруг Java Competency Center нестандартно мыслящих специалистов. А потому приходится экспериментировать.
Как это выглядит
Костяк Центра — около 30 человек. Это люди, которые плотно задействованы в его работе. Кроме них есть 1500+ инженеров, которые активно участвуют в технических комьюнити, и 5000+ человек вообще в Java-компетенции.
Основные “узлы” Java CC такие.
- Структура, которая организовывает комьюнити: комьюнити-менеджеры от HR бизнес-партнеров и комьюнити-драйверы от Java.
- Команда архитекторов. Ее привлекают в customer engagement, пресейлы и SWOT-кейсы (проекты, в которых есть риск потери денег или клиента, где нужна усиленная инженерная поддержка). Эта часть очень гибкая. Но внутри нее — core-группа, 5-6 архитекторов с высоким уровнем экспертизы. С ними мы работаем постоянно. В команду по необходимости и под задачу привлекаются архитекторы или разработчики с продакшна. А архитектор из core-группы для них становится техническим управленцем и супервизором.
- Образовательная группа. Ее участники создают тренинговые и менторские программы по Java. Группа очень разбросана и управляется Центром компетенции по-минимуму. Ведь программы обучения формируются исключительно под задачи отдельной локации. Причем, зачастую там же и выделяют на это ресурсы. От нас в этом есть помощь, но никогда не навязывание.
Если в общем, то Центр компетенции — это распределенная группа специалистов, которая решает сложные вопросы в разных локациях. И мы не ограничены ни какой-либо страной, ни тем более отдельным бизнес-юнитом.
Как учитывается работа
Один из самых сложных моментов для Центра: мы не можем забрать лучших инженеров полностью для работы с “красными” кейсами или только для обучения, сняв с них остальную рабочую нагрузку. Это усложнит контроль и частично оторвет их от реальности.
Требование для любого из наших экспертов: около 80% времени он должен заниматься реальными проектами. Преимущество — нет зацикливания на теории. Очевидный минус — при таких нагрузках сложно обеспечить эффективную структуру Центра компетенции. А команда, напомню, и так распределена.
Поэтому пока что мы выстраиваем Java CC в виде виртуальной группы. Люди работают на продакшене, прокачивают экспертизу. Мы же привлекаем их, чтобы они поделились знаниями и best practices в проектах, подобных тем, с которыми они уже сталкивались. Также они помогают нам в консалтинге клиентов, а мы формируем из этого billable утилизацию. Главное, чтобы вхождение эксперта в кейс было целесообразно.
Есть несколько моделей взаимодействия с центром компетенции:
- Помочь на старте. Эксперт Центра следит, чтобы новый проект запустился корректно, а команда оперативно собирала знания. После устаканивания процессов и перехода команды к планомерному выполнению задач эксперт выходит из проекта.
- Помочь советом. Эксперт консультирует команду только по отдельным возникающим вопросам.
- Помочь по конкретной задаче. Эксперт вовлекается в проект плотно, но только на определенный срок. Отдельно устанавливаются критерии выхода из проекта.
Мотивация контрибьюторов — важный момент. Да, круто поработать в сложных проектах и дополнительно прокачать себя. Но нужны и материальные поощрения. Это денежный бонус, от компании для тех, кто контрибьютит в Центре компетенции. От Центра предусмотрена отдельная мотивация: лучшим контрибьюторам мы дарим подарки от Java CC. А для тех, кто нам помогает постоянно, участвует в консалтинге, пресейлах, “красных” кейсах, также предусмотрен бонус за проект и, потенциально, годовой бонус от Центра компетенции.
Что успели и что планируем
Достижения Центра можно условно поделить на два типа. Внешние — это, конечно, список сложных проектов, полученных, решенных или вытянутых с участием экспертов Центра. О каждом кейсе можно писать отдельную историю. Что важно: Java CC помог в большой распределенной компании сформировать круг экспертов, заинтересованных в Java-компетенции. А без такого сосредоточения специалистов, пусть даже “облачного”, ничего бы не получилось. Это уже внутренние позитивные эффекты.
В рамках Центра было создано несколько акселераторов, которые помогают привлекать клиентов, упростить запуск или текущую разработку. К примеру, за два года наша команда экспертов сделала два успешных акселератора: EPAM Delivery Platform и EPAM Microservices Accelerator.
Кроме того, рождаются проекты для обучения сотрудников: запустились учебные инициативы, новостные рассылки о Java-технологиях, группы по обсуждению апдейтов. Есть постоянный поток полезной информации для инженеров.
Continuous learning — еще одна большая задача Центра. Это то поле, где мы пытаемся прицелиться в будущее, а потому постоянно спрашиваем сами себя:
- как определить, какие знания пригодятся специалистам?
- какие скиллы разработчика будут востребованы у заказчика?
- какие обучающие программы нужно подготовить, чтобы опередить спрос на новые технологии?
- как все это соединить с работающим бизнесом заказчика?
Для ориентира мы используем скилл-матрицу. В нее проставляем навыки, которые, как мы считаем, должны быть у разработчика от Junior до Chief. Матрица — точно не истина в последней инстанции, скорее, опора для разработчиков. Ребятам, развивающимся в Java, она помогает ориентироваться, на изучении чего лучше сосредоточить свои усилия на каждом уровне.
Отталкиваясь от скилл-матрицы, мы и хотим наладить continuous learning. Алгоритм такой: исследуем новые технологии —> они попадают в ячейки матрицы —> согласно матрице формируется образовательная программа —> по программе учатся сотрудники —> сотрудники попадают на проект, уже ориентируясь в новых технологиях.
Как видим будущее
Хотя сейчас наша структура распределена, в будущем хотелось бы выстраивать группы компетенций в разных локациях. Но пока мы укрепляем нынешнюю структуру.
Java CC двигается по двум основным векторам.
1. Разработка рекомендаций и методологий.
Так у нас стартовал микросервисный акселератор, который я упоминал выше. Мы спрогнозировали, что в ближайшие 3-5 лет микросервисы станут популярной темой. Сделали на это акцент: разработали референсную архитектуру для крупных клиентов, изучили ряд фреймворков, выделили из них те, которые больше всего востребованы на крупных предприятиях, с которыми мы сотрудничаем. И не прогадали — вскоре микросервисные проекты действительно взлетели по спросу. Благодаря акселератору мы шли на встречи к крупным клиентам хорошо подготовленными и сразу с демопроектами.
2. Обучение технологиям, на которые будет спрос в ближайшем будущем.
Как пример — на базе R&D-лаборатории мы целенаправленно обучили команду студентов-стажеров микросервисному стеку. На проекте, куда их направили, ребята работали продуктивнее, чем их коллеги — более опытные, но не имевшие подготовки именно по микросервисам.
Сейчас делаем акцент на PaaS-решениях — в частности, на Docker, Kubernetes, Open Shift, Cloud Foundry и подобных. Думаем, что спрос на них вскоре вырастет. Изучаем, пробуем поэтапно интегрировать экспертизу в живых задачах — готовимся к следующим проектам наших клиентов.
Что можем порекомендовать
Если вы решили создать центр компетенции, то, как и при старте чего бы то ни было, важно определиться с проблематикой и кейсами компании, которые вы ему поручите. А также понять/подумать/посчитать, какую ценность он может вам принести.
Допустим, у вас в компании работает группа людей с определенной экспертизой. Как потенциально они могут улучшить ваш бизнес? Что в сравнении с конкурентами даст вам такой ресурс? И, разумеется, сколько вы готовы инвестировать в эту структуру: времени, денег, нематериальных поощрений?
Ответы на эти вопросы дадут вам основания для первых шагов. А дальше — только действовать, экспериментировать и быть начеку.
Foreglance
Можете поделиться — почему Java? Не .NET?
mad_nazgul
В статье же ответили. Потому что возникла инициатива «снизу».
Для .NET такой инициативы не возникло выходит. :-)
Foreglance
Вопрос возник, поскольку периодически оцениваем — какие языки и фреймворки предпочтительно использовать для будущих проектов, исходя из ретроспективы, текущего состояния и трендов.
ros-77
эта статья о Java центре компетенции, в компании есть и другие центры компетенции, в том числе и .NET (Microsoft). Какие компетенции развивать решается на базе анализа трендов и запросов от наших клиетов.
Компетенции разделены т.к. для каждой из них проблемы, которые надо решать и возможности, которые возникаю на рынке часто разные.
В рамках Java компетенции, которая сама по себе очень широкая, мы тоже анализиуем фреймворки и подходы, которые возникают на рынке и осваиваем их внутри компании.
Foreglance
Центры компетенции — отличная идея, спасибо что поделились. Интересно было бы узнать о том, как можно организовать взаимодействие таких центров и мнение ваших экспертов о текущем состоянии и перспективах технологий разработки.
ros-77
Часто взаимодействие организовывается ситуативно, в зависимости от кейса над которым мы работаем. Просто привлекаются эксперты из разных ценров.
Некоторые центры могут иметь и достаточно плотное взаимодействие, т.к. они часто работают вместе. В таком случае главы центров компетенции договариваются о координации действий.
Плюс ежегодно мы собираемся вместе, чтобы обсудить результаты года в разных центрах и обсудить интересные инициативы на следующий год.
Все это позволяет быть в курсе того кто чем занимается и привлекать правильные центры компетенции и правильных экспертов, когда это необходимо.
ros-77
На самом деле у нас, если не ошибаюсь, более 20 центров компетенции разного размера и уровня зрелости. Постоянно появляются и новые, происходит это как снизу, когда группа специалистов понимает, что она хочет получить видимость на уровне компании так и сверху, когда бизнес решает, что необходимо развить определенную компетенцию, чтобы расширить наше предложение.