Запуск центра компетенции: ожидания и реальность

Небольшой рассказ-размышление о том, как мы запускали центр компетенции, что ожидали и что получили.

На московской конференции Infostart Event в 2021 году я уже рассказывал о том, почему решили запустить Центр компетенции.

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

Была поставлена задача:

• Кратно увеличить скорость разработки за счет прихода на продуктовый подход.

• Организовать системную работу с техническим долгом, который на тот момент был очень серьезен.

• И изменить оргструктуру таким образом, чтобы мы могли проверять любую новую гипотезу и встраивать новые продукты – чтобы система управления позволяла это делать.

С 2018 года этот процесс в компании начался, а IT-подразделение в «Спортмастере» – это больше 2000 человек. И где-то к 2021 году это докатилось до направления 1С, когда мы начали строить Центр Компетенции 1С – об этом я рассказывал на московской конференции.

Хвастаемся! Что получилось, что не очень…

Похвастаемся, что получилось за прошедший год:

• Во-первых, мы серьезно взялись за стандартизацию процессов разработки. Нужно понимать, что у нас четыре направления, которые исторически развивались отдельно друг от друга: система для HR, ERP, Бухгалтерия и системы ОПТа. С тремя направлениями нам уже практически удалось договориться, мы для них выработали общие правила, и к четвертому направлению еще придем. Это было, конечно же, непросто, потому что все эти отделы исторически разрабатывали по-своему. Но нам удалось договориться. Опирались на методические рекомендации 1С, мы выработали свои. Более того, это не то чтобы жесткая какая-то общая политика для всех, это скорее правила хорошего тона. Там остается поле для творчества и по направлению, и по конкретному продукту, потому что это иногда нужно.

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

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

Что не получилось – скорее не доделали:

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

• Второй момент – мы не победили техдолг. Его победить в принципе невозможно, он всегда у нас будет. Но сейчас не хватает системной работы с техдолгом. Когда мы работаем по спринтам, приносим заказчику планы на спринт, он говорит: «Вот это мне понятно, а вот это – непонятно, давайте выкинем». Весь техдолг практически всегда попадает в это «давайте выкинем». Заказчик – это вообще очень интересный собирательный образ. Когда мы ему говорим: «Давайте поклеим обои красивые», он говорит: «Окей, давайте попробуем». Аналитики с разработчиками становятся и держат обои. Заказчик говорит: «Отлично, супер, так оставляем». А мы говорим: «Теперь надо бы оттуда людей убрать», он говорит: «Зачем, оно же красиво висит». Поэтому нужно объяснять заказчику, что мы тут сэкономили время, сделали некий костыль, но это нужно обязательно переделать. Работа с техдолгом – это большая системная работа по объяснению заказчику, что переделывать все-таки придется, поэтому техдолг нужно в бэклог и в спринт вставлять.

• И еще мы не приступили к общему архитектурному контролю. Хочется работать с изменениями общей архитектуры более системно, чем просто через канал в Slack, куда каждый пишет, что он собирается поменять. Но нам кажется, что пока что СППР для этой цели использовать дорого и тяжело. В общем, пока не решили.

Размышляем… некоторые кейсы за прошедший год

Теперь про несколько кейсов, которые у нас произошли в течение 2022 года.

Я уже упоминал разницу между продуктовым и проектным подходом.

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

• У продукта подход другой – нужно максимально быстро дать результат избыточными ресурсами. Поэтому нам нужно каким-то образом создать этот избыточный ресурс.

Плюсы и минусы понятны:

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

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

При переходе от проектного к продуктовому подходу возникает «совместительство», поскольку мы должны обеспечить ресурсную избыточность и «размножить» людей в рабочем контексте.

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

• до этого он был в одной роли – разработчика или аналитика;

• а теперь он еще участвует в центре компетенции как эксперт по бизнес-области,

• и выступает как продакт лид для продукта.

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

Поскольку раньше работа строилась в иерархии – был начальник, который распределял задачи. А сейчас у нас плоские команды, где все равны, возникает ряд проблем:

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

• Если нет иерархии, возникают недопонимания. А поскольку ответственность общая – за продукт отвечает команда, возникают рабочие конфликты, которые потом могут переходить в разряд личностных. Это тоже проблема.

• Ну и третий момент – это погружение нового специалиста. Если продукт и команда незрелые, и мы погружаем туда нового специалиста, то он оказывается либо в ступоре, либо в шоке. У нас один человек так через неделю сбежал, не смог.

Что с этим всем делать?

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

Про набор сотрудников.

Я представляю Центр компетенции 1С, и мне Product Lead прислал вакансию с четкими требованиями. Я ее читаю, понимаю, ага, профиль такой-то. Можно ли отходить от этого профиля, учитывая, что профиль с резюме часто не совпадает? В общих словах, конечно, совпадает – но после слова 1С обычно начинаются расхождения.

• Первый кейс. Невнятное резюме, собеседование, «ну, ладно, все равно больше никого нет», и в итоге «вау, суперспециалист». Редкий случай, это как в лотерею выиграть. Но такие люди есть, и, если они проработали достаточно большое количество лет и набрались опыта, но при этом не прикипели к текущему контексту, они могут и переключать контекст – это важно.

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

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

Вечный вопрос – в чем ценность центра компетенции?

• С одной стороны, то, что мы делаем – это тусовка, это профессиональное общение, накопление и обмен знаниями, совместный поиск решений, творчество, в конце концов. Это все у нас есть.

• Но при этом есть люди, которые считают, что это какой-то космос, к ним не относящийся. У них есть свой огород, тяпка и картошка, а все остальное их не интересует.

Что с этим делать, я так до сих пор не решил, потому что этих людей достаточно много.

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

А что будет дальше?

Что планируем делать дальше?

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

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

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

• Ну и хочется вернуться к выработке единых архитектурных подходов и способов контроля. Канал в Slack через некоторое время перестанет быть функциональным, и придется что-то еще придумывать. Тут вопрос совершенно открытый.

Вопросы

Чем сейчас занимается Центр Компетенции?

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

Плюс набор. В Центр Компетенции сейчас ресурсно вошли разработчики, тестировщики, но пока не все аналитики.

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

А какой смысл изначально закладывался в функции Центра Компетенции? Что хотели покрыть изначально? Справляетесь ли вы? И какой вообще глобальный вектор, который вы закладываете в Центр Компетенции?

Глобально — это ресурсный центр, то, о чем я только что говорил.

В идеальной ситуации у нас все участники продуктовой команды набираются из разных Центров Компетенции. Есть ЦК Product Lead, ЦК аналитиков, ЦК тестировщиков, ЦК 1С – в зависимости от того, какой продукт команда будет использовать.

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

И Product Lead с улицы тоже не возьмешь – лучше его вырастить из аналитика или из разработчика.

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

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

Я допускаю, что кого-то это будет нервировать. Более того, я не думаю, что эта тема станет обязательной. Ко мне приходят люди и говорят: «Что бы мне такого изучить, чтобы быть полезным и мне было интересно». С этих людей я, пожалуй, и начну. Скорее всего, массово я это в ближайшее время внедрять не буду. Пусть люди привыкнут, что это на самом деле хорошо для них в первую очередь. Да, обязательства какие-то придется на себя брать.

Как вы растите своих разработчиков, какие грейды есть? Можете привести примеры того, как у вас растут с джуна до сеньора?

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

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

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

Есть сейчас черновик. Я клятвенно пообещал нашим, что в этом году мы все-таки к этой теме приступим. У нас есть ощущение, где джун, где мидл, где синьор.

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

Вы еще сказали, что, когда человек вырастает, вместо него появляется вакуум. Как вы заполняете этот вакуум?

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

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

Отличный нормальный выход. Мы пользуемся подрядчиками. Но везде нужен баланс. На ключевых компетенциях нужно своих поставить все-таки.

Есть разные направления и разные случаи. Решаем индивидуально в каждом случае. У нас есть подрядчики, и мы ими пользуемся.

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

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

Вы пытаетесь привлечь именно зарплатой или у вас есть еще какой-то мотивационный фон, который распределяется по KPI? Как это работает у вас?

У нас есть и зарплата, и вот эти KPI, которые запустились с прошлого полугодия.

Бизнес не всегда доволен тем, что делает IT. Должны быть общие цели. Сейчас пытаемся срастить общие цели между IT и бизнесом. На это у нас будут завязаны KPI в этом году.

Когда появился KPI, стало лучше или хуже?

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.