Несложно догадаться как пользоваться вилкой или ложкой, или штопором, однако, более сложные приспособления, даже, типа, открывалки, уже имеют инструкцию по применению.
Очевидно, что чем сложнее система, тем больше ошутима необходимость руководства пользователя.
Любые инструменты появляются под потребность, т.е. сначала возникает какая-то проблема, затем появляется решение, затем - инструменты, где придуманное решение уже реализуется. Если решаемая проблема понятна, то достаточно обойтись исключительно инструкцией по применению инструмента. Например, проблематика, адресуемая лопатой - понятна, поэтому исключительно инструкции ( шутка, :) ) - достаточно.
В сфере высоких технологий проблематика далеко не всегда понятна, как следствие, не понятна и потребность в инструментарии, и уж тем более не понятно как пользоваться имеющимися инструментами. В этих случаях просто руководством пользователя не обойтись (тем более, все еще хуже, когда нет и такого руководства). С высокотехнологическими продуктами надо продавать законченную историю, закрывающую не только вопросы о том, как правильно пользоваться инструментом, но и:
- какой операционный процесс нужно построить над этим инструментом (его поддержка, использование - если он генерит какие-то алерты, какая на них необходима реакция в каких случаях и т.п.)
- как этот бизнес-процесс использования инструмента вписывается в существующую операционную модель потенциального потребителя (да и вообще, каков профиль потенциального потребителя)
- как контролировать эффективность и результативность использования инструмента (т.е. как понять, что связка инструмент-процесс над ним работают, и работают как надо, каковы метрики).
Для передачи этой истории про правильное использование инструмента хороши все методы:
- гора печатных документов,
- доступ к вендорской базе знаний, где рассмотрены типовые сценарии,
- сиквел из коротких полумаркетинговых роликов продолжительностью не более 5 минут о том, как с помощью данного инструмента решать какие-то конкретные (лучше те, что на слуху) задачи,
- тренинги и сертификации,
- открытые community форумы\конферении\вебинары (да и любые другие мероприятия как физические, так и виртуальные), где потребители делятся своим опытом использования инструмента.
Причем, со стороны вендора инвестиции в эту историю вокруг продукта должны быть ничуть не менее важными, чем в сам продукт. Я бы даже сказал, что правильнее это рассматривать как часть продукта, и продукт считать законченным только когда он готов технологически и готовы все материалы, требуемые для обеспечения его правильного использования потребителем. Ведь, если пользователь будет использовать продукт неправильно\неэффективно, - это означает, что он не получит ожидаемой ценности, а это уже проблема вендора (ну конечно нормальные вендор заинтресован в том, чтобы его прдукты приносили пользу!), и вендор должен ее решать всеми доступными методами.
Очевидно, что чем сложнее система, тем больше ошутима необходимость руководства пользователя.
Любые инструменты появляются под потребность, т.е. сначала возникает какая-то проблема, затем появляется решение, затем - инструменты, где придуманное решение уже реализуется. Если решаемая проблема понятна, то достаточно обойтись исключительно инструкцией по применению инструмента. Например, проблематика, адресуемая лопатой - понятна, поэтому исключительно инструкции ( шутка, :) ) - достаточно.
В сфере высоких технологий проблематика далеко не всегда понятна, как следствие, не понятна и потребность в инструментарии, и уж тем более не понятно как пользоваться имеющимися инструментами. В этих случаях просто руководством пользователя не обойтись (тем более, все еще хуже, когда нет и такого руководства). С высокотехнологическими продуктами надо продавать законченную историю, закрывающую не только вопросы о том, как правильно пользоваться инструментом, но и:
- какой операционный процесс нужно построить над этим инструментом (его поддержка, использование - если он генерит какие-то алерты, какая на них необходима реакция в каких случаях и т.п.)
- как этот бизнес-процесс использования инструмента вписывается в существующую операционную модель потенциального потребителя (да и вообще, каков профиль потенциального потребителя)
- как контролировать эффективность и результативность использования инструмента (т.е. как понять, что связка инструмент-процесс над ним работают, и работают как надо, каковы метрики).
Для передачи этой истории про правильное использование инструмента хороши все методы:
- гора печатных документов,
- доступ к вендорской базе знаний, где рассмотрены типовые сценарии,
- сиквел из коротких полумаркетинговых роликов продолжительностью не более 5 минут о том, как с помощью данного инструмента решать какие-то конкретные (лучше те, что на слуху) задачи,
- тренинги и сертификации,
- открытые community форумы\конферении\вебинары (да и любые другие мероприятия как физические, так и виртуальные), где потребители делятся своим опытом использования инструмента.
Причем, со стороны вендора инвестиции в эту историю вокруг продукта должны быть ничуть не менее важными, чем в сам продукт. Я бы даже сказал, что правильнее это рассматривать как часть продукта, и продукт считать законченным только когда он готов технологически и готовы все материалы, требуемые для обеспечения его правильного использования потребителем. Ведь, если пользователь будет использовать продукт неправильно\неэффективно, - это означает, что он не получит ожидаемой ценности, а это уже проблема вендора (ну конечно нормальные вендор заинтресован в том, чтобы его прдукты приносили пользу!), и вендор должен ее решать всеми доступными методами.
No comments:
Post a Comment