Если описать программирование и работу в IT в 2023 году одним словом, то этим словом будет «эффективность». Технические компании – от Meta и Google до зарождающихся стартапов – переключились с подхода «рост любой ценой» к раздумьям, как получить максимум от той команды, которая у них есть. Эта сосредоточенность на эффективности обычно предстает способом достичь одной из двух целей, стоящих перед компаниями:

• Улучшить качество и скорость разработки программных продуктов
• Дать техническим командам возможность оказывать более ощутимое влияние на выручку компании

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

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

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

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

Первый компонент совокупной эффективности: наглядное представление показателей в реальном времени плюс ориентиры касательно «хороших» показателей

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

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

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

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

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

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

• улучшение (т.е. снижение) в размерах pull request-ов на 33,2%;
• улучшение в продолжительности цикла на 47,27%;
• улучшение в сроках проведения инспекции кода на 46,82%;
• улучшение в скорости отклика на 48,75%.

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

Второй компонент совокупной эффективности: автоматизация обработки pull request-ов и инспекции кода

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

Наименее оптимизированная часть процесса разработки обнаружилась в промежутке между написанием кода и развертыванием. Pull или merge request-ы и связанные с ними процессы инспекции кода оказались главным узким местом в разработке, значительнее серьезнее, чем все прочие.

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

• Средняя продолжительность цикла для рабочей единицы (от первого коммита до развертывания) в среднем составляет семь дней.
• Половина pull request-ов простаивает (иными словами, никто не ведет над ними активной работы) не менее 50% своего жизненного цикла.
• Продолжительность цикла и время простоя удваиваются для pull request-ов размером в двести строк кода по сравнению с теми, в которых только сто строк.

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

1. Формальный процесс передачи pull request-а на обработку конкретному лицу, как правило, не выстроен.
2. Для размера pull request-а не введены стандарты или рекомендации в лучших практиках.
3. Команды расценивают все pull request-ы как равнозначные, хотя они несут в себе разные степени риска.
4. Полностью отсутствует доступный контекст для pull request-а и представление о том, сколько его будут инспектировать (до того момента, пока его не откроют).

— Ты не взял в работу мой pull request!
— А ты не проставил примерное время!

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

gitStream позволяет разработчикам автоматически:

• назначать сотрудника для инспекции кода;
• добавлять примерный срок обработки в тэги pull request-а;
• ранжировать pull request-ы по уровню риска по отношению к репозиторию (низкий, средний или высокий риск);
• представить возможность автоматического одобрения низкорисковых pull request-ов.

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

Дальнейший рост эффективности после перехода на gitStream выражался в следующих цифрах:

• размер pull request-ов дополнительно снизился на 28,18%;
• продолжительность цикла дополнительно сократилась на 61,07%;
• сроки инспекции кода дополнительно улучшились на 38,14%;
• скорость отклика дополнительно увеличилась на 56,04%.

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

Третий компонент совокупной эффективности: укрепление и защита концентрации разработчиков

Есть один момент, который часто не встречает понимания за пределами технических отделов (а иногда и в их стенах): с разработчиками следует обращаться как с полноценными работниками умственного труда. Иными словами, им нужно выделять время на поиск решений, обдумывание проблем и творчество. Разработчики – не роботы на конвейере, которые могут выдавать продуктивность по щелчку, они занимаются созидательной, творческой деятельностью.




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

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

1. Разработчикам требуется 23 минуты непрерывной концентрации для перехода в состояние потока – именно в этот период они становятся по-настоящему продуктивны.
2. У разработчиков крупных компаний меньше времени на концентрацию: 16,9 часов в неделю против 22,5 часов в неделю у работников компаний поменьше. То есть больше половины рабочего времени программисты проводят в непродуктивном состоянии.

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

• 76% менеджеров утверждают, что с удлинением периодов концентрации возрастает выручка
• 90% руководителей утверждают, что с удлинением периодов концентрации улучшается производительность
• 80% программистов утверждают, что с удлинением периодов концентрации сокращаются сроки разработки.

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

Вот несколько проверенных способов, с помощью которых техлиды могут дать команде максимум концентрации:

1. Ни в коем случае не допускайте, чтобы у ваших разработчиков было раздробленное расписание.
2. Обязательные совещания ставьте вместе, единым блоком.
3. Используйте инструменты вроде CalendarHero, чтобы выстраивать расписание совещаний автоматически.