Командная разработка: настройка слаженной работы дизайнеров и разработчиков | Глава 3

(Перед вами перевод бесплатного курса «Design Engineering» от компании InVision. Если вы здесь впервые, то лучше начните сначала)

Добиться слаженной командной работы между дизайнерами и разработчиками не просто — такова реальность. В этой главе мы подробно разберем шаги, которые может предпринять каждый участник рабочей группы (в том числе и руководители), чтобы условия способствовали эффективному обмену идеями и давали каждому в команде возможность выполнять свою работу наилучшим образом. Шаги включают в себя (1)изменение ожиданий, (2)обнаружение паттернов и (3)создание систем для продуктивной командной работы.

1. Когнитивный сдвиг и изменение ожиданий

Командная работа между дизайнерами и разработчиками не возникнет сама собой. Здесь нужно поднимать абсолютно новый подход к работе!  Просто сказать ребятам «общайтесь» или «сядьте поближе друг к другу» — не сработает. Когда вы обнаружите, что ошиблись, сделав так, пройдет уже слишком много времени и к тому же, такая система неустойчива к уходу ребят, на которых была завязана вся коммуникация. Поэтому здесь нужен системный подход, чтобы команда могла слаженно работать и без вас.

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

Ир Адериноку (Ire Aderinokun), дизайн-инженер и co-founder BuyCoins

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

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

Как переводчик: проводник между ментальными моделями

Сейчас, когда я слышу фразы про «преодоление разрыва» между дизайном и разработкой, я понимаю, что куда важнее навык переключения между этими двумя дисциплинами. Больше общаться здесь не поможет, потому что у каждого специалиста разный язык и разный взгляд на то, что они создают и каким оно должно быть – разная ментальная модель.

Что такое ментальные модели?

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

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

Например, тот, кто сначала изучает Haskell (математический и продвинутый язык), может счесть JavaScript (который гораздо более легкий на подъем) хаотичным. А тот, кто начинает с JavaScript, может найти Haskell слишком ограниченным и прямолинейным.

• Сюжет 1: Дизайнер взялся за изучение CSS?: «Каскадные стили — это свобода, и декларативное мышление прекрасно»!
• Сюжет 2: Программист взялся за CSS?: «Да здесь фокусируются на всех вещах разом! Дайте мне поток управления здесь, и, боже мой, каскадные стили непредсказуемы».

Первоначальные знания влияют на то, как мы усваиваем новую информацию.

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

• CSS – это вообще язык программирования?
• Кто должен уметь в CSS? Дизайнеры или разработчики?
• А мой CSS хорош?

CSS уже 20+ лет. И по всем трем вопросам все еще идут горячие споры и именно из-за столкновения первоначальных знаний и различных ментальных моделей специалистов, а не самой технологии.

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

CSS — это язык программирования. Язык, который полезен как дизайнерам, так и разработчикам.

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

Когнитивный диссонанс: ловушка для новичков, с которой сталкивался каждый

Что такое когнитивный диссонанс? Представьте, что в процессе решения задачи, вы уверены и компетентны — правда же прекрасное чувство. Вы потихоньку совершенствуете навыки и развиваете удобную ментальную модель того, как всё работает. Хорошо разбираться в чем-то – это же круто! Но однажды, приступив к новой задаче, вы ожидаете, что здесь дела тоже пойдут привычным образом, но почему-то, все идет совсем не так, как хотелось. И в следующий момент, вы уже просто не понимаете, зачем вообще нужно решать эту задачу таким ужасным способом. В душе возникает ужасное и неприятное ощущение. Такая ситуация называется – когнитивный диссонанс – разочарование, которое мы испытываем, когда сталкиваемся с другим способом мышления. Когнитивный диссонанс – это одно из самых серьезных препятствий в обучении.

Конечно, опытный преподаватель готов к тому, что новичок может расстроиться, как только почувствует, что его ментальная модель трещит от непонимания. И есть шанс, что ученик даже начнет обвинять инструмент/метод/процесс – что угодно, только не собственное понимание. Все это, симптомы разочарования, если оно усилится, то может стать причиной отступления в зону комфорта. Я не осуждаю такое отступление – мы же все, так или иначе, встречаем когнитивный диссонанс. Однако диссонанс может стать серьезной проблемой, если будет окружать нас повсюду в сети.

Такая реакция на когнитивный диссонанс может остановить в развитии как новичков, так и опытных. А именно:

• Увеличить разрыв в понимании между дизайнерами и разработчиками.
• Открыть бурные дискуссии на пересечении ментальных моделей, например, в CSS.
• Создать череду уходов в узкую специализацию – отступления в зону комфорта
• Остановить ребят в безмерном развитии в смежные области.

Какие-то грустные сюжеты вырисовываются. Что делать?

Способ обойти когнитивный диссонанс: подняться над картиной происходящего

Хорошая новость в том, что, эти барьеры вымышлены и в значительной степени представляют собой накрученный характер, и поэтому есть масса вариантов их преодолеть. Первый шаг – прокачать гибкость мышления. Вы когда-нибудь были заложником плохо организованного рабочего процесса, искрящегося обвинениями? Чтобы убрать токсичные модели взаимодействия, нам нужно освободиться от разрозненности и сознательно попрактиковаться с применением различных ментальных моделей. Если мы не практикуем другие способы мышления, мы рискуем стать жесткими и неспособными к командной работе.

Если вы когда-либо программировали, скорее всего, вы слышали знаменитую цитату контр-адмирала Грейс Хоппер: «Самая опасная фраза: мы всегда так делали». Цитата часто используется, чтобы побудить людей принять изменения. Конечно, изменение курса, особенно радикальное, может выглядеть опасным. Это все из-за того, что нам просто неприятен когнитивный диссонанс, а возникает он, потому что происходит выход из зоны комфорта. Учиться некомфортно, соответственно, важно создать обстоятельства, которые позволят безопасно пережить этот дискомфорт и добиться прогресса. Учителя делают такое каждый день в классе.

Однажды я создала семестровый курс под названием Modular Design Patterns with React для Harvard Extension School и уделила особое внимание пересечению дизайна и разработки. Учебная программа привлекла профессионалов разного профиля, от графических дизайнеров до backend-разработчиков. На первом занятии рассказала, что практика командной работы станет для нас главной целью обучения, но я не предупредила их о том, как именно мы будем практиковаться.

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

Главное условие – каждый должен был согласиться на роль, в которой он был «худшим». После того, как паника на старте утихла, учащиеся разобрали роли в команде, и начали готовиться к освоению другой ментальной модели (того «как все должно работать» далеко за пределами их зоны комфорта):

• Программист с десятилетним опытом программирования на JavaScript стал дизайнером, отвечающим за UX;
• Эксперт по SEO стал экспертом по Git и внезапно узнал, что каждый может улучшить код;
• Графический дизайнер превратился во front-end разработчика с ответственностью за качество кода и доступность.

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

Что с результатами? Студенты усердно работали и смеялись, когда открывали интересные для себя вещи. Что наиболее важно, в конце многие из них сказали, что переход на другую роль помог им лучше понять вклад собственной работы в общее дело. Каждый сказал, что теперь видит способы вырасти и стать полезнее. Каждый стал лучше выполнять свою собственную работу, поработав в чужой роли. Слово «эмпатия» чаще всего встречалось в отзывах.

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

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

Мэтт Ротенберг (Matt Rothenberg), Designer/Front-End Developer, based in New York, Clearbit

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

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

2. Обнаружение паттернов

Задавайте вопросы

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

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

• Что именно сейчас не устраивает в командной работе? Кто все время доделывает работу за других? Кто сейчас стал самым слабым звеном?
• Возникает ли нездоровая атмосфера в команде? Кто из дизайнеров или разработчиков все чаще чувствует недооцененным свой вклад? Кто чувствует себя не услышанным?
• Часто ли возникает техническая некомпетентность или проблемы с реализацией? Как быстро накапливается технический долг? Изобретаем ли мы колесо/велосипед заново? 
• Кто несет ответственность за выполненную работу? Кто отвечает за качество кода? Кто развивает компонентную архитектуру? В чем вклад каждого участника?
• Мы работаем по водопадной модели? Почему разработчики не могут приступить к работе (прототипирование, тестирование, определение объема работ) до завершения дизайна? Как часто дизайнеры начинают проект без проработанных требований?
• Наш UI соответствует стандартам рынка? Кто несет ответственность за объем работ, качество обновлений и переработки при обновлении бренд-айдентики и гайдлайнов? Как мы узнаем, что не все учли?
• Как часто мы проводим бесполезные собрания? Действительно ли команда считает их полезными или так хочется верить? Как мы определяем, что коммуникация проходит как надо?

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

С чего начинается внедрение изменений

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

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

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

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

3. Создание систем для продуктивной командной работы

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

Начинать придется с самого себя. Здесь к месту старая пословица: «Делай как я говорю, а не как я». В общем помните, что значимые организационные изменения начинаются с вас. 

Перед тем как уйти в декретный отпуск, мне пришла в голову идея создать инструкцию, что и как будет делать каждый, пока меня не будет. Вместо того, чтобы писать слишком конкретную документацию о «правильном способе делать что-то», которую никогда не прочитал бы ни один человек, ценящий свое время, я решила постараться создать систему, которая бы облегчила переход от моей ментальной модели того, как все работает на ментальную модель моих коллег. Мне необходимо было найти для моей команды способы добиваться лучших результатов без меня. 
Например, в мои задачи входило взаимодействие между дизайном и разработкой. У меня были разносторонние навыки и я слишком поздно поняла, что никого не научила делать так, как умею сама – просто не прокачала у других свой способ мышления (ментальную модель). Поэтому я сделала инструмент, который помогает организовать передачу из дизайна в разработку без копаний в моей голове. Стайлгайды и библиотека компонентов помогли сделать нашу работу более наглядной, так как и дизайн и код стали хорошо структурированы: компоненты, гайдлайны, цвета, функции. Клево убрать слабое звено и увидеть как система начала работать лучше.

«Помочь двум людям взглянуть на одну и ту же проблему и обменяться идеями – очень эффективная стратегия».

Мэтт Ротенберг (Matt Rothenberg), Designer/Front-End Developer, based in New York, Clearbit

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

Если вы хотите повлиять на то, как ваша команда работает сообща, обязательно нужно изменить свои методы работы. К счастью, выход из зоны комфорта – это лучший способ учиться и расти. А это очень круто в нашем быстро меняющимся мире. Найдите минуту, чтобы поразмыслить о том, как вы работаете. Как сделать так, чтобы ваш образ мыслей, решений и творчества был заметнее?

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

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

Как правильно говорить «нет»?

Нет.

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

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

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

Как вы поймете что достигли цели в организации работы? Это выглядит примерно так:

1. Информация эффективно перемещается между различными специалистами в вашей команде;
2. Каждый в команде может уходить в отпуск или увольняться, не боясь, что без них все развалится;
3. По мере того как команды дорабатывают свои рабочие процессы, преобладает культура обучения и гибкости в переходах между ролями.
4. Продукт продается, компания растет быстрее конкурентов и вокруг царит приятная атмосфера.

Что делать, если ничего не делать?

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

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

Вывод и рекомендации

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

← Назад | Продолжение (Глава 4) →