Если бы мне пришлось описать историю команды веб-сайта IMPACT, я бы сказал, что она похожа на сюжет типичного голливудского фильма или телешоу.
Вспомните Стива Харрингтона и Дастина Хендерсона из «Очень странных дел». Базз и Вуди из «Истории игрушек». Леголас и Гимли из «Властелина колец».
Во всех этих сценариях есть главные герои, которые во многом являются полными противоположностями.
В начале отношений возникает много разногласий, и им трудно найти общий язык.
Однако по ходу истории они учатся откладывать в сторону свои разногласия, формировать маловероятную дружбу и работать вместе для достижения великой цели.
Дизайнеры и разработчики - такой дуэт.
Теперь, хотя наша главная цель в IMPACT не заключалась в уничтожении кольца в огне Роковой горы или победе над демогоргоном; это действительно зависело от того, как мы найдем способ объединить наших дизайнеров и разработчиков - задача, которую некоторые компании назвали бы такой же сложной.
Устранение разрыва между нашими дизайнерами и разработчиками - это то, над чем мы боролись годами. Наши команды не были едины в общих целях нашей команды и общении, и мы работали очень разрозненно.
Так что же стало причиной разлада между двумя командами?
Нам нужно было выяснить, что не работает и почему.
В течение следующих нескольких месяцев у нас было несколько ретроспективных встреч, на которых мы глубоко погрузились в каждый аспект нашей команды.
В конечном итоге мы пришли к выводу, что существует три основные проблемы, вызывающие раскол между дизайнерами и разработчиками.
1. Мы относились к проектам веб-сайтов как к конвейеру
Когда мы подошли к дизайну веб-сайтов, мы поняли, что вместо того, чтобы рассматривать его как совместный процесс, мы относимся к нему как к сборочному конвейеру.
Наши дизайнеры работают над дизайном, а затем передают его в разработку для кодирования и перехода к следующему проекту.
Единственная часть процесса, где между двумя командами было какое-либо общение, была во время краткой передачи управления, но мы просто предоставляли разработчикам ссылку на файлы нашего проекта и двигались дальше.
Ограниченное количество сообщений вызвало множество недопониманий относительно того, как должен выглядеть и функционировать конечный продукт, что затем привело к дополнительным раундам доработок.
В конечном итоге нам пришлось постоянно переносить даты запуска наших проектов, что наносило ущерб прибыльности и имело эффект домино на даты начала следующих проектов, которые мы планировали.
Отсутствие сотрудничества также повлияло на способность нашей команды внедрять инновации и расти.
Сотрудничество - ключевой фактор инноваций.
Когда вы эффективно сотрудничаете, вы можете увидеть, как разные команды работают и решают проблемы.
Вы знакомитесь с новыми привычками и получаете обратную связь извне, которая может помочь вам генерировать новые идеи или улучшать процессы.
К сожалению, работая с нашим разрозненным подходом, мы зашли в тупик.
Мы перестали внедрять инновации и стали больше времени придерживаться того, что знаем, вместо того, чтобы рисковать и пытаться подтолкнуть нашу команду вперед, чтобы опережать тенденции веб-сайтов.
2. Между командами существовали серьезные пробелы в знаниях
Работа на конвейере не только создала проблемы в общении и сотрудничестве, но также создала пробелы в знаниях между двумя командами.
Дизайнеры и разработчики не понимали, что происходит на других этапах процесса, поэтому вещи, над которыми мы работали, не всегда были связными.
Наши дизайнеры создавали эти прекрасные проекты, но когда их отправляли в разработку, их было нелегко перевести в код.
У нас не было четкого понимания того, какие вещи увеличивают время разработки.
Дополнительная работа, которую пришлось проделать нашим разработчикам, чтобы заставить дизайн работать, привела к серьезным задержкам в сроках нашего проекта.
С другой стороны, наши разработчики не знали, каковы цели страницы.
Они не знали, чего мы пытались достичь с помощью этих проектов.
Из-за этого им было сложно давать дизайнерам отзывы о функциональности.
Решение этих проблем не только повлияло на конечный продукт, который мы выпустили, но также оказало большое влияние на моральный дух нашей команды.
Мы были разочарованы тем, что продолжали сталкиваться с одними и теми же проблемами, и разочарованы тем, что не смогли выпустить конечный продукт, который мы все хотели.
3. Не было единой файловой структуры
Наконец, мы заметили, что у нас нет единой файловой структуры для передачи работы от проектирования к разработке.
Все наши дизайнеры поступали немного по-другому. У всех нас была разная структура именования файлов, разные способы оставлять функциональные заметки, и мы организовывали файлы по-своему.
Это означало, что каждый раз, когда наши разработчики получали новый проект, им требовалось дополнительное время, чтобы подготовиться и ознакомиться с тем, как все организовано.
Это было похоже на начало каждого проекта с нуля, снова увеличивая продолжительность наших проектов и оставляя больше места для ошибок.
Мы знали, что если хотим добиться желаемого прогресса в работе нашего веб-сайта, нам необходимо исправить эти проблемы.
Как мы объединили наши команды дизайнеров и разработчиков
Эти проблемы создали серьезный разрыв между нашими дизайнерами и разработчиками, из-за которого наша совместная работа стала практически невозможной.
Мы знали, что, если мы не устраним эти проблемы, мы никогда не сможем выпустить тот невероятный конечный продукт, на который, как мы знали, мы способны.
Как только мы узнали, что является причиной несовпадения, мы смогли разработать план, позволяющий нашим командам работать совместно и эффективно.
Мы реализовали следующие инициативы, чтобы начать разрушать эту разрозненность:
Наши команды говорят на одном языке
Одной из первых наших инициатив была идея, как заставить наши команды говорить на одном языке.
Мы заметили, что у одних и тех же элементов сайта есть много разных названий.
В нашей системе дизайна мы будем называть элемент одним словом, а в нашей среде разработки он будет называться чем-то другим.
Если бы мы могли создать общую терминологию, это помогло бы улучшить взаимодействие между командами и сократить недопонимание.
Чтобы это исправить, мы провели собрание команды, на котором мы рассмотрели все наши ресурсы для проектирования и разработки и выбрали правильное имя для каждого из них.
Затем мы обновили нашу систему дизайна и среду разработки, чтобы имена выстраивались в ряд.
Мы реализовали совместную проверку дизайна
Далее мы знали, что нам нужно изменить наш процесс, чтобы сделать его более совместным.
Для этого нам нужно было более активно вовлекать наших разработчиков на ранних этапах проектирования, а наших дизайнеров - на более поздних этапах.
Одним из способов, которым мы это сделали, была реализация проверки дизайна с участием всей нашей команды веб-сайта.
Во время этих обзоров наши дизайнеры могут представить проекты, над которыми они работают, и получить отзывы о разработке. Мы можем быстро увидеть, будет ли то, что мы проектируем, воплощено в коде и уложится ли в бюджет клиента.
Мы также можем провести мозговой штурм по функциональности страницы и обсудить любые тревожные сигналы, которые замечают разработчики и которые могут вызвать проблемы, когда придет время разработки.
В целом, это эффективный способ не только сотрудничать, но и устранить любые пробелы в знаниях, которые могут возникнуть между двумя командами.
Создан процесс передачи дизайнера разработчику
Многие наши недопонимания и задержки были вызваны отсутствием четкого процесса перехода от проектирования к разработке.
Итак, как команда, мы придумали единый способ организации и присвоения имен нашим файлам, решили, где мы хотим разместить все важные функциональные примечания для дизайна, и позаботились о том, чтобы все активы проекта были сохранены. где-нибудь, к чему все разработчики смогут легко получить доступ.
Эти небольшие изменения имели огромное значение, однако на всякий случай, когда придет время передачи, мы в последний раз проверяем окончательные проекты с разработчиками и убеждаемся, что у них есть все необходимое.
Найдены новые способы улучшить командное общение
В целом, самое важное, что нам нужно было улучшить, - это взаимодействие между дизайном и разработкой.
Наши совместные обзоры дизайна начали заставлять нас говорить и смотреть на вещи как с точки зрения дизайна, так и с точки зрения разработки, но мы хотели продолжить разговор за пределами этих встреч.
Итак, мы создали канал в Slack для общения членов нашей команды.
На канале мы можем делиться повторяющимися проблемами, которые мы замечаем в различных проектах, идеями дизайна, а также командными победами.
Помимо Slack, мы также внедрили новый документ о дорожной карте проекта, который помогает нашим командам согласовывать бюджет и ход реализации проекта.
В документе вы можете найти такие вещи, как ссылки на выполненные проекты проектов и расшифровку бюджета клиента.
Вся наша команда может легко просмотреть любой документ с дорожной картой и посмотреть, насколько далеко мы продвинулись в разработке или какой бюджет на разработку у нас остался. Это помогает поддерживать наши проекты в рамках объема и в срок.
Провел общекомандную тренировку
Как только у нас появился план по сплочению нашей команды, мы решили, что лучший способ начать наши новые инициативы - это провести обучение для всей команды.
Мы действительно хотели, чтобы все были в восторге от работы в среде более тесного сотрудничества и почувствовали чувство сопричастности к новому процессу.
Мы хотели, чтобы каждый почувствовал, что приложил руку к его созданию и что мы сделали то, чем мы все можем гордиться.
Во время тренинга мы представили все основные изменения, которые мы внесли в наш подход к проектированию. Мы обсудили любые вопросы и предложения, которые возникли у нашей команды, и позаботились о том, чтобы все четко поняли наше видение.
Как эти изменения повлияли на нашу команду
За первые три месяца после внедрения этих изменений мы заметили огромную разницу в работе нашей команды.
Мы чувствовали, что действительно работаем вместе.
Наши дизайнеры и разработчики были рады обучать друг друга своим специальностям, и в результате мы придумали новые интересные идеи для веб-сайтов наших клиентов.
С точки зрения рентабельности и сроков реализации проектов мы укладывались в бюджет наших проектов и запускали их вовремя. Кажется, что каждую неделю мы находим новые способы повысить эффективность и предоставлять нашим клиентам более качественный конечный продукт.
Теперь, если вы чувствуете, что ваша история дизайнера и разработчика застряла на ранних стадиях, когда ваши главные герои еще не совсем сходятся во мнениях, остановитесь и посмотрите, как вы работаете вместе..
Как общается ваша команда? Чувствуют ли ваши дизайнеры, что они понимают, как работают разработчики, и наоборот?
Совместная работа ваших разработчиков и дизайнеров не только даст вашей команде возможность выполнять работу как можно лучше, но также значительно облегчит соблюдение бюджета ваших проектов и улучшит общий моральный дух вашей команды.