Открыть список
Как стать автором
Обновить
0
Карма
0
Рейтинг

Пользователь

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

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

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

Если не сложно, опишите, пож-та, кратко, как у вас работает процесс принятия решения. Гпуппа экспертов — это клиенты добровольцы?

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

Спасибо за статью. Мы в Targetprocess тоже используем UserVoice как временное решение, пока свое не сделаем. Предполагалось использовать его только для ideas management, а обычную поддержку мы традиционно осуществляем через собственный продукт. Естественно, пользователи постили туда и конкретные технические вопросы/проблемы, что не очень удобно для команды техподдежки (два разных тула для одного и того же — на любителя). В качестве решения мы забацали интергацию UserVoice с Targetprocess через «посредника» в виде zapier.com. Таким образом, те посты в юзервойс, у которых тип Issue добавляются в виде request в Targetprocess, а Product Owner и занимается идеями (они на самом деле влияют на выбор реализуемых фич, но только как один из параметров).

Support — взгляд изнутри

Согласитесь, ситуация может очень сильно отличаться в зависимости от рынка и продукта, не стоит писать про весь саппорт. Это примерно как если бы я работал в секс-шопе и написал о том, что кругом одни извращенцы :). К нам, например, приходят те самые индийские девелоперы и с IQ там тоже есть вопросы местами :)
Однако я не верю, что с ситуацией, описанной в статье, ничего нельзя сделать. Просто кто-то не хочет или не может ничего делать по этому поводу, всех все устраевает. Я, кстати, согласен с Creat1ve. Что делать? С одной стороны все просто: подумать и реализовать то, что придумал. Я не верю, что человек в состоянии написать связанный текст не сможет придумать как облегчить жизнь себе и клиентам. Мы, например, проводим ретроспективы раз в месяц и постоянно становимся круче — это не так сложно, как кажется.
С другой стороны, все совсем не просто: таки нужно что-то делать. Более того, наиболее важные моменты могут требовать изменений за пределами непостредственно команды саппорта — тут уже важна культура компании… Вообще, полный ответ тянет на отдельную статью, но вот что бы я выделил сходу (из сложного и глобального):
1. подбор сотрудников. У нас проходит примерно 1 из 10, но требования выше средних. Тут важны и навыки и склонность к такой работе.
2. грамотный хелп/гайд, подсказки внунри приложения (если применимо), видео и т.п. Еще раз — грамотные. Такие чтобы ваш овощ не только понял, но и захотел досмотреть до конца.
3. «правильная» атмосфера внутри команды. Если никто не считает клиентов тупыми овощами, то и новый сотрудник не будет. Тут есть над чем работать, поверьте.
4. (самое крутое). Добиться чтобы саппорт влиял на сам продукт, делая его тем самым доступнее и реализуя пожелания клиентов. Тут, конечно, чем больше компания, тем сложнее… наверное.

Support — взгляд изнутри

Автор, подскажите, пожалуйста, в какой области вы работали. Из статьи создается мнение, что вся поддержка — это озятельно работа с тупыми конечными пользователями из бывшего СССР. Я просто тоже последние 3 года занимаюсь поддержкой и мой опыт не соответствует написанному выше чуть более чем полностью. Да, да, компания, в которой я работаю, и подход к поддержке не совсем типычны для стран СНГ, да и клиенты по всему миру. К чему это я? К тому, что после таких статей в стиле «саппорт это ад и работают там нелюди» становится все сложнее искать людей в компании, где работают человеки. Я даже в свое время статью про это писал, не на хабре, правда.

Наши процессы. Опыт формирования support-команды и немного про SMM

у нас две модели — Saas ( On-Demand ) и локальная установка ( On-Site ).

Наши процессы. Опыт формирования support-команды и немного про SMM

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

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

Наши процессы. Опыт формирования support-команды и немного про SMM

Бывают ситуации, типа «я тут самостоятельно продакшн переносил на другой сервер, все поломалось, 100 девелоперов не могут работать». Тогда для решения важна скорость, а для этого лучше чат + screen-sharing

Да и по опыту, у лучшие ощущения у клиентов остаются именно после «живого» общения

Наши процессы. Опыт формирования support-команды и немного про SMM

Согласен, про доработку продукта — вообще отдельная тема. Сами много чего используем и влияем на продукт путем решения клиентских проблем. Но к клиентским «хотелкам» относимся как к «идеям» — т.е. благодарим, но ничего не обещаем.

Наши процессы. Опыт формирования support-команды и немного про SMM

Я как раз недавно триалил Kayako — не понравилось, что клиент не может переслать файл через чат ( для тех. саппорта нам это важно), а при отправке логов в виде текстового сообщения теряет line breaks.
Буду признателен, если кто посоветут чат, в котором это можно делать нормально.
К тому же мы eat our own dogfood — используем то, что сами производим ( для саппорта у нас есть отдельная часть приложения, не самая мощная на мой взгляд). Это помогает нам сделать продукт лучше.

Что до левелов — мы как раз тоже не разбиваем. Т.е. стараемся использовать savvy support, но некоторые проблемы требуют привлечения девелоперов ( например, неизведанный ранее баг).

Используем тул который так и называется «GoToMeeting». Есть вопросы по скорости, думаем перейти на TeamViewer.

Информация

В рейтинге
6,024-й
Зарегистрирован
Активность