DevOps as a Service. Часть 6. Создание площадки обучения DevOps в компании

Всем привет!

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

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

Какие могут быть предпосылки?

Мы хотим изменений

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

С чего же стоит начать?

Начнём с того, что оглянемся по сторонам и сделаем следующее:

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

Кого стоит привлекать в данную гильдию прежде всего? Конечно же разработчиков, особенно, если вы отвечаете за контур разработки, который, например, находится в том же k8s. Начните с лида разработки, объясните полезность площадки, периодичность, формат и что будете обсуждать. А для пущего эффекта перед каждой встречей объявляйте набор тем для обсуждения, чтобы целевые участники были на встрече. Если вы постоянно взаимодействуйте с командой тестирования, поддерживаете контура тестирования, то первыми эшелонами затягивайте в гильдию тестировщиков, также предварительно это проговорив в лидом или лидами тестирования. Всех остальных - по остаточному принципу или принципу частоты взаимодействия, при этом допустимы и временные участники по экстренным вопросам. Если в вашей компании ранее не было гильдий, то эту практику можно распространить, начиная с вашего подразделения. Например, мы следом сделали гильдию безопасности, где обсуждали все те же насущные вопросы, но в разрезе безопасности и немного с другим составом лиц. Важно, что периодичность встреч подобных гильдий не стоит делать очень часто сразу после внедрения, иначе вы просто будете обсуждать одно и то же, либо это всем скоро надоест. Раз в 2-3 недели - самое то, а на первых парах, пока вопросов много, можно делать более частую периодичность. Если опыт использования гильдий дает результаты, то далее можно создавать гильдии разработки, тестирования и т.д.

Для начала стоит продумать структуру и то, что вы хотите там видеть. Для себя я давно понял, что хочу видеть примерно следующую структуру.

Немного поясним каждый из разделов:

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

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

Прежде чем мы пойдём дальше, следует сделать ещё несколько манипуляций:

- Можете делать сами, а можете договориться с HR или маркетингом и вести некий вестник DevOps, в котором на еженедельной основе давать краткие новости из мира ИТ, статьи, ближайшие внутренние и внешние мероприятия, как платные, так и бесплатные. Это поможет появиться некой единой культуре информационного поля, как внутри компании, так и на рынке за её пределами.

- Реализуйте карту компетенций DevOps, которая позволит вам более быстро составить список тем, на основе которых вы сможете делиться опытом с коллегами, обогащать вашу базу знаний новыми статьями, поможет вам сформулировать список тем для площадки обучения. Вот пример того, как она может выглядеть:

Понимаю, что некоторые вещи могут быть мелкие и плохо читаемые, поэтому шаблон того, как это может выглядеть с учётом списка технологий, софт и хард скиллов, выложил на github: https://github.com/darkbenladan/Matrix_compitetion_DevSevOps

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

- создание площадки обучения DevOps. Мы собрали темы и потребности на базе матрицы компетенций или просто через коллег, составили полноценный список. Далее собираемся с командой и обсуждаем, кто какую тему и когда рассказывает, постепенно делая таблицу в базе знаний. После чего делаем анонс на всю компанию сами или через HR, что стартует площадка и приглашаете весь ИТ туда. Причем начинаем это с подразделения DevOps путём рассказов про наши инструменты, мониторинг, CI/CD, troubleshooting, и т.д. Каждую встречу записываем; если есть презентация, прикладываем и выкладываем, если надо дополнительно по теме сделать статью в базе знаний, делаем. Постепенно всё это соединяем в единой структуре и проводим. Список может выглядеть примерно так:

Формат лучше всего выбирать 30-40 минут на тему, 10-20 минут вопросы из зала. Лучше всего не организовывать большие митапы, т.к. это займёт много времени. Лучше коротко, ёмко и по теме. Для начала стоит делать митапы на еженедельной основе, например, по вечерам в понедельник, а далее, вы сами это заметите где-то через 6-7 месяцев, можно их проводить уже раз в 2 или 3 недели. Это зависит от возможности привлечения спикеров из других подразделений, и наличия тем. Что ещё можно рассказывать? Кто-то прошёл обучение – вот рассказ на серию митапов, появился новый процесс или внедрилось новое ПО – рассказываем, сходили на конфу – сделали её ретро и т.д. Тем самым у нас работающая площадка, запущенная на поток, и тут важно не забывать, что вы не должны быть узким горлышком, кто этим занимается, в том числе ведёт и модерирует каждую встречу, пусть ведущие, модераторы и рассказчики каждый раз меняются, тем самым, в случае ваших болезни или отпуска ничего не остановится. Ещё небольшой совет – планируйте выступления площадки хотя бы на месяц вперед, а лучше на квартал). Что ещё можно дополнительно сделать?

- создаём карту внутренних мероприятий той самой площадки обучения, где мы перечисляем все даты, время, темы, ведущих, что входит в эту тему тезисно и обновляем это раз в 1-3 месяца.

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

- запускаем обучение на поток и радуемся жизни)

- Если вдруг возникают команды, которые отнекиваются от обучения, то через их руководителей и общее руководство доносите мысль о том, что происходит объединение команд едиными целями, например, для уменьшения показателей SLA по решению проблем в проде. Да, цели могут разными, вроде уменьшения t2m, регресс за сутки и т.д., но суть именно в том, что они должны быть понятны командам, должны стать общими, которые они будут делать вместе. Таким образом будет смещен фокус на развитие.

Резюме и итоги по всему циклу статей.

Ну что же, пора подводить итоги по всему циклу статей, которых набралось аж 6 штук:

А с Вами был Крылов Александр, до новых встреч в следующих статьях!

Небольшой спойлер, впереди будет и матрица компетенций, и DevOps governance, и многое другое))

Теги: #управление #обучение #devops