DevOps as a Service. Часть 4. Решаем проблемы развития сотрудников подразделения и управления инициативами

Всем привет! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем. В прошлых статьях мы описали сам подход, показали пути решения различных проблем. Со статьями можно ознакомиться здесь Часть1, Часть2, Часть 3. Сегодня мы поговорим о построении процесса развития сотрудников и команды в целом, а также о процессе управления инициативами.

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

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

• CI/CD;

• Мониторинг;

• Виртуализация/контейнеризация;

• Технологии управления инфраструктурой;

• и т.д.

Как всё это может выглядеть?

2) Есть ли у нас регламент или инструкция по проведению пилотов? Нет

3) Как часто нам приходится что-то пилотировать? От 2 до 5 раз в полгода

4) Есть ли у нас техническая площадка обсуждения инициатив по внедрению технологий? Нет

5) Как часто нам необходимо пересматривать архитектуру продукта? Не чаще 1-2 в год

6) Принимают ли участие во внедрении безопасники? Да

7) Есть ли подразделение технической безопасности в компании? Да

8) Сколько в компании систем, проектов и как часто между ними требуются новые интеграции? Несколько продуктов, допустим 4, новые интеграции требуются не часто.        

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

1) Если внедрение чего-то нового, в том числе исследование, происходит не на регулярной основе, например, по 1-2 пилота в месяц, то тут есть смысл управлять только самими пилотами, инициативами по ним и их результатами. В данном случае NAP будет достаточно.

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

3) 2-5 раз в полгода – это, конечно же, мало. Это говорит о том, что либо в компании нет такой необходимости, и в этом ничего плохо нет, либо процессы компании еще недостаточно зрелые, и поэтому утяжелять компанию бюрократизацией процессов за счёт внедрения Техкома или Архкома, нет смысла, достаточно NAP.

4) Если нет, то почему бы не сделать, но исходим из ответов на вопросы выше, что лучше подойдёт.

5) Если у нас всего несколько продуктов, а не 10+ систем и куча проектов, то, пожалуй, это один из основных критериев в пользу того, что Техком тут точно не нужен. Архком, возможно, но как редкое явление, а NAP вполне себе вписывается.

6) Это хорошо, значит должны быть некие требования к безопасности продукта и его разработки, если нет, то стоит задуматься об их появлении.

7) Это всегда хороший знак, если подразделения безопасности нет, то стоит позаботиться о том, чтобы оно появилось, исходя из потребностей бизнеса и стратегии развития продукта компании. Хорошим тоном является вхождение представителей безопасности в Тех и Архкомы. Что касается NAP, то тут будет достаточно DevSecOps специалиста с минимальным набором требований к технологиям.

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

Вывод – достаточно внедрения NAP.
Как может выглядеть данный процесс, и из каких компонентов он состоит?

Компоненты:

• что нам необходимо?;

• чего нам не хватает?;

• какие есть проблемы?;

• инициатива.

А далее идём по процессу:

1) Берём проблемы и задачи компании на год;

2) Понимаем, какие процессы или технологии могут их решить, и какие из них, в свою очередь, пока отсутствуют в компании, снимая при этом информацию по инициативам и хотелкам;

3) Валидируем всё это;

4) Назначаем статусные встречи для обсуждения инициатив и того, что следует пилотировать;

5) Пилотируем отобранные инициативы;

6) Изучаем результаты пилота;

7) Легализуем внедрение того, что пилотировали, если, конечно же, успешно;

8) Внедряем.

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

 

А визуально, например, в базе знаний, так:

 Теперь давайте вернёмся к тому, на чём мы остановились в части валидации внедрения технологий. Пусть внедрение NAP у нас было 4 этапом, посредством которого мы провалидировали все технологии, которые описывали в TO-BE, и согласовали их внедрение.

5 этапом мы попробуем сформулировать механизм развития сотрудников и команды. Если в компании нет принятой системы грейдов или KPI, MBO или иного механизма квартальных целей и их оценки, то это и усложнит, и упростит задачу одновременно. Упростит в том плане, что вы сможете соотнести развитие сотрудника с целями подразделения на год, которые поставите сами и согласуете с руководством, а также сможете сами разработать систему грейдов и матрицу компетенций. Сложности же тут, на мой взгляд, возникнут в двух моментах:

• с точки зрения отсутствия дополнительной финансовой мотивации, если к целям и KPI нет премирования;

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

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

Как формируется ИПР?

• берём задачи компании на год;

• берём MBO или KPI компании на квартал;

• соотносим всё это с квартальным проектами и “хотелками” сотрудников, в том числе о дополнительном обучении и посещении конференций;

• валидируем всё это;

• и получаем первую версию ИПР.

Если все oк, отдаем руководству, проходим дополнительную валидацию, после чего появляется итоговый ИПР сотрудника, за исполнением которого мы наблюдаем в течении квартала, в том числе можно задавать вопросы на one to one встречах. Таким образом, мы закрываем проблему отсутствия контроля за развитием, как каждого сотрудника подразделения, так и команды в целом.

Схематично процесс разработки ИПР выглядит таким образом:

   

Давайте ещё дополним этот процесс и разделим его на 2 фазы, первая из которых может использоваться как механизм принятия решения в пользу успешного завершения новыми бойцами испытательного срока.

Фаза 1. Onboarding:

• собеседование;

• оффер;

• назначение ментора;

• формирование ИПР на испытательный срок;

• серединный срез через 1,5 месяца по исполнению текущих задач ИПР;

• контрольный срез в конце испытательного срока.

Фаза 2. ИПР на год:

• скиллы;

• сильные и слабые стороны;

• цели и стратегия компании;

• квартальные цели компании и подразделения;

• новые проекты и технологии;

• хотелки сотрудников – обучения, технологии, конференции.

Фаза 3. Контроль:

• раз в месяц на one to one обсуждаем текущий статус с каждым;

• раз в месяц контролируем и общаемся на летучках про задачи подразделения на квартал;

• раз в 1,5 месяца индивидуальные и командный промежуточные срезы;

• к концу квартала подведение итогов и планирование или корректировка с их учётом следующего квартала.

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

В следующей статье мы с вами рассмотрим пути решения проблем, связанных с повышением компетенций ИТ подразделений в компании и подходы к работе с бэклогом. И маленький спойлер. В первой статье я рассказал про внедрение подхода DevOps as a Service, но не описал критерии его выбора - почему, например, не DevOps as a Platform или иные подходы. На предстоящей DevOps Сonf 2024 я раскрою это более подробно, после чего выйдет ещё одна статья, расширяющая первую с точки зрения того, как выбрать, что внедрять в той или иной ситуации.

Ну а с вами был Крылов Александр, до новых встреч!

Теги:

• management
• решение проблем
• управление командой
• управление людьми
• devops