Как запустить новое направление в компании по уму

Привет! Меня зовут Сергей, я занимаюсь направлением DevOps в KTS.

Наша компания помогает бизнесу реализовывать IT-сервисы. С 2015 года мы специализируемся на разработке сложных высоконагруженных сервисов для крупных корпораций, таких как Mail.Ru или X5.

Проектов очень много. На разработку и поддержку требуется много времени и ресурсов. Поэтому мы уделяем большое внимание инфраструктуре и различным способам повышения эффективности разработки. DevOps так и расшифровывается: Development & Operations.

К лету 2021 года мы настолько преисполнились пониманием мира DevOps, что решили выделить это как отдельную услугу. Ведь есть куча компаний, которым это очень надо — как мы в прошлом. По крайней мере, мы так считали.

Я уже писал про историю развития DevOps в нашей компании. Сегодня расскажу про то, как мы создавали из этого новую услугу.

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

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

Представьте, что будет, если вы оставите такого сотрудника в штате. При условной зарплате в 300 тысяч рублей в месяц за год вы заплатите около 3 600 000 ₽. Три c половиной миллиона за поддержку! Кажется, выгоднее нанять кого-нибудь для разового проекта.

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

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

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

Отлично, выбрали то, что умеем лучше всего.

Следующий шаг — исследовать, нужно ли вообще это кому-нибудь, или мы ошибаемся?

Мы обратились к нашим знакомым из компании, которая занимается проведением CustDev. Провели интервью с ними и рассказали свои гипотезы: что, по нашему мнению, может быть востребовано у клиентов. Потом попросили провести профессиональное исследование рынка, опираясь на наши данные.

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

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

Ответы внутри РФ:

Ответы среди экспатов:

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

Проблема 1: Все держится на одном человеке

Он может уйти в отпуск или уволиться. В этот момент все встает, потому что никто больше не разбирается, как работает целая инфраструктура.

Проблема 2: Нет круглосуточной поддержки

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

Проблема 3: Нет мониторинга

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

Проблема 4: Нет выделенного девопсера

Обычно в небольших компаниях девопсом занимается один из разработчиков, как правило, ведущий бэкендер. Когда возникают DevOps-задачи, он полностью вылетает из процесса обычной работы, а значит, продукт не развивается и компания теряет деньги. Более того, DevOps достаточно сложный, в нем куча всяких технологий, и далеко не каждый (даже очень опытный) бекендер хорошо в нем разбирается.

Кроме выделения проблем и подтверждения наших гипотез, мы понимали, что DevOps-задачи намного проще передать на аутсорс. Ведь DevOps-инженеру не надо глубоко погружаться во внутренние проекты, достаточно разбираться в проекте на уровне компонентов. Нам кажется, что это дает большое преимущество при выборе аутсорс / инхаус.

Когда гипотезы подтверждены, можно формировать предложение на рынке. Мы решили подготовить отдельный от основной компании сайт с общим описанием услуг и 2 лендинга — предложения по каждый из ключевых услуг:

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

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

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

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

Мы считаем, что это логично: бизнес занимается бизнесом, а мы берем на себя инфраструктуру и процессы в IT-продуктах.