Резюме

Почему выгорание встречается так часто и что с этим делать?

  • Симптомы выгорания часто возникают из-за неоптимальных процедур и условий труда. Это признаки серьезного и затяжного заболевания.
  • В частности, выгорание разработчиков программного обеспечения более распространено, чем можно было бы подозревать. Это поражает компании увеличением текучести кадров, снижением производительности команды и отпуском по болезни выше среднего, так же сильно, как и пострадавшие сотрудники.
  • Среди многих других причин непропорционально часто причинами называют «бессмысленную» работу, частую смену приоритетов, нереалистичные цели, сроки и переутомление.
  • Ранние индикаторы этих наиболее важных причин выгорания могут быть идентифицированы по работе над программным кодом с помощью DETANGLE Analysis Suite.
  • Благодаря этим результатам анализа руководители проекта / руководство проекта получают информацию, позволяющую выявлять опасные для здоровья условия труда своих разработчиков на ранней стадии, и могут своевременно принимать контрмеры.
  • При регулярном применении этого анализа станет доступной дополнительная информация о тенденциях соответствующих ключевых показателей. Со временем становится все проще сузить причины выгорания разработчика и избежать его на глазах у отдельного человека, и, как следствие, это серьезно повлияет на организацию.

Почему разработчики программного обеспечения так часто сталкиваются с симптомами выгорания?

Выгорание - серьезное и затяжное заболевание. Для него до сих пор нет четкого определения и диагноза. Часто его путают с депрессией.

Полезное описание можно найти, например, в Предотвращении выгорания для разработчиков программного обеспечения [1]:

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

- Эбби Кирнс, Cloud Foundry

Последствия выгорания серьезны для отдельного разработчика, команды и компании. Следующий список некоторых симптомов постоянно цитируется Как не выгореть: Руководство для разработчиков программного обеспечения [2]:

  • «Стать циничным или чрезмерно критичным на работе»
  • «Отсутствие энергии и концентрации без очевидной причины»
  • «Постоянная усталость»
  • «Откладывание задач, которые вы раньше выполняли с энтузиазмом»
  • «Чувство страха, апатии и неконтролируемости»
  • «Пониженная производительность»
  • «Беспокойство от незначительного до серьезного»
  • «Взрывы гнева»

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

Программная инженерия не имеет границ. Работа определяется не установленным количеством часов в день, а оптимистичными, а иногда и произвольными сроками управления. Как сказал мне один старший технический директор: «Я знал, что уложиться в срок невозможно, но я просто хотел, чтобы команда инженеров работала быстрее». Кроме того, нехватка персонала в проектных командах является обычным явлением, потому что набор разработчиков труден - и стоит дорого »[3].

Публикация Beware Burnout [3] перечисляет следующие специфические для разработки программного обеспечения причины повышенной вероятности получить выгорание:

  1. «Неясное или быстро меняющееся направление» (А),
  2. «Низкий коэффициент шины» (B),
  3. «Программирование изолирует» (D),
  4. «Осушение работ по техническому обслуживанию» (C),
  5. «Нетерпеливые или неблагодарные пользователи» (в случае разработки с открытым исходным кодом)
  6. «Кодирование для других»

В других публикациях, таких как 7 причин, по которым программисты выгорают [4] и Только вы можете предотвратить техническое выгорание [5], перечислены очень похожие и другие причины. Различные причины, которые разные авторы считают причиной повышенной предрасположенности к выгоранию, можно объединить в четыре группы:

(A) Отсутствие фокуса

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

(B) Высокая загруженность и / или несбалансированное распределение задач

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

(C) Значительная доля «не имеющей ценности» работы

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

(D) Плохое сотрудничество внутри и между командами разработчиков.

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

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

Ранние признаки выгорания можно измерить с помощью DETANGLE®.

Первым шагом в предотвращении выгорания является выявление индикаторов, которые, как известно или предположительно связаны с повышенной предрасположенностью к выгоранию (см. Четыре группы выше). Для кластеров категорий A, B и C мы записываем следующие параметры для каждого разработчика с течением времени с помощью DETANGLE®:

  1. Какова доля разработчика в объеме работы по обслуживанию системы по сравнению с разработкой функций?
  2. Над сколькими функциями / пользовательскими историями одновременно работает разработчик и каково распределение их усилий?
  3. Над сколькими разными каталогами исходного кода одновременно работает разработчик?
  4. Со сколькими разными языками программирования работает разработчик?
  5. Представляет ли разработчик риск проекта в течение длительного периода времени из-за его соответствующих и специальных знаний, и осознает ли он это (фактор шины)?

Анализ этих данных дает четкое представление об условиях работы, которые, как известно, вызывают чрезмерное количество сотрудников, страдающих синдромом выгорания. Например, чем выше индивидуальные усилия по обслуживанию, тем меньше доля реальной работы с добавленной стоимостью, которая обычно рассматривается как приносящая удовлетворение деятельность ©. Чем больше количество функций / пользовательских историй и чем больше каталогов исходного кода или языков программирования, тем меньше внимание разработчика (A), тогда как коэффициент шины также косвенно отражает его рабочую нагрузку (B).

На рисунке 1 показан коэффициент шины, то есть количество ключевых разработчиков проекта с открытым исходным кодом Django. Видно, что их количество увеличилось с 4 до 7 разработчиков с 2019 по 2020 год, и около 12% разработчиков считаются критически важными и вносят свой вклад в коэффициент шины. Потеря одного из этих разработчиков всегда связана с риском проекта. Поскольку эти ключевые разработчики также обычно несут наибольшую нагрузку и ответственность, они особенно подвержены риску выгорания. Таким образом, коэффициент шины также является ранним индикатором количества сотрудников, которым грозит выгорание. Если разработчик зарегистрирован как фактор загрузки в течение более длительного времени, менеджменту проекта следует попытаться перебалансировать его нагрузку и снизить его / ее высокий уровень постоянной высокой важности для проекта (ов).

Мы уже обращались к причинам категории D из предыдущего раздела (проблема плохого сотрудничества) в нескольких блогах. В разделах Комплексная проверка программного обеспечения - разработчики и их сотрудничество в центре внимания [6] и Переосмысление (коллективного) права собственности на код [7] мы объяснили, что важны не солисты-звезды, а игроки команды, чтобы ограничить уровень стресса в команде при одновременном повышении производительности и качества.

Вывод

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

Компания Cape of Good Code разработала аналитический программный подход для определения показателей, описывающих риск эмоционального выгорания человека, вызванного рабочими обстоятельствами в программной инженерии.

Регулярно используя DETANGLE®, руководители проектов могут получить представление об уровне стресса в своей команде, вызванном работой. Каждый индикатор дает конкретные подсказки о том, откуда может возникнуть стресс. Это позволяет руководителям проектов связаться с этим сотрудником и обсудить индивидуальные меры противодействия. Поговорив с сотрудником, можно окончательно прояснить, насколько стрессовыми он / она воспринимает рабочие обстоятельства и сможет ли он / она справиться с этим уровнем стресса.

Часто задаваемые вопросы

Какие требования должны быть соблюдены, чтобы программное обеспечение можно было автоматически исследовать с помощью Software Analysis Suite?

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

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

Может ли программный анализ выполняться полностью удаленно?

Это возможно и стало стандартом во времена ограничений на поездки. ИТ-специалисты компании, владеющей / использующей программное обеспечение, должны предоставить VPN-соединение, которое позволит компании Cape of Good Code установить аналитическое программное обеспечение DETANGLE® на соответствующий компьютер (или виртуальную машину) компании. Анализируемый код всегда остается исключительно в инфраструктуре компании. Обязательные личные интервью также могут проводиться через онлайн-встречи.

Может ли программный код быть слишком большим для автоматического анализа с помощью DETANGLE?

Несколько миллионов строк кода - не проблема для изучения за один проход. Для ›10 миллионов строк кода необходимо будет проверить, можно ли разделить код на значимые тестовые кластеры. Это особенно полезно для точной интерпретации результатов анализа.

Ссылки

[1] Предотвращение выгорания для разработчиков программного обеспечения
[2] Как не выгорать: руководство для разработчиков программного обеспечения
[3] Остерегайтесь выгорания
[4] 7 причин, почему программисты выгорают
[5] Только вы можете предотвратить техническое выгорание
[6] Комплексная проверка программного обеспечения - в центре внимания разработчиков и их сотрудничество
[7] Распространение ответственности Анализируемый феномен: раскрыть правду

Первоначально опубликовано на https://capeofgoodcode.com/2021/09/10/burnout-syndrome-why-it-hits-software-developers-so-often/ 10 сентября , 2021 г.