Я работаю в цифровом агентстве, и у нас много разных клиентов и проектов, и это здорово, но в конечном итоге мы назначаем каждого участника нескольким клиентам и помещаем Evertone в их собственный клиентский пузырь.
У нас есть канал для обмена ссылками и кратких комментариев о них, что хорошо, но этого недостаточно. Мы пытались создать ежедневный канал, чтобы люди могли делиться тем, что они делают, чтобы все знали, что происходит, и, возможно, имели некоторые идеи, но участие было низким.
Я чувствую, что главные проблемы — это время и информация. Как мы вписываем это в наш график и как мы эффективно помогаем друг другу, если мы на самом деле не «живем» клиентом изо дня в день.
Так что ты думаешь? Вы тоже боретесь с этим? Вы достигли какой-то хорошей системы в вашей компании? Я действительно с нетерпением жду, чтобы поделиться некоторыми мыслями с вами, люди! :D
Мы пытались создать ежедневный канал, чтобы люди могли делиться тем, что они делают, чтобы все знали, что происходит, и, возможно, имели некоторые идеи, но участие было низким.
Это может быть хорошей идеей, но вовлеченность останется низкой, пока руководство не применит ее. Когда они это сделают, будет период адаптации, когда члены агентства жалуются на дополнительную нагрузку (1-2 минуты в день на проект, чтобы ввести краткий статус - или, как компромисс, еженедельный отчет о статусе). И тогда это станет нормальным.
Хочет ли этого руководство? Если бы я был на их месте, я бы точно так и сделал, потому что рано или поздно кого-то "собьет автобус" (уволит, заболеет, выиграет в лотерею, действительно попадет под автобус), а другим придется подобрать слабину. На самом деле нехорошо задавать своим клиентам невежественные вопросы о работе, которую вы должны для них выполнять.
Я бы также рассмотрел возможность назначения двух членов для каждого клиента/проекта. Один брал на себя инициативу, а другой был в курсе событий и помогал при необходимости.
Эти меры требуют времени и денег (хотя, на мой взгляд, стоимость ежедневного/еженедельного отчета канала незначительна).
В настоящее время у сотрудников агентства нет мотивации тратить даже небольшую часть своего рабочего дня на обмен информацией, потому что это не входит в их обязанности. Опять же, это работа руководства, чтобы изменить это.
Возьмите пример Agile в разработке программного обеспечения и попробуйте Stand Up Meeting .
Первоначальная цель состояла в том, чтобы каждый вкратце рассказал, над чем он планирует работать каждый день, а также о любых препятствиях или препятствиях, с которыми они столкнулись.
В вашем случае вы можете чередовать каждого из ваших клиентов и рассказывать, чего вы достигли и как отреагировал клиент (сопоставьте это с тем, что работает для вас).
Обычно это делается в одно и то же время дня, первым делом утром... если у вас нет установленного графика работы, это может быть немного сложнее.
Проблема, с которой вы сталкиваетесь, мало чем отличается от проблемы, с которой сталкиваются группы с распределенной рабочей силой (например, в разных местах, в разных часовых поясах). Цель состоит в том, чтобы облегчить общение и повысить беглость общения между всеми членами команды.
Существует большое количество исследований в поддержку различных методов и способов расширения сотрудничества между проектными группами. Литература поддерживает ценность создания общих ментальных моделей, общего языка и универсального доступа к ресурсам и представлениям (например, макетам, черновикам и готовым продуктам). Это говорит о том, что конкретное средство коммуникации не так важно, как возможность доступа к нему и воспринимаемая ценность участия в нем.
Вот несколько наиболее часто цитируемых научных статей. Для получения дополнительной информации выполните поиск по запросу «сотрудничество в дизайне» на сайте research.google.com или аналогичном сайте. В вашей ситуации может быть полезно поискать статьи, представляющие собой тематические исследования или обзоры существующих исследований.
В этом могут помочь различные Agile-методы.
Пейринг — рассмотрите возможность назначения 2 дизайнеров одному клиенту вместо одного. Они будут сотрудничать и учиться друг у друга. Немедленной реакцией на это обычно бывает «но на все уйдет вдвое больше времени!» Но было показано, что парное программирование среди разработчиков на 15% медленнее, но приводит к снижению уровня брака на 15% .
Демонстрации — регулярные сеансы, на которых все демонстрируют друг другу свою работу.
Ретро - регулярные сессии, на которых группа ретроспективно оценивает то, что они делали, и как улучшить
Стендапы - ежедневные короткие встречи, на которых все сообщают, что они делали/будут делать/какие блокировщики или вопросы у них могут возникнуть
Существует множество ресурсов о применении Agile к модели цифрового агентства, посмотрите этот подкаст, в котором Рэйчел Герц и Бретт Харнед говорят об этом, и поищите еще!
Адриано Репетти
Халат