Разработка продукта — это почти всегда командный вид спорта.
Чтобы создать успешный продукт, несколько заинтересованных сторон должны работать вместе в течение цикла разработки, чтобы добиться цели. Сюда входят инженеры (очевидно), менеджеры по продуктам и проектам, дизайнеры, QA и даже люди из отдела маркетинга и продаж.
Но заставить «разработчиков» и «не разработчиков» (заинтересованных лиц, не являющихся инженерами) хорошо работать вместе не так уж и просто. Потому что каждая роль не только выполняет свою техническую функцию, но они также существенно различаются с точки зрения того, как они работают, какие инструменты они используют и как они общаются с другими членами команды. И когда вы просите людей с разными ролями, персонажами и стилями сотрудничать в сложной задаче, неизбежно возникает некоторое напряжение.
Эта напряженность рабочего процесса между заинтересованными сторонами широко распространена и хорошо известна в отрасли. Просто посмотрите на количество мемов и шуток, которые высмеивают то, как взаимодействуют разработчики и не-разработчики.
Но что интересно, иногда наиболее часто распознаваемые проблемы являются наименее определенными и наиболее неправильно понятыми.
Конечно, все знают, что существуют проблемы межфункционального сотрудничества, но большинство из нас не задумываются об этом. Мы просто продолжаем, бормочем что-то себе под нос и переходим к следующему общему собранию. Кажется, гораздо проще принять это и страдать, чем анализировать, понимать и исправлять.
Разработчики и не-разработчики общаются по-разному
Первое, что бросилось мне в глаза, — это степень, в которой разработчики и не-разработчики общаются (и работают) на разных длинах волн. У каждого человека в команде есть свой уникальный ритм и стиль общения.
Некоторые из ключевых цифр:
Разработчиков слишком часто прерывают
-
41% разработчиков признались, что их «регулярно раздражает» то, что не-разработчики перебивают их случайными вопросами.
Разработчики не понимают обратной связи, которую они получают
-
53% разработчиков заявили, что часто не понимают отзывов от не-разработчиков, и им нужно потратить больше времени, чтобы просмотреть их вместе с ними, чтобы продолжить работу.
Разработчиков просят использовать слишком много инструментов
-
54% разработчиков заявили, что вынуждены использовать слишком много инструментов с единственной целью — общаться с другими заинтересованными сторонами в команде во время рабочего процесса разработки.
Разработчики расстроены этим больше, чем думает остальная часть команды
Тот факт, что разработчики разочаровываются в таких вещах, примечателен, но не совсем удивителен.
Что было действительно интересно, так это обнаружить, в какой степени остальная часть команды не имеет ни малейшего представления о том, что их коллеги-инженеры думают так же.
Когда мы спросили не-разработчиков, что их коллеги-разработчики думают об этих проблемах, значительно меньший процент не-разработчиков ответил утвердительно по сравнению с прямыми ответами самих разработчиков.
Вот параллельное сравнение:
«Разработчиков раздражают частые прерывания коллегами, не являющимися разработчиками»
-
С этим утверждением согласился 41% разработчиков .
-
Но только 15% не-разработчиков считали это правдой.
«Разработчики часто не понимают отзывов о продукте от коллег, не являющихся разработчиками»
-
С этим утверждением согласились 53% разработчиков .
-
Но только 29% не-разработчиков считают, что это правда.
«Разработчики вынуждены использовать несколько инструментов для получения отзывов и контекста от коллег, не являющихся разработчиками»
-
С этим утверждением согласились 54% разработчиков .
-
Но только 23% не-разработчиков считают, что это правда.
Это показывает, что в среднем «неразработчики» не осознают, насколько их коллеги-инженеры разочарованы этими болями в рабочем процессе и коммуникации.
Переключение контекста негативно влияет на продуктивность разработчиков
Как правило, разработчики любят оставаться сосредоточенными и ненавидят переключение контекста. Типичный совместный рабочий процесс с участием нескольких заинтересованных сторон усложняет эту задачу.
Два типа переключения контекста
Благодаря нашим обсуждениям с разработчиками стало ясно, что это неприятие переключения контекстов проявляется как минимум двумя способами: переключением задач и переключением окружения .
Переключение задач — это когда разработчиков просят остановить (текущую) задачу номер один и вместо этого сосредоточиться на (новой) задаче два. Разработчики этого не выдерживают.
Однако переключение сред является более тонким и возможным даже в контексте одной и той же задачи. Это когда разработчики вынуждены покинуть контекст предпочтительного инструмента (например, 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% неразработчиков .
Иди разберись.
В заключение
Понятно, что разработчики недовольны состоянием общения и совместной работы во время рабочих процессов предварительной разработки.
Люди, не являющиеся разработчиками, относительно не обращают внимания на свои чувства по этому поводу и не соотносят последствия плохого общения и совместной работы так, как это делают разработчики.
Все согласны с тем, что эти вопросы принципиально важны и могут повлиять на многие области повседневной деятельности команды.
И хотя многие разработчики считают, что ничего нельзя сделать, чтобы улучшить это, подавляющее большинство не-разработчиков сохраняет оптимизм.
Просто знать об этих точках трения, понимать их распространенность и оценивать их влияние — это важные первые шаги. Эта осведомленность вместе с внедрением инструментов разработчика оказывается достаточно мощной комбинацией, чтобы значительно улучшить — если не полностью обратить вспять — эти негативные тенденции.
Итак, учитывая все обстоятельства, мы довольно оптимистичны в отношении того, куда все движется.
Несмотря на то, что вам может сказать половина разработчиков 🙂
