2 заметки с тегом

конфликт в команде

Семь фаз формирования команды

Недавно послушал выступление Ольги Герасименко о формировании команды. Теперь у меня и у вас есть конспект-руководство о формировании счастливой команды. Фаз всего семь и в теории тут действительно всё просто.

Фаза 1. Ориентация

Ответ на вопрос — что я здесь делаю? Ответ зависит от того, как человека ввели в коллектив, как он адаптируется. Если человек явно не понимает ответ на этот вопрос, это приведет, скорее всего, к уходу. Рано или поздно.

⌘ Каждый человек в команде должен пройти адаптацию с ментором и получить ответ на вопрос «что я здесь делаю?».

Фаза 2. Обретение доверия

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

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

Фаза 3. Уточнение цели

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

⌘ Цели компании и команды ставить нужно выше своих личных целей.

Фаза 4. Обязательность

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

⌘ Старайтесь синхронизировать варианты с коллегами и заранее оговорите решение.

Фаза 5. Распределение ролей

Ответ на вопрос — кто, что, как, когда? Если ответ найден, процессы протекают понятно для всех, а исполнение становится чётким. Фокус на результат. Если нет, происходит нарушение сроков, путаница, возникают деструктивные конфликты.

⌘ Каждый должен понимать что, кто, как и когда должен что-то сделать.

Фаза 6. Высокая производительность

На этой фазе нет вопроса, тут есть только слово: Ура! Мы добрались! Если мы сомневаемся, что у нас высокая производительность, то растет напряжение и удовлетворения нет.

⌘ Найдите способ проверить производительность команды.

Фаза 7. Обновление

Ответ на вопрос — зачем продолжать, что делать дальше? Если ответ найден, происходит новый рывок, происходит укрепление связей. Если нет, возникает скука и выгорание. Члены команды плавно ее покидают.

⌘ Постановка более амбициозных целей поможет обновить мотивацию команды.

Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме или RSS.

нет комментариев

Общение в команде

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

Общая цель и миссия

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

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

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

«Программисты думают только о себе, а не о пользователях»

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

Общее решение

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

«Это сделать невозможно!»

Есть такой принцип: «Выкидывай бумажки в урну». Дизайнер делает дешевые прототипы и маленькие итерации в макетах, чтобы легче отказываться от своих решений. Если они не работают, конечно же. Решение на салфетке с ними проще. Кучу нюансов всплавает на уровне макетов, но основную концепцию лучше рисовать на салфетке.

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

«Ничего не знаю, так было в макете!»

Вообщем, решение должно быть общим, больше общения и будет всем хорошо.

Общая точка успеха

Определили точку успеха. Что будет являться успешным завершением проекта или задачи в первом подходе. Это избавит проект от лишних хотелок. И вы тогда никогда не услышите от программистов:

«У вас концепция постоянно меняется, достали»

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

Равенство

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

«А почему у меня не спросили?»

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