Я спросил 200 команд разработчиков, насколько хорошо они работают вместе — вот что я узнал
18 ноября 2022 г.Разработка продукта — это (почти всегда) командный вид спорта.
Чтобы создать успешный продукт, несколько заинтересованных сторон должны работать вместе в течение цикла разработки, чтобы добиться цели. Сюда входят инженеры (очевидно), менеджеры по продуктам и проектам, дизайнеры, специалисты по контролю качества и даже специалисты по маркетингу и продажам.
Но заставить «разработчиков» и «не разработчиков» (заинтересованных лиц, не являющихся инженерами) хорошо работать вместе не так уж и просто. Потому что каждая роль не только выполняет свою техническую функцию, но они также существенно различаются с точки зрения того, как они работают, какие инструменты они используют и как они общаются с другими членами команды. И когда вы просите людей с разными ролями, личностями и стилями сотрудничать в сложной задаче, обязательно возникнет некоторое напряжение.
Эта напряженность рабочего процесса между заинтересованными сторонами широко распространена и хорошо известна в отрасли. Просто посмотрите на количество мемов и шуток, которые высмеивают то, как взаимодействуют разработчики и не разработчики.
Но что интересно, иногда наиболее часто встречающиеся проблемы являются наименее определенными и наиболее неправильно понятыми.
Конечно, все знают, что проблемы межфункционального сотрудничества существуют, но большинство из нас не задумываются об этом. Мы просто продолжаем, бормочем что-то себе под нос и переходим к следующему общему собранию. Кажется, гораздо проще принять это и страдать, чем анализировать, понимать и исправлять.
Поэтому я решил пойти против течения и посмотреть на это поближе. В течение прошлого года я (вместе со своей командой) изучал, как разработчики и не-разработчики сотрудничают и общаются на протяжении всего рабочего процесса разработки продукта. Я посмотрел, что работает, а что нет, и что именно каждый персонаж думает о другом на каждом этапе пути.
Если вам интересно, почему кто-то тратит на это столько времени, это справедливый вопрос.
По правде говоря, я испытал это напряжение на собственном опыте, работая над продуктами и маркетологами в нескольких компаниях, но моей главной мотивацией было присоединиться к Livecycle. Потому что таким образом мне поручили помочь создать продукт, предназначенный для решения именно этой проблемы.
Поскольку основной целью нашего продукта является ускорение цикла обратной связи и снижение напряженности в рабочем процессе, я чувствовал, что мне необходимо глубоко понять, в чем заключались эти проблемы.
И что может быть лучше для этого, чем каждый день разговаривать с сотнями людей, которых это задевает?
Итак, я приступил к работе и в конце концов услышал представителей 200 команд разработчиков программного обеспечения со всего мира (как я заставил их поговорить со мной — это совсем другая история). Я спросил их об их рутине и рабочих процессах. Я спросил об их взаимодействии и их разочарованиях. Я собрал ответы от людей, занимающих все ключевые инженерные и неинженерные должности в различных компаниях, от стартапов до публичных корпораций.
Некоторые данные подтвердили то, что, возможно, и следовало ожидать, но большая часть из них оказалась показательной. И весь процесс был действительно увлекательным.
Я собрал краткий обзор некоторых ключевых данных и выводов в надежде, что мои усилия могут быть полезны некоторым другим командам.
Разработчики и не разработчики общаются по-разному
Первое, что бросилось мне в глаза, это то, в какой степени разработчики и не разработчики in-a-tech-career">общаться (и работать) на разных длинах волн. У каждого человека в команде есть свой уникальный ритм и стиль общения.
Некоторые ключевые цифры:
Разработчиков слишком часто прерывают
- 41 % разработчиков признались, что их «регулярно раздражает», потому что люди, не являющиеся разработчиками, перебивают их случайными вопросами.
Разработчики не понимают отзывы, которые они получают
- 53 % разработчиков заявили, что часто не понимают отзывов, сделанных не разработчиками, и им нужно потратить больше времени, чтобы просмотреть их вместе с ними, чтобы продолжить работу.
Разработчиков просят использовать слишком много инструментов
- 54 % разработчиков заявили, что вынуждены использовать слишком много инструментов с единственной целью – общаться с другими заинтересованными сторонами в команде во время рабочего процесса разработки.
Разработчики расстроены этим больше, чем остальные члены команды
Тот факт, что разработчики разочаровываются в таких вещах, примечателен, но не совсем удивителен.
Что было действительно интересно, так это то, что остальная часть команды понятия не имеет, что их коллеги-инженеры так думают.
Когда мы спросили не-разработчиков, что их коллеги-разработчики думают об этих проблемах, значительно меньший процент не-разработчиков ответил утвердительно по сравнению с прямыми ответами самих разработчиков.
Вот параллельное сравнение:
"Разработчиков раздражают частые прерывания коллегами, не являющимися разработчиками"
- 41 % разработчиков согласились с этим утверждением
- Но только 15% не-разработчиков считают, что это правда
"Разработчики часто не понимают отзывов о продукте от коллег, не являющихся разработчиками"
- 53% разработчиков согласились с этим утверждением
- Но только 29% не-разработчиков считают, что это правда
"Разработчики вынуждены использовать несколько инструментов для получения отзывов и контекста от коллег, не являющихся разработчиками"
- 54% разработчиков согласились с этим утверждением
- Но только 23% не-разработчиков считают, что это правда
Это показывает, что в среднем "неразработчики" не осознают, насколько их коллеги-инженеры разочарованы этими болями в рабочем процессе и общении.
Переключение контекста негативно влияет на продуктивность разработчиков
Как правило, разработчики любят оставаться сосредоточенными и ненавидят переключение контекста. Типичный совместный рабочий процесс с участием нескольких заинтересованных сторон усложняет эту задачу.
Два типа переключения контекста
В ходе наших обсуждений с разработчиками стало ясно, что это неприятие переключения контекстов проявляется как минимум двумя способами: переключение задач и переключение среды.
Переключение задач — это когда разработчиков просят остановить (текущую) задачу 1 и вместо этого сосредоточиться на (новой) задаче 2. Разработчики этого не выносят.
Однако переключение сред является более тонким и возможным даже в контексте одной и той же задачи. Это когда разработчики вынуждены покинуть контекст предпочтительного инструмента (например, GitHub) и перейти на более иностранный инструмент или платформу, чтобы выполнить поставленную задачу (это может включать чтение электронной почты или просмотр заявки Jira).
Влияние переключения контекста
Суть в том, что любое переключение контекста негативно влияет на продуктивность разработчика. В нашем исследовании 44 % разработчиков признали, что "прерывания и переключения контекста регулярно и негативно сказываются на моей продуктивности" в значительной степени.
Это еще более важно в сочетании с нашими предыдущими выводами о перерывах разработчиков. Помните, что выше мы подчеркивали, что люди, не являющиеся разработчиками, на 50 % реже понимают, что разработчиков раздражают их вопросы и прерывания.
Это означает, что люди, не являющиеся разработчиками, в два раза чаще задают эти «невинные» вопросы и вызывают переключение контекста во время рабочего процесса разработки.
Плохая совместная работа напрямую влияет на опыт разработчиков
Мы придумали новый термин "опыт разработчика". Если «пользовательский опыт» — это уровень комфорта, доступности и радости, которые испытывает конечный пользователь при использовании продукта по назначению, то «опыт разработчика» — это уровень комфорта, доступности и радости, которые испытывает инженер, когда пишет. кода и разработки программного обеспечения.
Технические сотрудники ожидают рабочей среды и инструментов, которые позволят им выполнять свою работу наилучшим образом. Компании осознают это и предпринимают преднамеренные шаги, чтобы сделать рабочий процесс более приятным. Некоторые компании дошли до того, что ввели в команду новую функцию «Опыт разработчика», единственной обязанностью которой является буквальное повышение качества работы команды разработчиков.
Поэтому в рамках нашего исследования нам было важно попытаться оценить влияние плохой совместной работы и коммуникации на общий опыт разработчиков в команде.
Для этого мы спросили разработчиков и лиц, не являющихся разработчиками, согласны ли они со следующим утверждением: «Плохое общение и сотрудничество с другими заинтересованными сторонами делают мое рабочее время менее приятным прямым и существенным образом».
- 52% разработчиков согласились с этим утверждением
- Наоборот, только 26% не-разработчиков согласились
Это несоответствие согласуется с выводами, сделанными выше, о том, что люди, не являющиеся разработчиками, примерно на 50 % меньше осведомлены о том, что их коллеги-разработчики недовольны рабочим процессом. Примечательно, что более половины опрошенных нами разработчиков считают, что проблемы с общением и совместной работой в команде отрицательно сказываются на их опыте разработки.
Разработчики видят причину & влияние плохого сотрудничества больше, чем не-разработчики
Трудно измерить влияние плохой совместной работы и коммуникации в реальном бизнесе, поэтому вместо этого мы попытались хотя бы понять, как это влияние воспринимается вовлеченными людьми. Мы попросили команды разработчиков продуктов указать, в какой степени плохое сотрудничество и коммуникация в рабочем процессе напрямую повлияли на качество их продуктов, график поставок и напряженность с внешними сторонами.
Вот что мы узнали:
Плохая коммуникация в рабочем процессе приводит к снижению качества продуктов
- 45 % разработчиков заявили, что эти проблемы напрямую и негативно повлияли на качество их продукта. Интересно, что только 18 % не-разработчиков так ответили на вопрос тот же вопрос
Плохая коммуникация в рабочем процессе приводит к задержке доставки
- 47 % разработчиков заявили, что эти проблемы напрямую вызывают задержки в выпуске продукта.
- 32 % не-разработчиков так ответили на тот же вопрос
Плохая коммуникация по рабочему процессу приводит к напряженности в отношениях с клиентами и руководством
- 46 % разработчиков заявили, что эти проблемы напрямую создали напряженность между командой и руководством компании или между компанией и заказчиком.
- 38 % не-разработчиков так ответили на тот же вопрос
Межфункциональное сотрудничество влияет на то, как люди воспринимают & уйти с работы
Последствия плохой совместной работы и коммуникации не ограничиваются качеством продукта и задержками доставки.
Наше исследование показало, что эти проблемы оказывают реальное влияние и на отдел кадров.
Почти 60 % разработчиков и 65 % не-разработчиков указали, что способность (или неспособность) эффективно сотрудничать с другими заинтересованными сторонами в процессе разработки продукта является ключевое соображение при принятии решения о том, взять или оставить конкретную работу.
В то время, когда технологические компании борются с трудностями найти, нанять и удержать квалифицированных специалистов, это поразительные цифры. Понятно, что продуктивное взаимодействие между разработчиками и не разработчиками, когда они вместе создают продукты, гораздо серьезнее, чем очередная забавная шутка или остроумный мем.
Какие задачи рабочего процесса нуждаются в наибольшем улучшении?
Представленные на данный момент данные дают общее представление о состоянии межфункционального сотрудничества в ходе «рабочего процесса разработки», но не помогают нам понять, какие именно действия необходимо улучшить. Каждый рабочий процесс содержит ряд определенных действий, которые потенциально могут стать проблемными местами для междисциплинарной группы, которой поручено их выполнение.
Поэтому мы углубились в этот вопрос, чтобы лучше понять, какие именно задачи рабочего процесса нуждаются в наибольшем улучшении в отношении межфункционального взаимодействия и совместной работы.
Вот какие данные мы получили:
* Отзывы о дизайне пользовательского интерфейса = 57 % респондентов заявили, что их команда должна это улучшить. * Отчеты об ошибках = 37% * Приемочное тестирование = 35% * Копии отзывов = 28% * Настройка промежуточных сред = 26 % * Проверки кода = 20% * Документация = 4% * Аналитика = 2% * "Наш рабочий процесс идеален!" = 2%
Разработчики настроены чуть менее оптимистично, чем неразработчики
Наконец, услышав так много о проблемах и разочарованиях, нам было любопытно узнать, есть ли у этих команд разработчиков надежда на изменения и прогресс. Для этого мы спросили наших респондентов, согласны ли они со следующим утверждением: «Разработчики и не-разработчики никогда не будут в полной мере сотрудничать или общаться. Это как кошки & собаки или масло & вода. Они просто плохо сочетаются друг с другом».
45% разработчиков согласились с этим утверждением. В отличие от всего 3% не-разработчиков.
Разберись.
В заключение
Понятно, что разработчики недовольны состоянием общения и совместной работы во время рабочих процессов предварительной разработки.
Люди, не являющиеся разработчиками, относительно не обращают внимания на свои чувства по этому поводу и не соотносят последствия плохого общения и совместной работы так, как это делают разработчики.
Все согласны с тем, что эти проблемы имеют фундаментальное значение и могут повлиять на многие области повседневной деятельности команды.
И хотя многие разработчики считают, что ничего нельзя сделать, чтобы улучшить ситуацию, подавляющее большинство не-разработчиков сохраняет оптимизм.
Оставив в стороне мрачные взгляды разработчиков, мы должны задаться вопросом — что может сделать с этим команда?
Если общение и совместная работа в процессе разработки так важны для успеха любого продукта или компании, что мы можем сделать, чтобы внести улучшения?
Просто знать об этих точках трения, понимать их распространенность и оценивать их влияние — это важные первые шаги. Именно эта осведомленность вместе с внедрением инструментов разработчика оказывается достаточно мощной комбинацией, чтобы значительно улучшить, если не полностью обратить вспять, эти негативные тенденции.
Таким образом, учитывая все обстоятельства, мы довольно оптимистично смотрим на будущее.
Несмотря на то, что вам может сказать половина разработчиков :-)
Также опубликовано здесь
Оригинал