Привет!
Недавно мне попалась на глаза статья про 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% быстрорастущих стартапов внедрили продукт" и т.д.). Это самый важный пункт продаж (кроме очевидных). Вы должны убрать информацию с цифр эффективности (если мы говорим про автоматизацию, то принципиально не должно быть никаких подсчетов того, на что сейчас тратится рабочее время, что мешает работать быстрее/лучше и т.д.). Никакой индивидуальности, никакого пристального анализа.
- В начале внедрения необходимо найти отдел, который первым перейдет на вашу систему. В идеале, если он будет не шибко нагруженным (ему ведь не просто так не дают задач, верно?) и с людьми, которые замотивированы внедрить новое (им надо повторять почаще, что они инноваторы и т.д.). В идеале пообещать им премию за содействие (работает, что очевидно, не всегда). Важно: отдел, который первым будет пользоваться системой, не должен ни в коей мере быть заинтересован в критике системы. То есть мотиватором должно быть внедрение системы, а не качество работы или эффективность отдела.
- После внедрения: всё общение с разработчиками должно быть строго через ваши каналы (естественно, они должны быть не самыми удобными, с долгой и тормознутой службой поддержки, которая советует сначала переустановить систему, прежде чем начнет изучать вопрос).
Выводы
Надеюсь, эта статья поможет хорошим продуктам продвигаться на рынке. Я крайне надеюсь, что если вы участвуете в разработке продукта, то после прочтения статьи вы будете ближе к пользователям (а не к управляющим). В идеале, если вы сделаете опросник для пользователей (а лучше — периодический), где все поля будут необязательными, а как минимум половина — в стиле "если хотите добавить что-нибудь еще по пункту выше — напишите в этом текстовом поле".
Автор: Игорь Манушин
