Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Весна 2020 показала, что благодаря DevOps-практикам многие бизнесы смогли быстро перестроить продукты и перейти в онлайн, сохранив работоспособность. Оказалось, что от зрелости практик DevOps зависят не только результаты бизнеса, но и само его выживание.
Наши встречи на конференции DevOpsConf концентрировались не только на инструментарии инженеров, а еще и на процессах, для которых эти инструменты нужны. Кажется, этого недостаточно, чтобы бизнес увидел, как извлечь из DevOps максимум пользы для продукта.
Поэтому мы добавили фокус на том, как людям в разных позициях определить, какой зрелости DevOps-практик удалось добиться и как сознательно выбрать цели технического развития в своей организации и команде. Иными словами, я хочу увидеть, где на поле DevOps я сейчас нахожусь, и каков мой следующий шаг.
Основные измеряемые характеристики DevOps — это стабильность работы приложений и производительность IT-команд, от идеи до выкладки фичи на продакшн. Поэтому мы много говорим о time to market и мониторинге и продолжаем технический трек.
А ещё IT-команды состоят из живых людей, которые не только могут выдавать хорошие KPI, а ещё и делают заведомо полезную работу. Ведь если DevOps-подход завоевал популярность в мире, то, наверное, это кому-то нужно. Для вас мы повстречались с Product Owners и бизнесменами, которые не всегда знают, что такое DevOps (как будто мы знаем :D) и расспросили их о том, что же им важно получить от технарей. В чём эта самая польза.
Первым делом пришлось поменять свой словарь и способ общения. Мы говорили не нашими привычными терминами, а старались использовать язык продактов. Даже в качестве способа общения мы выбрали CustDev-интервью, как и принято в продуктовом мире. Эти интервью подтверждают или опровергают наши гипотезы о том, что же важно в работе над продуктом со стороны бизнеса.
Вот какие гипотезы мы проверяли на встречах:
Я беседую через с Zoom со своей давней знакомой, которая убеждена, что человеку, который ни разу в жизни не продавал, нечего делать в профессии Product Owner. Она часто появляется в передачах на радио и ТВ, проводит семинары по своей предметной области. Как только режим самоизоляции был облегчён, они с мужем и ребёнком арендовали дом на берегу великолепного озера и на всё лето переехали жить и работать туда. Её компания почти 20 лет на рынке онлайн-услуг. На первом месте по рейтингам в своей предметной области.
— Скажи пожалуйста, проводишь ли ты специальную работу по сокращению цикла разработки и запуска фич в продакшн в своей команде?
— Ты знаешь, уже нет. Если в 2014 году бутылочным горлышком была производительность айтишников, как разработки с тестированием, так и команды эксплуатации, то уже несколько лет я решаю другую задачу. Как успеть подготовить эксперименты, чтобы команде было, чем заняться (смеётся). Если говорить серьёзно, то сейчас я уверена, что фича будет запущена за срок от шести часов до недели...
— Погоди, 6 часов?! Это...
— От первой беседы с командой до пользователя. Т.е. уже на проде.
— Зачем тебе такая скорость?
— Я не ставила такой цели. Скорее, я склоняюсь к мысли, что это естественное следствие тех изменений в инструментарии разработки и эксплуатации и настройки взаимодействия между командами и мной, как представителем бизнеса.
Мы продолжили беседу, и за следующие полчаса Наталья рассказала, что крупные изменения продукта сейчас проходят гораздо увереннее и спокойнее. Основным фактором такого изменения она называет её уверенность в команде и доверие команды к ней.
Следующий мой звонок — на Пхукет. Игорь переехал туда несколько лет назад и для этого провел не самые простые переговоры со своим работодателем. Тогда удалённая работа была в диковинку, и все сотрудники работали в офисе в Москве. Сейчас за кадром слышны визги и возня его большой семьи. Его компания тоже лидирует на российском рынке по своему направлению.
— Внезапно я стал экспертом по удалёнке этой весной! (смеётся)
— Расскажи пожалуйста, какие сознательные шаги ты делал для того, чтобы увеличить стабильность работы приложения и зачем?
— Когда мы с техдиром начали эту работу, ещё не были в ходу такие термины, как LTV, customer retention или unit economy. Просто мы представили, что пользователи не очень довольны падением приложения 20% времени...
— Во, NPS!
— Андрей, не было никакого NPS. Сейчас это технологизированный индикатор того, насколько довольны пользователи. Он не покажет мне деньги. Он не покажет, каково отношение затрат на какой-либо проект и отдачи в деньгах от его реализации.
— Тебе именно это отношение важно?
— Мне важен рост аудитории. Т.е. её лояльность и приверженность к моему продукту.
— Что-то ещё? Как маркетинг связан с аптаймом?
— Смотри, «налить трафик» стоит денег. Будь то прямая реклама или SEO оптимизация, органические переходы. Когда в трафик вложены ресурсы, а на стороне приложения он попадает в черную дыру, то это немножечко потери.
— Т.е. для тебя сейчас важно, чтобы приложение было доступно.
— Сейчас я спокоен, потому что наш аптайм — 4,5 девятки. В течение месяца приложение исправно отвечает на 99,995% запросов.
— DevOps сделал своё дело, DevOps может...
— DevOps ещё и не это может. В какой-то момент мы посчитали, что наш способ развития, через изменения в «лаборатории» и проверку на фокус-группах, дороже, чем проверка на малых долях аудитории. Вместо того, чтобы разработать прототип, собрать фокус группу и получить одобрение, а потом на живых пользователях увидеть их разочарование, я могу быстро-быстро проверить три–пять вариантов на 0,1% пользователей и выбрать лучший.
— Т.е. разработчики наговнокодят что-то быстро на костылях, а потом ты выберешь удачный вариант.
— Да, из палок и синей изоленты. (Игорь морщится, потому что я на громкой связи, а рядом дети)
— Я вижу здесь две потенциальных проблемы. Во-первых, разработчики недовольны, что часть их работы будет заведомо выброшена. Во-вторых, те фичи, которые «выстрелили», остаются костылями.
— Поэтому для нас важно управлять техдолгом. Можно сказать, что между бизнесом и IT есть контракт: в течение года не менее 30% времени разработки идёт на разгребание долга. Причём, эти проценты мы считаем совокупно за год. Например, весной 2020 мы перекрыли работу с техдолгом полностью, потому что нам была важна скорость изменения продукта. Нам пришлось искать новые модели использования наших сервисов.
— Значит ли это, что за оставшиеся полгода ребята будут уже 40% времени заниматься рефакторингом, изменением архитектуры и выпиливанием костылей, а также работать с производительностью приложения?
— Абсолютно.
Дальше Игорь рассказал, что у него появилась возможность работать на опережение. Значительная часть задач направлена на освоение новых технологий и интерфейсов. Первые результаты экспериментов уже доступны пользователям, например общение на естественном языке. При этом на сегодняшний день скорее можно говорить о Research части R&D. Компания осваивает технологии заранее, чтобы использовать момент зрелости технологий искусственного интеллекта для получения конкурентного преимущества.
Если говорить об экспериментах, то настройки приложения разделили на три основные группы:
Любопытно, что первый запрос на разделение настроек пришёл из эксплуатации, когда релизы ещё запускались вручную. 20 релизов в день для изменения настроек — это не то, что радовало админов. Уже когда сервис настроек был готов, то это создало техническую готовность «крутить ручки» владельцам продукта.
Мы также созвонились с ребятами, которые ведут продукт в компаниях, где потенциал для развития DevOps намного больше. Они запускают стартапы или работают на крупного заказчика. Другими словами и больше через боль, они говорили о тех же ценностях для Product Owner-а, что и предыдущие собеседники.
Мы обнаружили, что находки нашего исследования подтверждают те выводы, которые есть в в отчете Google The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling (версия на русском).
Мы выделили четыре основные ценности для Product Owner-ов при использовании DevOps:
Поэтому на конференции поговорим как о важных технических темах, так и о новых. Например, про доверие расскажет Алексей Пикулев, который готовит воркшоп по диагностике и развитию доверия. Продолжим исследовать инженерные практики и инструменты, а также организацию процессов. Коммуникацию бизнеса с командой и между командами будем обсуждать на уже традиционном процессном треке конференции.
Ребята, не беспокойтесь о том, будет ли на конференции по-прежнему много технических докладов. Потому что мы, члены программного комитета, любим системных администраторов и DevOps-инженеров, которых нет. И даже сами ими являемся.
Большинство активностей на конференции сделаем интерактивными, потому что говорящих голов достаточно в интернете. Ведь каждый сознательный инженер может не только найти видео докладов по нужной ему тематике, но и прочитать статьи (например, статьи по следам всех DevOpsConf в профиле Александра Титова).
Наша цель этой осенью дать каждой компании возможность высадить виртуальный десант из Product Owner-ов, техлидов и инженеров всех мастей. Так, чтобы IT-спецназ сориентировался на местности и вернулся в работу с разработанным планом захвата Вселенной!
В следующих статьях расскажем про CTO, разработчиков и безопасников — зачем конференция им.
Наши встречи на конференции DevOpsConf концентрировались не только на инструментарии инженеров, а еще и на процессах, для которых эти инструменты нужны. Кажется, этого недостаточно, чтобы бизнес увидел, как извлечь из DevOps максимум пользы для продукта.
Поэтому мы добавили фокус на том, как людям в разных позициях определить, какой зрелости DevOps-практик удалось добиться и как сознательно выбрать цели технического развития в своей организации и команде. Иными словами, я хочу увидеть, где на поле DevOps я сейчас нахожусь, и каков мой следующий шаг.
Основные измеряемые характеристики DevOps — это стабильность работы приложений и производительность IT-команд, от идеи до выкладки фичи на продакшн. Поэтому мы много говорим о time to market и мониторинге и продолжаем технический трек.
А ещё IT-команды состоят из живых людей, которые не только могут выдавать хорошие KPI, а ещё и делают заведомо полезную работу. Ведь если DevOps-подход завоевал популярность в мире, то, наверное, это кому-то нужно. Для вас мы повстречались с Product Owners и бизнесменами, которые не всегда знают, что такое DevOps (как будто мы знаем :D) и расспросили их о том, что же им важно получить от технарей. В чём эта самая польза.
Первым делом пришлось поменять свой словарь и способ общения. Мы говорили не нашими привычными терминами, а старались использовать язык продактов. Даже в качестве способа общения мы выбрали CustDev-интервью, как и принято в продуктовом мире. Эти интервью подтверждают или опровергают наши гипотезы о том, что же важно в работе над продуктом со стороны бизнеса.
Вот какие гипотезы мы проверяли на встречах:
- TTM важен для интересов Product Owner-а.
- Стабильность работы приложения влияет на бизнесовые показатели.
- Разработчики зачастую не согласны с мнением PO о том, что и как делать.
- TTM помогает проводить CustDev. Речь не о технике интервью, а о поиске и подтверждении потребностей клиентов и построении компании.
Я беседую через с Zoom со своей давней знакомой, которая убеждена, что человеку, который ни разу в жизни не продавал, нечего делать в профессии Product Owner. Она часто появляется в передачах на радио и ТВ, проводит семинары по своей предметной области. Как только режим самоизоляции был облегчён, они с мужем и ребёнком арендовали дом на берегу великолепного озера и на всё лето переехали жить и работать туда. Её компания почти 20 лет на рынке онлайн-услуг. На первом месте по рейтингам в своей предметной области.
— Скажи пожалуйста, проводишь ли ты специальную работу по сокращению цикла разработки и запуска фич в продакшн в своей команде?
— Ты знаешь, уже нет. Если в 2014 году бутылочным горлышком была производительность айтишников, как разработки с тестированием, так и команды эксплуатации, то уже несколько лет я решаю другую задачу. Как успеть подготовить эксперименты, чтобы команде было, чем заняться (смеётся). Если говорить серьёзно, то сейчас я уверена, что фича будет запущена за срок от шести часов до недели...
— Погоди, 6 часов?! Это...
— От первой беседы с командой до пользователя. Т.е. уже на проде.
— Зачем тебе такая скорость?
— Я не ставила такой цели. Скорее, я склоняюсь к мысли, что это естественное следствие тех изменений в инструментарии разработки и эксплуатации и настройки взаимодействия между командами и мной, как представителем бизнеса.
Мы продолжили беседу, и за следующие полчаса Наталья рассказала, что крупные изменения продукта сейчас проходят гораздо увереннее и спокойнее. Основным фактором такого изменения она называет её уверенность в команде и доверие команды к ней.
Следующий мой звонок — на Пхукет. Игорь переехал туда несколько лет назад и для этого провел не самые простые переговоры со своим работодателем. Тогда удалённая работа была в диковинку, и все сотрудники работали в офисе в Москве. Сейчас за кадром слышны визги и возня его большой семьи. Его компания тоже лидирует на российском рынке по своему направлению.
— Внезапно я стал экспертом по удалёнке этой весной! (смеётся)
— Расскажи пожалуйста, какие сознательные шаги ты делал для того, чтобы увеличить стабильность работы приложения и зачем?
— Когда мы с техдиром начали эту работу, ещё не были в ходу такие термины, как LTV, customer retention или unit economy. Просто мы представили, что пользователи не очень довольны падением приложения 20% времени...
— Во, NPS!
— Андрей, не было никакого NPS. Сейчас это технологизированный индикатор того, насколько довольны пользователи. Он не покажет мне деньги. Он не покажет, каково отношение затрат на какой-либо проект и отдачи в деньгах от его реализации.
— Тебе именно это отношение важно?
— Мне важен рост аудитории. Т.е. её лояльность и приверженность к моему продукту.
— Что-то ещё? Как маркетинг связан с аптаймом?
— Смотри, «налить трафик» стоит денег. Будь то прямая реклама или SEO оптимизация, органические переходы. Когда в трафик вложены ресурсы, а на стороне приложения он попадает в черную дыру, то это немножечко потери.
— Т.е. для тебя сейчас важно, чтобы приложение было доступно.
— Сейчас я спокоен, потому что наш аптайм — 4,5 девятки. В течение месяца приложение исправно отвечает на 99,995% запросов.
— DevOps сделал своё дело, DevOps может...
— DevOps ещё и не это может. В какой-то момент мы посчитали, что наш способ развития, через изменения в «лаборатории» и проверку на фокус-группах, дороже, чем проверка на малых долях аудитории. Вместо того, чтобы разработать прототип, собрать фокус группу и получить одобрение, а потом на живых пользователях увидеть их разочарование, я могу быстро-быстро проверить три–пять вариантов на 0,1% пользователей и выбрать лучший.
— Т.е. разработчики наговнокодят что-то быстро на костылях, а потом ты выберешь удачный вариант.
— Да, из палок и синей изоленты. (Игорь морщится, потому что я на громкой связи, а рядом дети)
— Я вижу здесь две потенциальных проблемы. Во-первых, разработчики недовольны, что часть их работы будет заведомо выброшена. Во-вторых, те фичи, которые «выстрелили», остаются костылями.
— Поэтому для нас важно управлять техдолгом. Можно сказать, что между бизнесом и IT есть контракт: в течение года не менее 30% времени разработки идёт на разгребание долга. Причём, эти проценты мы считаем совокупно за год. Например, весной 2020 мы перекрыли работу с техдолгом полностью, потому что нам была важна скорость изменения продукта. Нам пришлось искать новые модели использования наших сервисов.
— Значит ли это, что за оставшиеся полгода ребята будут уже 40% времени заниматься рефакторингом, изменением архитектуры и выпиливанием костылей, а также работать с производительностью приложения?
— Абсолютно.
Дальше Игорь рассказал, что у него появилась возможность работать на опережение. Значительная часть задач направлена на освоение новых технологий и интерфейсов. Первые результаты экспериментов уже доступны пользователям, например общение на естественном языке. При этом на сегодняшний день скорее можно говорить о Research части R&D. Компания осваивает технологии заранее, чтобы использовать момент зрелости технологий искусственного интеллекта для получения конкурентного преимущества.
Если говорить об экспериментах, то настройки приложения разделили на три основные группы:
- Продуктовые. Product owner может включить или отключить фичу, а также раскатать её на заданный процент пользователей или даже конкретный список.
- Настройки взаимодействия сервисов — это зона ответственности разработчиков.
- Админские, их крутит команда, которая занимается инфраструктурой.
Любопытно, что первый запрос на разделение настроек пришёл из эксплуатации, когда релизы ещё запускались вручную. 20 релизов в день для изменения настроек — это не то, что радовало админов. Уже когда сервис настроек был готов, то это создало техническую готовность «крутить ручки» владельцам продукта.
Мы также созвонились с ребятами, которые ведут продукт в компаниях, где потенциал для развития DevOps намного больше. Они запускают стартапы или работают на крупного заказчика. Другими словами и больше через боль, они говорили о тех же ценностях для Product Owner-а, что и предыдущие собеседники.
Мы обнаружили, что находки нашего исследования подтверждают те выводы, которые есть в в отчете Google The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling (версия на русском).
Мы выделили четыре основные ценности для Product Owner-ов при использовании DevOps:
- Предсказуемость времени реализации фичи и уверенность в качестве софта — это необходимая база для активных экспериментов.
- Надёжность работы прода = деньги. Когда трафик попадает на работающее приложение, то это не только позволяет рационально использовать бюджет на продвижение, но ещё и повышает лояльность пользователей, а значит и долю на рынке.
- Скорость экспериментов определяет успех как для стартапа, так и для бизнеса со зрелым продуктом. Если стартапу важно быстро обнаружить предпочтения пользователей и удачные ответы на них, то зрелому продукту нужно удержание пользователей, стабильность массовой выручки и research — работа на будущее технологий.
- Доверие к разработчикам и взаимное доверие разработчиков к продакту. Партнёрские отношения между IT подразделением и бизнес юнитами, когда заключается «контракт» о способах взаимодействия и этот договор исполняют обе стороны. В терминах DevOps это управление техдолгом, поддержка кода в порядке и вовлечение команды в интерес своих пользователей.
Поэтому на конференции поговорим как о важных технических темах, так и о новых. Например, про доверие расскажет Алексей Пикулев, который готовит воркшоп по диагностике и развитию доверия. Продолжим исследовать инженерные практики и инструменты, а также организацию процессов. Коммуникацию бизнеса с командой и между командами будем обсуждать на уже традиционном процессном треке конференции.
Ребята, не беспокойтесь о том, будет ли на конференции по-прежнему много технических докладов. Потому что мы, члены программного комитета, любим системных администраторов и DevOps-инженеров, которых нет. И даже сами ими являемся.
Большинство активностей на конференции сделаем интерактивными, потому что говорящих голов достаточно в интернете. Ведь каждый сознательный инженер может не только найти видео докладов по нужной ему тематике, но и прочитать статьи (например, статьи по следам всех DevOpsConf в профиле Александра Титова).
Наша цель этой осенью дать каждой компании возможность высадить виртуальный десант из Product Owner-ов, техлидов и инженеров всех мастей. Так, чтобы IT-спецназ сориентировался на местности и вернулся в работу с разработанным планом захвата Вселенной!
В следующих статьях расскажем про CTO, разработчиков и безопасников — зачем конференция им.
DevOps Live пройдет онлайн — 29-30 сентября и 6-7 октября 2020. В онлайне будет всё, за что сообщество любит наши конференции, и при этом мы вместе исследуем новые возможности онлайна.
Пока до конференции есть немного времени — подписывайтесь на рассылку: будем присылать письма с новостями о программе, анонсами докладов (и расшифровками с прошлых конференций), а также с разными сюрпризами. И подавайте заявки на доклады или мастер-классы, если хотите повлиять на развитие DevOps в России. А если вы продакт, которому весь этот DevOps только мешает, напишите в комментариях, как вам удается держаться на плаву.
