Pull to refresh

Comments 12

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

Почти каждую неделю кто-нибудь приходит просить workaround типа «более быстрой лошади», и после уточнения этот запрос переформулируется или объединяется с другим, где описание сфокусировано на проблеме «хочу ездить быстрее». Необходимость объединять казалось бы разные предложения в одно и была первой причиной перехода на коммерческий тариф — понадобилась функция Merge.
Не видел ничего хуже plesk-панели, жутко тормозная и непонятная. Хотя видел только на одном хостинге, но негатив остался на всю жизнь
Яркий пример комментария из категории «мусор и негатив».
«Демократия в разработке», «где высказаться может каждый пользователь»…
А что ж вы поддержку своего продукта Desktop превратили в квест вместо нормальных каналов связи с техподдержкой?
Через определенное время после покупки от вас, как от продавцов и разработчиков, получить ответы на вопросы (в том числе и о нормальной работоспособности) становится НЕВОЗМОЖНО.

Специально усложнили, чтобы клиенты не надоедали? :-)
Извините, мы говорим про «высказаться может каждый» (предложения) в отношении одного продукта. Я не рассказываю про то, что «каждому помогут и ответят» — это было бы про службу поддержки. Это было бы совсем другое

Я, к сожалению, не очень компетентен в Desktop, тут надо понимать что Parallels большой, направлений и продуктов много, поэтому за совершенно другую часть бизнеса компетентно ответить не могу. Открыв сайт, сразу вижу следующее про «через определенное время получить ответы невозможно» — видимо речь о политике бесплатной поддержки 30 дней (http://www.parallels.com/ru/support/priority/) с момента покупки/регистрации и политике 2х лет с момента выхода (http://www.parallels.com/ru/support/phone/). Если это не про ваш случай, то если есть номер тикета в службе поддержки, могу частным образом поинтересоваться что с ним.
Спасибо за статью. Мы в Targetprocess тоже используем UserVoice как временное решение, пока свое не сделаем. Предполагалось использовать его только для ideas management, а обычную поддержку мы традиционно осуществляем через собственный продукт. Естественно, пользователи постили туда и конкретные технические вопросы/проблемы, что не очень удобно для команды техподдежки (два разных тула для одного и того же — на любителя). В качестве решения мы забацали интергацию UserVoice с Targetprocess через «посредника» в виде zapier.com. Таким образом, те посты в юзервойс, у которых тип Issue добавляются в виде request в Targetprocess, а Product Owner и занимается идеями (они на самом деле влияют на выбор реализуемых фич, но только как один из параметров).
Интересное решение. А тип issue пользователь выставляет сам?

Для нас голоса это тоже один из параметров. Всегда есть стратегия развития и всегда есть проблема «активного меньшинства», которые могут вывести в топ что-то нужное на самом деле немногим. Поэтому мы отдельно проверяем актуальность предложений через открытые источники и группы экспертов из числа текущих пользователей.
Тип Issue пользователь может выставить сам — ему же все равно, какой системой пользоваться. Нашел uservoice — пусть лучше в uservoice запостит, чем обидится и уйдет от нас. Иногда, конечно, и как Idea постят что-то техническое, но редко. Это отлавливает либо Product Owner, либо один из сотрудников, кому еще не лень просматривать ежедневные отчеты :)

Не очень понял про активное меньшинство — мы с этим не сталкивались особо. Несмотря на довольно простую возможность «накрутить» голоса, у нас это случилось только один раз, и то довольно легко выявили и лишние голоса подчистили. С другой стороны, если небольшой группе пользователей очень-очень нужно (большой pain/severity) одно, а большой группе — «неплохо бы» что-то другое, я бы вот так сходу не взялся бы говорить, что нужно именно другое. Мы для таких штук используем линейную модель (чтобы ее толково описать нужна отдельная статья). Там мы используем такие параметры как
— selling point (насколько эта фича поможет нам продавать приложение)
— votes
— pain
— spread (сколько людей из целевой аудитории будут использовать)
— frequency (как часто будут использовать)
— size (размер фичи, т.е. время на разработку)
У каждого параметра свой коэффициент. Выставляют эти штуки специально обученные представители разных профессий для увеличения объективности. Довольно сложно, но лучше любой экспертной.

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

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

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

Функция рассматривается с точки зрения упоминаемости (uservoice), с точки зрения влияния на бизнес (согласно модели) и вклада в стратегию, и с точки зрения проверки с избранными пользователями. Если есть расхождение между тремя точками зрения, то это повод насторожиться — что-то мы возможно неправильно понимаем. Собственно так мы в свое время и создали модель с разными сегментами — когда обнаружили противоречия в оценке пользы от ряда функций
Sign up to leave a comment.