{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "ivan's blog: posts tagged конфликт в команде", "_rss_description": "It is my diary. I’m ivan zviahin, an designer, manager, car enthusiast.", "_rss_language": "en", "_itunes_email": "ivanzviahin@gmail.com", "_itunes_categories_xml": "", "_itunes_image": "https:\/\/www.ivanzviahin.by\/blog\/user\/userpic-square@2x.jpg?1711411913", "_itunes_explicit": "no", "home_page_url": "https:\/\/www.ivanzviahin.by\/blog\/tags\/konflikt-v-komande\/", "feed_url": "https:\/\/www.ivanzviahin.by\/blog\/tags\/konflikt-v-komande\/json\/", "icon": "https:\/\/www.ivanzviahin.by\/blog\/user\/userpic@2x.jpg?1711411913", "author": { "name": "Ivan Zviahin", "url": "https:\/\/www.ivanzviahin.by\/blog\/", "avatar": "https:\/\/www.ivanzviahin.by\/blog\/user\/userpic@2x.jpg?1711411913" }, "items": [ { "id": "137", "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/sem-faz-formirovaniya-komandy\/", "title": "Семь фаз формирования команды", "content_html": "
\n\"\"\n<\/div>\n

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

Фаза 1. Ориентация<\/h2>\n

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

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

Фаза 2. Обретение доверия<\/h2>\n

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

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

Фаза 3. Уточнение цели<\/h2>\n

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

⌘<\/b> Цели компании и команды ставить нужно выше своих личных целей.<\/p>\n

Фаза 4. Обязательность<\/h2>\n

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

⌘<\/b> Старайтесь синхронизировать варианты с коллегами и заранее оговорите решение.<\/p>\n

Фаза 5. Распределение ролей<\/h2>\n

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

⌘<\/b> Каждый должен понимать что, кто, как и когда должен что-то сделать.<\/p>\n

Фаза 6. Высокая производительность<\/h2>\n

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

⌘<\/b> Найдите способ проверить производительность команды.<\/p>\n

Фаза 7. Обновление<\/h2>\n

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

⌘<\/b> Постановка более амбициозных целей поможет обновить мотивацию команды.<\/p>\n

\n

Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме<\/a> или RSS<\/a>.<\/p>\n", "date_published": "2020-03-02T18:53:08+00:00", "date_modified": "2020-03-05T15:46:41+00:00", "image": "https:\/\/www.ivanzviahin.by\/blog\/pictures\/215271-goran.jpg", "_date_published_rfc2822": "Mon, 02 Mar 2020 18:53:08 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "137", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [ "https:\/\/www.ivanzviahin.by\/blog\/pictures\/215271-goran.jpg" ] } }, { "id": "105", "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/programmisty-ne-ponimayut-dizaynerov\/", "title": "Общение в команде", "content_html": "

\n\"\"\n<\/div>\n

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

Общая цель и миссия<\/h2>\n

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

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

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

\n

«Программисты думают только о себе, а не о пользователях»<\/p>\n<\/blockquote>\n

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

Общее решение<\/h2>\n

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

\n

«Это сделать невозможно!»<\/p>\n<\/blockquote>\n

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

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

\n

«Ничего не знаю, так было в макете!»<\/p>\n<\/blockquote>\n

Вообщем, решение должно быть общим, больше общения и будет всем хорошо.<\/p>\n

Общая точка успеха<\/h2>\n

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

\n

«У вас концепция постоянно меняется, достали»<\/p>\n<\/blockquote>\n

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

Равенство<\/h2>\n

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

\n

«А почему у меня не спросили?»<\/p>\n<\/blockquote>\n

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

\n

Чтобы не пропустить новую заметку — подпишитесь на мой канал в Телеграме<\/a> или RSS<\/a>.<\/p>\n", "date_published": "2019-06-01T14:55:18+00:00", "date_modified": "2019-06-03T12:03:41+00:00", "image": "https:\/\/www.ivanzviahin.by\/blog\/pictures\/Adriaen.jpg", "_date_published_rfc2822": "Sat, 01 Jun 2019 14:55:18 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "105", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.ivanzviahin.by\/blog\/pictures\/Adriaen.jpg" ] } } ], "_e2_version": 3849, "_e2_ua_string": "E2 (v3849; Aegea)" }