Как мы с помощью кастдевов создали курс, решающий запросы всех стейкхолдеров
Задача
Разработать курс для специалистов поддержки, чтобы снизить затраты на найм новых senior-специалистов.
Решение
Провели кастдевы всех групп стейкхолдеров и скорректировали запрос. Запустили программу внутреннего обучения и снизили нагрузку на специалистов 3 линии поддержки, сократив тем самым потребность в найме дополнительных senior-сотрудников.
Задача
Клиент обратился в Т1 Цифровую Академию с запросом на разработку курса для специалистов поддержки по OpenShift. Руководители на стороне заказчика объяснили, что компании не удается нанимать экспертов с такой компетенцией, из-за чего им приходится брать на работу специалистов «на вырост» — отсюда и потребность в образовательной программе.
Решение
Определив, что проблема связана с наймом сотрудников, мы провели кастдев-исследование и опросили рекрутеров, финансистов и инженеров поддержки.
Что показали кастдевы разных групп стейкхолдеров
- Кастдевы команды рекрутеров показали, что на рынке в целом сложно найти экспертов по поддержке OpenShift. А редких специалистов, которые оказываются доступными для найма, быстро привлекают компании, предоставляющие им оклад на порядок выше рыночного.
- Кастдевы финансистов дали понять, что при выборе между наймом экспертов с завышенными зарплатными ожиданиями и внутренним обучением специалистов, выгоднее оказывается второй вариант.
- Опрос инженеров поддержки позволил получить важный инсайт: проблема у специалистов связана не столько с обращением с OpenShift, сколько с более общими знаниями о бизнес-процессах и инструментах ИТ-мониторинга.
В результате кастдевов мы выяснили, что запрос на самом деле был совершенно иным и более глубоким. То есть стейкхолдеры, владельцы бюджетов видели сложность в одном процессе, а на самом деле проблема оказалась в другом. Команде требовалось обучение не одному дополнительному инструменту, а целому комплексу смежных инструментов, владение которыми повышало количество инцидентов, которые первые линии поддержки решали самостоятельно, без перевода их к третьей линии и разработчикам.
После получения всех данных мы разработали комплексный курс по основным инструментам разработки ПО и анализа данных, которые позволили бы второй линии поддержки решать большинство проблем на своем уровне, не передавая их разработчикам.
Из чего состояла программа курса
- Майндсет DevOps. Знакомство с микросервисной инфраструктурой, ее общие принципы и отличия от монолитной архитектуры.
- Практика DevOps. Погружение в системы управления и версионирования кода Git и Bitbucket. Это самый большой блок — в этих системах DevOps-инженеры чаще всего и работают, и без их понимания дальше не продвинуться.
- Оркестрация ПО при помощи Docker. На примере Docker ученики разбираются в логике контейнеризации микросервисов — и тем самым закладывают базу для работы c Kubernetes, софта для автоматизации развертывания, масштабирования и координации контейнеризированных приложений.
- OpenShift. Работа с продвинутой надстройкой над Kubernetes и изучение нюансов обоих инструментов.
- Инструменты построения пайплайнов TeacmCity и Jenkins.
- Observability. Развитие навыков мониторить производительность приложений и понятно визуализировать результаты.
В курс вошли модули по изучению ПО Docker, Openshift, Kubernetes, Helm, Grafana, Prometheus, TeamCity и TeamCity Kotlin DSL.
Результат
После запуска обучения треть инцидентов стали закрываться, не доходя до инженеров 3 линии и разработчиков.
Две трети инженеров 3 линии и разработчики отметили, что инженеры поддержки 2 линии стали лучше описывать инциденты и собирать по ним данные, что ускорило решение на дальнейших уровнях.
