За более чем два десятилетия концепция производительности эволюционировала и расширилась во всех направлениях в программной инженерии – во многих случаях с запутанными или противоречивыми результатами. В начале моей карьеры в этой области я был под неправильным впечатлением, что больше часов работы, больше строк кода и больше “активности” автоматически означают лучшие результаты. Но этот взгляд на производительность – от разработчика к руководителю команды и далее к менеджеру по инженерии – только казался работать против самих целей, которые он должен был достичь, не только нанося ущерб качеству кода, но и оказывая серьезное влияние на благополучие разработчиков.

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

Иллюзия сверхурочной работы

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

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

Качественное время над количеством времени

Креативность и решение проблем, два важных навыка, необходимых в современной программной инженерии, резко ограничены усталостью. Использование инструментов отслеживания времени, таких как RescueTime и Toggl, на протяжении многих лет для изучения моделей работы наших команд привело к некоторым показательным результатам: наш код высшего качества производится, когда разработчики наслаждаются регулярными 4-5-часовыми блоками непрерывной концентрации. Когда люди переходят на 10- или 12-часовые дни, частота ошибок часто увеличивается, и переделка может занять еще больше часов на заднем плане. Принимая более умеренные графики, мы увидели значительное снижение количества ошибок, рост удовлетворенности команды и, в конечном итоге, более предсказуемые сроки поставки.

Фаллация фокуса

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

Прорывы вне клавиатуры

Одним из самых ярких демонстраций этого стал прошлый год, когда моя команда была в середине ожесточенной борьбы с хитрой проблемой микросервисной архитектуры. В течение двух недель мы выстукивали код в раздражении, пытаясь отладить сложную сеть сервисов. Наконец, мы отложили это в сторону и перешли в нашу зону отдыха для более неформального разговора. За кофе мы нарисовали решение на доске, которое было радикально проще, отрезая большую часть сложности, с которой мы боролись. Эти 30 минут разговора спасли нам то, что, безусловно, заняло бы месяцы болезненной рефакторинга. Это было мощным напоминанием о том, что эффективное решение проблем часто происходит вне пределов IDE.

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

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

Более целостный подход

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

1. Время выхода на рынок для новых функций
   Как быстро мы можем доставить функцию, которая действительно ценна для реальных пользователей? Это более надежный способ измерить пропускную способность, чем сырые изменения кода, поскольку он заставляет нас учитывать, являются ли функции, которые мы доставляем, действительно полезными.
2. Количество инцидентов в производстве
   Низкий уровень инцидентов подразумевает лучшее качество кода, более тщательное тестирование и обоснованные архитектурные решения. Частые инциденты в производстве сигнализируют о скрытых долгах или обрезках в разработке.
3. Оценки поддерживаемости кода
   Мы используем автоматические инструменты, такие как SonarQube, для обнаружения дублирования, сложности и потенциальных уязвимостей. Оценки, которые стабильны или улучшаются с течением времени, указывают на более здоровый код, с культурой, уважающей долгосрочное качество.
4. Обмен знаниями в команде
   Вместо того, чтобы сосредотачиваться исключительно на индивидуальном выходе, мы проверяем, сколько знаний циркулирует. Берут ли пары на себя задачи вместе, выполняют ли они тщательные обзоры кода и документируют ли они основные архитектурные решения? Хорошо информированная команда может коллективно решать проблемы.
5. Рейтинги удовлетворенности клиентов
   В конечном итоге, программное обеспечение предназначено для пользователей. Положительная обратная связь, низкий объем тикетов поддержки и сильные показатели принятия пользователей могут быть отличными индикаторами истинной производительности.

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

Сила стратегической лени

Я раньше думал, что великие разработчики были теми, кто будет писать тысячи и тысячи строк кода каждый день. Со временем я обнаружил, что все может быть совершенно противоположным. На самом деле, лучшие инженеры будут на самом деле практиковать то, что я называю “стратегической ленью”. Вместо того, чтобы погружаться в какой-то сложный решение, которое занимает много времени, они тратят время на создание или поиск более элегантной альтернативы – той, которая требует меньше кода, меньше зависимостей и меньше будущего обслуживания.

Я помню один проект, где младший разработчик потратил три дня на работу над скриптом обработки данных – весившим почти 500 строк кода. Это было просто неуклюжим, но оно работало. Вернувшись и пересмотрев позже того же дня, ведущий разработчик в моей команде смог показать компактное решение из 50 строк, чище, аргументируемо лучше выполняемое, к тому же.

Инструменты и методы для истинной производительности

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

1. Модифицированная техника Помодоро
   Традиционные сегменты Помодоро продолжительностью 25 минут могут показаться слишком короткими для глубоких задач программирования. Мои команды часто используют 45-минутные блоки фокуса, за которыми следуют 15-минутные перерывы. Этот ритм балансирует длительные периоды непрерывного внимания с необходимым временем для отдыха.
2. Гибрид Канбан/Скрам
   Мы объединяем визуальный рабочий процесс из Канбан с итеративными циклами из Скрам. Используя инструменты, такие как Trello и Jira, мы ограничиваем элементы работы в процессе и планируем задачи в спринтах. Это предотвращает перегрузку переключения контекста и держит нас сосредоточенными на завершении задач, прежде чем начинать новые.
3. Отслеживание времени и анализ результатов
   Учет часов с помощью инструментов, таких как Toggl и RescueTime, дает представление о естественных продуктивных часах разработчика. Вооруженные этой информацией, критические задачи для каждого человека планируются в их наиболее продуктивные часы и не ограничиваются жесткими слотами с 9 до 17.
4. Обзоры кода и парное программирование
   Коллаборативная культура имеет тенденцию создавать лучшие результаты, чем поведение отшельника. Мы часто делаем обзоры кода друг для друга, парно программируем время от времени, что помогает нам обнаружить проблемы на ранней стадии, распространяет знания и поддерживает последовательность в нашей базе кода.
5. Непрерывная интеграция и тестирование
   Автоматизированное тестирование и конвейеры непрерывной интеграции защищают от спешных, небрежных коммитов, которые могут сорвать весь проект. Правильно настроенные тесты быстро флагируют регрессии и поощряют вдумчивые, инкрементные изменения.

Создание здоровой инженерной культуры

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

Психологическая безопасность и устойчивые ожидания

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

Дни без встреч и блоки фокуса

Что сработало с одной из моих предыдущих команд, было введение “среды без встреч”. Разработчики проводили весь день, кодируя, исследуя или тестируя без перерывов. Производительность взлетела в эти среды, и каждый в команде просто любил этот блок тихого времени. Мы сбалансировали это с графиком необходимых встреч в другие дни, giữя их короткими и по существу, чтобы мы не увязли в длительных обсуждениях.

Уроки из реальных кейсов

Есть много примеров в более широкой технологической отрасли, которые показывают, как принятие сбалансированной, ориентированной на качество модели приводит к лучшим продуктам. Компании, такие как Basecamp (ранее 37signals), говорили публично о концепции спокойной, сосредоточенной работы. Ограничивая рабочие часы и не поощряя сверхурочную работу, они выпускали последовательно стабильные продукты, такие как Basecamp и HEY, с вдумчивым дизайном. В отличие от высокорисковых стартапов, итерирующих в спешке и выпускающих ошибочные функции, а также сжигающих добровольность разработчиков на своем пути.

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

Переосмысление значения “производительности”

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

Сбалансированное уравнение

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

1. Эффективная работа над продленной работой: Что действительно важно, так это то, что доставляется, а не сколько часов команда сидела перед экраном.
2. Ориентированные на ценность метрики: Мониторинг метрик в отношении результатов, таких как поддерживаемость, уровень дефектов или удовлетворенность пользователей.
3. Культурное непрерывное улучшение: Истинная производительность исходит из инкрементных улучшений в том, как течет работа, команды сотрудничают и пишется код. Ретроспективы, гибкое планирование, обмен знаниями – это то, что делает устойчивый темп возможным с течением времени.

Заключение

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

Личный путь научил меня, что “отработанные часы” или “закрытые тикеты” – такие меры могут быть тревожно обманчивыми. Фактическая производительность исходит от команд, которые энергизированы, пишут ответственный код и функции в соответствии с реальными потребностями пользователей. Для этого требуется целостный подход: вдумчивое планирование, осмысленные метрики, стратегическая лень и сильная инженерная культура, которая ценится за ясность, сотрудничество и креативность. Если мы остаемся открытыми для исследования новых методов, отбрасывая предположения, которые пережили свое время, мы можем построить технологическую отрасль, где производительность способствует не только лучшему программному обеспечению.