Запарное проектирование. Плюсы и минусы работы проектировщиков в паре
Готовясь к конференции ITGM #11, которая проходила 28 октября в Санкт-Петербурге, я написал большой текст для выступления про парное проектирование. Ниже о сути этого подхода, его плюсах и минусах, кейсе и истории о том, как меня затроллили и почему мне это понравилось. Выкладываю адаптированную для блога версию.
Всем привет, меня зовут Владислав Якимов. Я работаю проектировщиком в КБ «Собака Павлова». Пишу в корпоративный и свой блоги. И я просто в восторге от проектирования пользовательского опыта.
Это статья про парное проектирование. Я выбрал эту тему, потому что считаю, что техника ПП самодостаточна и вполне подходит как для работы над простыми проектами вроде сервисов для массового обслуживания, так и для проектирования сложных и даже профессиональных интерфейсов.
Прежде чем начать, набросаю дорожную карту, то есть структуру статьи.
Вначале изложу суть парного проектирования: базовые штуки, ключевые моменты. Короче, матчасть. Затем опишу сходства и различия с привычными для всех нас методами работы, остановлюсь на его сильных сторонах. Потом покажу, как устроена работа. Дальше следует практическая часть: приведу в пример кейс, расскажу про то, как меня затроллили и почему мне это понравилось. В конце — «плюшка» для терпеливого читателя.
Матчасть
Что такое парное проектирование? Вообще эта методика очень похожа на парное программирование, а его уже в 50-е годы упоминает Фредерик Брукс в книге «Мифический человеко-месяц» (https://ru.wikipedia.org/wiki/Мифический_человеко-месяц). Вместе со своим товарищем он создал 1500 строк кода без ошибок. Описанный Бруксом метод стал чрезвычайно популярен в эпоху Agile. Идея проста: процесс написания кода «водителем» курирует «штурман», который не пишет код сам. Если нужно, «гуглит» документацию, реализует простые куски кода и делает все, чтобы уберечь коллегу от выстрела в ногу. Хенрик Книберг, пионер Scrum, оценил этот метод и его плюсы, однако в своей книге «Scrum и XP: заметки с передовой» (https://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2) отметил, что парное программирование не стоит использовать весь день — люди устают. Это не относится к парному дизайну, его можно практиковать сколько душе угодно.
Собственно, на глобальном уровне парное проектирование не особо отличается от парного программирования. Здесь также работают два человека.
Первого принято называть «gen» или «generator» (генератор). Чаще всего эту роль играет тот, кто привык мыслить и изъясняться образами. Такие люди умеют доносить свои идеи четко и ярко, используя визуальные приемы. Они рисуют везде, где только возможно: на доске, на стикерах, на листочках. А еще они дистанцированы от своих решений и «не парятся», если решение не работает, они просто рисуют новое. Такова натура генераторов.
Второго называют «syn» или «synthesizer» (синтезатор). Эту роль играет человек, склонный мыслить аналитически. Как и аналитик, синтезатор должен держать в голове цельную картину, уметь тестировать идеи на ходу и подходить к делу критически. Есть в нем что-то и от менеджера — именно он указывает направление и выстраивает взаимосвязи.
Подытожу. Для генератора главное — легко выдавать картинки и при необходимости отбрасывать нерабочие решения, рисуя новые варианты, а для синтезатора важно аргументированно критиковать любое дизайн-решение генератора и ни в коем случае не пытаться давить авторитетом.
Парный дизайн — это контринтуитивная практика объединения мозгов двух дизайнеров для решения разного рода задач — с целью улучшения пользовательского опыта. У этой методики есть масса вариантов: когда в команде работают два дизайнера из одной компании или из двух разных, когда в команде работает один дизайнер и один программист, когда дизайнеры постоянно меняются ролями и т.д. Но всегда должны соблюдаться два базовых условия.
Во-вторых, парное проектирование про грамотное распределение ролей и обязанностей. Внутри пары есть строгие соглашения, у каждого свои задачи. Благодаря этому удается одновременно получить два свежих взгляда на проблему с совершенно разных сторон.
Сравнение
И здесь возникает неочевидный, но достаточно простой вопрос: «Эм, а почему я сам себе не могу устроить сеанс парного проектирования?» Или: «То есть когда мы работаем в команде, это не парное проектирование?»
Буддизм учит посредством контринтуитивного мышления: чтобы понять природу добра, нужно сперва понять природу зла. Пример в тему, я знаю. Прежде чем говорить о преимуществах/недостатках парного дизайна, стоит взглянуть на недостатки других методов.
Начну с самой простой ситуации — работы в одиночку. Здесь главная проблема в том, что не всем удается критически мыслить. Собственно, именно поэтому и существует парный дизайн: одному человеку трудно критиковать собственные решения и быть объективным. Более того, иногда попросту не хватает опыта, чтобы привести контрпример для собственного решения.
Что касается команд, то здесь главная проблема — предвзятое отношение к человеку, который выше должностью или более напористо отстаивает свою идею. Возникает «эффект привязки», когда трудно отказаться от того, что уже предложили. Еще одна проблема в том, что в любой момент кто-то может захотеть рисовать картинки. Зачем обсуждать, если все и так уже ясно?
Сравнение с дизайн-спринтами (https://designsprintkit.withgoogle.com/) от «Гугла» и прочими инструментами вроде «прижизненного эпикриза» (https://psy.wikireading.ru/48110) оставлю для домашнего изучения.
И все же какими достоинствами обладает парное проектирование? Парный дизайн:
заставляет делать больше итераций и тем самым следовать совету Дона Нормана (https://www.wikiwand.com/en/The_Design_of_Everyday_Things) «всегда иметь больше одного ответа на один вопрос»;
дает два взгляда на один вопрос («gen» смотрит на решение проблемы снизу, а «syn» — сверху; первый про тактику, второй про стратегию);
ставит на поток постоянный обмен знаниями (чем чаще меняешь пару, тем больше узнаёшь);
стимулирует дистанцированность («gen» легко отказывается от плохих решений, «syn» аргументированно критикует идеи).
П*зд!ть — не мешки ворочать (пока «gen» не нарисует, «syn» нечего критиковать).
Процесс
Самое время посмотреть, как это работает. Процесс работы в паре состоит из четырех этапов, практически на каждом дизайнеры работают, не отходя друг от друга. Лишь местами есть разделение, за которым, впрочем, все равно следует совместная работа.
Все начинается с совместного исследования. Пара беседует с заинтересованными лицами и выясняет всю информацию. Один полностью фиксирует разговор, записывая сказанное и делая транксрипт, второй в этот момент задает вопросы, вырисовывает связи, взаимодействия и записывает все инсайты, которые приходят в голову.
После исследования начинается процесс анализа и формализации. Нужно структурировать информацию, отделить зерна от плевел. Синтезатор рисует глобальную картину того, как устроен текущий процесс, отмечает, что нужно изменить и улучшить с учетом всех бизнес-требований заказчика. Также на нем создание пользовательских ролей и сценариев. Генератор не отходит от синтезатора ни на секунду, помогает структурировать информацию и подбирать данные — ведь он фиксировал беседы.
Затем следует этап проектирования концепта. На синтезаторе лежит управление проектной работой: общение с заказчиками, задачи на день и т.д. Генератор включается здесь на полную катушку и начинает предлагать решения: на каждую проблему он выдаёт одну или несколько идей и проговаривает, почему он сделал так, а не иначе. Задача синтезатора не только критически и аргументированно оценивать каждое решение, но и помогать напарнику, с одной стороны, не слишком углубляться в детали, с другой — избегать чрезмерных обобщений. Кстати, излагая свои решения, генератор не забывает документировать их все, а синтезатор фиксирует ключевые моменты в задании для разработчиков и дизайнеров.
Далее наступает финальная фаза, фаза детализации.
Нельзя вот так просто взять и отдать заказчику серые квадратики © Из бесед в КБ «Собака Павлова»
На этом этапе пара начинает целенаправленно детализировать и прорабатывать неосновные сценарии использования. Обычно в паре взаимодействуют два дизайнера, которые трудятся вплотную до этапа детализации концепта. Дальше всё зависит от бизнес-процессов внутри конкретной компании. Чаще всего к разработке подключаются графические дизайнеры, разработчики, тестировщики. На самом деле на этом этапе задача не столько в том, чтобы сделать всё понятным для заинтересованных лиц (хотя, конечно, и для них тоже), сколько в первую очередь — прояснить идею для собственной команды разработчиков, дизайнеров и т.д. Здесь надо отметить еще одну важную деталь: на последнем этапе, да и не только на последнем, неизбежны ситуации, когда напарники вынуждены разделиться и работать обособленно. Однако, когда необходимо принять решение о базовых документах, о варианте интерфейса или о чем-то еще, напрямую связанном с проектом, необходимо снова собраться вместе, решить проблему и лишь потом вернуться к другим делам. Собственно, вот так и появляются интерфейсы.
Кейс
А теперь давайте от теории перейдем к практике и рассмотрим один из множества кейсов. Возьмем кейс компании Cooper (https://www.cooper.com/work/kurbo).
Парным дизайном занимались Кристофер и Сьюзи. Перед ними стояла задача создать приложение Kurbo, которое помогает детям питаться здоровой и полезной едой. Кстати, в «Собаке» мы как-то уже разбирали этот кейс, правда, с другой стороны — рассказывали про то, как проводят UX-исследования на Западе (https://pavlova.cc/westuxresearch/). Советую почитать.
Так вот, есть Крис, он — генератор. И есть Сьюзи, она — синтезатор. Начали они с того, что провели полевые исследования и пообщались с детьми и их родителями. От одного интервью к другому они менялись ролями. Один из пары слушал и фиксировал информацию, второй задавал вопросы и вел беседу. После каждой такой сессии они обменивались инсайтами, делились впечатлениями и структурировали информацию. В одну из таких встреч они поняли, что дети не берут решения из ниоткуда. На них влияют среда, их родители и друзья. Значит, нужно отталкиваться от знакомой еды, сравнивать ее с неполезной и вырабатывать привычки.
После интервью Сьюзи описала персонажей и набросала возможные сценарии использования. Затем пара приступила к проектированию концепта. Крис генерировал решения, а Сьюзи суммировала информацию, тестировала, задавала вопросы. Так появилась идея использовать виртуального настраиваемого помощника, который будет помогать детям ставить цели на неделю и достигать их. Более того, Крис и Сьюзи предложили устраивать реальные веб-семинары с настоящими фитнес-тренерами, чтобы вдохновить детей еще больше.
После того как были отработаны все ключевые сценарии, и вымышленные персонажи были довольны приложением, они перешли к детальному прототипированию. Вместе они отрисовывали красивые интерфейсы, попутно документируя все значимые моменты для разработчиков. Когда настало время финальной презентации, Крис прошелся по сценариям, а Сьюзи акцентировала внимание на проблемах и преимуществах. Они постарались рассказать настоящую и честную историю о своем приложении. В итоге приложение выиграло призы на нескольких конференциях, помогло компании привлечь 5 млн долларов и, конечно, позволило детям держать себя в форме, получая от этого удовольствие. Эта работа была сделана за три месяца.
Так выглядит пример из реальности Кремниевой долины. Попробуем вернуться из мира грез на землю. Есть ли перспективы развития парного проектирования в России? Чтобы проверить эту гипотезу о реальность, я написал нескольким спецам из отрасли и поинтересовался их мнением о парном дизайне. Давайте посмотрим, что они ответили.
Меня все дружно затроллили и не дали ответов. О’кей, я не обломался и пошел дальше: я написал тому самому Крису, работавшему над проектом Kurbo. Он же — автор книги Pair-Design, которая тоже есть в списке источников.
Вот что он ответил:
Hello Vlad. Happy to help explain.
The main disadvantages are money and organizational will.
To assign two designers to the same problem looks on paper like you’re just doubling spending, even though there are correlated gains in speed, productivity, quality, and long-term stakeholder and user satisfaction.
So the organization has to care about quality and have the will to consider more than just the numbers. That’s rare.
There are some minor disadvantages, as well. If a team is at a spot where collaboration is vital to continue, having one person sick or unavailable may pause two people’s progress. A smart pair will be able to work out what can be done in the absence of the other, but sometimes things just stop.
Finally there’s more logistics in play managing an office of pairs rather than managing an office of individual contributors. Related to this, personality mismatches can become a problem when a pair just can’t seem to get along, or the opposite: A pair needs to be split up but just can’t bear to have it happen.
There might be others that I’m not thinking about, but these are the main ones that come up. Happy to continue the conversation via email.
Thank you for the quick response. It is clear. I will email you
перевод:
Привет, Влад.
Буду рад помочь.
Основные недостатки — это затраты и подход компании. Когда ты поручаешь двум дизайнерам решение одной и той же задачи, это выглядит так, как будто ты просто удваиваешь расходы, хотя при этом выигрываешь в скорости, производительности, качестве и удовлетворенности заинтересованных сторон и пользователей в долгосрочном аспекте.
Компания должна заботиться о качестве, должна уметь и хотеть видеть не только цифры. Это бывает нечасто.
Есть и определенные незначительные недостатки. Там, где совместная работа жизненно важна для команды, пара не сможет двигаться вперед, если один человек заболел или недоступен. Опытный тандем справится даже в таких условиях, но порой деятельность попросту останавливается.
И наконец, управлять офисом, где работают пары, сложнее, чем управлять отдельными участниками. Серьезной проблемой может стать личная несовместимость: два человека не могут найти общий язык. Возможна и обратная ситуация: пару нужно разбить, но для людей невыносима сама мысль об этом.
Наверное, есть и другие минусы, о которых я не задумывался, но это основные.
Выходит, основные недостатки парного проектирования — это увеличение затрат, тупиковые ситуации, несовместимость или чрезмерная взаимная привязанность партнеров.
Плюшка
На этом опыт парного проектирования не заканчивается, мне есть чем поделиться. Мы в «Собаке» любим заботиться о пользователях. Регулярно участвуя в конференциях, мы обратили внимание, что вместо резюме выступления мы делаем заметки вроде: «скачать доклад», «пересмотреть видео», «поделиться с коллегой». Это заставляет задуматься о том, каким образом мы потребляем информацию на таких событиях и какие конкретно цели преследуем. Так родилась идея создать вот такой простой бумажный интерфейс в помощь человеку, который идет на конференцию. Пользуйтесь на здоровье
складной помощник.
Итак, приключение длиною в статью подошло к концу. Было чертовски интересно бросить себе вызов и разобраться в теме, такой близкой, но такой непонятной. Особенно любопытно было встретить и услышать человека, применяющего парное проектирование на работе и который после рассказа с увлечением поделился своими взглядами на вопрос. Будьте и вы смелыми и выскажите свое мнение в комментариях. Ведь прочесть так много букв — уже подвиг!
