Что делать, чтобы быть более продуктивным — об этом написаны тонны литературы, от научной до художественной и даже эзотерической. Однако иногда почувствовать, что рабочий день удался, можно без стояния на гвоздях и подъема в пять утра — достаточно убрать раздражающие факторы. Мы в beeline cloud решили разобраться в исследованиях о том, что бесит разработчиков: джунов и сеньоров, в корпорациях и небольших фирмах.
Довольный разработчик — продуктивный разработчик
Идея связать производительность труда с уровнем счастья работающего, мягко говоря, не нова и восходит ещё к античности. За пару с лишним тысяч лет она, претерпев в процессе некоторые изменения, прочно вошла в обиход специалистов: к концу XX века гипотеза о взаимосвязи продуктивности с эмоциональным благополучием выросла до отдельного направления — позитивной психологии. Ее автор, американский академик Мартин Селигман, впоследствии сформулировал модель человеческого благополучия PERMA, на основе которой развивают управленческие методики в бизнесе. А понятие, предложенное еще в 1970-х психологом Михаем Чиксентмихайи, — состояние потока — и сейчас играет важную роль в исследованиях, направленных на поиск факторов и критериев, определяющих оптимальный баланс между стрессом и вовлечённостью сотрудника.
Накопленный опыт по мере возможностей стараются использовать в разных сферах бизнеса — ИТ-индустрия тут не исключение. Компании практикуют разнообразные подходы, чтобы сделать сотрудников более продуктивными: от банальных перестановок мебели в офисе до инвестиций в рабочие инструменты. И в этом ключе проводят новые, более узкоспециализированные исследования. Так, в 2021 году рабочая группа, состоящая преимущественно из инженеров Google (а также специалистов других ИТ-компаний), задалась вопросом: какие факторы действительно влияют на продуктивность разработчиков и зависят ли они от особенностей конкретной организации.
Исследование охватило несколько сотен сотрудников из трех международных ИТ-фирм. Результаты показали, что на восприятие своей продуктивности сильнее всего влияют нетехнические факторы: искренний интерес к решению задач, чувство поддержки от коллег при обсуждении личных инициатив, а также своевременная и конструктивная обратная связь от руководства и заказчиков. Эти факторы оказались более важными, чем изменения в офисной среде или улучшение технической инфраструктуры, и были отмечены респондентами во всех трех организациях, где проходили исследования.
Вообще, исследований о том, что помогает разработчикам, довольно много. Также существуют работы, авторы которых изучали связь между продуктивностью программистов и, например, временем сборки проекта или прохождением код-ревью. Однако в последнее время исследователи идут, что называется, от обратного:
Другой взгляд на продуктивность
Одно дело — разобраться в том, что может повысить эффективность работы. Другое — понять, что превращает обычный рабочий день в непродуктивный, когда человек чувствует стресс, усталость и раздражение. Чем больше таких дней, тем вероятнее наступают их долгосрочные последствия: потеря инициативности и мотивации, сомнения в собственных компетенциях и размышления об увольнении. Научных работ, рассматривающих вопрос с этого ракурса, пока не так много. Еще меньше исследователей попытались сопоставить то, что сами разработчики считают причиной «плохих дней», с объективными данными — например, метриками или телеметрией.
Исправить ситуацию решили специалисты Microsoft в сотрудничестве с исследователями из Университета Виктории (Канада) и Университета Пердью (США), которые в октябре этого года опубликовали результаты масштабной научной работы. Ученые выясняли, какие факторы ухудшают настроение программистов и становятся причиной «неудачных дней». Исследователи организовали серию интервью по видеосвязи с 22 инженерами-программистами из разных отделов Microsoft. У сотрудников уточняли, как они видят «неудачные дни», просили их рассказать о личных примерах и причинах сложностей на работе. Целью этих интервью было собрать первичные данные о том, что именно превращает обычный рабочий день в день, когда «…и ты горишь, и все горит, и ты в аду».
Чтобы подкрепить и углубить данные, полученные в ходе интервью, исследователи расширили выборку и организовали аналогичный опрос по электронной почте — уже среди более чем двухсот участников. Респонденты указывали свои роли в проекте, профессиональный опыт, давали определение термину bad day и расписывали факторы, влияющие на появление «неудачных дней». Дополнительно 79 респондентов вели дневники, оценивая каждый рабочий день в течение месяца. Они могли обозначить свои впечатления как нейтральные, хорошие и плохие. В последнем случае — указывали причины «неудачного дня». Также 131 участник опроса согласился на анализ телеметрии (от выявления проблем со сборкой до заминок с pull request’ами) в течение полугода.
Результаты анализа показали, что больше 80% разработчиков испытывали от одного до восьми «неудачных дней» в месяц. (Что интересно, цифра «бьется» с показателями, которые отметили участники обсуждения в тематическом треде на Hacker News — в среднем они сталкиваются с 3–5 «неудачными днями» ежемесячно). Чаще всего bad days вызваны неэффективными рабочими процессами, трудностями в общении с коллегами и недостаточной функциональностью инструментов для разработки.
Еще одной причиной возникновения «неудачных дней», по мнению 67% участников исследования, является низкое качество ИТ-инфраструктуры. Разработчики отмечают, что их продуктивность часто страдает из-за медленных и неэффективных сборок или устаревшего программного обеспечения. Перечисленные проблемы приводили к эмоциональному истощению.
Что интересно, эмоции специалистов, столкнувшихся с проблемами на работе, отличались в зависимости от их профессионального опыта. Специалисты со стажем ощущали раздражение и даже гнев. Если же «неудачные дни» шли один за другим, они начинали испытывать усталость, разочарование от работы и желание ее сменить. А вот для джунов основной негативной эмоцией было чувство вины. В первую очередь это может быть связано с тем, что для «сеньоров» основной причиной «неудачных дней» становились внешние факторы, замедляющие или осложняющие достижение целей. А вот для новичков проблемой нередко была нехватка компетенций. В целом авторы исследования отмечают, что их работа — лишь начало изучения феномена «неудачных дней», а компаниям и исследователям стоит уделить этому вопросу больше внимания.
Похожее исследование провел коллектив из представителей нескольких европейских (Германия, Италия, Норвегия, Финляндия) университетов в 2017 году. На GitHub специалисты нашли контактные данные 33 200 инженеров-программистов, а затем отправили им информацию об исследовании. Принять в нем участие согласились 2220 человек из 88 стран. Большинство (24%) были из США. Кстати, российские разработчики в исследовании тоже поучаствовали — в количестве 5% от общего числа опрошенных.
Экспертам удалось выделить 219 факторов неудовлетворенности («unhappiness»), которые отражаются на процессе разработки, ухудшают продуктивность и настроение программистов. В первую очередь опрошенные отмечали, что наибольший стресс вызывает (ожидаемо) ощущение тупика при решении задачи или нехватка времени на ее выполнение. Также значимыми факторами называли низкое качество кода в компании, недостаточную квалификацию коллег, неудачные организационные решения в процессе разработки и потерю мотивации из-за неудовлетворённости собственной работой. К тому же респонденты отмечали, что сложности в общении между сотрудниками и руководством угнетают моральный дух в команде, так как плохие эмоции передаются от одного разработчика к другому, а нерешённые конфликты воспаляются вновь.
Специалисты пришли к выводу, что многие причины, влияющие на качество рабочего дня и настроение сотрудников, находятся за пределами их личного контроля. Эти проблемы чаще всего связаны с организацией рабочего процесса, корпоративной культурой, коммуникацией внутри команды или управленческими решениями. Иными словами, это как раз те моменты, на которые вполне способно — по мере возможностей — повлиять руководство. Если, конечно, менеджмент будет в курсе существующих проблем. А это, к сожалению, не всегда так. Согласно статистике, которую приводит компания Atlassian в своем недавнем отчете State of DevEx report, только 44% разработчиков считают, что их руководители знают о сложностях, с которыми они сталкиваются на работе.
Такое расхождение в восприятии между инженерами и менеджерами становится одной из ключевых причин неудовлетворенности сотрудников и снижения их продуктивности. Чтобы обнаружить эти «болевые точки», Atlassian провела опрос среди 2100 своих сотрудников. Среди причин недовольства специалистов были выделены: а) неинформативная документация, б) чрезмерный технический долг, увеличивающий время на выполнение задачи, в) регулярные изменения рабочих процессов, которые порой вводятся без обоснования, вызывая стресс.
Некоторые участники опроса признались, что из-за накопленных негативных эмоций и усталости от затянувшихся проблем они всерьез задумываются о смене работы: 63% респондентов учитывают свою эмоциональную удовлетворённость, когда решают, оставаться ли им в компании или нет.
Самая простая рекомендация менеджерам, которую дают исследователи в завершение этого неутешительного анализа — активнее общаться с программистами. Пытаться улучшить жизнь разработчиков, не спросив об этом самих разработчиков — все равно что «искать телефон по всему дому, держа его в руке», иными словами, совершенно непродуктивно. И хотя этот совет не блещет оригинальностью, он действительно работает — к аналогичному выводу приходят и в многих других исследованиях.
Как с этим работают
На практике повышением продуктивности и созданием оптимальных условий труда для разработчиков занимаются в рамках отдельного направления — developer experience или DevEx. Этот термин обозначает узкоспециализированную область знаний, посвящённую созданию оптимальных условий для работы программистов. В свою очередь DevEx-специалисты фокусируются на улучшении рабочих процессов, оптимизации инструментов разработки, повышении уровня удовлетворённости сотрудников от своей профессиональной деятельности в целом.
Так, компания Wix работает над улучшением DevEx, развивая внутренние инструменты разработки. Другой пример — Spotify, компания внедрила (и передала в open source) платформу Backstage. Она стандартизирует внутренние сервисы, предоставляет разработчикам удобный доступ к ресурсам и информации. Как результат, они тратят меньше времени на поиск документации и управление сервисами и могут сосредоточиться на запуске новых функций. В целом DevEx-руководства и списки рекомендаций готовят и другие технологические компании — например, Microsoft.
Сократить влияние «неудачных дней» помогают не только методические рекомендации или масштабные разработки. К примеру, в компании Swarmia внедрили в корпоративный мессенджер специальную кнопку «paper cut» («Я порезался бумагой»). С её помощью любой разработчик мог рассказать о своём «неудачном дне» и поделиться с руководством или ответственными специалистами возможными причинами. Каждый такой отзыв автоматически превращался в задачу Jira, которую видела команда DevEx, так что вскоре отдел накопил больше 1000 отзывов о проблемах в рабочих процессах. И хотя большинство трудностей были вызваны мелкими сбоями и задержками, в компании признают, что без обратной связи от сотрудников их было бы сложно обнаружить.
В итоге специализированная команда инженеров сосредоточилась на анализе замечаний и предложений, внося изменения в корпоративное программное обеспечение. «Бумажные порезы» — небольшие, но раздражающие проблемы, неожиданно стали приоритетными. Что интересно, опыт пошел на пользу не только сотрудникам — инсайты также использовали для улучшения UX в клиентском программном обеспечении.
beeline cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.
Автор: beeline_cloud
