Привет Хабр!
Недавно мне попалась на глаза статья про 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% быстрорастущих стартапов внедрили продукт" и т.д.). Это самый важный пункт продаж (кроме очевидных). Вы должны убрать информацию с цифр эффективности (если мы говорим про автоматизацию, то принципиально не должно быть никаких подсчетов того, на что сейчас тратится рабочее время, что мешает работать быстрее/лучше и т.д.). Никакой индивидуальности, никакого пристального анализа.
- В начале внедрения необходимо найти отдел, который первым перейдет на вашу систему. В идеале, если он будет не шибко нагруженным (ему ведь не просто так не дают задач, верно?) и с людьми, которые замотивированы внедрить новое (им надо повторять почаще, что они инноваторы и т.д.). В идеале пообещать им премию за содействие (работает, что очевидно, не всегда). Важно: отдел, который первым будет пользоваться системой, не должен ни в коей мере быть заинтересован в критике системы. То есть мотиватором должно быть внедрение системы, а не качество работы или эффективность отдела.
- После внедрения: всё общение с разработчиками должно быть строго через ваши каналы (естественно, они должны быть не самыми удобными, с долгой и тормознутой службой поддержки, которая советует сначала переустановить систему, прежде чем начнет изучать вопрос).
Выводы
Надеюсь, эта статья поможет хорошим продуктам продвигаться на рынке. Я крайне надеюсь, что если вы участвуете в разработке продукта, то после прочтения статьи вы будете ближе к пользователям (а не к управляющим). В идеале, если вы сделаете опросник для пользователей (а лучше — периодический), где все поля будут необязательными, а как минимум половина — в стиле "если хотите добавить что-нибудь еще по пункту выше — напишите в этом текстовом поле".
Комментарии (12)
vyatsek
19.08.2018 23:32Тоже работаю с ServiceNow.
Продукт концепцией и идеологией подходит под Enteprise, судя по тому как у нас его настраивают, такое чувство что там можно сделать все или почти все с точки зрения бизнес процесса.
Но все это портит хреновый UX и ужасная производительность.
Ну и те кто заключают контракты, обычно этими тулами не пользуются постоянно.
Praporshik_Zadov
20.08.2018 08:27Столкнулся с SN несколько лет назад и, по сравнению в HP Service Manager, мне данная платформа понравилась больше. Не без недостатков конечно, но те задачи которые в НР решались танцами под звуки бубна, здесь решались быстро и с песней.
А вот на счет сейлов… В то время сейл был один — Peter Helner, если хотите узнать, как просрать продажи в России — это точно к нему.
Germanjon
20.08.2018 10:49Статистика показывает, что пользователи могут быть незаинтересованы в новой программе:
— Не хотят чего-то нового;
— Не хотят каких-то метрик, который покажут неэффективность их работы;
— Не хотят инструментов, которые позволят получать свою копеечку в обход правил;
— Тупо боятся, что не справятся с новой программой.
Отсюда рождается поток жалоб с общим посылом «программа плохая, ничего не работает» (причём, конечный юзер мог даже не открывать программу вообще, а опираться на беседы в курилке), после чего начинается пляска перед конечными пользователями в попытке заинтересовать.
Собственно, в программе эта оценка не рассматривается.imanushin Автор
20.08.2018 11:58Да, всё верно, все эти случаи тоже имеют место быть. Однако, по моему опыту (!!!), они редко встречаются в среде с активными специалистами.
Потому я и попытался сузить число возможных ситуаций до «специалист понимает, что программа сэкономит ему время» (извините за тавтологию).
а опираться на беседы в курилке
Зачастую программу поливают не просто так
SergeyMax
20.08.2018 20:01Страховые агенты люто ненавидят эту систему. Продукт мало того, что работает только на Windows
Вы сейчас говорили от лица страховых агентов, или от лица какого-то сисадмина?)imanushin Автор
22.08.2018 12:20От лица страховых агентов, которым я помогал настраивать эту систему на домашних машинах. Кстати, именно ради собственных ноутов вся гибкость и задумывалась
Imbecile
Очень странная и однобокая статья.
Что если продукт экономит время, но приводит к появлению большего количества ошибок?
Например, начали вести учёт продаж в Экселе вместо специализированной системы. В Экселе быстрее, но вот свести концы с концами — тяжелее.
А если наоборот. Что если продукт требует больше времени, но позволяет сделать то, что раньше не делали?
Например, специализированная система учёта продаж требует заполнения большого числа полей, но зато она через какое-то время сможет прогнозировать динамику спроса и, тем самым, планировать производство.
Или вот ещё. Вдруг внедрение новой системы, которая экономит время и всё прочее, стоит все деньги мира. И вам дешевле держать низкоквалифицированных сотрудников лет 10, чем внедрить систему здесь и сейчас.
Итог. Слишком уж упрощённый и идиалистичный взгляд на мир, когда всё можно измерить одним параметром — время специалиста. В жизни так не бывает.
imanushin Автор
Не, я, наверное, плохо расписал идею в статье. Если специалисты предлагает использовать продукт, в котором они сами будет работать, то всё ок, это выходит за рамки статьи. Зачастую с этим проблем не будет.
Проблема в том, когда решение об использовании продукта принимает одна группа людей (например, менеджеры среднего звена решили, что CVS — идеальная система контроля версий, а всё прочее — чушь), а работать с этим продуктом будут совсем другие люди (те же разработчики). Кстати, история в этом абзаце как раз из моей жизни.
Imbecile
Ещё раз перечитал пункт «0». Нет там оговорки, что описанные критерии оценки, применимы только если продукт выбран не самими пользователями.
vyatsek
Line
Тут вопрос того откуда происходит потребление системы. Если это облако производителя — одни вопросы, если селфхост — другие. Нужно разбираться. Тянуть она может много людей, а дальше надо ковыряться.