Должны ли пользователи видеть свою собственную статистику производительности в режиме реального времени - PullRequest
5 голосов
/ 01 февраля 2010

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

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

Есть ли у кого-нибудь информация о вреде и выгодах, включая эту статистику в приложение?

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

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

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

В моем приложении я могу думать об этих сценариях

т.е. ПЛОХО: «Я вижу, что уже потратил 10 минут на эту проблему, мне нужно закончить как можно скорее»

против

т.е. ХОРОШО: «Я смог быстро помочь этому клиенту, у меня сегодня хорошая производительность»

Ответы [ 3 ]

1 голос
/ 02 февраля 2010

Я думаю, что действительно может быть явление, которое можно назвать «Эффектом Facebook», когда просто представляя метрику (например, количество «друзей», минут за звонок), вы подразумеваете, что это важно. Однако я не думаю, что это проблема здесь, потому что ясно, что пользователи уже считают эти показатели очень важными, иначе они не стали бы просить вас о них.

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

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

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

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

1 голос
/ 01 февраля 2010

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

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

Несколько громких имен использовались для оценки сотрудников на основе таких факторов, как громкость звонка, среднее время разговора и т. Д. Помните, когда Dell пыталась передать все свои технические звонки в Индию? Клиенты здесь, в США, были разочарованы, и звонки были либо слишком длинными (не понимая), либо слишком короткими (клиенты не хотели иметь с этим дело). Ну, большие шутеры думали, что время звонков довольно точно соответствует прогнозу, и наши расходы снижаются. Но со временем оно достигло дна ...

0 голосов
/ 01 февраля 2010

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...