ivan's blog: posts tagged коммуникация

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

Ivan Zviahin — Mon, 02 Mar 2020 18:53:08 +0000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ситуационное лидерство

Ivan Zviahin — Thu, 23 Jan 2020 20:30:53 +0000

на русском · in english

Cитуационное лидерство — это стиль управления людьми, предполагающий использование одного из четырех стилей управления в зависимости от ситуации и уровня развития сотрудников по отношению к задаче. Согласно данной модели существуют 4 стиля лидерства и 4 степени развития сотрудника.

4 стиля управления

Первый — директивный стиль, или лидерство путём приказа. Высокая ориентация на задачу и низкая на людей. Лидер дает конкретные указания и следит за выполнением заданий.

Второй — наставнический стиль, или лидерство путём продажи идей. Совмещение высокой ориентации на задачу и на людей. Руководитель продолжает давать указания и следить за выполнением заданий, но при этом объясняет принятые решения сотруднику, предлагает высказывать свои идеи и предложения.

Третий — поддерживающий стиль, или лидерство путём участия в организации процесса работы. Высокая ориентация на людей и низкая на задачу. Лидер поддерживает и помогает своим сотрудникам в их работе. Лидер участвует в процессе принятия решений, но решения принимаются в большей степени подчиненными.

Четвертый — делегирующий стиль. Низкая ориентация и на людей, и на задачу. Лидер передает полномочия, права и ответственность другим членам команды.

4 степени развития сотрудника

Первый — не способен, но настроен. Сотрудник, находящийся на этом уровне, высоко мотивирован, демонстрирует много энтузиазма, но владеет только базовыми знаниями и навыками.

Второй — не способен и не настроен. У сотрудника, находящегося на этом уровне, обычно уже есть определенные знания и навыки, однако такой сотрудник по какой-то причине демотивирован.

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

Четвертый — способен и настроен. Сотрудник на этом уровне демонстрирует мастерское владение навыками, необходимыми для выполнения данного задания. Помимо этого он мотивирован и уверен в себе.

Итого

10% знаний, 100% мотивация — директивный стиль.
30% знаний, 10% мотивации — наставнический стиль.
70% знаний, 40% мотивации — поддерживающий стиль.
100% знаний, 100% мотивации — делегирующий стиль.

Макетная актуальность

Ivan Zviahin — Tue, 29 Oct 2019 16:02:18 +0000

Проектируя что-то новое на основании старого, дизайнеру необходимо куда-то обращаться за информацией. Например, как это работает, а как выглядит этот модуль, как себя поведет система?

У нас в команде есть 5 источников таких знаний:

требования в Jira,
макеты в Zeplin,
статическая вёрстка,
cтейджинг,
голова дизайнера.

Итак, разложим каждый по характеристикам: лёгкость поиска, читаемость, близость к правде, видимость деталей.

Требования в Jira

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

Макеты в Zeplin

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

Статическая вёрстка

К ним простой доступ по домену. Есть структура как у макетов, но не настолько детальная. Они близки к правде, так как они и есть правда. Как правило, верстка не показывают все состояния элементов интерфейса и детали сценариев.

Стейджинг

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

Голова дизайнера

К сожалению в свою голову всё не помещается, а чужая часто недоступна. Дизайнер скорее всего хорошо знает структуру, детали и состояния, но это не точно. Он легко может ошибиться или забыть.

Вывод

	Требования	Макеты	Вёрстка	Стейджинг	Голова
Лёгкость поиска	−	+	+	+	−
Читаемость	−	+	+	−	−
Правдивость	+/−	+	+	+	+/−
Видимость деталей	−	+	−	−	−
Итого	−3	4	3	0	−3

Вот и решайте теперь, стоит держать макеты актуальными или нет.

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

Уровень проработки

Ivan Zviahin — Tue, 24 Sep 2019 17:22:15 +0000

на русском · in english

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

Пользовательские сценарии в любом продукте можно разделить на три уровня. Уровень первый — сценарии, которыми люди пользуются чуть ли не каждый день. Мы такие сценарии назвали магистральными. Второй — важные, но нужные не часто. Эти сценарии назвали промежуточными. Третий — скорее исключения, это как раз те сценарии про которые обычно совсем забывают.

Уровень 1

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

Уровень 2

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

Уровень 3

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

Вывод

Никому не нужен магазин с идеально продуманным сценарием добавления товара в «Избранное» в двух вкладках браузера, когда поиск товаров работает плохо и непонятно.

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

Ivan Zviahin — Sat, 01 Jun 2019 14:55:18 +0000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Равенство

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

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

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

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