Рефлексия

Рефлексия

«Военачальник, который выигрывает сражения, прежде чем сражаться, много размышляет в своем храме»
© Сунь-Цзы, Искусство войны

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


Кому и зачем нужна рефлексия?

Менеджер, который все время в огне и вечно занят, находится на соответствующей ступени своего развития.

Часто бывает так, что специалист еще вчера делал работу руками. Сегодня он пытается стать руководителем, продолжая работать руками, одновременно являясь наставником и делая все подряд.

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

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

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


О чем думать?

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

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

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

Производственное мышление

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

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

Итог такого подхода: бессистемное восприятие компании. Отсутствие жизненно необходимых отделов в компании. Недостаток компетенций за пределами производства. И неуспешность компании как следствие.

Лечить это сложно. Если человек уверен, что работать можно только руками, а не головой — переубедить почти нереально. Можно попробовать расширить понимание технологического цикла. Ведь это не только изготовление изделий или оказание услуг. Это более длинная цепочка от анализа рынков до продвижения и продаж. Дизайн, маркетинг, продажи — просто участки производственной цепи.

Команда это важно

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

У нас этого не произошло, и на это было две причины.

Первая, и самая большая — я не хотел делиться работой. Я поставил себе глобальную цель использовать учебу как трамплин для раскачки своих навыков (я писал об этом ранее https://t.me/bukhtiyar/152), поэтому мне было в кайф брать на себя как можно больше нагрузки, а не быть менеджером команды. В итоге ребята, увидев мой запал, вместо того, чтобы включиться в конкуренцию за работу над проектом, отступили и дали мне полный карт-бланш.

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

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

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

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

Контекст пользователя

Контекст пользователя

Меня часто подкалывают, что я постоянно топлю за фокус на задаче, когда проектирую интерфейс. "Надоел ты, Леха со своими задачами. Поняли уже!", - говорят мне. А я то и рад, что у народа это на подкорку записалось. Но...

Помимо задачи пользователя, важен еще и контекст, с которым он к вам приходит. Выдерживает ли интерфейс этот контекст? Способны ли мы правильно "встретить" человека и провести по сценарию?

Пример

- Собираем карточку товара. Кладем сюда фото, сюда описание, а сюда кнопку "Купить". - Представим, что запущена реклама с коммуникацей про скидку.
- Предусмотрели ли мы состояние карточки под это? Заложили ли состояние, когда на фотках появляется бейдж с жирным скидоном? Можем ли этим гибко управлять? Или каждый раз делаем релиз под очередную акцию?

Понимание полного контекста пользователя коммуникациидают крепкое решение на выходе.

Рекомендации

Интернет маркетологи хорошо разбираются в аудитории, которую пригоняют в продукт. Ваша же задача - понять что эта за аудитория и что ей "пообещали" на шаге до. Засинхроньтесь с коллегами, узнайте кого именно и с какой коммуникацией привлекают. Учитывайте это в интерфейсе при проектировании. Так опыт пользователя будет бесшовным:

Увидел рекламу - считал сообщение/решение задачи - пришел с сообщением в интерфейс - решил задачу.

Практика

В своей работе мы часто используем сценарии пользователей. Вот реклама с такой коммуникацией, вот пользователь переходит на карточку товара, вот жмет кнопку "Купить". На первом этапе можно хоть из квадратов собрать, а потом уже дизайн под это рисовать.

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

Итого

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

В жизни каждого дизайнера возникает момент, когда клиент приходит за логотипом для какого-то нового проекта.

В жизни каждого дизайнера возникает момент, когда клиент приходит за логотипом для какого-то нового проекта.

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

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

1. Сначала узнать, есть ли в принципе сомнения. Можно просто спросить, окончательный ли это вариант, можно как-то ещё осторожнее, но главное спросить.

2. Если сомнения есть, нужно получить явное разрешение на критику. И очень аккуратно её сформулировать, не типа «вот почему это хрень», а «вот в каких ситуациях это может плохо работать». Неудобно произносить, неудобно писать, неудобно склонять, неудобно собирать по полу вытекающие глаза, по ситуации.

3. И если критика находит отклик, получить разрешение придумывать новое, и с этим разрешением придумывать.

4. И показывать не названия текстом, а быстрые логотипы из разных названий.

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

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

Это я книгу пишу и некоторые мысли туда просто не влезают. Вторая глава близко.

Как Reddit аудиторию набирал

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

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

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

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

Как создавалась активность на Reddit?

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

Такую же стратегию использовал сайт Quora (самый популярный сервис вопросов и ответов за рубежом). Два основателя без перерыва создавали новые вопросы и сами же отвечали на них. Потом к ним присоединились первые работники, бета-тестеры. Благодаря этому база вопросов и ответов начала заполняться, сайт ожил, пошёл органический рост.

Да, это непросто. Да, зачастую это приходится делать вручную (хотя, я думаю, что некоторые могут автоматизировать подобные процессы). Но когда других способов выйти из «долины смерти» нет, то и такой хак может оказаться спасительным.

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

Источник - https://m.habr.com/ru/company/changeagain/blog/298284/