{
    "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\/kommunikaciya\/",
    "feed_url": "https:\/\/www.ivanzviahin.by\/blog\/tags\/kommunikaciya\/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": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.ivanzviahin.by\/blog\/pictures\/215271-goran.jpg\" width=\"1406\" height=\"815\" alt=\"\" \/>\n<\/div>\n<p>Недавно послушал выступление Ольги Герасименко о формировании команды. Теперь у меня и у вас есть конспект-руководство о формировании счастливой команды. Фаз всего семь и в теории тут действительно всё просто.<\/p>\n<h2>Фаза 1. Ориентация<\/h2>\n<p>Ответ на вопрос — что я здесь делаю? Ответ зависит от того, как человека ввели в коллектив, как он адаптируется. Если человек явно не понимает ответ на этот вопрос, это приведет, скорее всего, к уходу. Рано или поздно.<\/p>\n<p><b>⌘<\/b> Каждый человек в команде должен пройти адаптацию с ментором и получить ответ на вопрос «что я здесь делаю?».<\/p>\n<h2>Фаза 2. Обретение доверия<\/h2>\n<p>Ответ на вопрос — подходят ли они мне? Если ответ ясный — отношения в коллективе становятся доверительными, появляется открытый диалог. Если мне понятно с кем я работаю, кто эти люди, безопасно ли мне с ними, интересно ли мне с ними, готовы ли они меня поддерживать, то тогда мы все обретаем доверие. Иначе отсутствие доверия приводит к сложностям в диалоге.<\/p>\n<p><b>⌘<\/b> Нужно стараться выяснить заранее, входят ли люди в команде в круг интересов нового члена команды, поведения и образа жизни.<\/p>\n<h2>Фаза 3. Уточнение цели<\/h2>\n<p>Ответ на вопрос — что мы делаем? Если ответ найден, формируется общая перспектива. Если нет, возникает апатия и нездоровая конкуренция. Команда не формируется, а превращается в отдельных людей. Каждый из которых перетягивает одеяло на себя и самоутверждается за счет других.<\/p>\n<p><b>⌘<\/b> Цели компании и команды ставить нужно выше своих личных целей.<\/p>\n<h2>Фаза 4. Обязательность<\/h2>\n<p>Ответ на вопрос — как мы это делаем? Если ответ найден, происходит автоматизация процессов, вырабатываются стандарты. Все принимают решения, которые рождаются командой. Единые решения. Если нет,  формируется сопротивление. Каждый делает так, как это видит, а это приводит к общему провалу.<\/p>\n<p><b>⌘<\/b> Старайтесь синхронизировать варианты с коллегами и заранее оговорите решение.<\/p>\n<h2>Фаза 5. Распределение ролей<\/h2>\n<p>Ответ на вопрос — кто, что, как, когда? Если ответ найден, процессы протекают понятно для всех, а исполнение становится чётким. Фокус на результат. Если нет, происходит нарушение сроков, путаница, возникают деструктивные конфликты.<\/p>\n<p><b>⌘<\/b> Каждый должен понимать что, кто, как и когда должен что-то сделать.<\/p>\n<h2>Фаза 6. Высокая производительность<\/h2>\n<p>На этой фазе нет вопроса, тут есть только слово: Ура! Мы добрались! Если мы сомневаемся, что у нас высокая производительность, то растет напряжение и удовлетворения нет.<\/p>\n<p><b>⌘<\/b> Найдите способ проверить производительность команды.<\/p>\n<h2>Фаза 7. Обновление<\/h2>\n<p>Ответ на вопрос — зачем продолжать, что делать дальше? Если ответ найден, происходит новый рывок, происходит укрепление связей. Если нет, возникает скука и выгорание. Члены команды плавно ее покидают.<\/p>\n<p><b>⌘<\/b> Постановка более амбициозных целей поможет обновить мотивацию команды.<\/p>\n<hr \/>\n<p>Чтобы не пропустить новую заметку — подпишитесь на мой <a href=\"https:\/\/t.me\/ivanzviahin\">канал в Телеграме<\/a> или <a href=\"http:\/\/ivanzviahin.by\/blog\/rss\/\">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": "134",
            "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/situacionnoe-liderstvo\/",
            "title": "Ситуационное лидерство",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/drafts\/situational-leadership\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.ivanzviahin.by\/blog\/pictures\/leadership-1.png\" width=\"1590\" height=\"628\" alt=\"\" \/>\n<\/div>\n<p>Cитуационное лидерство — это стиль управления людьми, предполагающий использование одного из четырех стилей управления в зависимости от ситуации и уровня развития сотрудников по отношению к задаче. Согласно данной модели существуют 4 стиля лидерства и 4 степени развития сотрудника.<\/p>\n<h2>4 стиля управления<\/h2>\n<p>Первый — директивный стиль, или лидерство путём приказа. Высокая ориентация на задачу и низкая на людей. Лидер дает конкретные указания и следит за выполнением заданий.<\/p>\n<p>Второй — наставнический стиль, или лидерство путём продажи идей. Совмещение высокой ориентации на задачу и на людей. Руководитель продолжает давать указания и следить за выполнением заданий, но при этом объясняет принятые решения сотруднику, предлагает высказывать свои идеи и предложения.<\/p>\n<p>Третий — поддерживающий стиль, или лидерство путём участия в организации процесса работы. Высокая ориентация на людей и низкая на задачу. Лидер поддерживает и помогает своим сотрудникам в их работе. Лидер участвует в процессе принятия решений, но решения принимаются в большей степени подчиненными.<\/p>\n<p>Четвертый — делегирующий стиль. Низкая ориентация и на людей, и на задачу. Лидер передает полномочия, права и ответственность другим членам команды.<\/p>\n<h2>4 степени развития сотрудника<\/h2>\n<p>Первый — не способен, но настроен. Сотрудник, находящийся на этом уровне, высоко мотивирован, демонстрирует много энтузиазма, но владеет только базовыми знаниями и навыками.<\/p>\n<p>Второй — не способен и не настроен. У сотрудника, находящегося на этом уровне, обычно уже есть определенные знания и навыки, однако такой сотрудник по какой-то причине демотивирован.<\/p>\n<p>Третий — способен, но не настроен. Сотрудник на этом уровне имеет знания и хорошо развитые навыки для выполнения задачи, однако его уверенность в себе и своих силах неустойчива, что может влиять на мотивацию.<\/p>\n<p>Четвертый — способен и настроен. Сотрудник на этом уровне демонстрирует мастерское владение навыками, необходимыми для выполнения данного задания. Помимо этого он мотивирован и уверен в себе.<\/p>\n<h2>Итого<\/h2>\n<p>10% знаний, 100% мотивация — директивный стиль.<br \/>\n30% знаний, 10% мотивации — наставнический стиль.<br \/>\n70% знаний, 40% мотивации — поддерживающий стиль.<br \/>\n100% знаний, 100% мотивации — делегирующий стиль.<\/p>\n",
            "date_published": "2020-01-23T20:30:53+00:00",
            "date_modified": "2022-04-27T19:58:12+00:00",
            "image": "https:\/\/www.ivanzviahin.by\/blog\/pictures\/leadership-1.png",
            "_date_published_rfc2822": "Thu, 23 Jan 2020 20:30:53 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "134",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/leadership-1.png"
                ]
            }
        },
        {
            "id": "125",
            "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/maket\/",
            "title": "Макетная актуальность",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.ivanzviahin.by\/blog\/pictures\/1547750932_maxresdefault.jpg\" width=\"1280\" height=\"720\" alt=\"\" \/>\n<\/div>\n<p>Проектируя что-то новое на основании старого, дизайнеру необходимо куда-то обращаться за информацией. Например, как это работает, а как выглядит этот модуль, как себя поведет система?<\/p>\n<p>У нас в команде есть 5 источников таких знаний:<\/p>\n<ul>\n<li>требования в Jira,<\/li>\n<li>макеты в Zeplin,<\/li>\n<li>статическая вёрстка,<\/li>\n<li>cтейджинг,<\/li>\n<li>голова дизайнера.<\/li>\n<\/ul>\n<p>Итак, разложим каждый по характеристикам: лёгкость поиска, читаемость, близость к правде, видимость деталей.<\/p>\n<h2>Требования в Jira<\/h2>\n<p>Когда продукт большой, найти нужные знания бывает невозможно, а если и возможно, то это долго и неудобно.  Текст и блок-схемы воспринимаются намного хуже, чем картинки. Читаемость таких знаний низкая. Как правило, многие визуальные детали есть только в макетах и не описаны в требованиях.<\/p>\n<h2>Макеты в Zeplin<\/h2>\n<p>Макеты легко найти, но тяжело поддерживать. У них понятная структура, нейминг и есть превьюшки. Они близки к правде и показывают почти все состояния элементов интерфейса и детали сценариев.<\/p>\n<h2>Статическая вёрстка<\/h2>\n<p>К ним простой доступ по домену. Есть структура как у макетов, но не настолько детальная. Они близки к правде, так как они и есть правда. Как правило, верстка не показывают все состояния элементов интерфейса и детали сценариев.<\/p>\n<h2>Стейджинг<\/h2>\n<p>К ним простой доступ по домену. Он имеет горизонтальную структуру и порой, чтобы увидеть какой-то экран, нужно сделать много действий, взаимодействовать с админкой или с чем-то ещё. Он самый правдивый из всех, но все детали сценариев и состояния элементов интерфейса трудно воспроизвести.<\/p>\n<h2>Голова дизайнера<\/h2>\n<p>К сожалению в свою голову всё не помещается, а чужая часто недоступна. Дизайнер скорее всего хорошо знает структуру, детали и состояния, но это не точно. Он легко может ошибиться или забыть.<\/p>\n<h2>Вывод<\/h2>\n<div class=\"e2-text-table\">\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\">\n<tr>\n<td style=\"text-align: center\"><\/td>\n<td>Требования<\/td>\n<td>Макеты<\/td>\n<td>Вёрстка<\/td>\n<td>Стейджинг<\/td>\n<td>Голова<\/td>\n<\/tr>\n<tr>\n<td>Лёгкость поиска<\/td>\n<td>−<\/td>\n<td>+<\/td>\n<td>+<\/td>\n<td>+<\/td>\n<td>−<\/td>\n<\/tr>\n<tr>\n<td>Читаемость<\/td>\n<td>−<\/td>\n<td>+<\/td>\n<td>+<\/td>\n<td>−<\/td>\n<td>−<\/td>\n<\/tr>\n<tr>\n<td>Правдивость<\/td>\n<td>+\/−<\/td>\n<td>+<\/td>\n<td>+<\/td>\n<td>+<\/td>\n<td>+\/−<\/td>\n<\/tr>\n<tr>\n<td>Видимость деталей<\/td>\n<td>−<\/td>\n<td>+<\/td>\n<td>−<\/td>\n<td>−<\/td>\n<td>−<\/td>\n<\/tr>\n<tr>\n<td><b>Итого<\/b><\/td>\n<td><b>−3<\/b><\/td>\n<td><b>4<\/b><\/td>\n<td><b>3<\/b><\/td>\n<td><b>0<\/b><\/td>\n<td><b>−3<\/b><\/td>\n<\/tr>\n<\/table>\n<\/div>\n<p>Вот и решайте теперь, стоит держать макеты актуальными или нет.<\/p>\n<hr \/>\n<p>Чтобы не пропустить новую заметку — подпишитесь на мой <a href=\"https:\/\/t.me\/ivanzviahin\">канал в Телеграме<\/a> или <a href=\"http:\/\/ivanzviahin.by\/blog\/rss\/\">RSS<\/a>.<\/p>\n",
            "date_published": "2019-10-29T16:02:18+00:00",
            "date_modified": "2019-10-29T16:34:41+00:00",
            "image": "https:\/\/www.ivanzviahin.by\/blog\/pictures\/1547750932_maxresdefault.jpg",
            "_date_published_rfc2822": "Tue, 29 Oct 2019 16:02:18 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "125",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/1547750932_maxresdefault.jpg"
                ]
            }
        },
        {
            "id": "115",
            "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/urovenprorabotki\/",
            "title": "Уровень проработки",
            "content_html": "<p>на русском · <a href=\"https:\/\/ivanzviahin.by\/blog\/drafts\/development-levels\/\">in english<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.ivanzviahin.by\/blog\/pictures\/devlevels-1.png\" width=\"1590\" height=\"628\" alt=\"\" \/>\n<\/div>\n<p>Я бы хотел рассказать о решении одной важной проблемы в продуктовой команде. Проблема — мы делаем задачи слишком долго. Одна из причин — слишком глубокий уровень проработки каждой. Как бы времени у нас совсем нет, а функциональность урезать нельзя. Остается только снизить уровень проработки. Мы решили понижать его не для всех задач, а только для некоторых.<\/p>\n<p>Пользовательские сценарии в любом продукте можно разделить на три уровня. Уровень первый — сценарии, которыми люди пользуются чуть ли не каждый день. Мы такие сценарии назвали магистральными. Второй — важные, но нужные не часто. Эти сценарии назвали промежуточными. Третий — скорее исключения, это как раз те сценарии про которые обычно совсем забывают.<\/p>\n<h2>Уровень 1<\/h2>\n<p>Это самые важные сценарии, которые пользователь использует каждый день. Например, поиск товаров в магазине или чтение новостей в журнале. Проработка таких сценариев должна быть на высочайшем уровне. Тут необходимо потратить время на проверки и тестирование. Продумать все исключения, сделать анимации и хоткеи. Таких сценариев обычно не много.<\/p>\n<h2>Уровень 2<\/h2>\n<p>Это сценарии важные, но при этом ими пользуются не так часто. Например, настройки профиля. В таких сценариях нужно не меньше времени уделить проектированию и проверкам, но можно более хладнокровно относиться к ошибкам. Тут учитывать хоткеи уже нет смысла и если какой-то сценарий приведет к ошибке — это не так страшно, как в первом случае. Говорят, что именно поэтому в автомобиле салон сделан максимально комфортным, по сравнению с моторным отсеком. Таких сценариев обычно намного больше, чем первых.<\/p>\n<h2>Уровень 3<\/h2>\n<p>А вот эти сценарии самые популярные обычно у программистов. Есть четкое ощущение, что ими можно пренебречь в проектировании. Это не значит, что про них можно просто забыть и все. Их нужно обрабатывать, но делать это — максимально грубо. Например, представьте, вы открываете одну страницу в двух вкладках браузера и в одной из них делаете какое-то действие, которое меняет статус чего-то. А потом идёте в другую и делаете это же действие, как должна повести себя система? От способности обрабатывать исключения зависит лишь качество кода, а вот успех продукта находится в первую двух уровнях.<\/p>\n<h2>Вывод<\/h2>\n<p>Никому не нужен магазин с идеально продуманным сценарием добавления товара в «Избранное» в двух вкладках браузера, когда поиск товаров работает плохо и непонятно.<\/p>\n",
            "date_published": "2019-09-24T17:22:15+00:00",
            "date_modified": "2022-04-27T19:57:23+00:00",
            "image": "https:\/\/www.ivanzviahin.by\/blog\/pictures\/devlevels.png",
            "_date_published_rfc2822": "Tue, 24 Sep 2019 17:22:15 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "115",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/devlevels.png",
                    "https:\/\/www.ivanzviahin.by\/blog\/pictures\/devlevels-1.png"
                ]
            }
        },
        {
            "id": "105",
            "url": "https:\/\/www.ivanzviahin.by\/blog\/all\/programmisty-ne-ponimayut-dizaynerov\/",
            "title": "Общение в команде",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.ivanzviahin.by\/blog\/pictures\/Adriaen.jpg\" width=\"1780\" height=\"947\" alt=\"\" \/>\n<\/div>\n<p>Тут у меня сегодня будет поток мыслей на тему коммуникации между разработчиком и дизайнером. Наблюдая и делая какие-то выводы, я сформулировал несколько принципов, которые должны улучшить коммуникацию. Это не точно, но у нас работает.<\/p>\n<h2>Общая цель и миссия<\/h2>\n<p>Начать стоит с того, чтобы сформулировать цель и миссию вместе с коллегами. Вот прям поговорили, записали, друг другу показали, кивнули. Звучит это очень банально, но мало команд это делает.<\/p>\n<p>Беда в той команде, где люди идут к разным целям. Из этого вытекает следствие, что цель проекта должна быть выше, чем личная. Проблема в том проекте, в котором у дизайнера цель сделать портфолио, у программиста — поехать на конференцию в Амстердам с клёвым докладом, а у маркетолога — победить в конкурсе «Бренд года».<\/p>\n<p>Я сам бывал и бываю таким дизайнером, который рисовал макеты для своего портфолио и не думал о цели компании. В итоге программисты говорят, что такое сделать сложно и меняют решения находу. Тебе ничего не остаётся, кроме того, как винить во всем программистов. Ведь все задуманное для портфолио осталось только на картинках. В бою проект оказался совсем другим. Проект в итоге получается кривым, а в портфолио лежат только джепеги. А это большой минус для портфолио дизайнера. Вы же часто слышали от дизайнера такую фразу:<\/p>\n<blockquote>\n<p>«Программисты думают только о себе, а не о пользователях»<\/p>\n<\/blockquote>\n<p>Чтобы исключить такие ситуации, кажется, надо ставить выше цель проекта и синхронизироваться с командой.<\/p>\n<h2>Общее решение<\/h2>\n<p>Самая большая ошибка, это пойти сразу рисовать макеты. Рисовать их неделю. Две. А потом бежать с этими макетами к разработчикам (вокруг макетов лучи нимба), а они в итоге говорят, что есть решение проще или еще хуже:<\/p>\n<blockquote>\n<p>«Это сделать невозможно!»<\/p>\n<\/blockquote>\n<p>Есть такой принцип: «Выкидывай бумажки в урну». Дизайнер делает дешевые прототипы и маленькие итерации в макетах, чтобы легче отказываться от своих решений. Если они не работают, конечно же. Решение на салфетке с ними проще. Кучу нюансов всплавает на уровне макетов, но основную концепцию лучше рисовать на салфетке.<\/p>\n<p>Беда в команде, если программист и дизайнер не разговаривают. Следом за салфеткой, следует этап общения и обсуждения. У программистов есть много хороших идей и шикарное представление технических ограничений. Тогда и разработчик никогда не скажет:<\/p>\n<blockquote>\n<p>«Ничего не знаю, так было в макете!»<\/p>\n<\/blockquote>\n<p>Вообщем, решение должно быть общим, больше общения и будет всем хорошо.<\/p>\n<h2>Общая точка успеха<\/h2>\n<p>Определили точку успеха. Что будет являться успешным завершением проекта или задачи в первом подходе. Это избавит проект от лишних хотелок. И вы тогда никогда не услышите от программистов:<\/p>\n<blockquote>\n<p>«У вас концепция постоянно меняется, достали»<\/p>\n<\/blockquote>\n<p>Нужно чётко понимать, что будет достаточно сделать, чтобы решить задачу. Прям напишите это где-то и пускай все кивнут.<\/p>\n<h2>Равенство<\/h2>\n<p>Уважайте друг друга. Дизайнер является полноценным членом команды разработки. Разработчики — тоже дизайнеры. У вас без друг друга врядли что-то хорошее получится, уважайте профессию друг друга. Учитесь слушать и слышать, договариваться. Это чтобы не было таких фраз в вашу сторону:<\/p>\n<blockquote>\n<p>«А почему у меня не спросили?»<\/p>\n<\/blockquote>\n<p>Беда в том проекте, где дизайнер руководит разработчиками или наоборот. Это равные позиции в команде. Иначе дизайнер становится визуализатором, а программист говнокодером. А так быть не должно.<\/p>\n<hr \/>\n<p>Чтобы не пропустить новую заметку — подпишитесь на мой <a href=\"https:\/\/t.me\/ivanzviahin\">канал в Телеграме<\/a> или <a href=\"http:\/\/ivanzviahin.by\/blog\/rss\/\">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)"
}