🧾Changelog, pt. 2
Как вести журнал изменений

Changelog — для людей.
Изменение — с версией и датой релиза.
Последняя версия — сверху в журнале.
Это не лозунги, это устоявшиеся правила ведения журнала изменений. А ниже пак советов и идей, основанных на личном опыте. Думаем, что они будут полезны не только нам ☺️

▪️Не стоит публиковать записи в changelog в формате длинных текстов. Если изменений много, лучше разбить одну такую мегазапись на несколько и делиться ими с интервалом в 1-2 дня.

▪️Используйте теги.

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

▪️Не заморачивайтесь с инструментом ведения такого журнала. Если вам удобно его вести в формате блога в Телеграм — вы в своём праве. Содержание превыше всего.

▪️К вопросу про содержание: изменения, о которых вы пишете, должны затрагивать пользователей. Если ваша БД переехала на новые серверы, то нужно будет объяснить, как это отразится на юзере.

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

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

#community_management_AGIMA
#managing_team_AGIMA
#cx_ux_research_AGIMA

⚖️ Scrum VS. Kanban. Scrumban?..

«Об эджайле много песен сложено,
Я спою тебе ещё одну...»

Продукт без Agile — это уже что-то на средневековом. Даже если некто утверждает, что их разработка обошлась совсем без Agile, он (скорее всего) искажает факты. Потому что хоть какие-то кусочки популярных методов таки проникли в проект, куда ж без них. Сегодня поговорим про scrum и kanban, и тут можно было бы решить, что круче. Но нет — вы же знаете, не всё так однозначно, и есть масса факторов, которые влияют на выбор метода. Поэтому победит дружба.
Итак, встречайте: Scrumban (тут зрители читатели аплодируют, аплодируют... кончили аплодировать).

Scrumban — это такой метод, который берет всё лучшее от своих составляющих: гибкость scrum и измерение потока kanban (ну, или метод, который подходит тем, кто никак не может определиться). То есть, scrum уже внедрён, и вы делаете его ещё прекраснее с помощью kanban.

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

Мы, как всегда, не навязываем свою точку зрения, но, как говорится, think about. Потому что сочетать разные методы, адаптируя их под свои процессы — это хорошо ☺️

#agile_AGIMA

31 мая расскажем, как сделать продукт, который всем понравится: https://u.to/JsIoHA.

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

Нам показалось интересным поговорить об этом с экспертами, которые специализируются на CX/UX-исследованиях. Поэтому 31 мая проводим митап «Как создать продукт, желанный для человека».

Выступят эксперты из М.Видео-Эльдорадо, Alfa Research Center и INTEGRAL DESIGN. Вот темы их докладов:

- О чем молчат для вас клиенты?
- Как за полтора года встроить CX/UX-исследования в работу продуктовых команд в большом бизнесе?
- Как создать востребованный продукт в условиях неопределенности.

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

🤔 Agile или Waterfall: выбираем подход

Да, мы здорово сократили пространство вариантов до двух. Это мы специально, потому что Agile и Waterfall — самые популярные, а остальные (о них мы тоже когда-нибудь поговорим) используются не так часто. Сегодня поделимся списком вопросов, ответы на которые дадут понимание наиболее подходящего подхода к разработке под конкретный проект.

🔘 Что критичнее: запуск полностью готового продукта к дате или быстрый запуск с последующей доработкой функционала?
Waterfall хорошо вписывается в сроки, когда есть подробное ТЗ и функций не слишком много. В противном случае есть риск запустить морально устаревший продукт. Agile же заставляет нас расставлять приоритеты и запускать быстрее, а дорабатывать уже потом.

🔘 Предоставленное ТЗ четкое или нет (или его вообще нет как такового)?
Есть сформулированная задача, подробно составленные требования, определены сроки, заказчик не планирует что-то менять и добавлять. Это Waterfall. Есть примерное понимание того, как должно быть, заказчик вовлечен и собирается чекать каждую итерацию. Это Agile.

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

Нет плохих подходов. Есть ошибки выбора ☺️

#agile_AGIMA
#development_methodologies_AGIMA

Пора регистрироваться на открытый урок для проджект-менеджеров «Оценка и тайминг»:https://clck.ru/iXmfx.

1 июня мы проводим бесплатный вебинар пройдет в рамках онлайн-курса «Project manager. Advanced» от OTUS и компании AGIMA — лидера на российском рынке digital-решений. Поговорим о классических и гибких методологиях и поможем структурировать знания.

Вести урок будет руководитель компании AMIGA Дмитрий Тарасов. Из его лекции вы узнаете:

- кто такой менеджер проекта и как им стать;
- почему Waterfall еще жив;
- в чем ценность экспертной оценки;
- зачем нужны SMART и DoD.

Руководитель направления Education в AGIMA Ольга Парий расскажет подробнее о курсе, ответит на вопросы и поможет разобраться, нужно ли вам у нас учиться. Начинаем 1 июня в 19:00 мск. Чтобы зарегистрироваться, переходите по ссылке.

🤷🏻‍♀️ UX и UI. Так в чём разница?

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

Предлагаем окончательно и бесповоротно разобраться в этих аббревиатурах:
▪️UX — User Experience (пользовательский опыт) — это впечатления пользователя от взаимодействия с продуктом.
Так что UX-дизайн — это создание простых, полезных и приятных в использовании продуктов, формирующих позитивный UX.
▪️UI — User Interface (пользовательский интерфейс) — то, как выглядит интерфейс и какие физические характеристики приобретает.
Отсюда UI-дизайн — создание эстетичного дизайна интерфейса продукта.

Из общего у UX и UI-дизайна — высшая цель «сделать хороший дизайн». При этом UX-дизайн — про то, чтобы пользователю было легко и удобно достигать своих целей в приложении, а UI-дизайн — чтобы пользователю «было красиво». Именно поэтому мы почти всегда встречаем UX и UI рядом.
Ведь в дизайне, как и в человеке, всё должно быть прекрасно: и UX, и UI ☺️

#product_design_AGIMA

❓Shared understanding + Product Management

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

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

Интегрировать shared understanding в вашу команду можно с помощью того же OKR. Один из методов, который убивает всех интересующих зайцев: и командную осознанность развивает, и синками славится, и контроль делает эффективным. Но про OKR уже в следующем посте нашего уютного канала ☺️

#managing_team_AGIMA

🗝 OKR — больше, чем просто три буквы. Pt.1

OKR (Objectives and Key Results, Цели и Ключевые Результаты) — метод постановки целей, который за счет иерархии и прозрачности этих самых целей помогает синхронизировать команду. OKR пришел к нам из управления проектами, но так как всё что угодно можно представить в виде проекта, фреймворк успешно «пророс» в менеджмент (любой, в продакт тоже).

▪️Составляющие
O — Objectives. В этой букве прячется основное отличие OKR от других инструментов. Потому что цель должна быть амбициозной и даже невыполнимой. Если к завершению периода она выполнена на 70-75% — хорошо.
KR — Key Results. Метрики, с помощью которых мы сможем понять, что происходит в части достижения наших целей.

▪️Суть
Ставим несколько сложных целей (O) на определенный промежуток времени (квартал/год), определяем их и для команды, и для отдельного сотрудника. Далее для каждой из целей формируем 2-5 метрик (KR), которые позволят судить о достигнутых результатах. Постоянный процесс «нащупывания» тонкой грани между ожиданиями и реальностью в постановке целей — так OKR выглядит на практике.

▪️Пример
Objective: стать самой любимой языковой онлайн-школой
KR: NPS (индекс лояльности) > 75; RC (показатель возвращаемости) > 70%; CSat (показатель удовлетворенности) > 85%

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

P.S. Вы всё правильно поняли, про плюсы/минусы и процесс интеграции OKR — в следующих выпусках. Оставайтесь с нами ☺️

#managing_team_AGIMA
#product_metrics_AGIMA

🤨 No-code: а вам точно нужны разработчики?

No-code не то чтобы очень новая тема (конструкторы сайтов живут и процветают не первый год), но, определённо, рабочая. Как можно легко понять из названия, no-code — метод создания IT-продукта без написания кода, с использованием платформ визуального программирования. Для MVP и/или теста гипотезы более чем полезный инструмент, так что постараемся раскидать плюсы-минусы.

Начнем с плюсов:
➕ легко освоить. Разобраться с no-code-ПО не составит труда даже человеку без навыков кодинга и в самые сжатые сроки
➕ экономия финансово-временных ресурсов. Так как нужный инструмент легко и быстро освоить, то и собрать продукт несложно, а, следовательно, недорого
➕ быстрые доработки. Перенести иконку из угла в угол можно самостоятельно, без заведения задачи в бэклог команды разработки

Минусы:
➖ если число пользователей вашего продукта перевалит за 5-7 тысяч, то без подключения разработчиков не обойтись. То же касается сложных SaaS-продуктов
➖ скачать код вашего проекта с той или иной ноукод-платформы, скорее всего, не получится.

Резюмируем: ноукод почти всегда будет отличным решением для диджитал-специалиста, стартапа и S-бизнеса (а иногда и для M).

#managing_team_AGIMA
#lean_canvas_model_AGIMA

📝 OKR, pt.2: интеграция

Как внедрить OKR так, чтобы это были именно Objectives & Key Results, а не Обсессивно-Компульсивное Расстройство для всей команды?
Постановка идеальных OKR с первого раза — редкое явление, но его можно встретить при наличии правильных причин для внедрения и при соблюдении всех этапов.

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

Этапы запуска OKR в команде
1️⃣ Топы/основатели в конце года определяют OKR компании на следующий год
2️⃣ Команда составляет свои OKR на квартал, исходя из OKR компании и стратегических целей
3️⃣ Команда ставит цели на месяц, в соответствии со своими квартальными OKR
4️⃣ Команда раз в неделю (опционально, раз в 2 недели тоже ок) проводит встречи, где мониторит статусы выполнения OKR
5️⃣ В конце квартала — встреча-ретроспектива, где команда оценивает результаты достижения OKR этого квартала и ставит новые OKR на следующий квартал.

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

#managing_team_AGIMA

💡 Design thinking, pt.1. Не жди вдохновения

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

Процесс дизайн-мышления состоит из перетекающих друг в друга или развивающихся параллельно этапов:
🔘Empathize (эмпатия). В основе эмпатии лежит наблюдение: мы погружаемся в опыт человека и разделяем его чувства и переживания.
🔘Define (определение). Анализируем полученные данные, систематизируем, интерпретируем и определяем проблемы.
🔘Ideate (генерация идей). На этом этапе важно найти как можно больше решений, даже если на первый взгляд они кажутся странными, и выбрать максимально жизнеспособные. Идеи — это не «осенило вдруг», хотя и это тоже, идеи — почти всегда поиск.
🔘Prototype (прототипирование). Проверяем, как работают наши решения на практике.
🔘Test. Масштабируем рабочий прототип, тестим, дорабатываем продукт.

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

#design_thinking_AGIMA

🪢 Design thinking и Agile

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

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

Принципы Design Thinking:
▪️фокус на потребностях человека
▪️больше делать, чем говорить,
▪️один раз показать, а не сто раз сказать
▪️объединяться и сотрудничать
▪️всегда экспериментировать
▪️следовать процессу и понимать его.

И для Agile, и для Design Thinking характерна склонность к ценности для человека, итерационность и взаимодействие заинтересованных сторон.

Цель дизайн-мышления — найти ключевую проблему у человека — точку приложения усилий и понять, как ее лучше всего можно решить (find the right problem). А функция AGILE — создать условия для эффективной разработки решения проблемы (solve the problem right).

Поэтому, когда Agile и Design thinking «дружат», выстраивается итерационная последовательность действий (от полной неопределенности до запуска готового продукта), объединенная общими культурными ценностями и принципами.

#design_thinking_AGIMA
#agile_AGIMA

А вы думали, что мы остановимся на идее совмещения Design Thinking и Agile? 😉 В этой связке есть недостающее звено — Lean Startup. С ним концепция «перетекания» из подхода в подход станет ещё эффективнее!

Ничто не ново под Луной — ребята из Gartner топили за комбинирование этих моделей еще в 2016 году, так в чем его профит? Давайте на примере.

Представим, что мы запустили онлайн-школу, уникальность которой в максимальном погружении студента (преподаватели с 10:00 до 21:00 мотивируют студентов на продуктивность лично🙈). Но после запуска оказалось, что люди к такому погружению не готовы, их устраивала привычная схема обучения. Что было бы, если бы мы шли в связке DT + Lean Startup + Agile?

С помощью DT мы бы поняли проблему потенциального клиента (важно образование, хотят быть продуктивными, но в отведенное для этого время, а не весь день). Lean Startup не дал бы запустить то, что решает несуществующую проблему, а Agile сократил бы цикл разработки.

#design_thinking_AGIMA
#agile_AGIMA
#lean_startup_AGIMA

⏱ 5-тисекундный тест

Запуск продукта без юзабилити-тестирования — почти всегда деньги на ветер. Но в ряде кейсов это исследование можно здорово подсократить за счет выбора 5-тисекундного теста в качестве инструмента.

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

В чем суть? Берём человека, который никогда раньше не видел наш лэндинг/баннер/промо-материал, показываем ему страницу, через 5 секунд закрываем. И переходим к самому интересному — задаём вопросы и готовимся узнавать новое:
▪️о чем эта страница?
▪️какие слова или фразы вы запомнили?
▪️как думаете, что можно сделать на этой странице? (нажал бы кнопку, воспользовался строкой поиска, тапнул бы элемент навигации и т. п).
▪️что ожидаете после выполнения действия?
Список вопросов не закрытый и адаптируется под конкретный кейс.

5-тисекундный тест — рабочий способ для сбора качественного фидбека о первых впечатлениях. Но, как вы понимаете, use-case'ов в нём нет, так что полноценное тестирование интерфейса этот метод исключает.

#cx_ux_research_AGIMA

🔬Проверяем гипотезы: HADI

HADI-цикл — пожалуй, лучший способ проверки гипотез. Разберём, в чём его суть и почему мы его так любим.

HADI — это аббревиатура из первых букв названий каждого из четырех блоков, которые и образуют этот самый цикл:
▪️H — Hypothesis — формулирование гипотез (мы думаем, что)
▪️A — Action — действия для проверки (чтобы это проверить, мы сделаем)
▪️D — Data — получение измеряемого результата (с целью собрать такие данные)
▪️I — Insights — выводы по валидации гипотез (если данные = X, то гипотеза верна. Если они ≠ X, гипотеза не подтвердилась).

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

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

#marketing_reseach_AGIMA
#lean_startup_AGIMA

💍NSM. Метрика Всевластия

North Star Metric (NSM), или метрика Всевластия — это такая невозможно крутая метрика, отслеживая и влияя на которую успеха не избежать. Звучит как что-то на волшебном, так что давайте разбираться, утопия это или нет.

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

Например, для игрового мобильного приложения NSM-метрикой может стать DAU. Представим, что мы оптимизировали SEO, и увеличили DAU x2. Вот только пользователи после установки приложения запускают его всего один раз 🤷🏻‍♀️

Так что идея NSM работает в двух случаях:
▪️ когда есть контрольный показатель, который сможет подсветить ценность изменений нашей метрики Всевластия в долгосроке. В случае с приложением это может быть Stickiness (показывает, как часто аудитория возвращается в приложение)
▪️ когда мы используем NSM для конкретной фичи или точечной задачи. Потому что пляски вокруг NSM без использования других метрик чреваты гиперфокусом, а все мы знаем, что это плохо (знаем же, да? Если не уверены, то читаем пост в грядущий четверг☺️).

#product_analysis_AGIMA
#product_metrics_AGIMA

🔺Пирамида метрик, pt. 1

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

И здесь к нам на помощь приходит пирамида метрик. Этот подход предполагает и иерархию метрик, и их классификацию. Так чем же эта пирамида хороша?

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

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

🔘Определяем зоны ответственности за изменение метрик и выставляем KPI
После того, как мы распределили метрики по пирамиде, обозначить KPI будет гораздо проще.

Как построить пирамиду метрик расскажем уже в следующем посте, долго ждать не придётся ☺️

#product_analysis_AGIMA
#product_metrics_AGIMA

🔺Пирамида метрик, pt. 2: выбираем правильные метрики и определяем связи

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

1️⃣ Аудит. Мы определяем данные, которые отслеживаются и которые нужно отслеживать
2️⃣ Классифицируем наши показатели, дабы избавиться от гиперфокуса
3️⃣ Добавляем базовую иерархию
4️⃣ Выстраиваем связи между метриками
5️⃣ Проверяем работоспособность показателей на основании анализа бизнес-модели
6️⃣ Изучаем показатели
7️⃣ Проводим эксперименты для проверки иерархии (опционально, если есть потребность).

И в итоге распределяем метрики по уровням пирамиды.

◼️NSM
На вершину водружаем нашу метрику всевластия, которую считаем самой важной.

◼️Бизнесовые
Следующий уровень сверху вниз — это бизнесовые метрики. Сюда закладываем денежный оборот, доходы, инвестиции, верхнеуровневые аудиторные показатели.

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

◼️Интерфейсные
На этом уровне мы замеряем взаимодействие с пользователем в точках контакта. Тут притаилась конверсия форм и кнопок.

◼️Платформенные
А в основе нашей пирамиды расположились доступность и техническая надежность продукта.

Пирамида метрик — удобный инструмент, способствующий восприятию картины целиком.

#product_analysis_AGIMA
#product_metrics_AGIMA

🗄 Desk-research: когда нужна кабинетка?

Кабинетное исследование (desk-research) — один из методов качественных исследований — сбор и анализ информации о рынке из открытых источников. Мы часто используем его в связке с другими инструментами: как правило, для полноты картины вводим CX-research (по понятным на то причинам).

Desk-research полезен при поиске ответов на такие вопросы:
- какая ситуация на рынке сейчас?
- что с актуальными тенденциями развития рынка?
- какие объемы (и иные параметры) и темпы роста/падения рынка?
- как спрогнозировать развитие основных показателей рынка?
- какая у рынка структура?
- как дела у конкурентов и поставщиков?
- что с ценовой и ассортиментной политикой?
- как найти основные каналы реализации и продвижения?
- какие ниши свободны?
- и т.п.

Плюсы кабинетного исследования:
➕относительно быстро
➕относительно дёшево
➕много источников — «широкий взгляд» на проблему
➕минимум влияния исследователя.

Минусы кабинетного исследования:
➖информация может быть устаревшей/неполной
➖информация может вызывать сомнения в достоверности (зависит от источника).

В общем, кабинетное исследование — это полезно и круто, но для полного счастья недостаточно. Так что desk-research сам по себе — не самая рациональная трата бюджета, и по-настоящему качественный результат даст только совмещение методов ☺️

#marketing_reseach_AGIMA

❓Как избежать типичных ошибок в аналитике
https://habr.com/ru/company/agima/blog/676918/.

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

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

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

#cx_ux_research_AGIMA

👬 Product VS. Project

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

Продакт-менеджер:
▪️объект — продукт. Товар/услуга, которую мы предлагаем рынку для удовлетворения потребностей потребителей;
▪️главные вопросы: «Что?» и «Зачем?»;
▪️связующее звено между бизнесом и пользователями;
▪️KPI связаны с прибылью от продукта;
▪️база: знание ЦА и понимание методов и инструментов получения прибыли от продукта (product-market fit);
▪️необязательно есть сотрудники в подчинении, но на развитие продукта влияет именно он.

Проджект-менеджер:
▪️объект — проект. Временнóе предприятие, направленное на создание уникального продукта, услуги или результата;
▪️главные вопросы: «Когда?» и «Как?»;
▪️связующее звено между бизнесом и разработчиками;
▪️KPI связаны с реализацией проекта в установленные сроки и в рамках запланированного бюджета;
▪️база: умение грамотно организовать рабочие процессы с использованием релевантных подходов к разработке;
▪️отвечает за распределение ресурсов и управляет командой.

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

#managing_team_AGIMA