State of DevOps 2024. DevExp, лидерство и клиентоцентричность

Хей! Всем привет, а вот и заключительная часть обзора исследования State of DevOps 2024. А остальные ниже:

Обзор исследования State of DevOps 2024 DORA

1 часть: Dora‑метрики и элитность
2 часть: Искусственный интеллект
3 часть: Platform Engineering
4 часть: DevExp. Лидерство. Клиентоцентричность <‑— ты тут 😉

Разберем, как важно трансформационное лидерство, DevExp и клиентоцентричность, как все это взаимосвязано и на что влияет. Эта часть для тех, кто занимается выстраиванием процессов и руководит. Естественно, деталей, как конкретно это реализовать, в исследовании нет и не будет, если бы были четкие и детерминированные алгоритмы — зачем тогда мы) Но исследование показывает нам куда двигаться, к чему стремиться. Посмотрим и разберем основные поинты в исследовании. Что ж погнали:)

---

Клиентоцентричность и DevExp

Клиентоцентричность — это мощная философия, которая делает лучше всем.

• Клиентоцентричность помогает клиентам
  Она позволяет клиентам получать более качественные и востребованные продукты.
  

• Клиентоцентричность помогает не только клиентам, но и инженерам
  Разработчики часто трудятся в условиях, где приоритет отдается функциональности и инновациям, вместо оценки ценности этих функций для пользователей.

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

  Опрос показал, что 93% работников считают важным выполнять значимую работу, а другой исследование выявило, что респонденты готовы пожертвовать 23% своих будущих доходов ради работы, которая всегда будет иметь смысл.

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

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

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

• Организации должны создавать комфортные условия для инженеров
  Нужно быть клиентоцентричным не только к клиентам, но и к тем, кто делает для них продукты — к инженерам. Хорошие условия, помогают разработчикам сосредоточиться на создании продуктов, улучшении пользовательского опыта.

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

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

  Это придает их работе смысл и уверенность в важности создаваемых функций. Разработчики видят прямое влияние своей работы, устраняя разрыв между ПО и его применением. Однако давление на поставки может снижать внимание к качеству.

• Клиентоцентричность усиливает кросс‑функциональное сотрудничество Ориентированный на пользователя подход к разработке ПО усиливает межфункциональное сотрудничество, помогая разработчикам работать в команде, укреплять командную работу и решать проблемы, ориентируясь на интересы пользователей. Это повышает вовлеченность сотрудников и создает стимулирующую рабочую среду, предотвращая выгорание.

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

1. Например, вы в компании, которая является разработчиком собственного ПО. Безусловно, вам важна лояльность ваших существующих и будущих клиентов, вы несёте им ценность по решению их проблем с использованию вашего продукта(ов). Модель лояльности будет строиться вокруг продукта и процессов технического presale и самого sale продукта со всеми вытекающими, которые должны быть очень жёстко учтены при контрактовании, и предусмотрены с расписанием всех аспектов и рисков работы вашего продукта. А далее, если продажа состоялась, то вы уже идёте по пути внедрения и принесения пользы конечному клиенту.
   По этому поводу я рекомендую почитать книгу Ленсиони — «Пять пороков команды», там на примере компании хорошо показано, как подобные компании, имея общие цели на клиентоориентированность, могут достигнуть успеха.

2. При этом, не стоит и забывать наиболее распространенный паттерн, это энтерпрайс финансового сектора (банки, страховые, биржи и т. д.). Там история больше нацелена на удовлетворение клиента от вашего продукта (продукт тут чаще всего трансформируется в услугу, например, страховка дома или от клеща) или услуги. И тут ваша стратегия разработки и метрики понимания удовлетворенности клиента будут строиться уже совсем иначе, как и иным может быть контур разработки с упором в безопасность, скорость и актуальность технологий. В этом плане очень хорошо подходит паттерн, который описан в работе и организации команд в книге «Team Topologies: Organizing Business and Technology Teams for Fast Flow» от авторов Manuel Pais и Matthew Skelton. И не забываем про относительно новую книгу от тех же авторов — «Remote Team Interactions Workbook: Using Team Topologies Patterns for Remote Working»

---

Документация

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

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

Хотя Agile ставит работающий софт выше исчерпывающей документации, качественная документация по‑прежнему остается важной для успешного ПО. Проблемная документация часто создается для бюрократии или из‑за недоверия, и бывает неэффективной. Здоровая культура документации ориентируется на доступность и актуальность контента, учитывая потребности коллег или будущего себя.

Рекомендации по созданию здоровой культуры документации в своей команде:

• Документирование критических случаев использования.

• Обучение техническому письму.

• Определение ответственных и процессов обновления документации.

• Распределение работы над документацией внутри команды.

• Поддержание документации как части жизненного цикла разработки ПО.

• Удаление устаревшей или избыточной документации.

• Учет работы над документацией при оценке производительности и продвижении.

Качественная документация повышает производительность продукта.

Добавлю также, что тут нужно подходить с точки зрения здравого смысла. Документировать всё и вся — классно, но не всегда надо. Более того, документация должна быть понятна конечному пользователю. Для этого есть неплохой лайфхак — при приходе нового инженера DevOps/QA/DEV, попросить их актуализировать документацию и спросить, что в ней не понятно, не актуально, не работает, устарело и т. д. Безусловно, это не единственный вариант. Можно так же и на кошках.

Допустим, вы делайте документацию при передачи компетенций или их расширения в другое подразделение. Пишите, рассказывайте с записью на видео в виде конференции, согласуете срок на ревью и правки и сдаёте. А далее очерчиваем черту, когда у вас лапки и внесение изменений в документации происходить только тогда, когда что‑то поменялось или итерационно актуализировалось.

Есть очень крутой доклад, который рекомендую по этому поводу посмотреть в части управления базы знаний от Анастасии Граф «Как управлять базой знаний и не сойти с ума»

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

---

Стабильность и приоритеты

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

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

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

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

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

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

  Десятилетия академических исследований показывают вредное воздействие хронического стресса на здоровье и благополучие. Хроническая нестабильность увеличивает неопределенность и снижает ощущение контроля. Такое сочетание — отличная предпосылка для выгорания.

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

Что происходит при стабилизации приоритетов?

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

Не забываем про классическую историю, описанную ещё в «Проект Феникс». Gene Kim. Удивительно, но она актуальна и по сей день. Более того, для крупного бизнеса ещё появилась и другая книга «Wiring the Winning Organization» за авторством того же Gene Kim. Крайне рекомендую к ознакомлению.

---

Трансформационное лидерство

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

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

Про то каким должен быть лидер, отлично описано в книжке «Ускоряйся», можно взять оттуда тест и сматчить со своими руководителями. Интересное упражнение, очень рекомендую, хехе)

Настоящие грамотные лидеры поощряют свои команды работать для достижения общей цели через следующие аспекты:

• Видение
  Лидеры имеют четкое видение того, куда движется их команда и организация.

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

• Интеллектуальная стимуляция
  Лидеры побуждают членов команды думать о старых проблемах по‑новому и переосмысливать некоторые из своих базовых предположений о своей работе.

• Поддерживающее лидерство
  Лидеры учитывают личные чувства других перед принятием решений, ведут себя с учетом личных потребностей других.

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

Исследование показывает, что повышение уровня трансформационного лидерства на 25% ведет к увеличению производительности сотрудников на 9%.

Трансформационное лидерство может помочь улучшить не только производительность. Наличие хороших лидеров также может привести к:

• Снижению выгорания сотрудников

• Повышению удовлетворенности работой

• Повышению производительности команды

• Улучшению производительности продукта

• Улучшению организационной эффективности

Исследования обнаружили статистически значимую связь между вышеуказанными качествами лидеров и показателями ИТ‑производительности в 2017 году. Высокоэффективные команды имели лидеров с высокими оценками по всем пяти характеристикам, а низкоэффективные команды имели самые низкие оценки. Кроме того, авторы заметили сильную корреляцию между трансформационным лидерством и Employee Net Promoter Score (eNPS), вероятностью рекомендовать работу в компании.

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

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

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

---

Полезняшки

• Книга «Ускоряйся! Наука DevOps: Как создавать и масштабировать высокопроизводительные цифровые организации» — от создателей исследований State of DevOps

• О том, что нужно мерять продуктивность команды, а не отдельного сотрудника

• State of DevOps Russia

• IT Friday — мой канал про тренды в ИТ‑индустрии, практики, инструменты и другие полезняшки

Заключение 

State of DevOps 2024 довольно интересное исследование, и гораздо больше чем просто опрос. Тут и опрос и интервью специалистов, гипотезы, умные мысли и куча полезняшек. Основное в этом году:

• Новая метрика Rework rate для частоты хотфиксов.

• ИИ используется все чаще, улучшает удовольствие на работе, но требует осторожного внедрения из‑за рисков для стабильности процессов и пока индустрия только учится его использовать. Есть боязни, что ИИ негативно скажется на экологии, социуме, карьере

• Платформенная инженерия помогает масштабировать команды, предоставляя самообслуживающиеся инструменты, однако платформы могут и аффектить поставки приложений, поэтому нужно внимательно отслеживать метрики.

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

А еще очень рекомендую почитать русский State of DevOps, это совершенно другое исследование и оно прекрасно дополняет исследование от DORA. А чтобы еще лучше разобрать и покрутить исследование — соберетись местной айтишечкой и вместе понабрасывайте и похоливарьте, так гораздо интереснее и веселее. Всем хорошего дня 😉

Благодарности

Те, без которых бы ничего не вышло, поправляли опечатки, поддерживали и вдохновляли, ревьювили:

Мария Васильева, Алексей Папко, Игорь Курочкин, Александр Крылов, Ирина Николаева, Алена Задорожная, Тимур Казьмин, Тимур Гильмуллин, Олег Блохин, Вячеслав Иванов, Бронислав Житников, Андрей Руденец, Антон Павленко, Анастасия Золотарева, Ирина Волна

И если кого вдруг забыл — вам тоже огромное спасибо:)