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

коммуникация

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

Рубрика «Разбор терминов» :-) В википедии написано: ситуационное лидерство — это стиль управления людьми, предполагающий использование одного из четырех стилей управления в зависимости от ситуации и уровня развития сотрудников по отношению к задаче. Попробую разобраться с этим чуть глубже. Согласно данной модели существуют 4 стиля лидерства и 4 степени развития сотрудника.

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

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

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

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

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

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

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

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

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

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

Итого

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

Звучит достаточно просто. На деле, наверное, нет.


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

23 января   книги   команда   коммуникация   лидерство   ситуационное

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

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

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

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

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

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

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

Макеты в Zeplin

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

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

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

Стейджинг

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

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

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

Вывод

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

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


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

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

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

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

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

Магистральные сценарии

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

Промежуточные сценарии

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

Сценарии исключения

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

Как определить сценарии, если это неочевидно

Тут мы придумали простую систему. Берем три метрики: количество пользователей, частота встречи сценария, серьезность. И оцениваем каждую либо 0, либо 1. Как правило, магистральные сценарии получают оценку 3, промежуточные 2, а исключения 1 или 0.

Что делать, если и на первые два уровня уже нет ресурсов

Первое о чем стоит подумать — это делать ли эти сценарии вообще. Ну а если уже решили всё же делать, то делайте низкую проработку модульно. Определите часть системы, которую позже комплексно можно будет переделать.

Вывод

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Равенство

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

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

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


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