Почему продуктивность разработчиков зависит не только от инструментов и искусственного интеллекта

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

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

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

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

Три наиболее важные стратегии для максимизации продуктивности разработчиков

1. Создайте условия для достижения разработчиками состояния потока

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

Представьте, что вы держите весь этот контекст в своей голове, а затем кто-то отправляет вам сообщение в Slack с небольшим запросом. Весь контекст, который вы создали, рушится в этот момент. Требуется время, чтобы переориентироваться. Это все равно, что пытаться заснуть и просыпаться каждый час.

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

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

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

2. Нанимайте исключительных менеджеров по продукту

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

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

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

3. Ставьте приоритет на счастье разработчиков

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

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

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

Мы в основном рассматриваем инструменты как способ оптимизировать счастье разработчиков. Это вносит определенные преимущества в качество жизни и ускоряет выполнение рутинных задач. Мы призываем наших инженеров платить и использовать GitHub Copilot, например, потому что мы обнаружили, что сочетание программирования с искусственным интеллектом приводит к повышению производительности разработчиков на 30–40 %. Это инструмент, который стоит вложений.

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

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

Капил Кале — соучредитель и главный операционный директор платформы выплат. Огромный.