Русский
Русский
English
Статистика
Реклама

Product development

Советы по эффективной локализации продукта

16.07.2020 12:18:27 | Автор: admin


Локализация это воплощение принципа удобства для пользователя: примерно 75% людей в мире чувствуют себя более свободно и уверенно при использовании продуктов на родном языке, а не на английском.


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


Сложности локализации на стыке с разработкой


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


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


Правильный подход с самого начала


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


Переводческие компании часто могут посоветовать процессы и удобные инструменты управления переводами для конкретной задачи. К примеру, мы в Alconost, часто разрабатываем собственные коннекторы для интеграции систем управления контентом, что позволяет добиться высокой степени автоматизации.


Этапы локализации продукта и рекомендации


В стратегии по локализации важны налаженные процессы и конкретные инструкции: они обеспечивают эффективную локализацию в рамках разработки цифровых продуктов.


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


Этап 1. Проверка исходных текстов


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


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


Этап 2. Тестирование локализации (псевдо-локализация)


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


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


Этап 3. Работа со сторонней компанией по локализации


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



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


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


Этап 4. Оценка качества перевода


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


Этап 5. Исправление интерфейса и перевод остальных текстов


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


Проблемы и решения в непрерывной локализации


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


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


Небольшие по объему регулярные переводы частое лучше делать с помощью профессионального программного обеспечения (не прибегая к машинному переводу). К примеру, с помощью нашего сервиса для перевода текстов Nitro можно получить профессиональный перевод в течение нескольких часов.



Интеграция программного обеспечения для управления переводами


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


А ещё на таких платформах менеджеры по продукту, специалисты по локализации и переводчики получают уведомления, когда необходимо перевести новую строку (слово, фразу, абзац). И затем либо сразу приступают к переводу (если есть такая договоренность), либо ждут, когда будет назначено задание.


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


Оценка качества


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


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


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


Нужна помощь с локализацией / переводом? Мы в Alconost всегда рады помочь!


О нас


Alconost профессионально занимается локализацией игр, приложений и сайтов на более 70 языков. Лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджмент проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем видеоролики.
Подробнее

Подробнее..

Delivery Club x GIST

10.11.2020 12:07:03 | Автор: admin


Привет! Меня зовут Илья Воробьёв, в Delivery Club я отвечаю за направление клиентских продуктов. Вместе с Андреем Евсюковым я расскажу о том, как в растущей команде мы пересобирали процессы планирования и к чему это привело.

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

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

С чего всё началось


К лету 2019 года переход к кросс-функциональным продуктовым командам дошёл до финальных стадий во всех продуктовых направлениях Delivery Club. В итоге мы получили понятный и достаточно предсказуемый темп движения на уровне менеджера продукта и разработки (кстати, про это мы уже рассказывали тут), но на контрасте стали более заметны трудности уровнем выше взаимодействие продуктовых команд и менеджеров продукта со стейкхолдерами.
Мария:
Год назад с каждой командой нужно было общаться по-разному. Например, у логистического продукта были планирования раз в две недели. С R&D не было планирования. Мы сидели за соседними столами и нормально всё решали. У остальных команд были разные процессы в зависимости от количества заказчиков, которых нужно подружить между собой и поделить ресурсы, и от количества исполнителей у каждой из команд.


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


Стас:
До внедрения GIST у нас применялся классический подход, когда компания находится в стадии переходного периода, внутри продуктов часто творился хаос. У менеджеров продукта был свой roadmap, но у разработчиков не было к нему доступа. Product-менеджеры где-то что-то фиксировали и с этим работали. Выдержки в виде продуктового описания приносили командам разработки, которые формировали технические требования. Появилась потребность весь этот хаос упорядочить, потому что работать становилось очень сложно.

Проблемы быстро обострялись, и этому способствовали:

  • нарастающая конкуренция на рынке;
  • переключение фокуса компании на развитие собственных операций и увеличение доли собственной доставки;
  • рост количества сотрудников, отвечающих за развитие операций и бизнеса (те самые стейкхолдеры, ага);
  • параллельный рост количества разработчиков и команд разработки.

Если окинуть взглядом происходящее на тот момент в компании ещё на уровень выше, то сразу возникают опасения: У нас большая команда, которую мы продолжаем расширять, но уверены ли мы, что эти люди действительно заняты тем, чем нужно? Не теряются ли идеи, слышим ли мы все голоса в команде? Не упускаем ли ценные данные от стейкхолдеров?

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

  • Не очень понятно, кому нести задачу. Вроде бы, надо менеджеру продукта, но какому? А в каком виде?
  • Неясно, что дальше произойдет с задачей. Кто и как её будет делать? Когда будет готова?
  • Нет прозрачного способа ускорить выполнение задачи (а ведь она, конечно же, самая важная).

Первую проблему было не так сложно решить: определили ответственных менеджеров, и поток задач потёк в нужную сторону. Но тут-то выстрелили две другие проблемы: не имея прозрачного процесса приоритизации, стейкхолдеры ринулись ускорять свои инициативы очень простым и широкодоступным способом давлением. Вспоминают Антон Сокольников и Мария Чебакова:

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

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

Мария:
За 1,5 года количество команд разработки выросло в два раза, а количество людей примерно в три. У них уже тогда было какое-то количество заказчиков. Проблема в том, что заказчиков было больше, чем ресурсов. В такой ситуации всегда возникает делёжка. В нашем случае она была не слишком структурирована: всё зависело от силы заинтересованности конкретного человека в решении конкретной задачи.

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

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

  • не получить ожидаемого результата;
  • упустить возможность сделать более полезные задачи от тех людей, которых обошли (или даже не услышали).

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


Иногда сессии по разбору задач растягивались на долгие часы и выглядели как-то так.

Поиск пути


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

Запросы удалось уложить в четыре лаконичных пункта:

  1. Не теряем важные задачи от всех членов команды: стейкхолдеров, менеджеров, разработчиков.
  2. Процесс приоритизации и планирования легко управляется и не занимает чрезмерно много времени.
  3. У всех участников процесса есть понимание (или, на худой конец, возможность понять), что происходит с любой задачей и на каком этапе она находится.
  4. По каждой завершенной задаче команда получает измеримый результат и может использовать эти знания для пересмотра существующих приоритетов.

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

Для заполнения пробелов в коммуникации и планировании стоит ввести новую роль в команде?


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

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

Мы решили обратиться к этому средству, если не сможем найти другого решения.

Существующего процесса будет достаточно, если внедрить систему скоринга?


Баталий на встречах можно избежать (ну, или хотя бы снизить накал страстей), если внедрить общую и понятную для всех систему оценки идей и гипотез. В голову сразу приходят подходы RICE (Reach, Impact, Confidence, Effort) или ICE (Impact, Confidence, Ease), которые позволяют при заполнении показателей получить почти автоматическую приоритизацию.

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

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

Может выделить в команде слоты под задачи каждого из стейкхолдеров (или группы стейкхолдеров)?


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

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

Подойдём системно и перестроим процесс!


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

Изучая практики с рынка, нас заинтересовали подходы Итамара Гилада (Itamar Gilad, кстати, очень крутой дядя с большим количеством интересных трудов). Работая в Google, он собрал и внедрил этапную систему работы над задачами, которую назвал по первым буквам этапов жизненного цикла работы GIST: Goals, Ideas, Step-Projects, Tasks.

Базовые принципы подхода:

  • Goals цели, которые обозначаются командой на достаточно продолжительный промежуток времени. Они должны быть измеримы и понятны. При генерировании идей команда, менеджеры и стейкхолдеры сосредоточиваются на достижении общих целей.
  • Ideas любой член команды может закинуть идею. Команда регулярно приоритизирует и разбирает идеи, выделяет минимум, который позволит проверить ценность предложения минимальной ценой.
  • Step-Projects большие комплексные идеи разбиваются на этапы, которые можно сделать относительно быстро и проверить жизнеспособность и ценность на реальных данных. Чем быстрее такой проект можно завершить, тем лучше.
  • Tasks декомпозиция проекта на конкретные задачи, которые команда будет брать в разработку.
  • Каждый из этапов команда разбирает на регулярных сессиях и сосредоточивает ресурсы на идеях, которые приносят наибольший результат.



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


Принципы GIST звучат довольно просто (почти как Agile-манифест), но концептуально хорошо отражают то, как мы видели правильную работу команды и стейкхолдеров. Оставалось понять, как обернуть фреймворк в рамки конкретного процесса. Ну, и самое главное: как его запустить и убедиться, что всё действительно работает задуманным образом.

Have Space Suit Will Travel


Понимая, что просто копировать описанные Итамаром идеи будет опрометчиво, мы начали разбирать и адаптировать фреймворк под наши запросы и особенности.

При этом какие-то части процесса не были описаны Итамаром совсем, а некоторые вполне конкретно обозначены, и более того, многие компоненты уже были у нас внедрены:

  • Этапы Step-Projects и Tasks перенести на наши реалии было нетрудно: команды уже работали в рамках двухнедельных итераций, умели декомпозировать и запускать задачи в хорошем темпе (напоминаю, что детали можно посмотреть в этой статье).
  • C Goals тоже не было проблем. На уровне всего Delivery Club есть понятная стратегия развития, которая довольно просто трансформируется в цели и задачи на уровне команд и направлений. Например, у логистики, с которой мы и хотели начать пересобирать процессы, есть хорошо измеримые цели по загруженности курьеров, среднему времени и стоимости доставки заказа.
  • Самая мякотка для нас заключалась в этапе Ideas: как правильно научиться собирать идеи и выстроить работу по их приоритизации.

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

Идея и как её создать


Рассмотрев успешные кейсы в Delivery Club, мы выделили несколько общих факторов:

  • Почти у каждой выстрелившей идеи или гипотезы было проработанное бизнес-обоснование. Например, в начале 2019 года часть команд клиентского направления приступила к проработке решения по запуску доставки продуктов из магазинов. Но до перехода к проектированию мы очень подробно изучили динамику изменения рынка онлайн-ритейла за последние годы и перспективы роста на будущее. Это позволило сразу сфокусироваться на модели маркетплейса для магазинов решения, которое в полной мере расцвело в безумный 2020 год.
  • Время на проектирование и реализацию в продукте всегда было ограничено либо внешними факторами, либо самой командой. Стараясь уложиться в срок, ребята находили оригинальные решения и отрезали всё, что не было важно для проверки гипотезы на запуске. Подчеркнём, что короткие итерации в разработке это не что-то новое или революционное. Хитрость в том, чтобы у команд было изначальное ограничение на количество итераций для финального решения. Кстати, в книге Shape Up Райана Сингера есть подробный разбор этой механики и её использования для развития продукта в Basecamp.
  • Инициатор гипотезы работал в тесной связке с менеджером продукта и командой на протяжении всего процесса: от проектирования и разработки до запуска и оценки результатов. В ряде случаев такое вовлечение позволяло отказываться от реализации на ранних этапах. А где-то раскопать несколько новых идей и гипотез на следующие этапы.

В этот момент проявились контуры того, как мы хотели построить работу:

  • Любой член команды может завести идею и положить её в общее пространство.
  • У идеи должен быть набор обязательных параметров к заполнению:
    • Суть.
    • Почему возникла идея и какую ценность она несёт. Чем больше здесь доказательств, тем лучше. Именно из этого и складывается Impact, который кратко описывается.
    • Как выглядит верхнеуровневая реализация по мнению инициатора.
    • Какой результат ожидаем и почему.
  • Менеджер продукта будет периодически просматривать новые идеи с командой и давать комментарии по описанию, а также дополнять идею данными со своей стороны и фиксировать ограничение по времени на поиск и реализацию решения (это отражает для нас Effort).
  • При первичном разборе часть идей будет склеиваться с уже существующими, часть будет отсеиваться, а часть наполняться деталями. На обсуждение выносим те идеи, которые инициатор готов защищать не только силой своей харизмы, но и набором фактов с пониманием ограничений на реализацию.
  • Раз в две недели проводим общую встречу по приоритизации, на которой происходит три важных события:
    • инициаторы публично защищают свои идеи;
    • команда разбирает результаты завершенных проектов;
    • пересматриваем приоритеты по задачам, которые находятся в бэклоге, и команда сообщает, что уйдёт в разработку далее.


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

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

Как проходит защита


Стало понятнее, но последним пробелом остаётся сама защита. Да и как проходит встреча по приоритизации, тоже неясно. А устроено это так:

  • В полном составе команды, стейкхолдеры и менеджеры встречаются раз в две недели.
  • Должны быть разобраны три блока: защита идей, разбор результатов по завершённым проектам, реприоритизация бэклога.
  • Для простоты и прозрачности все идеи и проекты это задачи в Jira, которые разложены на Kanban-доске (доска идей). Кроме очевидных Done и Closed доступны ещё шесть статусов:



    • Inbox список новых идей. Задачи из этого статуса регулярно просматривают менеджеры продукта, помогая сформировать правильное описание и дойти до защиты.
    • Pitch идеи на защиту, которые будут обсуждаться на ближайшей приоритизации. Успешная защита означает перемещение в бэклог.
    • Backlog, Next, Now отражают состояние защищённой идеи в бэклоге. Соответственно, ожидаем реализации в рамках квартала, следующего спринта, или уже следим за реализацией.
    • Analysis запущенные проекты, по которым команда и стейкхолдеры должны собрать результаты и оценить, насколько идея была успешна (или неуспешна) и почему.

  • У самих задач на доске для наглядности вывели поля Impact (влияние идеи на бизнес и продукт) и Effort (какое время команда берёт на проектирование и реализацию решения). Оба значения заполняются в свободной форме. Обычно в Impact попадает несколько ключевых метрик и прогнозируемые изменения, а в Effort количество спринтов на реализацию.
  • Итогом каждой встречи должно стать следующее: колонка Pitch пуста, BacklogNextNow отражает актуальное положение дел, а в Analysis остаются только те задачи, по которым ещё не набралось достаточно данных.
  • Пара слов про защиту. Инициатор должен отстоять идею, команда и менеджер будут бороться за слот на реализацию. Ограничений по формату нет, но на каждую защиту выделяется 5-7 минут, за которые нужно успеть доказать ценность идеи, согласовать ограничения на реализацию и перенести в бэклог. Изначально мы предполагали собирать на защиту комитет из людей с независимой позицией, но решили отложить эту схему на случай крайней необходимости.

Внедрение


Всё вышеописанное, начиная от формата задач до повестки встреч, зафиксировали в Confluence. Потом завели проект в Jira и настроили Kanban-доску. На этом простая часть закончилась и началась сложная внедрение.

Справедливости ради, не во всех направлениях проблема стояла одинаково остро, поэтому пилотировать мы начали там, где болело больше всего. А больше всего болело в направлении логистики.



Какие шаги предприняли:

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

В первые пару месяцев получалось довольно тяжко. Вот как вспоминают и оценивают тот период Мария, Антон и Стас:
Мария:
Хорошо помню переход на GIST. Сначала было больно, потому что новый процесс ставил людей в новые рамки. Каким бы они ни были благом для конкретного человека, воспринимались в штыки. Выгоды были понятны, но когда ты их ещё не получил, а ограничения уже есть, это вызывает протест. Когда внедряли GIST в первой команде, люди сопротивлялись. А когда дошли до третьей команды, люди уже сами просили внедрить GIST.

Антон:
Сначала нужно было свыкнуться с тем, что у тебя есть соседи по целям и проектам, и с ними придётся делиться ресурсами. Мы аккуратно, постепенно ко всему этому приходили. Начали с доски, в которой мы заводили задачи и описывали их, то есть приучали бизнес к тому, что задачи надо завести. Раньше они просто набрасывали свои идеи, а менеджеры всё заводили.

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

Стас:
Чтобы процесс проходил менее деструктивно внутри команд, мы стали заводить задачи разработки в продуктовые эпики. Они же потом стали формировать список проектов Step-Projects. После того, как все привыкли к Step-Projects, мы ввели следующий этап Идеи. Идея, в свою очередь, может состоять из нескольких этапов нескольких Step-Projects.

В тот момент как раз поступила крупная задача на 2,5-3 месяца разработки. Мы её оформили в Идею, выделили MVP это и был наш Step-Project. Дальше его поделили на таски и попытались поставить их на продакшен за два спринта в составе Step-Projectа. Поняли, что идея нам подходит, есть прогресс со стороны бизнеса. Дальше сформулировали следующий этап итерации.

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

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

Например, чтобы перейти на GIST в одной из команд клиентского направления и обучить стейкхолдеров работать по новой схеме, пришлось провести пять дополнительных встреч, помимо kick-off и первых двух модерируемых приоритизаций.

Эти встречи позволили:

  • Объяснить правильную структуру и принципы описания идеи.
  • Выстроить и зафиксировать прозрачные для стейкхолдеров цели.
  • Научиться получать верхнеуровневые оценки по разработке на ранних этапах.
  • Мыслить в формате влияния на бизнес и метрики.
  • Технической команде приносить и высказывать продуктовые идеи.

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

Хорошие новости в том, что ситуация постепенно исправляется. Эмпирически выяснили, что на трансформацию мышления у всех участников процесса уходит 2-3 месяца, после чего нагрузка на менеджеров продукта постепенно спадает.

И жили они долго и счастливо?


GIST хорошо прижился в рамках логистического направления (хоть и пришлось немного помучиться при внедрении):
Мария:
Есть очевидный плюс: все команды приоритизируются одинаково, процесс знаком всем сотрудникам в любой команде. Каждый может посмотреть, чем занимается другая команда. Это добавляет прозрачности. Все понимают, что делает команда, и что она делает благо: у задач есть спрогнозированный результат для бизнеса. Все радуются, что эта команда принесёт нам дополнительный прирост KPI там, где он нужен.

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

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

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

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

Стас:
У меня не было чётких ожиданий перед внедрением. У меня были проблемы, которые я хотел решить с помощью GIST. И они действительно решились. Но при этом я точно знаю, что у GIST большой потенциал, если его продолжать внедрять. Останавливаться не стоит.

Из плюсов: был прецедент, когда ребята из разработки сами предложили какие-то идеи. У них появился для этого прозрачный механизм. Есть доска идей, есть правила оформления и прохождения через весь этот процесс. Когда у кого-то есть идея, он знает, что нужно зайти, создать задачу, довести её до нужного статуса, указать все необходимые элементы. А потом по этой задаче придёт product-менеджер с вопросами, и дальше она пойдёт в приоритизацию.

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

  • У команд и стейкхолдеров вырабатывается привычка подробно оценивать идеи с точки зрения влияния на бизнес и продукт. А это, в свою очередь, отличная предпосылка к поддержанию и развитию целеполагания по OKR.
  • Ориентация на единый инструмент (Jira) и возможность отследить движение идеи добавляет прозрачности и снижает использование сторонних решений (меньше Google-таблиц и их аналогов, да).
  • Понятные шаги по созданию и продвижению идей постепенно вовлекают в работу с продуктовыми командами людей из бизнеса, обычно далёких от разработки.

Результаты в направлении логистики нас порадовали, и началось постепенное внедрение в других командах. К осени 2020 года GIST проник во все продуктовые направления Delivery Club, но не везде прижился как основной процесс.

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

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

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

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

Кто такой продакт-менеджер? Или не все PMы проджект-менеджеры

28.12.2020 22:14:52 | Автор: admin
В каждой компании наступает момент, когда она становится больше, чем стартап, и принцип работы каждый отвечает понемногу за все уже не эффективен. Что это значит? Пришло время расписывать необходимые роли, чтобы знать, кто и зачем вам нужен.
Давайте поговорим о такой должности как Product Manager, который только появляется на рынке труда и является незаменимой для компаний, которые хотят расширяться, а также затронем отличия этой роли от роли проджект-менеджера.
"

Кто такой Product Manager?


Менеджер продукта это человек, который отвечает за создание продукта или продуктов для компании. Что такое продукт? Это товар или услуга, которая создается специально для удовлетворения потребностей рынка. Продакт-менеджер работает с продуктом с момента зарождения идеи и вплоть до его смерти. Продолжительность жизни продукта относительна и не имеет четко выраженных границ в отличие от проекта, который имеет четкие сроки и размер выделенного бюджета.
Именно в этом главное отличие двух PMов: продакту важен именно продукт, а проджекту процесс реализации. К тому же, как правило, один продукт это целый ряд проектов; в то время как проект не равно продукт.

Задачи Product Managerа


  1. Определить, кто является целевой аудиторией для продукта, и какие функции будут для нее первоочередными, а какие второстепенными.
  2. Проанализировать рынок аналогичных продуктов, чтобы понимать, какие потребности ЦА они закрывают и каким образом.
  3. Решить, как можно привлекать пользователей (внутренний продукт) и клиентов, получать от них оплаты, а также как поддерживать их лояльность продукту (внешний рынок).
  4. Определить, почему клиенты прекращают пользоваться продуктом (технические недостатки, высокая цена, неподходящий функционал).
  5. Создавать и проверять гипотезы, чтобы потом писать технические задания командам.
  6. Принимать решения о том, нужно ли вообще создавать новый продукт.
  7. Контролировать жизненный цикл продукта и его прибыльность.

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

Обязанности менеджера продукта


  1. Написание и проверка гипотез.
  2. Общение с клиентами.
  3. Анализ продукта, его недостатков и сильных сторон.
  4. Анализ рынка, целевой аудитории, конкурентов с дальнейшим документированием.
  5. Написание требований к продукту и согласование функционала с командой разработки, согласование MVP.
  6. Согласование цен, программ лояльности, работа с прототипами и проведение демонстраций для получения обратной связи.
  7. Запуск продукта, контроль его релизов, работа над новым функционалом для соответствия требованиям рынка.

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

Для кого подходит должность Product Manager


Работодатели видят в этой должности человека с образованием в области маркетинга, менеджмента или экономики, который умеет анализировать и систематизировать большие объемы данных, понимает, как выглядит путь клиента, имеет опыт работы с гибкими методологиями, готов быстро изучить домен и понять его особенности. Также очень важны коммуникативные навыки для получения правильной обратной связи от потенциальных клиентов и работы с командами.
Средняя зарплата для продакт-менеджера, у которого менее 1 года опыта, согласно DOU $950, а после 4 лет работы на этой позиции уже можно говорить о $2000.
Данная роль это отличная перспектива, так как она позволяет расти в разные управленческие роли, вплоть до CEO.
В современных реалиях роль менеджера по продукту часто является второй ролью для бизнес-аналитика, проджект-менеджера, а порою тестировщика или разработчика. Для проекта в целом очень полезно, если члены команды надевают шляпу продакт-менеджера, чтобы понять, насколько то, что они делают, будет соответствовать ожиданиям их пользователей.
Это перспективная профессия, которая пользуется спросом на рынке труда, но количество кандидатов еще достаточно мало. Будьте проактивными обучайтесь тому, что будет актуально через пару лет!
Подробнее..

Recovery mode Кто такой продакт-менеджер? Или не все PMы проджект-менеджеры

29.12.2020 02:22:15 | Автор: admin
В каждой компании наступает момент, когда она становится больше, чем стартап, и принцип работы каждый отвечает понемногу за все уже не эффективен. Что это значит? Пришло время расписывать необходимые роли, чтобы знать, кто и зачем вам нужен.

Давайте поговорим о такой должности как Product Manager, который только появляется на рынке труда и является незаменимой для компаний, которые хотят расширяться, а также затронем отличия этой роли от роли проджект-менеджера.



Кто такой Product Manager?


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

Именно в этом главное отличие двух PMов: продакту важен именно продукт, а проджекту процесс реализации. К тому же, как правило, один продукт это целый ряд проектов; в то время как проект не равно продукт.

Задачи Product Managerа


  1. Определить, кто является целевой аудиторией для продукта, и какие функции будут для нее первоочередными, а какие второстепенными.
  2. Проанализировать рынок аналогичных продуктов, чтобы понимать, какие потребности ЦА они закрывают и каким образом.
  3. Решить, как можно привлекать пользователей (внутренний продукт) и клиентов, получать от них оплаты, а также как поддерживать их лояльность продукту (внешний рынок).
  4. Определить, почему клиенты прекращают пользоваться продуктом (технические недостатки, высокая цена, неподходящий функционал).
  5. Создавать и проверять гипотезы, чтобы потом писать технические задания командам.
  6. Принимать решения о том, нужно ли вообще создавать новый продукт.
  7. Контролировать жизненный цикл продукта и его прибыльность.

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

Обязанности менеджера продукта


  1. Написание и проверка гипотез.
  2. Общение с клиентами.
  3. Анализ продукта, его недостатков и сильных сторон.
  4. Анализ рынка, целевой аудитории, конкурентов с дальнейшим документированием.
  5. Написание требований к продукту и согласование функционала с командой разработки, согласование MVP.
  6. Согласование цен, программ лояльности, работа с прототипами и проведение демонстраций для получения обратной связи.
  7. Запуск продукта, контроль его релизов, работа над новым функционалом для соответствия требованиям рынка.

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

Для кого подходит должность Product Manager


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

Средняя зарплата для продакт-менеджера, у которого менее 1 года опыта, согласно DOU $950, а после 4 лет работы на этой позиции уже можно говорить о $2000.

Данная роль это отличная перспектива, так как она позволяет расти в разные управленческие роли, вплоть до CEO.

В современных реалиях роль менеджера по продукту часто является второй ролью для бизнес-аналитика, проджект-менеджера, а порою тестировщика или разработчика. Для проекта в целом очень полезно, если члены команды надевают шляпу продакт-менеджера, чтобы понять, насколько то, что они делают, будет соответствовать ожиданиям их пользователей.
Это перспективная профессия, которая пользуется спросом на рынке труда, но количество кандидатов еще достаточно мало. Будьте проактивными обучайтесь тому, что будет актуально через пару лет!
Подробнее..

YouTrack теперь с центром уведомлений

07.04.2021 20:14:16 | Автор: admin

Привет, Хабр!

На связи команда YouTrack из JetBrains. Мы рады открыть релизный год сразу несколькими хорошими новостями: YouTrack теперь умеет показывать уведомления прямо во встроенном центре уведомлений, в YouTrack Lite появились функции учета времени, настраиваемые поля стали поддерживать ссылки, а в профили пользователей теперь можно добавлять дополнительные поля. Ниже расскажу обо всем подробнее добро пожаловать под кат!

Держите руку на пульсе

Раньше уведомления YouTrack можно было просматривать только во внешних приложениях в почте, Jabber или Slack. В новой версии мы представляем центр уведомлений место, куда приходят все оповещения об актуальных изменениях, комментариях, упоминаниях и реакциях. Красный кружок на колокольчике подскажет, что у вас есть непрочитанные уведомления.

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

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

В правом верхнем углу центра уведомлений вы увидите три точки под ними спрятано несколько опций: пометить все уведомления как прочитанные; отобразить только непрочитанные уведомления; перейти в настройки уведомлений (например, чтобы отключить отправку уведомлений по электронной почте, если вы решили пользоваться только центром уведомлений YouTrack).

Время под контролем: теперь и в YouTrack Lite

В версии 2020.6 мы представили альтернативный интерфейс YouTrack Lite с удобным текстовым редактором и табличным представлением списка задач. Мы получили много положительных отзывов о новом интерфейсе и продолжили его развивать: по просьбам наших пользователей в этой версии мы добавили функции учета времени. Теперь YouTrack Lite позволяет указывать затраченное время и просматривать единицы работы.

Связь с внешним миром: ссылки в строковых полях

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

Поиск полного дерева подзадач

Теперь вы можете осуществлять поиск целого дерева подзадач. Используйте для этого синтаксис совокупность подзадача: и укажите идентификатор задачи. Так вы сможете, например, найти все пользовательские истории и подзадачи, относящиеся к определенному эпику, независимо от количества уровней вложенности.

Этот синтаксис можно применять не только к типу связи подзадача, но и ко всем типам связи с направленностью объединение, например, к дубликатам (совокупность дубликат: ID задачи)

Иерархия групп

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

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

Дополнительные поля в профилях пользователей

Помимо учетных данных, имен и электронных адресов, в профилях пользователей теперь можно указывать дополнительную информацию например, телефонные номера или должности сотрудников. Рабочие процессы (workflows) YouTrack тоже могут оперировать этими полями. Например, вы сможете разрешить выполнение определенных действий только генеральному директору компании. Кроме того, настраиваемые атрибуты могут быть синхронизированы с AD-сервером (или любым LDAP-сервером) и доступны через REST API Hub, что открывает еще больше возможностей для автоматизации.

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

Лучше один раз увидеть, чем сто раз прочитать. Напомню, что YouTrack со всеми его новшествами можно попробовать бесплатно. Мы будем рады вашей обратной связи!

Команда YouTrack

Подробнее..

Midmare свободный от HTTP-Layer модуль Node.js

06.09.2020 22:19:56 | Автор: admin
Midmare это минималистичная open-source библиотека. Я написал её в достаточно сжатые сроки с целью оптимизировать конкретные процессы в своей компании. Но в результате удалось прийти к решению, потенциал которого значительно превышает изначальную задумку.

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

Предыстория


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

С учетом этих особенностей необходимо было найти гибкое и универсальное решение, чтобы переписать существующий backend. Таким решением стала библиотека Midmare.

Вводные задачи


У меня была задача сделать так, чтобы библиотеку можно было использовать и с TypeScript, и с JavaScript. При этом команда целилась на то, чтобы полностью переписать код с TS на JS для ускорения разработки.

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

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

Я пришел к идее использовать middleware


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

Так у меня получился стек middleware, который по своему принципу похож на Коа. Такая схожесть гарантирует, что остальным библиотеку будет легко использовать. Но в Midmare методов значительно меньше, всего 4. Библиотека Midmare сама по себе минималистичная.

Начало работы


Перед установкой Midmare необходимо скачать и установить Node.js версии 10 и выше. При создании нового проекта нужно также сперва создать package.json с командой npm init.

Установка Midmare выполняется через команду npm install midmare.

Ниже приведен образец инициализации приложения.


Общая инициализация приложения на Midmare


Использование роутеров (промежуточных обработчиков уровня маршрутизатора)

Возможности Midmare


В первую очередь, мы говорим о впечатляющих возможностях декомпозиции кода. Промежуточные функции (middleware) могут не знать друг о друге ничего. Они просто берут данные, обрабатывают и отпускают дальше.

Библиотека Midmare идеально подходит в тех случаях, когда нужно использовать одну систему маршрутизации для разных API source и destination. То есть когда нужно создать некий общий узел обработки. Но так же можно создавать и более простые приложения.

Приведу несколько примеров, чтобы подчеркнуть возможности Midmare.

Отлов ошибок с помощью промежуточной функции. Он же пример декомпозиции кода


Простая промежуточная функция, закрывающая HTTP-сессию в случае несовпадения маршрутов


Пример обработки какой-либо команды, в данном случае отправка данных в Redis

Маленькая библиотека делает свою маленькую работу, но при этом ни в чем не ограничивает доступные тебе опции. В Midmare можно подключить по сути всё, что угодно не ломая голову, как строить архитектуру.

Ключевое преимущество


Ключевое преимущество этой библиотеки полная отвязка от каких-либо лейеров (HTTP, WS, etc.). Если Koa рассчитан на HTTP-сервер, то Midmare в этом плане не создает ограничений.

Можно даже просто написать терминальную утилиту. С Midmare это удобно, так как мы можем использовать параметры в ``. Как в примере ниже:


Используя Midmare, можно вернуться всё к тому же HTTP-серверу. Подключить его не будет сложностью. Уже есть готовый роутер для HTTP.

При этом также можно спокойно подключать WebSockets. Нужно только инициализировать сам клиент WebSockets. А дальше дело за максимально простым роутингом.


Пример объединения HTTP и WebSockets с Midmare

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

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

Готовых библиотек такого формата я не встречал


То есть полного аналога: без низкоуровневых привязок, будь то WebSockets, HTTP или, если обобщать, сетевая связь или программная работа в самой ОС.

Midmare может делать это всё одновременно и буквально в 56 строк настройки.

А идея в её основе достаточно простая построить цепочку выполнения функций с использованием метода next/send для вызова. Если ничего дальше вызывать не нужно, программа остановится. Плюс роутинг, минус HTTP и мы имеем Midmare.

Зачем использовать эту библиотеку?


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

Кроме того, слишком много фильтров существует в мире программистов. Кому-то хочется писать на TypeScript, кому-то на JS. Я искал решение, чтобы захватить оба варианта.


Сейчас я стараюсь активно тестировать и дорабатывать Midmare

Большой плюс маленькой библиотеки её создатель сам же её активно поддерживает.

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

Циклические вызовы первая из исправленных проблем


Посмотрим на пример ниже:

Допустим, нам нужно добавить в шаг .process(/message) вызов /send, но в .process(/send) уже содержится вызов /message. Тогда Шаг 2 будет вызывать Шаг 1. При этом в Шаге 1 будет каждый раз срабатывать вызов Шага 2 и так по кругу.

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

В данном случае у нас возникнет ошибка Maximum call stack size exceeded и JS упадет в ответ на многократный рекурсивный вызов одной и той же функции.

Решение такой проблемы в этой библиотеке: Сохранение истории путей в одном контексте. То есть каждый вызов `ctx.send` или `app.send` имеет свою историю вызовов.

Поскольку в Midmare есть обработка этого момента, библиотека выдаст ошибку в случае циклического вызова.

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

На случай, если в реализации будет требоваться цикличность, в Midmare существует опция установить игнорирование ошибки через `ignoreCycleError: true`.



Библиотека ждёт своё комьюнити


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

Если в конкретном случае не хватает какой-то обработки, её можно самостоятельно дописать в условные 4 строчки. Как в примере с функцией для закрытия HTTP-сессии:


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

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

Автор: Иван Петушинский, Senior Node.js Developer
Подробнее..

Какие бывают метрики. Дизайнер и метрики, 2 часть

27.08.2020 08:21:11 | Автор: admin
image

Вы читаете вторую статью из серии Дизайнер и метрики. В первой статье я пытался ответить на вопрос, нужны ли дизайнеру метрики. Ее можно найти тут.


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


Retention метрика, на которую я смотрю чаще всего


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


Начнем с retention метрика, которая показывает возвращаемость пользователей. То есть, если сегодня наше приложение скачало 100 новых пользователей, то retention ответит на вопрос, сколько из них к нам вернется завтра, через месяц и так далее.


Допустим, что retention второго дня равен 60% это значит, что на второй день приложение запустят 60 пользователей из 100 скачавших.


Эту метрику можно посчитать на любой день жизни пользователя. Допустим, retention 7 дня равен 30% это означает, что на 7 день с момента скачивания в нашем приложении останется 30 человек из 100 скачавших.


image

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


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


Допустим, наше приложение скачали 1000 раз за неделю. Во второй день из этой тысячи зашли 600 пользователей, а в седьмой 300. Используя эти данные, мы можем посчитать retention второго дня 600/1000 = 60%, и retention седьмого дня 300/1000 = 30%


Чем полезна эта метрика?


Она быстро даёт понять, удалось ли нам сделать продукт, который был полезен пользователю, или он пощёлкал, посмотрел и удалил.


Если retention какого-то дня составляет 0%, значит, из всех, кто когда-то скачивал приложение, никто в нем не остался, и приложение никому не нужно. Может, стоит его закрыть?


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


Но чаще всего цель разработки приложения найти пользователей, которые будут пользоваться им в течение длительного времени. То есть, с какого-то дня retention должен перестать убывать retention 90 дня должен быть равен retention 180 дня и так далее. В таком случае аналитики говорят, что retention вышел на плато.


Если у продукта большая и постоянно растущая аудитория, это свидетель того, что продукт вышел на плато retention как Facebook, Telegram, Google Maps и так далее.


Метрики роста и метрики продукта


Отойдем на шаг назад и посмотрим, какие вообще бывают метрики. Выделяют 2 типа: метрики роста и метрики продукта


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


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


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


Как думаете, retention это метрика роста или метрика продукта?


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


Допустим, мысленно сравняйте количество пользователей своего приложения с количеством пользователей Facebook. Retention приложения при этом останется неизменным. Как был 30% на седьмой день, так и останется. А значит, Retention это метрика продукта.


А что произойдет с выручкой? Выручка при увеличении аудитории заметно взлетит. Если один пользователь приносил нам 10, то 100 пользователей принесут нам 1 000 , а 1 000 000 пользователей 10 000 000 . Получается, что выручка (или revenue) это метрика роста.


Итак, метрики роста отвечают на вопросы:


Растет или падает дневная аудитория нашего приложения?


Сколько зарабатывает наш продукт?


А метрика продукта:


Сколько денег нам приносит один средний пользователь?


Какая часть пользователей остается с нами спустя месяц после установки приложения?


Зачем разбираться в метриках роста и продукта


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


Конечно, проще всего было бы ответить на эти вопросы, посмотрев на метрики роста. Мол, если мы стали больше зарабатывать значит, все не зря, а если начали зарабатывать меньше, то что-то идет не так.


Но в этом подходе кроется ошибка, которая может стоить продукта.


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


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


Команда выкатывает эту фичу и она оказывается неудачной. Метрики продукта то есть, retention, возвращаемость пользователей летят вниз. Продукт начинает хуже удерживать пользователей, доход на нового пользователя уменьшается.


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


Получается, что по метрикам продукта все очень плохо, но по метрикам роста просто отлично. И руководство, посмотрев на метрики роста, радуется и повышает плохого менеджера, который только испортил продукт.


Такой случай не редкость в компаниях.


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


Подытожим


  1. Одна из главных метрик продукта это retention, то есть, возвращаемость пользователей. Найти его можно, разделив количество дневных пользователей на N-ный день на количество скачавших приложение.
  2. Мы научились отличать метрики роста от метрик продукта. Достаточно мысленно увеличить количество пользователей приложения и посмотреть, увеличился вслед за этим показатель метрики или нет. Например, выручка revenue увеличится; значит, это метрика роста. А retention нет; значит, это метрика продукта.
  3. Поняли, что для оценки продукта и своей деятельности нужно использовать именно метрики продукта.

Что дальше


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

Подробнее..

Как продуктовому дизайнеру оценить свою работу

21.09.2020 10:09:24 | Автор: admin

image
Photo by Brooke Cagle on Unsplash


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


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


Дни после релиза


После раскатки нового функционала каждый дизайнер спрашивает себя: что изменилось? Удалось ли нам улучшить продукт?


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


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


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


Как сравнить метрики до и после


Реальное значение метрики против замеренной


У каждой метрики есть её реальное значение назовем его R (реальное), а есть значение, которое мы получили через замеры Z (замеренное).


И первое, с чем нам надо справиться это понять, что R Z.


Разберемся на примере


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


Допустим, теоретически мы могли бы опросить каждого человека в России, силовик он или нет, и получить реальное значение, то есть R.


Но поскольку практически это невозможно, мы опрашиваем столько людей, сколько смогли найти допустим, 300 человек (выборку формируем по науке), и потом просто экстраполируем эти данные на всю Россию.


Так мы получаем Z, то есть замеренную метрику. Думаю, теперь стало понятно, что почти всегда Z R.


Как из замеренной метрики получить реальную?


На этот вопрос как раз и отвечает математика. С помощью математической формулы мы можем получить промежуток значений, в котором находится R.


Вернемся к примеру с силовиками. Предположим, что после опроса 300 человек, 5 из них ответили, что являются сотрудниками силовых структур, то есть приблизительно 1,7%.


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


  1. Замеренное значение метрики в случаем с силовиками это 1.7%
  2. Количество выборки, на которой сделан замер 300 человек
  3. Количество потенциальной выборки (не обязательно) в нашем случае наслеление России 146 млн человек.
  4. Выбрать точность, с которой мы хотим получить результат. Обычно используют 90, 95 и 99%

Эти данные нужно ввести в специальный калькулятор для расчета доверительного интервала и нажать вычислить.


На выходе мы получим промежуток, в котором содержится R с вероятность 90, 95 и 99% (в зависимости от того, какой процент мы выбрали при расчёте).


Если вернуться к примеру с силовиками, то после этих расчётов можно сказать, что R находится в промежутке (или доверительном интервале) от 0% до 3,59% от всего населения России.


А значит, если умножить этот процент на население России, то получим интервал от 0 человек до 5 268 274 человек. (В этом интервале действительно содержится верный ответ в реальности это 2,6 миллиона).


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


А как же все-таки сравнить метрики до и после


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


Если пересечения нет, то мы получили статистически значимые результаты и можно утверждать, что мы что-то изменили в продукте.


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


Разберемся на примере маркетинговой компании


Допустим, мы подготовили 2 креатива, и их посмотрели по 5 000 пользователей. Первый показал значение CTR 2% (это процент нажавших на креатив и перешедших на лендинг), а другой 3%. Можно ли сказать, что второй лучше первого?


Чтобы ответить на этот вопрос, нам надо собрать все данные для измерения доверительного интервала:


По первому банеру:


  1. Значение метрики 2%
  2. Сколько людей увидело этот банер 5 000
  3. Опускаем потенциальную выборку
  4. Выбираем точность 95%

Получаем, что R по первому креативу с 95% вероятностью находится между [ 1,61% 2,39% ]


Тоже самое проделываем по второму банеру (его посмотрело тоже 5 000 человек) и получаем интервал [ 2,53% 3,47% ]


image


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


Подытожим


  1. Чтобы оценить работу дизайнера, недостаточно просто посмотреть метрики до и после, нужно сравнить их доверительные интервалы.
  2. Посчитать доверительный интервал можно с помощью специального калькулятора.
  3. Если доверительные интервалы до и после не пересекаются значит, работа дизайнера точно дала положительный результат.

Что дальше


Это была 3 и последняя статья из серии Дизайнер и метрики.


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

Подробнее..

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

28.07.2020 18:07:12 | Автор: admin
image

Содержание


Введение. О чем эта статья
Цели и дисклеймеры
Часть 1. Хороший продукт
Часть 2. Пользовательский опыт (UX). Что это?
Часть 3. Архитектура выбора
Часть 4. Архитектор выбора
Часть 5. Когнитивные искажения и Пользовательский опыт
Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)
Часть 6. Наши дни
Часть 7. Не только искажения
Часть 8. Эпилог
Часть 9. Материал, качественно дополняющий эту статью

Введение. О чем эта статья


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

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

В какой-то момент своей жизни я перепрофилировался из технического специалиста в IT-сфере, коим я проработал около 6 лет (LAN/WAN/DevOps/InfoSec), в Product Manager-а. Моей основной деятельностью на этой должности является анализ ожиданий и принятых решений пользователей с целью создания более комфортного и желанного продукта.

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

Цели и дисклеймеры


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

  • показать четкие доказательства важности глубоких знаний в психологии для работы в качестве менеджера по продукту;
  • дать определение понятию UX (Пользовательский опыт) с позиции психологии и поделиться наиважнейшим источником знаний для создания качественного UX;
  • показать механизм оценки грамотности продакт менеджеров (и не только);
  • побудить инвесторов больше инвестировать в продукты, в основе которых лежит когнитивная психология и поведенческая экономика;
  • предоставить продакт менеджерам дополнительные аргументы в поддержку их идей, которые, часто являясь верными, увы, блокируются техническими специалистами из-за непонимания полной картины и технического склада ума;
  • показать с другого угла скучные исследования, которые пылятся на полках библиотек, акцентируя чрезвычайную важность этих материалов для будущего разработки ПО;
  • побудить психологов и экономистов взглянуть в сторону продакт менеджмента как возможной опции смены карьерного направления. Мир IT нуждается в вас гораздо больше, чем в диванных аналитиках и псведо-менеджерах с MBA и PMP.

Я намеренно опускаю такие бизнес вопросы как целесообразность создания продукта, анализ рынка, анализ конкурентов и прочие, так как они имеют мало общего с UX. Продукт может быть качественным вне зависимости от спроса, от целесообразности его выпуска на рынок и силы конкурентов.

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

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

Часть 1. Хороший продукт


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

Итак, чуть выше я убрал вопросы про рынки, конкурентов и целесообразность продукта, потому что я исхожу из того, что качественный продукт это, прежде всего, продукт без внутренних противоречий. Такой продукт идеально связан как идеологическими его составляющими (история создания, его миссия, все использованные изображения, текстовые и печатные материалы используемые для его разработки и продвижения и прочее), так и техническими (back end, пользовательский интерфейс, элементы взаимодействия и дизайн, бизнес цвета, инструкции для работы службы поддержки клиентов, tone of voice of the company и много другого).

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

  • неудачный тайминг (изменилась коньюнктура на рынке, люди еще не осознали всю серьезность проблемы, решаемой продуктом и т.п.);
  • человеческий фактор (утечки внутри компании, уборщица, опрокинувшая ведро рядом с серверами в день релиза и т.п.);
  • слабые управленческие навыки руководства (основатели компании слишком поздно начали обсуждать распределение прибыли, что создало конфликты; чрезмерный нажим на команду разработчиков повлек массовые увольнения и сорвал переговоры об инвестировании и пр.)
  • банальное невезение, важность которого повально игнорируется как новичками, так и экспертами в бизнесе (Черные Лебеди Н. Нассима Талеба).

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

Часть 2. Пользовательский Опыт (UX). Что это?


Так как на данный момент понятие UX гораздо чаще относят к UI дизайну, моим оппонентом в обсуждении данного вопроса будет Джо Натоли. Джо ветеран-дизайнер с опытом работы более 30 лет, один из самых популярных в мире IT экспертов по UXD (User Experience Design), автор ряда книг, а также самых популярных видео-курсов по UX на Udemy. Натоли провел более тридцати лет консультируя по вопросам дизайна пользовательского опыта (UXD) компании из списка Fortune 100, 500 и правительственные организации. На своем вебсайте он называет себя User Experience Evangelist, значит, я могу ссылаться на его утверждения, высказанные публично в его книгах и видеоуроках.

В одном из своих уроков, где господин Натоли объясняет понятие User Experience, он ссылается на Питера Мерхольца:

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

Другой UXD эксперт Билл ДэРушэ (Старший продакт менеджер / Workflow Experience Lead at Zendesk). В обсуждении UXD говорит следующее: Для UXD даже не нужен экран. UXD это любое взаимодействие с любым продуктом, любым элементом, любой системой .

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

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

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

Итак, практически все UXD эксперты сходятся во мнении, что UX это понятие, выходящее широко за рамки интерфейсов. Их общее мнение сводится к тому, что UX это фактический опыт, получаемый пользователем при его интеракции с продуктом/компанией.

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

Часть 3. Архитектура Выбора


Понятие архитектура выбора популяризировалось после совместного труда Ричарда Талера и Касса Санстейна над Теорией Подталкивания. Вместе они написали книгу Подталкивание (англ. Nudge Theory), которая позволила множеству разных специалистов, ответственных за создание выбора для пользователей, взглянуть на свою работу под новым углом. Чтобы читатель понимал значимость вышеуказанных персон, приведу здесь их краткое описание:

Касс Санстейн со-автор теории подталкивания. После выхода книги Подталкивание президент Обама предложил Санстейну место в Отделе информации и регуляторной политики. Это дало исследователю широкие возможности внедрять идеи психологии и поведенческой экономики в работу правительственных учреждений. 10 сентября 2009 года Санстейн был назначен на пост главы OIRA, которое является частью Административно-бюджетного управления Администрации президента. OIRA осуществляет надзор за реализацией государственной политики и рассматривает проекты нормативных актов. Пост главы OIRA считается одним из наиболее влиятельных, учитывая его возможность влиять на тексты принимаемых законов. СМИ неофициально называют этот пост regulatory czar. OIRA Санстейн возглавлял до 21 августа 2012 года.

В августе 2013 года Санстейн вошел в состав комиссии по надзору за АНБ (англ. Review Group on Intelligence and Communications Technology). Кроме него в комиссии еще два бывших работника Белого Дома: крупейший специалист по контртерроризму и кибервойнам Ричард Алан Кларк и бывший заместитель директора ЦРУ.

Ричард Талер автор Теории Подталкивания, лауреат премии по экономике памяти Альфреда Нобеля 2017 года за вклад в область поведенческой экономики. При правительстве Великобритании было создано новое подразделение, чья цель применять принципы поведенческой науки к решению государственных задач. Официальное название подразделения Группа поведенческого инсайта, но чаще и в правительстве, и за его пределами ее называют Группа подталкивания. Талер является одним из советников этой группы.

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

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

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

image

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

Часть 4. Архитектор Выбора


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

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

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

В такой компании несложно понять, кто является архитектором выбора. Это тот, кто занимается организацией контекста, в котором человек (пользователь) принимает решения в приложении, либо просто Product Manager.

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

Часть 5. Когнитивные Искажения и Пользовательский Опыт


Итак, мы дошли до основного материала статьи.

Далее я выложу ряд известных науке когнитивных искажений, которые были научно выведенны и задокументированны. Отдельной ссылкой я выложил онлайн инструмент, который я назвал UX CORE. В нем вы сможете найти 105 когнитивных искажений с примерами их использования в менеджменте и в разработке приложений.

Для структурирования материала я использовал Кодекс когнитивных искажений, категоризированный и структурированный Бастером Бэнсоном в 2016м году (по ссылке выше дизайн Джона Манукяна III). Помимо новой формы презентации искажений, к каждому из них я добавил пример использования в разработке программного обеспечения, а в некоторых случаях- в управлении командой. Были учтены самые современные практики по управлению командами и компаниями (PMP, PMI ACP), а также разработке продукта.

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

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

Итак, как верно заметил Бастер Бенсон, суть изложенных когнитивных искажений в том, чтобы помочь нам решить 4 проблемы:

  • Работа с большим объемом данных. Когда много информации;
  • Расплывчатость, недостаточность данных. Когда не хватает смысла;
  • Недостаточно времени. Когда быстро реагируем;
  • Разные приоритеты по информации. Когда запоминаем и вспоминаем.

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

#1 Эвристика доступности [P]
Процесс, при котором человек оценивает частоту или вероятность события по легкости, с которой примеры или случаи приходят на ум, т.е. легче вспоминаются.

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

Другой пример: биткоины и разного рода ICO. Тема криптовалют так часто негативно форсировалась в СМИ, что в какой-то момент инвесторы просто решили избегать всего, что с этим связано, не вдаваясь в детали. Простые же пользователи поняли, что их ослепленность повышенной волатилностью этих рынков не привела ни к чему хорошему. Хайп по этой теме сошел на нет, а множество действительно качественных блокчейн-проектов столкнулись с серъезными сложностями в развитии из-за сильно искаженной репутации всего, что ассоциируется с блокчейном, биткоином и крипто в целом.

Последний пример это то, что я выбрал тему проектирования ПО и блокчейн технологий для описания эвристики доступности. Первая тема очевидна для меня в силу моей профессии (product manager), вторая же тема просто с легкостью пришла мне на ум, когда я задал себе вопрос: Какое направление в IT было полно хайпа, а потом быстро сошло на нет?.

#4 Эффект знакомства с объектом [P]
Психологический феномен выражения симпатии к объекту только на основании имеющегося знакомства с ним. Чем чаще человек видит кого-то, тем приятнее и привлекательнее ему кажется этот человек.

Важно подчеркнуть, что речь идет не только о людях, а об объектах вообще.
Предположим, у нас есть успешное приложение, которое мы хотим продвинуть в Испании. Если мы используем в наших цифровых промо-материалах описание нашего приложения в цветах Испанского флага (ненавязчиво, конечно), это даст ощущение знакомого у испаноязычных читателей. Другой пример мы размещаем очень блеклое, монохромное изображение Саграда Фамилия на фон белой страницы, на которой на испанском описываются преимущества нашего приложения. Если в текст добавить величественные, высокопарные слова вкупэ с фоновым изображением, они вполне дадут эффект знакомства и повысят вероятность конвертации потенциальных пользователей в фактических.

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

#6 Забывание без подсказок [P]
Является неспособностью вспомнить воспоминание из-за отсутствия стимулов или сигналов, которые присутствовали во время кодирования памяти.

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

Приведу простой пример на онлайн тотализаторе, где множество пользователей делают ставки. Очевидно, что средний пользователь как выигрывает, так и проигрывает. В интересах бизнеса правильно будет поддержать такого пользователя в тот сложный момент, когда он все проиграл. Так как в сознании игрока, который пережил серию поражений одни поражения, система может напомнить ему о целом ряде побед по некоему паттерну, оживив в нем всю ту серию хороших воспоминаний, которые он испытал. Это может быть сделано ненавязчиво, сообщением типа Уважаемый %username%, мы просто хотели напомнить вам о невероятно успешной серии ваших побед, продлившейся три дня подряд на играх %game_names%. Навязчиво? Возможно. Изменим сообщение на Вы попали в топ 20% наших игроков, благодаря вашей серии побед в %game_name%!. Уже не так навязчиво, это уже статистика . Конечно, делать это не этично с точки зрения морали. Поэтому букмекерские конторы и казино, работающие под лицензиями Malta Gaming Authority (MGA), Кюрасао и других, заранее соглашаются, что не будут подталкивать игроков к острым азартным действиям. В любом случае, приведенный пример наглядно иллюстрирует как можно извлечь пользу для бизнеса, зная о такой простой ошибке нашего мозга.

#11 Ошибка базового процента [P]
Это ошибка в мышлении, когда сталкиваясь с общей информацией о частоте некоторого события (базовый процент) и специфической информацией об этом событии, человек имеет склонность игнорировать первое и фокусироваться на втором. Например: люди верят показаниям теста, сигнализирующем о наличии редкой болезни, сразу, не принимая во внимание, что редкая болезнь, вообще говоря, редкая. Либо другой пример: страх террористов и полетов на самолете. Суть в том, что наш мозг склонен преувеличивать частный случай в ущерб статистике.

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

Вы собираетесь запустить процесс дефрагментации диска. С вероятностью 99% операция пройдет успешно.

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

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

Когда люди видят 15,800 хвалебных отзывов и 50 крайне негативных отзывов в перемешку с ними, они склонны считать продукт менее ценным, непропорционально тому факту, что негативных отзывов меньше 0.1%.

#13 Эффект юмора [P]
Смешные вещи легче запомнить, чем не юмористические, что может быть объяснено увеличенным временем когнитивной обработки, чтобы понять юмор, или эмоциональным возбуждением, вызванным юмором.

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

Здесь очень важно понять, что речь идет о запоминании юморных вещей, но не о позитивном отношении к ним. Так, если в процессе работы над важным действием (заполнение формы, сохранение данных), пользователь попадает на страницу ошибки (500 (Internal server error), 502 (Bad gateway), 503 (Service unavailable), 504 (Gateway timeout) ), то юмор типа Хо хо! Наши пираты работают над ошибкой и скоро все будет восстановлено! будет не к месту. В этом случае юмор будет замечен, запомнен, и, вероятнее всего, вызовет гнев пользователя так, что это событие запомнится лучше. Если подобное событие произойдет несколько раз за месяц, в соответствии с эвристикой доступности, в следующий раз подумав о качестве нашего продукта пользователь с высокой вероятностью даст негативную оценку. Даже если в 99% случаев приложение справлялось с задачей (ошибка базового процента).

Хорошим пользовательским опытом в данной ситуации будет считаться страница с ошибкой, где компания принимает вину на себя, объясняет суть ошибки и оповещает о том, что скоро все восстановится и страница сама обновится.

#21 Ошибка различения [P]
Это тенденция рассматривать два варианта как более отличительные при оценке их одновременно, чем при оценке их отдельно.

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

#36 Пренебрежение вероятностью [P]
Когнитивное искажение, согласно которому человек склонен к игнорированию малых вероятностей при принятии решений в условиях неопределенности. Небольшие риски обычно либо полностью игнорируются, либо сильно недооцениваются. Континуум между крайностями игнорируется. Как объясняет Рольф Добелли, причина, по которой это происходит, заключается в том, что мы не обладаем интуитивным пониманием риска и поэтому плохо различаем разные угрозы. По сути, чем более серьезна угроза и эмоциональнее тема (напр. Радиоактивность), тем менее обнадеживающим представляется снижение риска.

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

К примеру, зная что наши пользователи игнорируют вероятность полной потери данных, мы можем подтолкнуть их к созданию бэкапов сообщением вида Уважаемый %user_name%, в последний раз вы создавали бэкап ваших данных 571 день назад. Мы настоятельно рекомендуем создать бэкап чтобы избежать риска полной безвозвратной потери ваших данных.. Здесь мы ничего не говорим о вероятности потери. Она могла постоянно быть равной 0.1%, но написав сообщение с призывом к эмоциям (полной безвозвратной потери ваших данных) и конвертируя условные 19 месяцев в 571 день, мы с большей вероятностью добьемся действия пользователя (бэкап системы).



Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)


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

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

В завершении, я бы хотел рассказать об ошибке GI JOE задокументированной профессором Лори Сантос буквально несколько лет назад. Ошибка касается широко распространенного утверждения, что знать это уже пол дела, что, однако, не имеет научных оснований и является ложным утверждением. На самом деле, одного лишь знания недостаточно, чтобы изменить модель нашего поведения. Настоящие перемены невозможны без наших целенаправленных действий. Вы можете выучить наизусть все когнитивные искажения и механизм их работы, но, если вы не меняете модель своего поведения под полученными знаниями, ценность ваших знаний снижается. Более того, подобное знание не будет крепким, вам придется регулярно возвращаться к таблице и повторять написанное, чтобы не забыть. Если же вы не только поймете, но и предпримите определенные действия для усвоения материала, изменения вашего образа мыслей, вашей жизни, тогда самые лучшие решения по продукту, удивительным образом станут для вас крайне очевидными.

Часть 6. Наши дни


К сожалению, нехватка хороших продакт менеджеров является главным препятствием для создания качественных продуктов на рынке. Ситуация усложняется тем, что большинство компаний еще не до конца понимают разницу между Product Manager-ом и Product Ownerом, иногда, даже, прописывая их в вакансиях через /.

На данный момент, взглянув на рынок и на требования к продакт менеджерам лучших компаний, можно обнаружить описания и опросники, на которые ответит почти каждый, кто прошел PMI-ACP. По сути, отсутствие четкого понимания роли Product Manager-а приводит к тому, что на них вваливаются обязанности Project Managerов, Scrum Master-ов, и других.

Оговорюсь, что речь идет в первую очередь о странах СНГ, хотя на европейском рынке абсолютной ясности по поводу продакт менеджеров; как их найти, как интервьюировать, и чего от них ожидать тоже нет.

Полагаю, с США дела обстоят лучше, т.к. развитие продакт менеджмента идет именно оттуда.

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

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

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

Часть 7. Не только искажения


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

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

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

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

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

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

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

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

Без внимания к деталям, невозможно добиться высокого качества.

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

Часть 8. Эпилог


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

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

Попробую объяснить иначе. Вне зависимости от идеологической составляющей вашей жизни, вашего стиля и публичного образа, вы можете в любой момент записаться на курсы по SCRUM, изучить этот фреймворк, почитать о нескольких других, понять идеи Agile и устроиться работать проект менеджером в какую-то компанию. Вы также можете пройти пару онлайн курсов и подтянуть ваши знания по front-end и back-end программированию, понять принципы работы баз данных, и это займет у вас буквально месяц. Еще за месяц вы можете сами выучить HTML и CSS, поиграть с разметкой, собрать несколько макетов и понять общую идею работы Javascript.

По сути, вы можете месяца за три собрать достаточно знаний для понимания технической составляющей проекта, и этого более чем хватит для начинающего продакт менеджера. Для понимания трендов вы можете скачать самые последние приложения, пройти по списку самых популярных онлайн платформ, зарегистрироваться на producthunt, betalist, techcrunch и всегда быть в курсе происходящего. Новостной информационный пробел легко восполнить регулярно читая Google News и hackernoon.

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

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

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

Завершить статью я хочу провокационной мыслью.

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

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

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

Большое спасибо за проявленный интерес.

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

Я буду очень рад познакомиться с людьми со схожими интересами, поэтому, если вы изучаете когнитивные науки и/или их применение в разработке продуктов добавляйтесь ко мне в LinkedIn или Facebook.

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

Часть 9. Материал, качественно дополняющий эту статью


  • Даниел Канеман Думай медленно Решай быстро;
  • Николас Нассим Талеб Черный Лебедь;
  • Касс Санстейн и Ричард Талер Подталкивание;
  • Ричард Дэвидсон Как эмоции управляют мозгом;
  • Михай Чиксентмихайи Поток;
  • Джим Коллинз От хорошего к великому;
  • Jesse James Garrett The Elements of User Experience (2nd Edition);
  • William Lidwell Universal Principles of Design;
  • James Clear Atomic Habits;
  • Erin Meyer The Culture Map;
  • Joe Natoli UX Design Fundamentals Udemy Video;
  • Joe Natoli UX & Web Design Master Course: Strategy, Design, Development Udemy Video;

Эта статья была написана в период объявленного карантина из-за пандемии коронавируса (COVID-19) в Армении, г. Ереван. Я очень рад, что статья оказалась полезна многим людям, которые успели ознакомиться с разными частями написанного материала в период моей работы над ней.

Оригинал статьи
Английская версия

По любым вопросам и предложениям пишите, буду рад помочь: alexanyanwolf@gmail.com / www.linkedin.com/in/alexanyan / www.facebook.com/AlexanyanWolf
Подробнее..

LiveOps в играх

26.07.2020 18:18:25 | Автор: admin

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


На написание статьи меня вдохновил пост Кристин Кокс. Это не перевод статьи, но не могу не сослаться на некоторые мысли.


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


Игра как продукт


На первом этапе игра представляла собой программное обеспечение, записанное на физический носитель. Игрокам требовалось специальное оборудование, носитель с игрой, а также много часов, посвященных исключительно играм. Бизнес игр также был тесно связан с розничной торговлей, дистрибуцией, изданием и большими рекламными компаниями. Общение между игроками и разработчиками практически отсутствовало или сводилось к минимуму. Это время пришлось на мое детство. Я признаюсь, что минуты, проведенные в The Sims и No One Lives Forever, были для меня настоящим счастьем.


Игра как сервис


Со временем в связи с распространением высокоскоростного интернета стала зарождаться онлайн-культура, что привело к изменениям и в игровой индустрии.


Игра стала постоянным сервисом и стала ориентироваться на привлечение игроков и воронки продаж. На этом этапе получили широкое распространение социальные и мобильные игры. У разработчиков появилась возможность напрямую продавать игры своим игрокам. Кроме того, в связи с ростом социальных сетей общение между разработчиками и игроками стало более распространенным. Говоря про этот этап, нельзя не упомянуть онлайн-сервис цифрового распространения компьютерных игр Steam, выпущенный в 2003 году. Многие Игры как Сервис в некоторой степени используют LiveOps, но в большей степени этот подход характерен именно для этапа Игра как Сообщество.


Игра как сообщество или время LiveOps


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


Кроме того, игра начинает сегментировать игроков и каждому сегменту старается предложить определенный тип игры. Этого позволяет добиться подход LiveOps.


Кристин Кокс пишет:

Будущее это LiveOps

Почему так?
Какая магия скрывается под этим словом?


Если переводить дословно, Live Operations или действия в режиме реального времени подразумевает все улучшения, которые будут внесены в игру за время ее существования после стадии релиза. Это также означает, что в игру заложены механики, поддерживающие процесс постоянного взаимодействия и это происходит благодаря изменению контента, который становится доступным для игроков с течением времени (при наступлении определенного события в игре или наступления определенного времени). Контент закладывается в игру заранее и становится доступным без обновления всего продукта.


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


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


А также обеспечение баланса между издержками на производство контента и ожидаемой прибылью (это означает поиск способов сделать контент более повторяемым и дешевым для производства).


Цель LiveOps:


  • Улучшение финансовых показателей в игре
  • Удержание игроков

LiveOps это комплексный подход, который включает:


  • Внутриигровые события
  • Обновление контента
  • Постоянное улучшение продукта (аналитика, А/B тесты)
  • Поддержка пользователей и организация сообщества

Внутриигровые события


По масштабу распространения внутриигровые события можно разделить на:


  • Общие затрагивают всех игроков в игре (добавление новых глав, эпизодов, героев, скиллов, предметов)
  • Таргетированные затрагивают определенные сегменты игроков (чаще всего это акции к региональным праздникам, офферы и цены для разных регионов в зависимости от платежеспособности региона или активности игрока и др.)

По назначению:


  • Предложения и акции уникальные или обычные ресурсы можно приобрести за деньги (различные офферы, распродажи, скидки на праздники, серии из покупок). Эти события направлены на повышение KPI.
  • Игровые ивенты ограниченные по времени события, участие в которых имеет для игрока какую-то выгоду (например, получение пакета основных ресурсов за призовые места) или соревновательный характер. Это могут быть различные турниры, соревнования, миссии. Эти события направлены на удержание игроков и увеличение длительности сессии, а также на расход игровых ресурсов.


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


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


Игровой ивент -> Акция -> Игровой ивент -> Акция



Ивенты по возможности должны быть таргетированы. Это означает, что необходимо сегментировать игроков и каждому сегменту нужно предложить определенный тип игры. Сегментацию можно разделить на 2 типа: по контенту и по монетизации. Цель состоит в том, чтобы предоставить релевантный контент каждому сегменту в любой момент времени.


Система ивентов должна проектироваться до релиза.


Обновление контента


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



Постоянное улучшение продукта


A/B-тестирование и анализ данных важная часть LiveOps и условие непрерывного улучшения игрового процесса. Поскольку не всегда можно точно определить последствия тех или иных решений, гипотезы должны быть сформулированы и проверены. А A/B-тестирование должно проводиться непрерывно для оптимальной настройки внутриигровых параметров.


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


Анализ включает в себя: сбор данных (типы событий, которые мы будем фиксировать в игре, и в каком формате они передаются в систему аналитики), способ обработки, прогнозирование вероятных проблем. На основании полученных данных можно принимать решения об изменениях в проекте: выдвигать гипотезы по улучшению и влиянию на показатели и проводить A/B-тесты.


Поддержка пользователей и организация сообщества


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


К таким мероприятиям относятся:


  • конкурсы в группах в социальных сетях, подарки (как внутри игры, так и физические)
  • пуш-уведомления как локальные, так и глобальные (в идеале также должны учитывать сегмент подстраиваться под пользователя)
  • возможность поделиться с другом и преимущества от игры с другом виральность
  • почтовые рассылки
  • рекламные акции, распродажи, анонсы в группах в социальных сетях, чтобы подготовить игроков к предстоящему событию


Заключение


LiveOps подход в разработке игр бесценен. Чтобы успех игры исчислялся годами, нужно принимать решения, исходя из данных аналитики, постоянно проводить A/B тестирование, развивать длительные отношения со своими сообществами игроков, предоставляя им качественный контент и события в игре.
Каждая из этих областей важна для оперативной работы, но требует постоянной работы команды, конвейеров для управления и инструментов для сборки. И есть много инструментов, которые могут обеспечить основу работы в этих областях. Но разработка плана конкретных событий, обновлений, предложений, рекламных акций требует индивидуальных решений.

Подробнее..

Stol-p1 подставка для ноутбука и айпада в стиле Оригами

20.10.2020 06:12:58 | Автор: admin
image
stol-p1 проект Оригами подставки для работы на ноутбуке и таблетах, который я разрабатываю с ребятами последние 7 месяцев. Он имеет 5 разных позиции для удобной работы за ноутом.

В нём имеется:

  • Держатель для стакана

  • Беспроводная зарядка

  • Холдер для таблета и книжек

  • LED лампа

  • Анти соскальзывающая поверхность

  • Складная подставка


image

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

Проблема:
Я практически всё своё время провожу за ноутбуком или айпадом, и большинство времени сижу в одном положении что само по себе плохо для осанки и шеи. Когда сидишь за ноутом 10-12 часов в день, 6 дней в неделю, начинаешь ощущать реальный дискомфорт. И я начал искать решение этой проблемы, а решение является разнообразить ваше положение за ноутбуком и айпадом, вы можете стоять или сидеть под другим углом, наклониться или лежать на кресле. Но блин это ноутбук, как бы я не старался поставить ноутбук в другое положение это либо неудобно либо ноутбук соскальзывает с твоих ног. И так я начал искать подставку с разными углами чтобы ты сидел и чилил за работой, вообще не парясь о том как тебе удобнее. В поисках аналогов на amazon, ebay, taobao, alibaba и kickstarter, всё что я нашел было громадное и предлагало всего 2 положения подставки, к тому же оно было наполовину из металла. Еще я нашёл регулируемый стол, который поднимается и опускается при нажатии кнопки и вся это лепота стояла больше $250 долларов, и я про себя сказал: чуваки вы гоните. Самое интересное что кроме космических цен они ничего из себя не представляли кроме просто стола который поднимается и опускается.

image

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

image

Proof of concept:
Как мы знаем что спрашивать друзей о том что они думают про твой продукт дело гиблое, потому что мало кто ответит, ты крутой и это самое лучшее что они видели либо ты свихнулся и что это такое ))) Поэтому я решил спросить у Reddit, закинул рендеры и сказал что: ребята это то что над чем я работаю, к удивлению меня поразила обратная связь:

image

Это был мой самый счастливый день, то чувство когда ты над чем то работал понравилось какому то рандомнуму чуваку, Reddit топ! И кстати после этого мне написал редактор IMore.сом и сделал про нас статью.

image

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

stol-p1 имеет 5 разных позиции для работы на ноутбуке и таблете:

image

Для того чтобы посмотреть больше информации и поддержать мой проект переходите сюда

Немного о себе:
Меня зовут Али, мне 23 года. Я обожаю заниматься разработкой продуктов и созданием концептов. Еще я гик который интересуется всеми новыми технологиями и хардвером. Помимо этого я люблю кофе и музыку, и аниме.

Stol-P1 это проект который является для меня вызовом, чтобы сделать что то крутое и доказать себе что я чего то стою. Мы собираемся запускаться на платформе Kickstarter, сейчас работа идёт полным ходом. Если вам понравился проект thumbs up!)image
Подробнее..

Иван Дёмшин, Head of Engineering в Miro, о продуктовой разработке, смене технологий и эволюции процессов в компании

27.07.2020 14:05:23 | Автор: admin
Это конспект интервью сИваном Дёмшиным, Head ofEngineering вMiro, про историю продукта икомпании, структуру продуктовой разработки, смену технологий нафронте ибэке, эволюцию тестирования, процесс найма иразвития инженеров.



Полную двухчасовую версию можно посмотреть на Ютуб-канале Хекслет.

Оглавление:
История продукта и компании
RealtimeBoard Miro

Как устроена продуктовая разработка
Рабочее окружение
Стек, монолит
Релизы

Выбор технологий и их эволюция
Flash Canvas
Angular React
Сервера и базы данных
Java
Эволюция тестирования
Рост нагрузки и рефакторинг

Процессы в разработке
Техническое решение и code review
Performance Review
Как устроен найм инженеров
Джуниор-позиции

История продукта и компании


Miro платформа для визуальной коллаборации ввиде бесконечной онлайн-доски (online collaborative whiteboard platform). Ключевое слово коллаборация, совместная работа, соответственно, ключевые метрики, покоторым мымеряем свою эффективность, количество коллаборативных досок иколлаборативных сессий, которые случаются впродукте.

Мыназываем себя платформой, потому что уже вышли зарамки просто продукта: унас есть открытый API, marketplace, кабинет разработчика, поэтому любая компания может расширять продукт под себя.

Наша целевая аудитория продуктовые команды, которые работают изодного или разных офисов. Чаще всего Miro используют для проведение воркшопов, стратегических сессий, мозговых штурмов, agile-практик (планинги, ретроспективы).



Яруковожу разработкой вMiro. Явырос вПерми ипродолжаю здесь жить. Компания исторически появилась вПерми, отсюда родом наши основатели. Большая часть нашего отдела разработки находится сейчас здесь, ав2019 году мызапустили иактивно развиваем второй инженерный офис вАмстердаме.

Раньше яработал взаказной разработке: начинал спостроения аналитических хранилищ данных вкачестве разработчика, потом проектировалих, азатем руководил большими проектами. В2016 году присоединился кMiro, когда вкомпании работало 30человек. Стех пор мысильно выросли: сейчас унас пять офисов, 400человек, изних 140инженеров.

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

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

Примерно до2016 года все сотрудники работали вПерми. Пользователи сами платили заподписку, нокнам уже приходили компании ссотнями итысячами сотрудников, которые хотели заключить договора иполучать инвойсы. Для работы стакими компаниями нам нужны были продажники, поэтому мынаняли Head ofSales для создания sales-команды вАмерике.

Затем появился первый сотрудник Customer Success команды, вАмстердаме, и также начал строить свою команду.

Самой большой функцией у нас была и остаётся продуктовая разработка, которая сегодня составляет примерно половину компании.

Смена названия


Оребрендинг мызадумывались ещё в2015году, носделали его витоге в2018. Наше прежнее название RealtimeBoard длинное исложное. Внём часто допускали ошибки, сокращали доRTB или, что самое плохое, вообще его забывали. Кроме того, оно неэмоциональное, заним нет истории. Мыхотели сделать новое название коротким, ёмким, говорящим, запоминающимся.

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



Кновому названию быстро привыкли имы, ипользователи. Мыбыстро растём, поэтому несколько миллионов новых пользователей даже незнают отом, что мыназывались иначе. Приятным бонусом ребрендинга стали награды от European Design Awards за айдентику, которую мы разработали в рамках ребрендинга совместно с европейским агентством Vruchtvlees.

Как устроена продуктовая разработка в Miro


Вся команда продуктовой разработки из170 человек находится вПерми иАмстердаме: инженеры, продакты, продуктовые дизайнеры, скрам-мастера.

Мне раньше было сложно представить, что так много человек может работать над одним продуктом. Носегодня язнаю, что вUber, Slack иAtlassian над одним продуктом работают тысячи инженеров. Мыпродолжаем расти ипонимаем, что нас сейчас явно недостаточно, иследующая целевая точка вмоей голове 300 человек вразработке, апотом мыпродолжим расти дальше. Это непросто число изголовы. Унас есть стратегическое планирование, мыпонимаем, где мыхотим быть через два года, через пять лет ичто нам для этого нужно сделать.

Сточки зрения оргструктуры есть гильдии: фронтенд, бэкенд, QAитак далее. Для работы над проектами они объединяются вкросс-функциональные команды.

Команды распределяются по ключевым направлениям:
  • Горизонтальный продукт основная функциональность продукта, которую видят все пользователи: стикеры, текст, шейпы, фреймы и т.д.
  • Системное направление отвечает за core-платформу и инфраструктуру.
  • Growth всё про рост числа пользователей: активация, вовлечение, возврат, монетизация.
  • Enterprise доработка продукта для крупных компаний, у которых много специфических требований. Во-первых, тысячи и десятки тысяч их сотрудников пользуются Miro, а это значит что для их аккаунтов нужны разные права доступа и удобные инструменты управления ими. Во-вторых, есть международные стандарты качества и безопасности для SaaS-продуктов, которым мы должны соответствовать. Мы не делаем кастомизацию под конкретного пользователя, а выбираем, что необходимо сделать в соответствии со стандартами и требованиями большинства крупных пользователей.
  • Платформа мы запустили открытую бету в 2019 году. Уже есть открытый API, кабинет разработчика, marketplace, всё это нужно поддерживать и развивать, давать больше возможностей внешним разработчикам, которые хотят создавать для себя и других дополнительную ценность на базе нашего продукта.
  • Основные юзкейсы продукта новое направление, которое мы активно масштабируем. Пользователи приходят в продукт, чтобы решить конкретную задачу, но большинство способов, с помощью которых они её решают в Miro, можно объединить в несколько групп: Meetings & Workshops, Ideation & Brainstorming, Research & Design, Agile Workflows, Strategy & Planning, Mapping & Diagramming.

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


Рабочее окружение


Основной софт инженеров: IntelliJ Idea, Jira, Slack, Zoom, Miro, Confluence. Большинство сотрудников работают на MacBook, большинство инженеров на MacBook Pro, некоторым покупаем более мощные машины при необходимости.

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

Стек, монолит


Фронт у нас на Typescript, React и AngularJS. Бэкенд Java. Базы данных Redis, Postgres, для кластерного взаимодействия Hazelcast и ActiveMQ. Хостимся в Amazon, в одном дата-центре. В продакшене порядка 400 серверов. Application servers, которые обрабатывают доски пользователей, бывает до 100, всё автоматически оркестрируется.

Используем стек от Atlassian: Jira, Bitbucket, Bamboo и собственные скрипты, которые прикручены к Bamboo и позволяют всё раскатывать на сервера. Пока все релизы один большой релиз на фронт и один большой на бэк. Сейчас думаем, как сделать, чтобы этих релизов было больше.

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

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

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

Релизы


Сама сборка занимает 15-20 минут, включая выполнение юнит-тестов. End-to-end тесты могут выполняться до 40 минут. Весь процесс занимает полтора-два часа, чтобы довести мастер до релиза. Это долго, нам ещё есть над чем здесь поработать.

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

Выбор технологий и их эволюция


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

Маленькие компании, которые только начинают иищут product market fit, бегут быстро, быстро собирают MVP ибыстро ихвыбрасывают. Для них важнее найти рынок, анесоздать сложные технические решения. Нокогда рынок найден технические решения выходят напервый план, потому что позволяют создать запас прочности для роста ибезопасности.

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

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

Больших смен технологий у нас было несколько, на фронте и на бэкенде. Приведу несколько примеров.

Flash Canvas


До 2015 года весь фронт был на Flash, потом Flash начал умирать и мы перешли на HTML и Canvas. Смена стека хорошо сказалась на производительности и удобстве продукта, привела к заметному росту аудитории. Переход занял примерно год, это был большой и сложный проект. Статья про детали этого проекта.

Сейчас мы рассматриваем переход на WebGL, но пока нет чётких доказательств, что оно того стоит.

Angular React


Последние пару лет мы постепенно переходим с Angular JS на React. Основные причины:
  • React позволяет лучше типизировать, а в дальнейшем это позволяет лучше рефакторить код и гарантирует, что ничего не отвалится.
  • React даёт больше возможностей для оптимизации приложений. Когда мы внедряли ленивую загрузку и разбивали тяжёлый монолит на фронте, Angular вставлял палки в колёса. Нам пришлось найти обходные пути для оптимизации загрузки с помощью Angular, а всё новое уже пишем на React, его же используем при глоабльном рефакторинге.
  • React хорош с точки зрения найма, так как найти разработчиков на Angular JS сильно сложнее.


Сервера и базы данных


В 2015 году мы перехали с арендуемых серверов Hetzner на хостинг в Amazon. Больше года идёт проект по переносу основной базы данных с Redis на PostgreSQL. У нас есть статьи об этом: проектное управление миграцией данных, создание отказоустойчивого кластера.

image

Наш кейс осложняется тем, что с Key Value хранилища мы переезжаем на SQL базу. Рефакторинга много. Важно делать всё так, чтобы приложение не останавливалось. Это как поменять колесо у едущей машины, потому что база данных фундамент, на котором стоит приложение. Непосредственно для контента досок мы реально делали всё без maintenance. Да, процесс перехода затянулся по времени, зато пользователи ничего не заметили, продукт работал.

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

Java


Java очень сильно помогает нам в плане производительности и ресурсов разработчиков, которые мы можем найти. Знаю, что Booking переходит с Pearl на Java, потому что они устали переучивать своих инженеров.

К нам приходят инженеры с С++ и DotNet и нормально адаптируются. Если ты опытный разработчик, пробовал разные технологии и знаешь, как строится система, то погрузиться в новый язык уже не так сложно. Главное, чтобы инженер придумывал правильные решения, а в язык закопаться он точно сможет, я верю в это.

Эволюция тестирования


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

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

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

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

image

Подробное описание всех этапов нашего QA-процесса.

Рост нагрузки и рефакторинг


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

Запас прочности понадобился не только на бэкенде, но и на фронтэнде и клиенте, так как в продукте возросло количество синхронных работ. Если раньше на одной доске могло работать одновременно 20 человек, то сейчас это 300 человек. Наши фронтэнд-инженеры много занималась и продолжают заниматься производительностью загрузки. Например, мы делаем так, чтобы dashboard со списком досок грузился отдельно от всего остального и делал это быстрее, чем раньше. А если пользователь переходит прямо на доску, не через dashboard, то должен грузиться код и контент доски, без всего остального.

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

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

Процессы в разработке


Техническое решение и code review


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

На базе продуктового решения формируется техническое решение, которое отвечает на вопрос Как мы будем это делать?. Его разрабатывают инженеры команды, которая будет реализовывать функционал. Техническое решение проходит несколько процессов review:
  • с командами, с которыми есть пересечения в функциональности;
  • security review по компонентам, которые мы будем затрагивать в архитектуре;
  • как мы будем деплоить результат.

После начинается непосредственно разработка. Важно, чтобы code review не тормозил разработку, поэтому недавно вместо обязательного получения двух code review мы внедрили персональную ответственность на уровне компонентов. Теперь на уровне кода мы всегда знаем, кто отвечает за этот кусок, что сильно облегчает коммуникацию при разработке. Соответственно, как только ты внёс изменения в код, автоматически назначается reviewer, владелец этого кода. Если код твой, то review делает участник твоей команды.

Зачем мы ввели персональную ответственность? Раньше было несколько человек, старичков, которые знали, как работает весь продукт и могли проверить любой кусок кода. Но по мере роста продукта возможностей этих людей стало не хватать, они уже не могли знать про всё, что происходит в разработке. Процесс code review начал тормозить остальные процесса, было непонятно, к кому идти на code review. Тогда мы начали нести всю необходимую компетенцию по конкретным блокам продукта в команду, которая работает над ними. Так команды смогли проводить code review самостоятельно. В своё время это помогло нам сильно ускориться.

Performance Review


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

На основе этой картины тимлид с каждым членом команды формирует персональные планы развития: сотрудник сам говорит, куда хочет развиваться, а Performance Review подсвечивает его сильные стороны и и пробелы.

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



С тимлидами происходит всё точно также, дополнительно для них есть внешнее обучение и внешний менторинг.

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

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

Как устроен найм инженеров


У нас цепочка найма стандартная для России и для Европы. В России воронка найма уже, поэтому первое интервью может проводить не рекрутёр, а сразу hiring manager (обычно это тимлид команды, в которую мы нанимаем человека) после того, как рекрутер обработал резюме и отсеял неподходящие под требования вакансии.

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

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

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

После всех собеседований мы собираем с участников обратную связь, выставляем оффер.

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

Джуниор-позиции


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

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

Высокие требования при найме


Ходит легенда, что к нам очень сложно устроиться на работу из-за очень высоких требований. Это не совсем так.

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

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

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

Исследование про исследователей что мы узнали

01.02.2021 16:08:09 | Автор: admin

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


Нам было интересно увидеть картину порынку исравнить еёстем, как всё выглядит вАвито.



Формальности поопросу


Мысфокусировались наопыте исследователей UX, продуктовых или маркетинговых исервис-дизайнеров.


Ответы собирали с23.12.20 по15.01.2021. Всего анкету заполнил 251человек. Кроме двух вопросов оместе работы идолжности, остальные были необязательными, поэтому наних мыполучили меньше ответов.


Демографический портрет респондентов


Средний возраст респондентов 30лет, общий разброс от20до44лет. Большинство (82%) живут вМоскве, 7% вСанкт-Петербурге, 4% вЕкатеринбурге.



Большинство респондентов занимаются исследованиями больше 5лет, либо от1года до3лет.



Восновном наши респонденты работают втекущей компании меньше года (43%), треть отгода до2лет.



Погрейдам мыполучили большую часть ответов отведущих или старших (40%) иmiddle-исследователей (32%).


Для тех, кто любит сам смотреть наданные, полный файл исследования доступен поссылке нагугл.документ.

Вовсех следующих смысловых блоках уреспондентов была возможность выбирать несколько вариантов ответа.


Что мыузнали окомпаниях, вкоторых работают исследователи?


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


Большинство респондентов (41%) работает вкрупных компаниях, где больше 2000сотрудников.


Количество исследователей вкомпании показало большой разброс. Всреднем вкомпаниях по9исследователей (медиана 5, мода 3). Разброс мыувидели ивколичестве исследований вмесяц, которое приходится наодного исследователя (медиана 3имода 2, почти треть респондентов).


Для сравнения, вАвито сейчас работают 5исследователей иболее 40продакт-менеджеров. Мыхотим уменьшить нагрузку накаждого исследователя ирасширяем команду, поэтому ищем ещё ребят. Ссылка на вакансию вконце статьи.


Большинство исследователей (55%) работают более чем спятью заказчиками. Натекущий момент вАвито примерно такаяже ситуация: накаждого исследователя приходится от4до8команд внутри продуктового кластера. Мыпоняли, что такое соотношение непозволяет исследователю уделять достаточное внимание ипродукту, иработе над задачами, поэтому пришли крешению, что наодного исследователя должно быть ровно 4команды.


Общий контекст работы исследователей вкомпаниях


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


Формат работы исследователей


Больше половины респондентов (57%) работают вформате один исследователь напродуктовое направление инесколько команд. Текущая модель UXlab вАвито работает так же. У45% принят формат внутреннего агентства, когда самые разные команды привлекают исследователей напроекты.36% работают внутри одного продукта.


Кто исследует?


Ожидаемо, что вовсех компаниях качественные исследования проводят, собственно, исследователи. Ноу36% респондентов этим занимаются также продакт-менеджеры, ау28% дизайнеры.18% привлекают агентства или фрилансеров.


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


Кто проводит количественный этап?


74% респондентов отметили, что количественные исследования проводят UX-исследователи, навтором месте маркетинговые исследователи (62%), аучетверти респондентов этим занимаются аналитики.



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


Также для локальных задач UX-исследователи подключают команду колл-центра. Это помогает запустить опрос на100 человек иполучить результаты запару дней.


Как замеряют реакцию пользователей наизменения впродукте?


Напервом месте, конечноже, аналитика (78%), следом идут обращения вподдержку иопросы (по70%).



Каких навыков нехватает коллегам издругих функций?


Больше половины респондентов считают, что уихколлег издругих функций страдают навыки формулирования гипотез (53%) идоведение изменений допродукта поитогам исследований (52%). Чуть отстаёт отних, нотакже входит втоп-3, постановка задачи наисследование (49%).



Что делают кроме исследований?


Помимо непосредственно исследований, коллеги внедряют новые инструменты (63%), распространяют знания опользователях внутри компании (63%), оптимизируют процессы (60%) иобучают команды исследованиям (53%).



Как учат коллег исследованиям?


Восновном входе проектов (86%). У45% есть внутренний курс пообучению исследованиям, а15% отправляют коллег учиться навнешних ресурсах.


Награфике ниже можно увидеть, чему именно исследователи обучают коллег:



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


Поэтому, если увас есть курс или блок обучения потеме качественных исследований, ивыготовы провести его для команд Авито завознаграждение, напишите Михаилу: mmpravdin@avito.ru. Обсудим формат иусловия сотрудничества.


Как оценивается качество работы исследователей?


Лидирующий способ оценки качества работы исследователей отзывы коллег (69%), анаименее популярный количество исследований (20%). Примерно равнозначны улучшение процессов иинструментов (45%), влияние напродукт (43%) ипрогресс поличному плану развития (41%).



Как исследователи делятся знаниями смиром?


Восновном, либо никак, либо обучая коллег (по42%). Некоторые выступают наконференциях (17%), пишут статьи (14%), преподают начужих курсах (13%) или вуниверситете (11%).



Проблемы наработе


Явного лидера всписке трудностей нет, всех беспокоит разное, ноунаёмных сотрудников первое место занимает перегрузка задачами, ауфрилансеров нечёткость целей. Интересно, что уисследователей относительно редко встречается проблема карьерного роста иихредко неустраивает зарплата (15% и19% соответственно).



Как исследователи работают над проектами


Ещё мызадавали вопросы осамих исследованиях: методах ихпроведения, общении среспондентами, поиске дополнительных данных иоформлении результатов работы.


Методы исследований


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


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



Накаком этапе развития продукта чаще всего проводятся исследования?


Топ-3 исследование целевой аудитории, полностью работающий продукт истадия макетов.



Скем взаимодействуют исследователи?


Сотрудники, скоторыми чаще всего контактирует исследователь, это продакт-менеджеры (84%), дизайнеры (68%), другие исследователи (59%), аналитики (50%) исотрудники отдела маркетинга (48%). Если говорить про исследователей вагентствах, тоихтоп такойже, нонапервом месте другие исследователи, анеменеджеры.


Про опыт фасилитации


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



Общение среспондентами


Сейчас среди способов связи среспондентами безоговорочное лидерство забрал Zoom (94%). Треть респондентов также используют Skype (33%), ачетверть умудряется встречаться очно.


Модерация исследований инаблюдатели


Более половины респондентов (67%) сами модерируют поля иоколо трети ответили, что вэтом участвует команда (28%). При этом у40% исследователей вполях наблюдатели бывают очень часто, у32% присутствуют пару раз. Варианты никогда инакаждом интервью/тесте набрали по13% ответов.


Поиск респондентов


Кто ищет. Более половины исследователей ищут респондентов силами внешних рекрутёров, половина пользуется панелями/базами/сообществами ипочти половина ищут сами.37% отметили, что поиском респондентов для них занимаются другие сотрудники компании. При этом самостоятельно ищут чаще винхаусе, нежели вагентстве (35% против 26%).


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



Где ищут. Лидирующий источник собственные базы данных (66%), примерно равнозначны опросы или уведомления впродукте (48%) иемейл-рассылка (45%). Платными панелями иличными контактами пользуются около трети респондентов (32% и27% соответственно).



Дополнительные данные напроектах


Больше половины респондентов впроцессе работы над проектом обращаются каналитике (72%), смотрят информацию оконкурентах (67%) ичитают обращения вподдержку (59%).


Менее популярны чтение отзывов винтернете/магазинах приложений (45%), общение сменеджерами попродажам (42%) изнакомство срезультатами опросников NPS/CSI (41%).


При этом, аналитику чаще смотрят несами (самостоятельно смотрят23% респондентов), аставят задачу аналитику (больше половины опрошенных, 54%).




Оформление результатов


Лидируют старые добрые презентации, ноиMiro неотстаёт. Эти два способа выбирают половина респондентов.



Чем заканчиваются проекты для исследователя?


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



Сохранение иобмен знаниями оклиентах


Восновном есть база отчётов (75%) иорганизация встреч (51%), накоторых командам рассказывают оклиентах. Треть респондентов (32%) ведут корпоративный канал или блог иотносительно редко исследователи разрезают отчёт наотдельные инсайты (19%).



Когда другим сотрудникам нужна информация изисследований, они предпочитают обратиться кисследователю занужными ссылками (84%). 58% респондентов говорят, что коллеги сами ищут нужные отчёты вбазе и44% исследователей помогают командам сосбором нужной информации изразных отчётов.



Также мыпросили понекоторым вопросам дать оценку пошкале от1до10


Так мы узнали, что:


  • На7исследователи оценили уровень внедрения исследований впроцесс создания продуктов.
  • Втоже время, качество использования результатов коллеги оценили чуть ниже на6,7.
  • Влияние исследователей напродукты оценили всреднем на6,9.
  • Рекомендовать свою компанию как отличное место работы всреднем готовы на7,4 (мода 10).

А блиц-опрос вконце показал, что:


  • Большинство исследователей хотелибы работать впарт-тайм режиме (53% ответивших). Около25% вообще нехотелибы возвращаться вофис.


  • Топ-3 любимых источника знаний обисследованиях Medium (23%), телеграм-канал UXHorn (19%) исайт Nielsen Norman Group (17%).


  • Любимая одежда наудалёнке это футболка ипижама.


  • Среди любимых инструментов для работы лидирует Miro его назвали33% респондентов. МывАвито солидарны сбольшинством итакже делаем отчёты вMiro.


  • Топ-5компаний, вкоторых хотелибы работать исследователи. Это Яндекс (46%), Mail.ru Group (31%), Miro (31%), Авито (30%), Озон (23%).

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



  • Топ-3навыка, важных для исследователя эмпатия (22%), аналитическое, критическое мышление, здравый смысл (19%) игибкость, любознательность (15%).


  • Среди советов куда пойти учиться лидируют рекомендации найти стажировку/работу или реальный проект (36%), НИУ-ВШЭ (34%) истать психологом/социологом влюбом вузе (19%).


  • Большинство UX-исследователей хотят научиться работе сданными. Изтоп-5навыков, которые они хотелибы приобрести, 4относятся кработе сколичественными данными. Это анализ данных (15%), количественные исследования (12%), статистика (9%) иPython/R/SQL (8%). Также втоп-5 попало желание научиться проектированию интерфейсов (9%).




Про деньги


Мынеобошли стороной ивопрос сколько тызарабатываешь. Вот что получилось:



Сайд-проекты: даили нет?


Тех, кто работает вштате, мыспрашивали, берутли они сторонние проекты наисследования всвободное отработы время. Оказалось, что большинство UX-исследователей неберут сторонние проекты (38%). Еще13% готовы только консультировать, нонеделать проекты руками. Оставшиеся48% готовы временно поработать навнешних проектах, но18% неуспевает совмещать ихсосновной работой, а13% ненаходят таких проектов изадач.



Эти данные совпадают снашими результатами опроса впроекте облачные исследователи. Там мыузнали, что70% исследователей сейчас имеют постоянную занятость, нохотят иготовы попробовать себя навнешних проектах. Напомним, что для таких исследователей мысделали сообщество, где публикуем проекты отразных компаний: Яндекс, Mail.ru, Авито, Сбер, Joom ипр. Если выпопали вгруппу хочу, ждём вас внашем сообществе.


Минутка благодарностей


Спасибо Тане Чернявской запрограммирование опроса ианализ данных, Мише Правдину заидею иподготовку вопросов, атакже всем кто помогал сфинальной анкетой иеераспространением: всей команде UXlab Авито, Даше Хлоповой, Алине Ермаковой, Наташе Спрогис, Диме Соловьеву, Анне Кон, Максиму Козлову иМише Хананашвили.


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


Ссылки для исследователей


  1. Подробнее посмотреть результаты исследования.
  2. Присоединиться к сообществу облачных исследователей.
  3. Стать частью исследовательской команды Авито.
Подробнее..

Fatal Fight How weve got 5 million organic installs?

12.10.2020 14:18:52 | Автор: admin
Fatal Fight Android game

The story of Fatal Fight started in 2015. The time when going global and having 5 million downloads on Google Play Store seemed to be a dream of every game developer.

In this article, I will talk about the way we converted the dream into our actual reality. To make it super understandable, find a guide below where I will cover all the stages of development of Fatal Fight and even more.


Research


The idea of Fatal Fight hasn't just come from nowhere. Before understanding what game to develop, we needed to research what are the current gaps in the mobile games market. And, to come to this point, we took several steps.

First, we analyzed what are the most searchable mobile games in the Google Play Store. It turned out, the top 3 mobile games that users were looking for were the following:

  • Puzzle Games
  • Car Games
  • Fighting Games

Here we narrowed down our research. We were playing most downloaded games from each category to figure out if those games meet users needs while trying to answer what kind of challenges they have with those games.

As a result, Puzzle and Car Games had a wide range of mobile games with pretty nice UI/UX design and other characteristics. However, during the testing of the fighting games, the picture was quite different.

We were surprised by the fact that we could not find any proper games with satisfactory features. And I believe, not only we but also the dozens of users who were craving for favorable experience while playing a fighting game.

While asking ourselves the question Why? we found out that the main reason was the gameplay. The interaction between users and the games was complex. It was not comfortable to manage punching, kicking, jumping and other possible moves separately or even all at once on a smartphone.

Well, all of these for us was a subtle reference to a glaring fact. Fighting Games was not meeting the needs of existing users in the mobile games market.

Moreover, according to Google Play Store search rankings the keyword addictive games was one of the top ones. It showed us that users want something that will excite them to play the game on an everyday basis. This information was an added value to the conclusion that we came up with by that time:
We need to create an enjoyable fighting game with easy-to-use gameplay that will retain users

We wanted to come up with the gameplay that would not be complex for users in the first place. Once we give ourselves a question What if we will duplicate the gameplay of a PC fighting game?. This question seemed controversial, but it was raised because we explored the One Finger Death Punch PC game.

This fighting game had simple gameplay. You could literally manage the game only by clicking to the right and left sides of the mouse. This type of gameplay was an absolute match to what we were envisioning in our mobile fighting game. As a result, we took it as a good case practice and added Right and Left taps on mobile as an alternative to the same thing on the mouse.

Though we were grateful for the gameplay we could apply for our game, there was nothing else to take as a good case practice from this game. Even the name of the game was screaming I am the name of the game that no one ever will remember. We got for ourselves that probably their marketing strategy was not set up.

We created the prototype of the game to be sure that the gameplay we created was actually fit users needs. You can see in the picture that I inserted below that graphics were not the main thing we wanted to test there, the main focus of ours was to understand either the interaction between users and the game itself is comfortably managed.
"image

Winning the Google Play Store Optimization


Naming is another important point to take into account while developing a mobile game. It needs to be easy to remember and tailored to Play Store Optimization. The reason why we named our game Fatal Fight was the popular game Mortal Kombat. Yes, the game that won the admiration of billions was an inspiration for us in many ways.

Back then (in 2015 for those, who might have forgotten) there was no mobile version of Mortal Kombat. However, again the keyword Mortal Kombat had high rankings in Google Play. This means a lot of people were searching for this game on mobile but could not find it.

The truth is: If SEO (or Play Store Optimization) cannot find the exact keyword it always looks for synonyms.

Based on that, we decided to use synonyms for the words Mortal and Combat and combine them. And eventually Fatal Fight naming was created.

It meant to us that the audience that was looking for Mortal Kombat would find the Fatal Fight in the first pages on Google Play Store. It was a huge thing that we explored. Felt like a big responsibility at some point, we did not want to disappoint the Mortal Combat lovers, but to surprise them with a universal mobile fighting game in all senses.

Another thing that was inspired by Mortal Combat was the graphics. We were encouraged by some heroes such as Lui Kang. Raiden, Kung Lao, etc. in our game as well. It was one of the ways we could meet the expectations of Mortal Kombat lovers who were actively searching for this game online in the mobile version.


Once finished with all that, we had one aim We want to go global.

Soft-launch


Before opening up to the whole world, we made a soft-launch. Soft-launch is testing your product in a market that you are not really interested in. The reason is building up a feedback loop where you get the reviews from the users while developing the product according to the users needs.

Another thing that needs to be tracked during this period is the following key metrics in the Play Store:

  • LTV Lifetime Value
  • ARPU Average Revenue Per User
  • ARPPU Average Revenue Per Paying User


LTV metrics is the one that evaluates the average revenue that the user brings throughout its lifespan. Returning users to your app (in other words those who do not delete games right after the first try, but in long-term perspective consistently being involved with the game) are in the interests of the Play Store. Active users who constantly use the app bring the revenue due to the advertisement featuring in the apps through AdMob (which is the product of Google too). This is where the increment of ARPU metrics happen. By all means in the same way it also influences the AVPPU metrics. While tracking these metrics, we could evaluate whether we are developing the game in the right direction. The better metrics, the higher probability that your app will appear on the first page of Google Play Store.

We launched the game in Azerbaijan where we aimed to get as much feedback as possible. This was the way we wanted to fix all the bugs that they could face and be better prepared for the market that we consider as a target one. As a result, we fixed all major bugs in the app and got a 4.8 mark in the Play Store.

The soft-launch stage could finish there, but no, it did not. We entered another alternative market Russia. The different cultures, possible different habits of the users, and other factors made us understand that we need to try soft-launch in a new country. Another reason behind this was the scale. In Russia in 2015, the number of smartphone users was around 51.3 million people. We considered this market as a good platform where we could test our app.

In a few weeks, after launching the game in the new market, we started to receive negative reviews while losing the traffic. All of them was regarding one thing:

Most of the Russian users did not have a Facebook account where they needed to invite their friends or were not willing to pay $1 (one of these was required to proceed to pass to the next stage once they reached the 10th stage).

It made us understand that we need to come up with something universal in this stage of the game. We replaced Facebook invitations to gain 30 starts during the first 10 stages and be able to pass to the next stages once reached the 10th one kind of solution.

As a result of all these procedures with soft-launching, we got pretty high metrics in the Play Store that impacted our Play Store Optimization. We appeared on the first page of the Play Store.

Google Play Store is giving you a rate based on the countries that you already launched the app before. If you soft-launched the mobile app in specific markets first and got good marks from the users it equals the fact that when you will launch the game for the global market it will already have high Google Play Store rates. That was something that was supporting our vision.

Wise Choice of Operating System


You might notice that so far in the article I was mentioning everything about Android and its Play Store. And that was not an accident.

Usually, developers first launch mobile apps on IOS OS. The argument behind it is that the majority of people are IOS users or the purchasing power of this particular segment is higher rather than the one that Android users have. We questioned this understanding because for us it seemed like a myth.

We compared the metrics Average Revenue Per Paying User and Average Revenue Per User
Besides. For both operating systems it was the same amount. In our case, the weight of Fatal Fight was heavy and would only work on flagship smartphones that anyways cost a lot.

Besides that, we had several other reasons why we consciously choose Android over IOS:

Market Share. Sensor Tower reports that the Google Play Store pulled in approximately 75.7 billion first-time apps installed worldwide in 2018. Comparatively, the App Store only drove 29.6 billion.

Fast process. The updates on Android are being approved faster than on IOS. When giving our first build to IOS it took the game 3 months to be added to the App Store.

The difference in algorithms. Google Play Store is more generous with organic traffic. If you have built a great app, it will reward you with organic traffic. However, in IOS this picture differs. You need to buy traffic for money. For a long time, making apps popular through incentivized traffic was the leading strategy for Apple App Store. It involves some negatives including low lifetime value for the users. When users are incentivized by a reward, they are more likely to install your app without actually wanting it. This often makes it easier for them to uninstall your app after a few days. We wanted users to authentically choose us. Users who choose to involve themselves with the app due to personal interest was the priority both for our team and apparently for Android. This is why we love Google Play Store over Apple App Store.

Going Global


When we finally published Fatal Fight on IOS, Apple featured us in the Top new games'' category. It was not just a matter of luck. The game was developed using the Unity 3d engine, so we were using the same code for both platforms. The secret was the whole journey that this product passed with Android. The huge number of available devices in Android OS allowed us to face a variety of bugs and as a result, we have launched a polished product in the App Store.

Famous British blogger Deji also featured the game in his Paintball Challenge video on YouTube. Right after that, we were on top rankings in the USA and UK.

Now when we were in both stores and going global consequently our aim was to be the most agile with the feedbacks that we were receiving to keep the high ratings in both Google Play and App Store. We were pretty successful in the beginning. However, there were some bugs we could not fix.

Once we started to receive a series of feedbacks. All of them had the same issue I cannot hear the music and the sounds users were reporting. Samsung smartphones were the devices from where the reports were coming. We had several Samsung devices in the house. There were no issues with the sound in these devices. Then we noticed another pattern. All the feedback was coming from one model of Samsung Galaxy Tab 2. It turned out, specifically this type of device was not producing the sound. We bought a Galaxy Tab 2 and reproduced the bug and as a result, we fixed it and released the update.

Time passed, and we faced the major crush that came with the new update we released. All the users of Fatal Fight lost their game progress. Does not matter the number of stages the user might pass, it all crashed down.

Imagine losing the progress of a game where you spent your time, energy, and also money on digital goods. In other words, millions of users had to give up on the mobile game that already became a part of their lifestyle.

After 3 years in the market, we sold Fatal Fight to ITech Media Solutions in Estonia. Later they entered the Chinese market and released it on taptap.com which was one of the biggest Android mobile apps markets in the country. Fatal Fight became the number 1 most downloaded app on taptap.com.

This long journey with Fatal Fight made me face the major issues when it seemed that all the risks were minimized. While reflecting, I figured out that if there could be any platform where all the types of devices would be available for testing, any game would succeed.

The realization was a turning point for me and an inspiration for my next startup.

I have built Buglance to help other developers to release better mobile apps. It includes a network of 50k testers worldwide representing 10k+ unique devices. Here you are free to choose the type of device, country, demographics to test your app to make sure it works best for your audience. In other words, we built a product that could save Fatal Fight.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru