Инженерные команды находятся в постоянной охоте за повышением производительности. У них популярны такие подходы, как DevOps и agile, так как они помогают продвигаться вперед благодаря совместной работе, общению и постановке целей. Хотя эти методологии могут изменить ситуацию, существуют и другие препятствия для повышения производительности, которые выходят за рамки простых рабочих процессов, пишет на портале The New Stack Питер Пезарис, вице-президент группы и генеральный менеджер по стратегии и инструментам для разработчиков компании New Relic.

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

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

1. Контекстное переключение между инструментами и платформами

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

Конечно, этот пример остался в прошлом. Такие инструменты, как Google Docs и Microsoft 365, позволяют нескольким редакторам одновременно комментировать и обсуждать один и тот же документ, обеспечивая совместную работу непосредственно там, где ей и место — в самом документе.

Тем не менее, устаревший пример с Microsoft Word представляет собой уместную аналогию для многих современных сред разработчиков. Хотя такие инструменты, как GitHub, JIRA, Terminal и Slack, приносят ценность для команд разработчиков, они требуют от разработчиков переключения между несколькими инструментами. Частое переключение контекста приводит к бесчисленным часам отвлечения внимания, что резко отрицательно сказывается на скорости разработки. Решение для разработчиков заключается в использовании аналогов Google Docs или Microsoft 365 для инженерных инструментов — расширяемых интегрированных сред разработки (IDE), которые объединяют важные, но разрозненные инструменты в единый рабочий процесс.

2. Институциональные пробелы в знаниях

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

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

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

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

3. Устранение неполадок в контексте

Практика DevOps облегчает командам понимание работы своих членов. Однако отсутствие видимости самого технологического стека может ограничить преимущества подхода DevOps.

Многие разработчики сегодня ограничены менталитетом push-and-pray (сдал и понадеялся на лучшее), развертывая код в продакшн без четкого понимания того, как он работает или как это развертывание меняет другие аспекты производительности, такие как количество ошибок и клиентский опыт. Понятно, почему так происходит. Тому, кто-то сталкивался с обзором 1500 строк кода, может быть знаком соблазн просканировать его и поставить печать одобрения на весь обзор. Однако даже если 1495 строк кода не являются критическими, оставшиеся пять могут иметь существенные последствия для производительности.

Команды разработчиков должны иметь возможность использовать встроенную в IDE наблюдаемость, чтобы диагностировать свои инструменты в контексте. Если сделать наблюдаемость и производственную телеметрию неотъемлемой частью ежедневного рабочего процесса разработчика, это позволит командам немедленно оценивать влияние изменений на свой код.

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

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