Компании все больше внимания уделяют команде разработчиков программного обеспечения как фактору повышения производительности. Работа над драйверами командной продуктивности, а не индивидуальной производительности разработчиков, требует иного взгляда и методологии. И все начинается с обмена знаниями, поскольку разрыв в знаниях между разными разработчиками может привести к ненужному снижению общей производительности, даже если некоторые члены команды будут казаться более продуктивными, чем другие.
Во-первых, немного информации о бизнес-проблемах, которые заставляют команду разработчиков уделять больше внимания. Производительность команды разработчиков становится настолько важной для бизнеса, что стала важной темой в залах заседаний по всему миру. В марте 2019 года Morgan Stanley опубликовал отчет под названием «Новый программный стек для цифровой эры», в котором описывается переход от старого стека (например, Oracle, Tibco, Old Microsoft) к New Stackпредставлен такими компаниями, как Atlassian, PageDuty, Splunk, MongoDB и New Microsoft. Согласно отчету, новый стек представляет собой возможность на 50 миллиардов долларов с среднегодовым темпом роста 22 % против 4 % по сравнению с ростом старого стека благодаря широкому внедрению DevOps и Agile методология. Morgan Stanley определяет DevOpsis как «любую практику, методологию или архитектуру, которые уменьшают или уменьшают неэффективность в процессе предоставления новых функций и услуг конечным клиентам».
С более технической точки зрения DevOps — это стратегия разработки программного обеспечения, которая устраняет разрыв между разработчиками и ИТ-персоналом. С DevOps организации могут очень быстро выпускать небольшие функции и учитывать полученные отзывы. Это приводит к 1) меньшему количеству сбоев программного обеспечения и 2) сокращению времени между исправлениями, то есть повышению производительности. Чтобы все это работало должным образом, обмен знаниями часто является недостающим звеном.
Обмен знаниями важнее всего
Согласно отчету Coding Sans Состояние разработки программного обеспечения за 2019 год, второй по значимости проблемой, с которой сталкиваются технологические компании, является обмен знаниями – сразу после емкости. Как правило, обмен знаниями страдает, когда бэклог заполнен и приближается крайний срок. Другими словами, в мире, где спрос разработчиков превышает предложение разработчиков (как это будет в обозримом будущем), снижение неэффективности во многом зависит от способности организации делиться знаниями.
В отчете также указывается на разницу между взглядами руководства и разработчиков на самые серьезные проблемы в 2019 году. Для разработчиков обмен знаниями является самой важной проблемой, с которой они сталкиваются, 24,57 % респондентов по сравнению с 18,11 %. в 2018 году.
Если обмен знаниями так важен, как сегодня команды решают эту фундаментальную проблему? Процесс Agile уделяет большое внимание личным беседам для передачи информации, но это то же самое, что и комплексный подход к обмену знаниями? Поскольку команды распределены по разным часовым поясам, разговоров становится все меньше. Что дополнит или заменит эти разговоры с глазу на глаз?
Дистанционное управление — это новая норма
Удаленный доступ становится все более распространенным явлением среди разработчиков в организациях любого размера. Согласно тому же отчету, 72,2% разработчиков сообщают, что в их организации разрешена удаленная работа.
Организации с удаленными разработчиками часто обращаются к таким решениям, как Skype или Zoom, которые могут легко заменить личное общение. Разговор в Slack или Microsoft Teams, где можно обмениваться знаниями асинхронно — и утомительно, когда речь идет о коде, — также может отвечать на вопросы и делиться знаниями. Однако эти подходы ничего не делают для команды или организации с точки зрения сбора и организации этих общих знаний, чтобы они могли быть легко доступны через месяц или год. Вместо этого они приводят к повторяющимся и расточительным взаимодействиям, поскольку одни и те же вопросы и опасения поднимаются снова и снова, или, что еще хуже, они становятся барьерами для новых разработчиков, которые боятся задать простой вопрос, опасаясь вызвать раздражение у старших членов команды.
Командная продуктивность и обмен знаниями
Разработчики знают, что существует взаимосвязь между способностью команды делиться знаниями и ее способностью работать более продуктивно — как команда. Существуют различные виды знаний, которыми может делиться команда. Первый вид, общие знания о программировании, может быть передан в сообщениях, документах, вебинарах, книгах и т. д. и может помочь всем членам команды прийти к общему пониманию подходов и методов, которые использует команда. Например, Давиде де Паоло пишет в своем посте Что делает разработчика 10X? что одной из характеристик рок-звезды является обмен знаниями: Как только вы чему-то научились, постарайтесь помочь кому-то еще, научите других коллег, поделитесь своими знаниями. Это может быть совет после ежедневного стендапа, короткая презентация для вашей команды, написание поста в блоге или роль наставника на онлайн-платформе кодирования.
Второй вид знаний специфичен для самого кода. Невозможно получить такие знания, разместив вопрос на Stack Overflow или Quora, поскольку только члены вашей команды могут знать ответ, и, кроме того, из соображений безопасности может потребоваться обсуждение кода только внутри компании.
Многие разработчики сообщают, что разочарованы тем, что тратят большую часть своего времени — иногда до 75 % — на попытки понять код, написанный кем-то другим. Менее 20% разработчиков, опрошенных Stack Overflow в 2018 году, заявляют, что они используют внутреннюю документацию компании, пытаясь понять, как работает код, над которым они работают. В контексте продуктивности команды, как следует делиться такого рода знаниями?
Делитесь знаниями о вашем коде
Чтобы этот второй вид знаний способствовал продуктивности команды, он должен соответствовать четырем критериям:
- Он должен быть легко доступен в любое время
- Это должно быть контекстно
- Он должен быть стойким
- Он должен допускать интерактивность, которая еще больше прояснит его значение и применимость.
- Настало время, когда знания о вашем коде переместятся из изолированных и разрозненных источников в сам код. Знания в контексте легче понять. Команды должны отказаться от концепции кода, который объясняет сам себя, и вместо этого принять решения и технологии, которые заполняют пробелы в знаниях и поднимают всю команду на более высокий уровень. Тогда общие знания становятся конкурентным преимуществом для всей организации.
Вы можете подумать, что комментарии к коду могут позаботиться об этом, но это не так. Комментарии к коду долгое время использовались для объяснения того, как работает код, но они страдают тремя основными недостатками: 1) они относительно быстро устаревают по мере развития кода, 2) они не являются диалоговыми и, следовательно, не подходят для итерации. вокруг объяснения, и 3) вы не можете легко задать вопрос, используя комментарий к коду, а вопросы, возможно, являются наиболее важным элементом обмена знаниями. Это потому, что тот, кто объясняет свой собственный код, не знает заранее, какие аспекты кода не будут легко понятны другому разработчику. Таким образом, возможность задавать вопросы в коде ведет к повышению качества и улучшению документации.
Поэтому командам, заинтересованным в совместном использовании ресурсов и знаний, следует искать решения, соответствующие четырем указанным выше критериям и вписывающиеся в их существующий рабочий процесс и набор инструментов. Обмен знаниями в вашей любимой среде IDE должен упростить обсуждение кода, а интеграция с предпочитаемым вами программным обеспечением для обмена сообщениями и отслеживания проблем позволит разработчикам оставаться в контексте, уведомляя всю команду о появлении новых вопросов и ответов.
Резюме
Продуктивность команды достигается, когда члены команды широко обмениваются знаниями. Разработчики уже чувствуют боль, если им передается слишком мало знаний, и считают это проблемой номер один. Традиционные беседы лицом к лицу могут помочь получить определенные виды знаний, но с распространением удаленного доступа требуются новые решения, которые удовлетворяют как насущные, так и долгосрочные потребности в обмене знаниями. Конкретную информацию, которая описывает, как работает ваш код, не следует отделять от самого кода, поскольку это делает эту информацию менее пригодной для использования и менее понятной. Следующая волна решений и инструментов для разработчиков должна восполнить пробел в знаниях и поднять всю команду на более высокую производительность.
Первоначально опубликовано на https://www.codestream.com.