Как оценить качество продукта

в 17:05, , рубрики: ERP-системы, feedback, smm, бизнес-модели, взятки, впаривание, казнокрадство, конференции, коррупция, кумоство, маркетинг, менеджер, обратная связь, отзывы, Презентации, продажи, Управление медиа, Управление продажами, управление проектами, Управление проектом, успешные продажи

Привет!

Недавно мне попалась на глаза статья про Service Now. В ней описывалось про то, какой же хороший у них продукт. Даже показали менеджера среднего звена с микрофоном, которая без цифр что-то говорила (из статьи — "сократило время административного труда, и врачи смогли сфокусироваться на своём основном предназначении").

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

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

Моё личное, не совсем культурное и к тому же эмоциональное мнение о продукции Service Now

Если описывать данное решение одним словом, то идеально подходит "дно". Если описывать двумя словами, то "полное дно".

В теории этот продукт должен помогать администрировать работу крупного предприятия (где менеджер из Индии может увидеть, что открылась заявка на поставку груза в Нигерии), однако я абсолютно не понимаю, как это возможно, если:

  • Технически продукт является убожеством:
    • В нем не поддерживается работа из разных вкладок (я напомню — сейчас 2018 год). Нельзя одновременно редактировать "тикет" в двух разных вкладках браузера
    • В нем не поддерживается подписка на определенные тикеты/задачи (или по-другому — сущности). То есть если вы создали заявку, то проверяйте статус каждый час. Еще раз напомню, что в маркетинговых брошюрах говорится об оптимизации предприятия.
    • Сайт работает настолько медленно, что в углу экрана сделан специальный виджет, который показывает, насколько долгий был отклик сервера, клиента (т.е. браузера). Зачем это пользователю? Еще раз убедиться в том, что отдел IT состоит из слабых разработчиков?
  • С точки зрения помощи бизнесу, с продуктом полный провал:
    • У пользователя нет возможности кастомизации и оптимизации под себя. Видимо, торговцы от Service Now считают, что они могут сделать динамическую форму удобную для всех сразу. Они ошибаются.
    • Продукт не поддерживает интеграции с email (как это было сделано у salesforce). Т.е. нельзя вести переписку вне этого сайта, с автоматическим сохранением в систему, а значит море привычного общение переходит на непривычный сайт.
    • Нет даже приблизительных цен на продукт. На вас посмотрят, выставят цены, а при ближайшем обновлении лицензии вы заплатите намного больше. В реальности цены выдаются под NDA.

Единственное, чем я восхищаюсь — так это продавцами Service Now. Если бы у меня были эти ребята в команде, я бы не раздумывая открыл компанию в любом секторе экономики. Раз они продали Service Now, то они способны не просто впарить снег зимой, но и продать многолетнюю подписку на снег для арктических экспедиций.

Однако это всё эмоции, дальше только конструктив.

0: хорошие и плохие продукты

Чтобы заранее обозначить термины статьи, а заодно и сузить предметную область, термины лучше определить так:

  • Продукт — программа/сервис и т.д., которая помогает в работе специалистам (в теории или на практике). В статье не рассматриваются сервисы, которые навязываются государством. А также в статье не рассматриваются программы, которые позволяют избавиться от рабочих (как, например, замена банковских касс на банкоматы), так как в этом случае наиболее объективным фактором будут экономические показатели. Также в статье не рассматриваются вещи, которые помогают не специалистам на работе, а, например, человеку дома/вне работы.
  • Хороший продукт — продукт, который позволяет специалисту экономить время на рутинных задачах (например, врач сможет меньше заниматься рутинной писаниной, а больше тратить время на пациента)
  • Плохой продукт — антоним к хорошему продукту, то есть решение, на работу с которым специалист тратит больше времени, чем тратил ранее, при условии, что нагрузка на других рабочих компании тоже не уменьшилась (после введения продукта в эксплуатацию)
  • Продукт А лучше продукта Б — продукт А позволяет экономить больше времени на решении рутинных задач для специалистов, чем продукт Б.

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

1: кто оценивает продукт

Сразу тезис: хороший продукт хвалят специалисты, которые с ним работают; плохой продукт будут хвалить люди, которые к нему даже не прикасались. Или другими словами — если нет никаких оснований считать продукт хорошим, то рекомендации будут от людей, которые вообще с продуктом не работали. Зачастую это те же самые люди, которые получили бонус за успешное внедрение сервиса.

Если вернуться к статье про великолепный Service Now, то можно увидеть, что хвалебные оды идут от "представителя медицинской компании Magellan Health" (если цитировать дословно). И продолжая пересказ: "сократило время административного труда, и врачи смогли сфокусироваться на своём основном предназначении". То есть вместо врачей приехал условный "представитель", который за врачей рассказал, как им стало хорошо.

История из жизни: в одной из старых страховых компаний РФ (к сожалению, не могу назвать имени, так как NDA и пр.) используется самописная система для учета полисов (плюс для автоматизации бизнес процессов). В большинстве случаев с этой системой работают страховые агенты (собственно, ради них она и разрабатывалась), однако есть ряд нюансов:

  • Страховые агенты люто ненавидят эту систему. Продукт мало того, что работает только на Windows, так еще и в самые часы пик любит кидаться ошибками вида "нет свободных лицензий", "Ошибка ORA-12345" и т.д.
  • Технологическое состояние системы настолько высокое, что:
    • Для её настройки требуется прописать несколько сертификатов в доверенные на своей ОС
    • Из-за того, что ряд операций проходит на терминальном сервере, система по-умолчанию не видит подключенный принтер (действительно, зачем страховому агенту что-то печатать?)
    • Система не умеет делать стандартные рутинные вещи, такие как масштабирование фотографий и т.д. Страховой агент должен уметь самостоятельно ужимать снимок до N Kb
  • Качество системы таково, что люди стараются работать с продуктом по-минимуму. В частности, как-то раз у брокера я спросил "Вы дали мне цены для шести страховых компаний. И можно еще для компании M?". И в ответ услышал, что настройка системы слишком сложна, так что брокер просто не работает с этой страховой компанией, если это возможно.

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

Из этих заключений получаем вывод, что если продукт хвалит тот, кто с ним не работает, то качество этого "продукта" ниже плинтуса.

2: как оценивают продукт

Кратко идея: если на продукт нет положительных отзывов от пользователей, то программа кишит недостатками, которые искусно замазываются. Или по-другому: если пользователи не хвалят продукт, то это верный признак того, что у продукта отсутствует feedback. А его нет зачастую нет там, где пользователи будут только зло отвечать в стиле "что за убожество вы сделали" и т.д. Отсюда и получаем: чтобы ограничить число негатива, заодно отрезаем и весь позитив.

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

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

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

Как видно из примера выше, до разработчиков достучаться невероятно сложно. В итоге с одной стороны потеряна обратная связь, я с другой стороны — менеджер среднего звена может с радостью отчитаться: "жалоб нет, мы не косячим". Для сравнения, про эти продукты можно с легкостью пожаловаться: IntelliJ Idea, Artifactory.

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

3: как успешно презентовать плохой продукт

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

  • Самое первое — никаких контактов с пользователями. Их не должно быть ни на презентациях, на при внедрении продукта (на всех стадиях: покупка и т.д.).
  • Второе — вы должны показать, что немало авторитетных людей из других компаний пользуются продуктом. Главное — это человек, а не прибыль. Если говорите про Apple — покажите фото Стива Джобса на фоне яблока.
  • И последнее — вы продаете продукт менеджерам, а не специалистам. Вы не должны помогать "простым рабочим". Делайте упор на "систематизацию" (не так много директоров знают, что там делают далекие подчиненные, а с вашей системой всё будет под контролем), "автоматизацию" (ведь в будущем можно будет сократить штат). И не надо забывать про тренды: вместо фразы линейная регрессия можно употребить Искусственный Интеллект или ML.

Как осуществлять внедрение:

  • Продажа: перво-наперво необходимо показать, что продуктом пользуются многие. У любого менеджера должна быть железная отмазка, что у всех всё работает (т.е. когда менеджер будет показывать отчет начальнику, в документе должно быть четко продемонстрировано, что "половина компаний из TOP-500 успешно внедрили у себя продукт", или же "30% быстрорастущих стартапов внедрили продукт" и т.д.). Это самый важный пункт продаж (кроме очевидных). Вы должны убрать информацию с цифр эффективности (если мы говорим про автоматизацию, то принципиально не должно быть никаких подсчетов того, на что сейчас тратится рабочее время, что мешает работать быстрее/лучше и т.д.). Никакой индивидуальности, никакого пристального анализа.
  • В начале внедрения необходимо найти отдел, который первым перейдет на вашу систему. В идеале, если он будет не шибко нагруженным (ему ведь не просто так не дают задач, верно?) и с людьми, которые замотивированы внедрить новое (им надо повторять почаще, что они инноваторы и т.д.). В идеале пообещать им премию за содействие (работает, что очевидно, не всегда). Важно: отдел, который первым будет пользоваться системой, не должен ни в коей мере быть заинтересован в критике системы. То есть мотиватором должно быть внедрение системы, а не качество работы или эффективность отдела.
  • После внедрения: всё общение с разработчиками должно быть строго через ваши каналы (естественно, они должны быть не самыми удобными, с долгой и тормознутой службой поддержки, которая советует сначала переустановить систему, прежде чем начнет изучать вопрос).

Выводы

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

Автор: Игорь Манушин

Источник

Поделиться

* - обязательные к заполнению поля