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

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

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

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

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

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

Креативность и решение проблем, два важных навыка, необходимых в современной программной инженерии, существенно ограничиваются усталостью. Используя инструменты отслеживания времени, такие как 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. Культурное непрерывное совершенствование: Истинная производительность исходит из инкрементных улучшений того, как течет работа, как команды сотрудничают и как пишется код. Ретроспективы, гибкое планирование, обмен знаниями – это то, что делает устойчивый темп возможным с течением времени.

Заключение

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

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