DevOps as a Service. Часть 4. Решаем проблемы развития сотрудников подразделения и управления инициативами
Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем. В прошлых статьях мы описали сам подход, показали пути решения различных проблем. Со статьями можно ознакомиться здесь Часть1, Часть2, Часть 3. Сегодня мы поговорим о построении процесса развития сотрудников и команды в целом, а также о процессе управления инициативами.
Прежде всего, нам стоит понять сильные и слабые стороны каждого сотрудника подразделения. Начнём мы, безусловно, с hard skills, но и про софтскилы не будем забывать. Представим, что у нас нет на руках никакой информации, и мы будем собирать её с нуля. К кому мы пойдём? Правильно, к руководству - для понимания текущих целей и задач хотя бы на квартал, но лучше, если есть возможность, то сразу на весь год с разбивкой на кварталы. Не забываем спросить про планы и стратегию компании, т.к. могут быть пересечения с появлением новых технологий, инструментов, процессов, что также может повлиять на сотрудников подразделения. То есть, если весь процесс разбивать на этапы, то наш первый этап – снятие информации с руководства.
На втором этапе мы снова обращаемся к стэку. Если в рамках хронологии мы его уже изучили, как было описано в статье Часть1, то теперь нам следует снять обратную связь по желанию сотрудников развивать этот самый стэк. Тут можно разбить на разные стримы, например:
- CI/CD;
- Мониторинг;
- Виртуализация/контейнеризация;
- Технологии управления инфраструктурой;
- и т.д.
Как всё это может выглядеть?
Мы взяли стэк AS-IS, а теперь надо подумать над TO-BE. Если по результатам обсуждения с командой нас в CI/CD всё устраивает, то переходим к следующим стримам: мониторинг и т.д. Если мы поняли, что с пунктом выше всё “ок”, и мы ничего менять не будем, то лучше и не упоминать об этом при дальнейшем обсуждении с руководством. Предположим, по мониторингу нам потребуются изменения. Схема в таком случае будет выглядеть иначе.
Собираем каждый из элементов инфраструктуры в таком виде, и делаем это до тех пор, пока у нас не сформируется весь набор целевой архитектуры и инструментов, которые можно назвать целевыми. Но, как мы с вами понимаем, они не могут стать целевыми, пока они не согласованы с руководством, если, конечно, у вас нет такой власти и права принятия решения. В стартапах – это может быть так, в среднем и большом бизнесе, такой возможности может и не быть.
И это нас подводит к 3 этапу – процессу согласования внедрения.
Если у Вас есть подразделение архитектуры и CTO, с которыми можно это обсудить, то подготавливайте подробный slide desk по каждому элементу инфраструктуры формата AS IS -> TO BE с пояснениями и аргументацией по каждому изменению, как в конфигурации, так и в технологиях.
Тут важно вспомнить, что мы хотим решить не только проблему развития сотрудников, но и наладить процесс управления инициативами и внедрения новых технологий. Если в компании нет единого процесса по валидации, пилотированию и внедрению технологий, почему бы его параллельно не сделать?
Прежде, чем это делать, предлагаю задать и сразу ответить на ряд вопросов, на основе которых мы сможем понять, что нам лучше всего подойдёт: Архком, Техком, NAP или что-то иное.
Давайте раскроем каждое из этих определений и перейдём к вопросам.
Архком или архитектурный комитет – это площадка обсуждения Enterprise & Solution архитекторов, которая проводится по требованию и решает проблемы архитектуры. Не всегда, но в неё также могут быть включены наиболее опытные члены команд разработки, архитектуры, DevOps, DevSecOps, тестирования. Лидером данного комитета является CTO. Помимо решения архитектурных проблем комитет так же может заниматься блокировкой или разблокировкой технического долга и консультацией по архитектуре решений. И его рабочий процесс может выглядеть примерно так:
Техком или технический комитет – экспертная площадка по обсуждению и валидации внедрения новых технологий в компанию. В отличие от архитектурного комитета он состоит из более узкого круга высокопоставленных лиц и отбирается CIO, который является лидером это площадки. Каждая встреча протоколируется, решения принимаются в формате голосования большинством голосов.
Next action plan (NAP) – процесс управления инициативами подразделения DevOps, который может быть расширен участниками команд разработки и тестировани с целью стимулирования и управления инициативами по пилотированию и внедрению новых процессов и технологий в компанию. В компаниях, где есть NAP и Техком или Архком, NAP всегда выступает инструментом валидации инициатив и пилотирования до их попадания на Техком и Архком. PS – в ряде компаний названия могут звучать иначе.
С определениями утвердились, теперь перейдём к вопросам и ответам на них (ответы будем выдумывать).
- Как часто у нас внедряется что-то новое? Раз в несколько месяцев
- Есть ли у нас регламент или инструкция по проведению пилотов? Нет
- Как часто нам приходится что-то пилотировать? От 2 до 5 раз в полгода
- Есть ли у нас техническая площадка обсуждения инициатив по внедрению технологий? Нет
- Как часто нам необходимо пересматривать архитектуру продукта? Не чаще 1-2 в год
- Принимают ли участие во внедрении безопасники? Да
- Есть ли подразделение технической безопасности в компании? Да
- Сколько в компании систем, проектов и как часто между ними требуются новые интеграции? Несколько продуктов, допустим 4, новые интеграции требуются не часто.
На основе полученных выше ответов, по которым мы можем судить о стадии зрелости компании, давайте попробуем определить, какой процесс будет наиболее подходящим для внедрения.
- Если внедрение чего-то нового, в том числе исследование, происходит не на регулярной основе, например, по 1-2 пилота в месяц, то тут есть смысл управлять только самими пилотами, инициативами по ним и их результатами. В данном случае NAP будет достаточно.
- Если нет такого регламента или инструкции по проведению пилотов, то почему бы их не создать? Даже если пилоты не такая частая история, то иметь подобный документ точно не будет лишним с точки зрения ускорения процесса, как по вводным данным, так и по анализу результата пилотов.
- 2-5 раз в полгода – это, конечно же, мало. Это говорит о том, что либо в компании нет такой необходимости, и в этом ничего плохо нет, либо процессы компании еще недостаточно зрелые, и поэтому утяжелять компанию бюрократизацией процессов за счёт внедрения Техкома или Архкома, нет смысла, достаточно NAP.
- Если нет, то почему бы не сделать, но исходим из ответов на вопросы выше, что лучше подойдёт.
- Если у нас всего несколько продуктов, а не 10+ систем и куча проектов, то, пожалуй, это один из основных критериев в пользу того, что Техком тут точно не нужен. Архком, возможно, но как редкое явление, а NAP вполне себе вписывается.
- Это хорошо, значит должны быть некие требования к безопасности продукта и его разработки, если нет, то стоит задуматься об их появлении.
- Это всегда хороший знак, если подразделения безопасности нет, то стоит позаботиться о том, чтобы оно появилось, исходя из потребностей бизнеса и стратегии развития продукта компании. Хорошим тоном является вхождение представителей безопасности в Тех и Архкомы. Что касается NAP, то тут будет достаточно DevSecOps специалиста с минимальным набором требований к технологиям.
- Такой ответ даёт нам окончательно понять, что в компании достаточно процесса NAP, т.к. зрелости процессов не хватает для внедрения Архкома или Техкома. В этом нет ничего плохо, но, на данном этапе эти комитеты, скорее, могли бы больше навредить из-за повышенной бюрократии, чем помогать.
Вывод – достаточно внедрения NAP.Как может выглядеть данный процесс, и из каких компонентов он состоит?Компоненты:
- что нам необходимо?;
- чего нам не хватает?;
- какие есть проблемы?;
- инициатива.
А далее идём по процессу:
- Берём проблемы и задачи компании на год;
- Понимаем, какие процессы или технологии могут их решить, и какие из них, в свою очередь, пока отсутствуют в компании, снимая при этом информацию по инициативам и хотелкам;
- Валидируем всё это;
- Назначаем статусные встречи для обсуждения инициатив и того, что следует пилотировать;
- Пилотируем отобранные инициативы;
- Изучаем результаты пилота;
- Легализуем внедрение того, что пилотировали, если, конечно же, успешно;
- Внедряем.
Этот процесс нужно превратить в рутину, и назначать итеративные встречи, например, раз в 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 я раскрою это более подробно, после чего выйдет ещё одна статья, расширяющая первую с точки зрения того, как выбрать, что внедрять в той или иной ситуации.
Ну а с вами был Крылов Александр, до новых встреч!
Теги: