5 сентября 2018

Успех совместной работы — привлечение дизайнеров к процессу code review

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

Идея вовлекать в рабочий процесс, особенно на ранних стадиях, представителей других сфер деятельности не всегда кажется привлекательной. Пример совместного участия разных специалистов в code review показывает нам, как мы можем улучшить не только работу разработчиков в команде, но и их взаимодействие с другими специалистами: контент-менеджерами, дизайнерами и UX-аналитиками.

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

При таком подходе мы не прибегаем к каскадной модели. Тем не менее, на раннем этапе разработки часто кажется неуместным привлечение людей из различных областей деятельности. В худшем случае это приводит к так называемой “разработке комитетом”.

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

Как же всё-таки вовлечь в ранний этап процесса разработки специалистов из разных областей, избежав каскадной модели и не создав разработку комитетом? Ответ удалось найти, изучив, что же такое, собственно, code review.

“Вот оно!”— момент

В июле 2017 года я основала Confrere вместе с двумя разработчиками, и мы быстро нашли нашего первого инженера (я сама не разработчик, скорее UX—дизайнер или контент—менеджер). Наше сотрудничество шло удивительно гладко, настолько, что на ретроспективах мы не раз озвучивали всеобщее ощущение того, что мы “всё делаем правильно”.

Noveo Noveogroup Dag-Inge (CTO), я (CPO) и Ингвильд (Sr. Engineer) UX analyst
Dag-Inge (CTO), я (CPO) и Ингвильд (Sr. Engineer)

Я садилась за стол со своими коллегами, и мы пытались определить для себя, что именно мы делаем “правильно”, чтобы сохранить это чувство “правильности”, в то время как наша компания росла и команда расширялась. Мы осознали всю ценность совместной работы на раннем этапе, этот открытый и честный диалог. Наш технический директор Даг-Инге добавил: “Мы работаем как эксперты — поэтому всё получается. Вы не ругаетесь и просто обмениваетесь мнениями об ошибках друг друга”.

Слово “эксперт” и навело меня на этот момент “Вот оно!”. Я поняла: дизайнеры, UX-аналитики и технические писатели могут многому научиться у разработчиков в процессе сотрудничества.

Экспертная оценка в виде code review имеет важное значение для создания программного обеспечения. Для меня ревью кода — это некое вдохновение, которое не только улучшает работу в наших собственных областях, но и служит моделью для сотрудничества в различных сферах.

Если вы уже знакомы с code review, можете пропустить следующий раздел.

Что такое ревью кода?

Ревью кода может быть выполнено различными способами. На сегодняшний день наиболее распространенной является формат пул-реквестов (с использованием технологии git). Как показано ниже, пул-реквесты позволяют другим людям в команде знать, что разработчик завершил написание кода, который они хотят объединить с основной базой кода. Данный формат также позволяет команде просматривать код: они дают отзыв о коде, если он нуждается в улучшении.

Пул-реквесты имеют четко определенные роли: есть автор и рецензент(ы).

Noveo Noveogroup designer UX analyst
Ингвильд (автор) просит провести ревью у Даг-Инге (ревьюер).

В качестве примера предположим, что наш старший инженер Ингвильд внесла изменения в регистрационный поток Confrere. Прежде чем он будет объединен с основной базой кода и отправлен, автор создает запрос на включение внесенных изменений (pull-request), чтобы взять отзыв у нашего CTO Даг-Инге (рецензента). Он не будет вносить никаких изменений в ее код, только лишь добавит свои комментарии.

Noveo Noveogroup designer UX analyst
Даг-Инге комментирует код Ингвильд.

Ингвильд решает сама, как ей реагировать на полученный в ревью фидбэк. Она просто обновит пул-реквест со всеми необходимыми на ее взгляд изменениями.

Noveo Noveogroup UX analyst designer
Ингвильд обновляет свой код, внося изменения в соответствии с комментариями Даг-Инге

После того как ревьюер(-ы) подтвердят пул-реквест, Ингвильд сможет объединить внесенные ею изменения с главной базой кода.

Noveo Noveogroup UX analyst designer
Даг-Инге в знак одобрения ставит в ревью thumb up и Ингвильд может переправлять код на дальнейшие этапы разработки.

Зачем вообще делать ревью кода?

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

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

(Брюс Джонсон, соучредитель Full Story)

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

Правильно организованное ревью кода выстраивает культуру совместной работы и открытость. Способность понять и внести объективную критику в работу других людей — это отличный способ саморазвития, а также вы получаете честную обратную связь о своей работе.

Участие как минимум двух людей в ревью кода также способствует отходу от таких понятий как “мой” код и “ваш” код. Это наш код.

Учитывая всё вышеперечисленное, преимущества ревью выходят за рамки одного лишь кода.

Принципы ревью всех сфер деятельности, не только кода

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

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

  • Взаимоуважение между коллегами и уважение их сфер деятельности.
  • Перед тем, как принимать участие, вы должны быть уверены в собственной роли и в том, что можете адекватно давать и воспринимать критику (это может отразиться на психологической среде внутри команды).

Такая методика в целом представляет собой рекомендованный стандарт работы не только в отношении ревью кода.

В нашей команде при проведении ревью мы стараемся придерживаться следующих принципов:

  1. Критикуем работу, а не автора.
  2. Будьте критичны, но оставайтесь порядочны и внимательны.
  3. Существует разница между а) предложениями, б) требованиями, в) пунктами, требующими обсуждения и прояснений.
  4. Больше обсуждений вживую и меньше в тексте.
  5. Не забудьте отметить удачные моменты — ум, креативность, надежность, оригинальность, подход с юмором и позитивом и т.д.

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

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

Пример

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

ЭТАП 1: СБОР ТРЕБОВАНИЙ

Автор: Ида (UX)

Ревьюеры: Свен (стратегия), Даг-Инге (разработка), Ингвильд (разработка)

Noveo Noveogroup UX analyst designer
Команда собирается вокруг доски. Свен (генеральный директор) слева, Ингвильд (старший разработчик), справа.

Собрания вокруг доски могут показаться утомительными, если в них нет структуры. Чтобы поддерживать производительность и креативность, мы используем структуру “автор / ревьюер” даже в стандартах обычного мозгового штурма на доске. В данном случае я выступала в роли автора, а остальная часть команды давала свой фидбэк и выступала в роли ревьюеров. Поскольку они также знали, что смогут провести ревью моей работы на 2 этапе (а это гораздо больше возможностей для корректировки, внесения предложений и улучшений), мы работали оперативно и смогли достичь соглашения за два часа.

ЭТАП 2: МАКЕТ С МИКРОКОПИЕЙ

Автор: Ида (UX)

Ревьюеры: Ингвильд (разработка), Эйвинд (дизайн), Свен (стратегия)

Noveo Noveogroup UX analyst designer
Когда макеты оформлены как Google-документы, разные специалисты могут оставлять комментарии.

Вы создаете макет потока регистрации с помощью микрокопии. Был ли поток регистрации понятен пользователю и разработчику? И как мы могли бы улучшить поток с точки зрения дизайна и фронтенда? На этом этапе важно работать в формате, где легко поддерживается обратная связь с участниками из разных областей деятельности (мы выбрали Google Docs, также можно использовать такой сервис как InVision).

ЭТАП 3: СОЗДАНИЕ РЕГИСТРАЦИОННОГО ПОТОКА

Автор: Ингвильд (разработка)

Ревьюер: Ида (UX) и Даг-Инге (разработка).

Мы пришли к согласию в отношении потока, полей ввода и микрокопии, и это помогло Ингвильд в разработке. Благодаря Surge мы можем автоматически создавать превью веб-страницы для просмотра изменений, чтобы люди, которые не умеют читать код, также могли дать отзыв на этом этапе.

ЭТАП 4: ПОЛЬЗОВАТЕЛЬСКОЕ ТЕСТИРОВАНИЕ

Автор: Ида (UX)

Ревьюер: Пользователи

Noveo Noveogroup UX analyst designer
Ида производит пользовательское тестирование в рамках небольшого бюджета.

Да, мы рассматриваем пользовательское тестирование как форму ревью. Мы предоставили наш недавно созданный регистрационный поток на рассмотрение фактическим пользователям. Этот шаг открыл нам все тонкости восприятия, в результате чего мы смогли внести самые значительные изменения в наш регистрационный поток.

ЭТАП 5: ДИЗАЙН

Автор: Эйвинд (дизайн)

Ревьюеры: Ингвильд (разработка) и Ида (UX).

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

Noveo Novoegroup designer UX analyst
Первая версия регистрационного потока базировалась на уже существующих элементах дизайна. На данном этапе Эвинд разработал несколько новых элементов с целью улучшения дизайна.

ЭТАП 6: РЕАЛИЗАЦИЯ

Автор: Ингвильд (разработка)

Ревьюер: Эйвинд (дизайн), Ида (UX) и Даг-Инге (разработка).

А затем мы снова вернемся к реализации.

Почему ревью работает

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

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

Регулярные “ревью-пробежки”

По примеру “пробежек” по коду, мы также проводим и регулярные “ревью-пробежки”, фокусируясь на разных вещах и руководствуясь следующими принципами

  • Мы делаем “пробежку” вместе.
  • Ревью и документированием занимается один человек.
  • Идея состоит в том, чтобы идентифицировать проблемы, не обязательно решать их.
  • Мы выбираем такой формат, который дает как можно больше контекста, так что можно легко влиять на результаты позже (например, InvisionApp — для визуальных ревью, Google Docs для текста и т.д.)

Мы провели “ревью-пробежки” по таким моментам, как аудит доступности, просмотр запросов функций, аудит реализации дизайна и эвристические оценки удобства использования.

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

Встреча лицом к лицу (или хотя бы в видеочате) помогает создать некую исследовательскую среду для решения проблем, а не чувство контроля или управления на микроуровне.

Noveo Noveogroup UX analyst designer
Ревью доступности: Джоаким (справа) знакомит Ингвилд и Даг-Инге с проблемами доступности, которые он обнаружил в ходе аудита.

Вы ловите себя на том, что у вас постоянно скапливаются срочные задачи в списке приоритетов? Тогда ревью смогут помочь вам. Если вы ежедневно будете выделять по полчаса на ревью уже проделанной работы, вы сможете обнаружить проблемы до того, как они станут срочными. Это также поможет вам правильно расставить ориентиры и приоритеты, придерживаясь рациональной траектории. Может быть, вашей команде не стоит приступать к новым задачам, пока вы не убедитесь, что предыдущая соответствует стандартам.

Пользовательское тестирование — это форма ревью

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

Очевидно, что если вы хотите снизить риск поставок с явными проблемами с точки зрения юзабилити, пользовательское тестирование должно быть частью обязательной работы. Стандартного ревью интерфейса UX-дизайнерами недостаточно. В нескольких исследованиях выяснилось, что даже эксперты по юзабилити не могут идентифицировать все проблемы практического использования. В среднем, 1 из 3 проблем, выявленных экспертами, оказалась ложной тревогой — она не была проблемой для пользователей на практике. Но что еще хуже, 1 из 2 проблем, замеченных пользователями, была упущена экспертами.

Отказ от пользовательского тестирования — такой же большой риск, как и отказ от ревью кода.

Ревью – смерть креативности?

Люди, работающие в области дизайна, UX и написания контента, зачастую имеют художественное или филологическое образование, в которых талант и вдохновение идеализированы. Если углубиться в историю, у разработчиков наблюдалась аналогичная картина. Со временем произошли существенные изменения, поскольку веб-разработка становилась более сложной.

Если творчество для вас — это глубоко личный аспект, идея ревью кода может показаться пугающей. Кто-то будет вмешиваться в процесс вашей работы? Ой-ой. Но если предположить, что творчество может произрастать из разнообразных источников, таких как диалог, разностороннее видение, сотрудничество или любая иная форма вдохновения (как извне, так и из вашего внутреннего мира), в таком случае ревью — это лишь преимущество и новые возможности.

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

Давайте создавать прекрасное вместе!

Спасибо Анастасии за перевод!

Оригинал: www.smashingmagazine.com/2018/07/collaboration-designers-code-review-process

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте в нашем блоге

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: