Улучшение совместной работы за счет вовлечения дизайнеров в процесс проверки кода
Опубликовано: 2022-03-10Налаженное сотрудничество между разработчиками и дизайнерами — это то, к чему стремятся все, но это, как известно, сложно. Но с сегодняшней продвинутой сетью трудно — если не невозможно — создать действительно отличный продукт без сотрудничества между различными дисциплинами. Из-за множества технологий, необходимых для создания продукта, продукт может быть по-настоящему успешным только тогда, когда все дисциплины — разработчики и дизайнеры, создатели контента и специалисты по стратегии взаимодействия с пользователем — активно участвуют в проекте на ранних стадиях. Когда это происходит, все концы того, что требуется для создания продукта, естественным образом объединяются в единое целое и, таким образом, в отличный продукт.
Из-за этого никто больше не продвигает водопадные процессы. Тем не менее, вовлечение других людей на раннем этапе, особенно людей из других дисциплин, может показаться пугающим. В худшем случае это приводит к «проектированию комитетом».
Более того, как дизайнеры, так и контент-стратеги часто имеют опыт работы в областях, в которых единственный творческий гений все еще является идеалом. Когда кто-то другой доказывает вашу работу, это может ощущаться как угроза вашему творчеству.
Итак, как вы можете привлечь людей на раннем этапе, чтобы избежать водопада, но также убедиться, что вы не настраиваете себя на разработку комитетом? Я нашел свой ответ, когда узнал о обзорах кода.
Ага! Момент
В июле 2017 года я основал Confrere вместе с двумя разработчиками, и мы быстро наняли нашего первого инженера (сам я не разработчик, я больше UX или контент-дизайнер). Наше сотрудничество шло на удивление гладко, настолько, что на наших ретроспективах постоянно повторялась тема, которая заключалась в том, что мы все чувствовали, что «делаем это правильно».
Я села с коллегами, чтобы попытаться точно определить, что именно мы «делаем правильно», чтобы мы могли попытаться сохранить это чувство, даже когда наша компания росла, а наша команда расширялась. Мы пришли к выводу, что все мы ценим участие всей команды на раннем этапе и то, что мы были честны и ясны в своих отзывах друг другу. Наш технический директор Даг-Инге добавил: «Это работает, потому что мы делаем это на равных. Вас не ругают, а просто выдают список недостатков».
Слово «сверстник» — это то, что дало мне момент ага. Я понял, что тем из нас, кто занимается UX, дизайном и контентом, есть чему поучиться у разработчиков, когда дело доходит до совместной работы.
Рецензирование в форме обзоров кода имеет важное значение для того, как создается программное обеспечение. Для меня обзоры кода вдохновляют на улучшение сотрудничества в наших собственных областях, а также являются моделью для сотрудничества между областями и дисциплинами.
Если вы уже знакомы с проверками кода, не стесняйтесь пропустить следующий раздел.
Что такое обзор кода?
Код-ревью можно проводить разными способами. Сегодня наиболее типичная форма проверки кода осуществляется в виде так называемых запросов на извлечение (с использованием технологии, называемой git). Как показано ниже, запросы на включение сообщают другим людям в команде, что разработчик завершил код, который они хотят объединить с основной кодовой базой. Это также позволяет команде просматривать код: они дают отзывы о коде до того, как он будет объединен, на случай, если он нуждается в улучшении.
Пулл-реквесты имеют четко определенные роли: есть автор и рецензент(ы).
В качестве примера предположим, что наш старший инженер Ингвильд внес изменение в процесс регистрации Confrere. Прежде чем он будет объединен с основной кодовой базой и отправлен, она (автор) создает запрос на вытягивание, чтобы запросить проверку у нашего технического директора Даг-Инге (рецензента). Он не будет вносить никаких изменений в ее код, только добавит свои комментарии.
Ингвильд сама решает, как она хочет действовать в соответствии с отзывами, которые она получила в обзоре. Она обновит свой запрос на вытягивание с изменениями, которые считает нужными.
Когда рецензент(ы) одобряют запрос на вытягивание, Ингвильд может объединить свои изменения с основной кодовой базой.
Зачем делать код-ревью?
Если вы никогда не делали обзор кода, описанный выше процесс может показаться бюрократическим. Если у вас есть сомнения, вот масса сообщений в блогах и научных исследований о преимуществах проверки кода.
Проверка кода задает тон для всей компании, что все, что мы делаем, должно быть открыто для проверки другими, и что такая проверка должна быть желанной частью вашего рабочего процесса, а не рассматриваться как угроза.
— Брюс Джонсон, соучредитель Full Story
Проверка кода снижает риск. Наличие кого-либо, подтверждающего вашу работу, а также знание того, что кто-то будет проверять вашу работу, помогает отсеять ошибки и повысить качество. Кроме того, он обеспечивает согласованность и помогает каждому члену команды ознакомиться с дополнительной базой кода.
Если все сделано правильно, проверка кода также формирует культуру сотрудничества и открытости. Попытка понять и критически оценить работу других людей — отличный способ учиться, как и получение честных отзывов о своей работе.
Наличие как минимум двух человек, просматривающих код, также снижает представление о «моем» коде и «вашем» коде. Это наш код.
Учитывая эти преимущества, обзор не должен касаться только кода.
Обзор принципов для всех дисциплин, а не только для кода
У рецензий всегда есть один автор и один или несколько рецензентов. Это означает, что вы можете привлечь людей на ранней стадии, не прибегая к разработке комитетом.
Во-первых, я должен упомянуть два важных фактора, которые повлияют на способность вашей команды делать полезные обзоры. Вам не обязательно владеть ими, но, как минимум, вы должны стремиться к следующему:
- Вы и ваши коллеги уважаете друг друга и правила друг друга.
- Вы достаточно уверены в своей роли, чтобы чувствовать, что можете и давать, и получать критику (это также связано с психологической безопасностью команды).
Даже если мы не проверяем код, можно многому научиться из существующих передовых методов проверки кода.
В нашей команде мы стараемся придерживаться следующих принципов при проведении обзоров:
- Критикуйте произведение, а не автора.
- Будьте критичны, но оставайтесь приветливыми и любопытными.
- Проведите различие между а) предложениями, б) требованиями, в) моментами, требующими обсуждения или уточнения.
- Переместите обсуждение из текста в личную встречу. (Видео засчитывается)
- Не забывайте хвалить хорошие части! Что умного, креативного, солидного, оригинального, смешного, милого и так далее?
Эти принципы не были записаны до тех пор, пока мы не обсудили, почему наше сотрудничество работает так хорошо. Мы все чувствовали, что нам разрешено и ожидается, что мы уже можем задавать вопросы и предлагать улучшения, и что наша мотивация всегда была связана с созданием чего-то великого вместе, а не с критикой другого человека.
Поскольку мы четко понимали, какую обратную связь мы даем, а также не забывали хвалить друг друга за хорошую работу, отзывы были скорее позитивной силой, чем демотивирующей.
Пример
Чтобы дать вам представление о том, как наша команда использует рецензирование в разных дисциплинах и на протяжении всего процесса, давайте посмотрим, как разные члены нашей команды переключались между ролями автора и рецензента, когда мы создавали процесс регистрации.
Шаг 1: Сбор требований
Автор: Ида (UX)
Рецензенты: Свейн (стратегия), Даг-Инге (инженерия), Ингвильд (инженерия).
Сеансы у доски могут быть утомительными, если в них нет структуры. Чтобы поддерживать продуктивность и креативность, мы используем структуру автор/рецензент даже для таких, казалось бы, простых вещей, как мозговой штурм на доске. В этом случае, когда мы придумывали требования для нашего процесса регистрации, я должен был быть автором, а остальная часть команды давала свои отзывы и выступала в качестве рецензентов. Поскольку они также знали, что смогут просмотреть то, что я придумал на шаге 2 (много больше возможностей для корректировок, предложений и улучшений), мы работали быстро и смогли согласовать требования менее чем за 2 часа.
Шаг 2: Макет с микрокопией
Автор: Ида (UX)
Рецензенты: Ингвильд (инженерия), Эйвинд (дизайн), Свейн (стратегия).
Как автор, я создал макет процесса регистрации с помощью микрокопии. Имеет ли процесс регистрации смысл как с точки зрения пользователя, так и с точки зрения инженеров? И как мы могли бы улучшить поток с точки зрения дизайна и внешнего интерфейса? На этом этапе важно было работать в формате, в котором всем специалистам было бы легко оставить отзыв (мы выбрали Google Docs, но это можно было сделать и с помощью такого инструмента, как InvisionApp).
Шаг 3. Реализация процесса регистрации
Автор: Ингвильд (инженерия)
Рецензент: Ида (UX) и Даг-Инге (инженерия).
Мы договорились о потоке, полях ввода и микрокопии, поэтому Ингвильд должна была реализовать это. Благодаря Surge мы можем автоматически создавать URL-адреса для предварительного просмотра изменений, чтобы люди, которые не умеют читать код, также могли оставить отзыв на этом этапе.
Шаг 4. Пользовательское тестирование
Автор: Ида (UX)
Рецензент: Пользователи.
Да, мы рассматриваем пользовательское тестирование как форму обзора. Мы представили наш недавно созданный процесс регистрации лицом к лицу с реальными пользователями. Этот шаг дал нам массу информации, и в результате произошли самые значительные изменения в нашем процессе регистрации.
Шаг 5: Дизайн
Автор: Эйвинд (дизайн)
Рецензенты: Ингвильд (инженерия) и Ида (UX).
Когда дизайн внезапно появляется здесь, на шаге 5, это может быть очень похоже на процесс водопада. Тем не менее, наш дизайнер Эйвинд уже участвовал в качестве рецензента с шага 2. Он дал кучу полезных отзывов на этом этапе, а также смог начать думать о том, как мы могли бы улучшить дизайн процесса регистрации за пределами существующих модулей. в нашей дизайн-системе. На этом этапе Эйвинд также может помочь решить некоторые проблемы, которые мы выявили в ходе пользовательского тестирования.
Шаг 6: Реализация
Автор: Ингвильд (инженерия)
Рецензент: Эйвинд (дизайн), Ида (UX) и Даг-Инге (инженерия).
И тогда мы вернемся к реализации.
Почему обзор работает
Таким образом, всегда есть только один автор, что позволяет избежать разработки комитетом. Вовлекая в качестве рецензентов ряд дисциплин на раннем этапе, мы избегаем каскадного процесса.
Люди могут заранее сообщить о своих опасениях, а также начать думать о том, как они могут внести свой вклад позже. Четко определенные роли держат процесс в нужном русле.
Регулярные пошаговые обзоры
Вдохновляясь пошаговыми руководствами по коду, мы также проводим регулярные пошаговые обзоры с различными фокусами, руководствуясь следующими принципами:
- Прохождение выполняется вместе.
- Один человек отвечает за рассмотрение и документирование.
- Идея состоит в том, чтобы выявлять проблемы , а не обязательно решать их.
- Выберите формат , который дает как можно больше контекста, чтобы впоследствии было легко действовать на основе результатов (например, InvisionApp для визуальных обзоров, Google Docs для текста и т. д.).
Мы сделали пошаговые обзоры для таких вещей, как аудит доступности, рассмотрение запросов функций, аудит реализации дизайна и проведение эвристических оценок удобства использования.
Когда мы проводим ежеквартальные проверки доступности, наш консультант по доступности Йоаким сначала изучает интерфейс и документы и расставляет приоритеты по проблемам, которые он нашел в общей таблице Google. Затем Йоаким знакомит нас с наиболее важными выявленными им проблемами.
Встреча лицом к лицу (или, по крайней мере, на видео), чтобы обсудить проблемы, помогает создать среду для обучения, а не ощущение контроля или микроуправления.
Если вы обнаружите, что постоянно связаны с чем-то, что должно быть выпущено, или исправляете то, что находится в верхней части вашего почтового ящика, обзоры могут помочь исправить это. Если вы регулярно выделяете полдня на анализ уже проделанной работы, вы можете выявить проблемы до того, как они станут срочными. Это также может помочь вам переориентироваться и убедиться, что ваши приоритеты остаются в правильном направлении. Возможно, вашей команде не следует начинать создавать эту новую функцию, пока вы не будете уверены, что существующие функции соответствуют вашим стандартам.
Пользовательское тестирование — это форма обзора
Важной мотивацией для проверки кода является снижение риска. Делая это каждый раз, когда вы вносите изменение или добавляете что-то новое в свой продукт, а не только тогда, когда вы подозреваете, что что-то может быть не на должном уровне, вы уменьшаете вероятность появления ошибок или некачественных функций. Я считаю, что мы должны смотреть на пользовательское тестирование с той же точки зрения.
Видите ли, если вы хотите снизить риск появления серьезных проблем с юзабилити, пользовательское тестирование должно быть частью вашего процесса. Недостаточно просто попросить ваших UX-дизайнеров просмотреть интерфейс. Несколько исследований показали, что даже эксперты по юзабилити не могут выявить все реальные проблемы с юзабилити. В среднем 1 из 3 проблем, выявленных экспертами, были ложными тревогами — на практике они не были проблемами для пользователей. Но что еще хуже, 1 из 2 проблем, которые действительно возникали у пользователей, не учитывались экспертами.
Пропустить пользовательское тестирование так же опасно, как и пропустить код-ревью.
Означает ли обзор смерть творчеству?
Люди, работающие над дизайном, взаимодействием с пользователем и контентом, часто имеют образование, полученное в художественных школах или, может быть, в литературе, где единственный создатель или творческий художественный гений провозглашается идеалом. Если вы вернетесь в историю, то это имело место и для разработчиков. Со временем это изменилось по необходимости, поскольку веб-разработка стала более сложной.
Если вы цепляетесь за идею творчества, исходящего откуда-то глубоко внутри вас, идея обзора может показаться угрожающей или пугающей. Кто-то вмешивается в вашу недоделанную работу? Ой. Но если вы думаете о творчестве как о чем-то, что может исходить из многих источников, включая диалог, сотрудничество или любую форму вдохновения (будь то извне или откуда-то внутри вас), то обзор — это только актив и возможность.
Пока мы создаем что-то для Интернета, нет возможности сотрудничать с другими людьми, будь то в нашей области или с другими. А хорошая идея выдержит проверку.
Давайте создадим что-то великое вместе.