https://www.ivanzviahin.by/blog/tags/konflikt-v-komande/ It is my diary. I’m ivan zviahin, an designer, manager, car enthusiast. Ivan Zviahin en E2 (v3849; Aegea) Ivan Zviahin ivanzviahin@gmail.com It is my diary. I’m ivan zviahin, an designer, manager, car enthusiast. no 137 https://www.ivanzviahin.by/blog/all/sem-faz-formirovaniya-komandy/ Mon, 02 Mar 2020 18:53:08 +0000 Ivan Zviahin https://www.ivanzviahin.by/blog/all/sem-faz-formirovaniya-komandy/ <div class="e2-text-picture"> <img src="https://www.ivanzviahin.by/blog/pictures/215271-goran.jpg" width="1406" height="815" alt="" /> </div> <p>Недавно послушал выступление Ольги Герасименко о формировании команды. Теперь у меня и у вас есть конспект-руководство о формировании счастливой команды. Фаз всего семь и в теории тут действительно всё просто.</p> <h2>Фаза 1. Ориентация</h2> <p>Ответ на вопрос — что я здесь делаю? Ответ зависит от того, как человека ввели в коллектив, как он адаптируется. Если человек явно не понимает ответ на этот вопрос, это приведет, скорее всего, к уходу. Рано или поздно.</p> <p><b>⌘</b> Каждый человек в команде должен пройти адаптацию с ментором и получить ответ на вопрос «что я здесь делаю?».</p> <h2>Фаза 2. Обретение доверия</h2> <p>Ответ на вопрос — подходят ли они мне? Если ответ ясный — отношения в коллективе становятся доверительными, появляется открытый диалог. Если мне понятно с кем я работаю, кто эти люди, безопасно ли мне с ними, интересно ли мне с ними, готовы ли они меня поддерживать, то тогда мы все обретаем доверие. Иначе отсутствие доверия приводит к сложностям в диалоге.</p> <p><b>⌘</b> Нужно стараться выяснить заранее, входят ли люди в команде в круг интересов нового члена команды, поведения и образа жизни.</p> <h2>Фаза 3. Уточнение цели</h2> <p>Ответ на вопрос — что мы делаем? Если ответ найден, формируется общая перспектива. Если нет, возникает апатия и нездоровая конкуренция. Команда не формируется, а превращается в отдельных людей. Каждый из которых перетягивает одеяло на себя и самоутверждается за счет других.</p> <p><b>⌘</b> Цели компании и команды ставить нужно выше своих личных целей.</p> <h2>Фаза 4. Обязательность</h2> <p>Ответ на вопрос — как мы это делаем? Если ответ найден, происходит автоматизация процессов, вырабатываются стандарты. Все принимают решения, которые рождаются командой. Единые решения. Если нет, формируется сопротивление. Каждый делает так, как это видит, а это приводит к общему провалу.</p> <p><b>⌘</b> Старайтесь синхронизировать варианты с коллегами и заранее оговорите решение.</p> <h2>Фаза 5. Распределение ролей</h2> <p>Ответ на вопрос — кто, что, как, когда? Если ответ найден, процессы протекают понятно для всех, а исполнение становится чётким. Фокус на результат. Если нет, происходит нарушение сроков, путаница, возникают деструктивные конфликты.</p> <p><b>⌘</b> Каждый должен понимать что, кто, как и когда должен что-то сделать.</p> <h2>Фаза 6. Высокая производительность</h2> <p>На этой фазе нет вопроса, тут есть только слово: Ура! Мы добрались! Если мы сомневаемся, что у нас высокая производительность, то растет напряжение и удовлетворения нет.</p> <p><b>⌘</b> Найдите способ проверить производительность команды.</p> <h2>Фаза 7. Обновление</h2> <p>Ответ на вопрос — зачем продолжать, что делать дальше? Если ответ найден, происходит новый рывок, происходит укрепление связей. Если нет, возникает скука и выгорание. Члены команды плавно ее покидают.</p> <p><b>⌘</b> Постановка более амбициозных целей поможет обновить мотивацию команды.</p> <hr /> <p>Чтобы не пропустить новую заметку — подпишитесь на мой <a href="https://t.me/ivanzviahin">канал в Телеграме</a> или <a href="http://ivanzviahin.by/blog/rss/">RSS</a>.</p> 105 https://www.ivanzviahin.by/blog/all/programmisty-ne-ponimayut-dizaynerov/ Sat, 01 Jun 2019 14:55:18 +0000 Ivan Zviahin https://www.ivanzviahin.by/blog/all/programmisty-ne-ponimayut-dizaynerov/ <div class="e2-text-picture"> <img src="https://www.ivanzviahin.by/blog/pictures/Adriaen.jpg" width="1780" height="947" alt="" /> </div> <p>Тут у меня сегодня будет поток мыслей на тему коммуникации между разработчиком и дизайнером. Наблюдая и делая какие-то выводы, я сформулировал несколько принципов, которые должны улучшить коммуникацию. Это не точно, но у нас работает.</p> <h2>Общая цель и миссия</h2> <p>Начать стоит с того, чтобы сформулировать цель и миссию вместе с коллегами. Вот прям поговорили, записали, друг другу показали, кивнули. Звучит это очень банально, но мало команд это делает.</p> <p>Беда в той команде, где люди идут к разным целям. Из этого вытекает следствие, что цель проекта должна быть выше, чем личная. Проблема в том проекте, в котором у дизайнера цель сделать портфолио, у программиста — поехать на конференцию в Амстердам с клёвым докладом, а у маркетолога — победить в конкурсе «Бренд года».</p> <p>Я сам бывал и бываю таким дизайнером, который рисовал макеты для своего портфолио и не думал о цели компании. В итоге программисты говорят, что такое сделать сложно и меняют решения находу. Тебе ничего не остаётся, кроме того, как винить во всем программистов. Ведь все задуманное для портфолио осталось только на картинках. В бою проект оказался совсем другим. Проект в итоге получается кривым, а в портфолио лежат только джепеги. А это большой минус для портфолио дизайнера. Вы же часто слышали от дизайнера такую фразу:</p> <blockquote> <p>«Программисты думают только о себе, а не о пользователях»</p> </blockquote> <p>Чтобы исключить такие ситуации, кажется, надо ставить выше цель проекта и синхронизироваться с командой.</p> <h2>Общее решение</h2> <p>Самая большая ошибка, это пойти сразу рисовать макеты. Рисовать их неделю. Две. А потом бежать с этими макетами к разработчикам (вокруг макетов лучи нимба), а они в итоге говорят, что есть решение проще или еще хуже:</p> <blockquote> <p>«Это сделать невозможно!»</p> </blockquote> <p>Есть такой принцип: «Выкидывай бумажки в урну». Дизайнер делает дешевые прототипы и маленькие итерации в макетах, чтобы легче отказываться от своих решений. Если они не работают, конечно же. Решение на салфетке с ними проще. Кучу нюансов всплавает на уровне макетов, но основную концепцию лучше рисовать на салфетке.</p> <p>Беда в команде, если программист и дизайнер не разговаривают. Следом за салфеткой, следует этап общения и обсуждения. У программистов есть много хороших идей и шикарное представление технических ограничений. Тогда и разработчик никогда не скажет:</p> <blockquote> <p>«Ничего не знаю, так было в макете!»</p> </blockquote> <p>Вообщем, решение должно быть общим, больше общения и будет всем хорошо.</p> <h2>Общая точка успеха</h2> <p>Определили точку успеха. Что будет являться успешным завершением проекта или задачи в первом подходе. Это избавит проект от лишних хотелок. И вы тогда никогда не услышите от программистов:</p> <blockquote> <p>«У вас концепция постоянно меняется, достали»</p> </blockquote> <p>Нужно чётко понимать, что будет достаточно сделать, чтобы решить задачу. Прям напишите это где-то и пускай все кивнут.</p> <h2>Равенство</h2> <p>Уважайте друг друга. Дизайнер является полноценным членом команды разработки. Разработчики — тоже дизайнеры. У вас без друг друга врядли что-то хорошее получится, уважайте профессию друг друга. Учитесь слушать и слышать, договариваться. Это чтобы не было таких фраз в вашу сторону:</p> <blockquote> <p>«А почему у меня не спросили?»</p> </blockquote> <p>Беда в том проекте, где дизайнер руководит разработчиками или наоборот. Это равные позиции в команде. Иначе дизайнер становится визуализатором, а программист говнокодером. А так быть не должно.</p> <hr /> <p>Чтобы не пропустить новую заметку — подпишитесь на мой <a href="https://t.me/ivanzviahin">канал в Телеграме</a> или <a href="http://ivanzviahin.by/blog/rss/">RSS</a>.</p>