Как стать автором
Обновить

Комментарии 9

Отловить случайных людей с коридора, а ещё лучше — представителей заказчика и посадить на пол часа к вашей прорывной системе, чтоб они без объяснений сделали типичные действия пользователя.
Потом — записывать «что не так», молча обтекать и думать, какие правки вносить:
то, что за пол года работы над UI стало для вас очевидным, скорее всего, для сторонних вообще не очевидно, а вот эта вот функция, которой вы гордитесь — будет мешать половине пользователей.
Например, если вы захотите сделать «умного» клиента, который сам просканирует доступные сети и найдёт свой правильный сервер для конторы с чуткими безопасниками — лучше не надо.
Потом — записывать «что не так», молча обтекать и думать, какие правки вносить: то, что за пол года работы над UI стало для вас очевидным, скорее всего, для сторонних вообще не очевидно, а вот эта вот функция, которой вы гордитесь — будет мешать половине пользователей.

я бы не торопилась сразу обтекать)), меня в этой ситуации всегда смущает, что опросить много людей сложно и дорого, получается мы поговорим с несколькими представителями ЦА, потестируем на них, возможно, что-то допилим, потом посмотрим, как новые функции зашли пользователям (их будет больше, статистика достовернее)
и вот если зашло, а раньше об этом никто и не думал, тогда можно начинать обтекать))
Вы оба верные вещи говорите.
Качественные анализ в виде глубинных интервью 10-и человек может позволить выявить 70% ключевых недочетов в сервисе. Из этих интервью вы формулируете гипотезы и проверяете их уже на большей аудитории при помощи количественных методов, например, через A/B тестирование.
Обтекать — это по собственному опыту, ситуация аналогична любому тестированию ( да хотя бы на аварийного переключения сервисов между кластерами), которое раньше не делали: в целом оказывается «всё хорошо, НО...» столько мелочей, что хорошо оказывается погребено под ними (как и самомнение разработчиков)
Проверка гипотез, фидбеки и портреты конечного пользователя хорошо работают только на b2c и рынка SMB. Если ваш заказчик крупнее, то методики будут другими.

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

Для людей, которые не занимаются продукт менеджментом, продуктовый подход развивает следующее упражнение (я так детям его даю)
— Надо выбрать любой предмет, который нравится. Можно нематериальный (музыка, фильм), но он обязательно должен быть создан человеком.
— Почему он нравится?
— Кто те люди, котом он тоже понравится? Возраст, пол, род занятий и т.п.

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

Сами себе противоречите.
Очевидно, что нужно прежде всего рассчитывать, что приложением будет пользоваться целевая аудитория в самом широком смысле. Для них и нужно делать, а не для младенцев и бабушек. Если конечно они в нее не входят.
Этот пункт не про целевую аудиторию. Безусловно, младенцы и бабушки будут статистическим выбросом в большинстве ЦА. Это про запас прочности. Если ориентироваться при разработке на них, то для остальных точно будет все очевидно.

_11. Декомпозируй правильно.
Коллеги за технику сначала пилят БД, потом сервисы потом UI. И им порой трудно обьяснить как сначала делать сценарий1 потом сценарий2 и тд.
Вот как объяснить?

Столько времени прошло, а статья все еще очень крутая. Спасибо!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации