...

четверг, 3 октября 2013 г.

Война миров: Пользователь VS. Разработчик


План статьи:



  1. Критерии к продукту — пользователь vs. разработчик (функциональность vs. удобство). Юзабилити интерфейсов и их важность.

  2. Клиентоориентированность и в чём она проявляется (+ примеры продуктов с плохой клиентоориентированностью)

  3. Не дайте архитектурным астронавтам вас запугать — о том, что излишнее желание угодить всем пользователям может рождать сложные архитектурные решение, которые усложняют систему и ее поддержку

  4. Не дайте пользователям вас запугать — о том, что пользователи часто диктуют свои условия развития продукта разработчику.




Мир разработки и консьюмерский мир похожи настолько, насколько похожа Матрица и мир Аватара, где проходили главные события киноленты Джеймса Кэмерона. То есть вообще не похожи.

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


Война двух миров ожесточается с каждым днем. Но давайте рассмотрим ситуацию с двух сторон.



Пользователь vs. Разработчик




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

  1. Пользователю всё-равно, сколько усилий потратил разработчик на создание приложения. Объяснить пользователю, что такое трудозатраты в 10 человеко-лет, все равно, что заставить его представить расстояние в 10 световых лет.

  2. Для среднего пользователя при выборе чего-либо важна не компания, набор функциональных возможностей или операционная система, а бренд и… внешний вид. Т.е. Samsung или Apple более важные слова, чем Android или Windows Phone.

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

  4. Пользователи не понимают 99% тех слов, которые им рассказывают разработчики и большинство консультантов. В итоге все заканчивается «хочу вон тот красненький с большими кнопочками», а фраза «хочу самсунговский айфон» уже давно не ставит в ступор.




Главный посыл в том, что, работая на консьюмерском рынке, большинство ваших пользователей — именно такие.

По статистике средний пользователь использует максимум 3% функциональных возможностей Microsoft Word. Мозг человека, в среднем, задействован тоже на 3%, из чего можно сделать вывод, что Word писался для полноценного человека, а пользуемся им мы :-)


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



  1. Программист не хочет ничего решать, он хочет зеркалку и свободный график.

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

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

  4. Разработчик, как правило, переоценивает важность своего продукта для окружающих и мирового научно-технического процесса.




Не все пользователи одинаковые, скажете вы, и будете правы. Есть профессиональный софт, есть продвинутые пользователи, есть разработчики, которые также иногда превращаются в обычных консьюмеров. Но, написав, несколько десятков мобильных приложений для топовых смартфонов, пришел к выводу, что нужно ориентироваться на пользователей, у которых IQ не сильно отличается от комнатной температуры. В таком случае ваша ЦА будет удовлетворена, а более продвинутая аудитория воспримет ваш продукт на ура!

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


Клиентоориентированность




Мы — клиентоориентированная компания! Как часто доводилось слышать эту фразу?

Клиентоориентированность — это способность компании создавать дополнительные оборот и прибыль за счет глубокого понимания и удовлетворения потребностей клиентов.


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


Как стать клиентоориентированными?



  1. Первое и самое главное — узнать, кто твой пользователь. Потом нужно мысленно с ним подружиться, а, главное, понять и простить его. Программист, который не любит делать фото, никогда не создаст Instagram. Программист, который никогда не пользовался социальными сетями, не создаст новый Facebook. Программист, который никогда не пользовался сервисами знакомств и не испытывал проблем с поиском партнеров (партнерш), никогда не создаст новую Mamba. Чтобы создать что-то стоящее, нужны не только хорошие профессионалы, но и единомышленники.

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

  3. Любить и верить в свой продукт.

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




Быть клиентоориентированным трудно. Вот одна история из жизни хабраюзера:


Сегодня утром мне звонит тот самый клиент и говорит что сайт у них не открывается. Яндекс открывается, а сайт не открывается. И мол звонили их партнеры и говорили, что сайт якобы закрыт на реконструкцию. Проверяю. Работает. Проверяю домен. Делегирован. Проверяю другие сайты на том же хостинге. Все ок. Прошу скриншот (рассказал как делать). Получаю картинку. Что там? Правильно, красочное предложение обновить браузер.







Объясню.


Картинка понятная, красивая, по-русски написанная. Но мне пришлось потратить 10 минут на то, чтобы объяснить:



  1. что такое браузер и почему он у них устарел;

  2. что бывают другие браузеры;

  3. что их клиент, который уверен что сайт «не работает», видел эту же надпись и теперь им надо его (ВСЕХ) предупредить;

  4. откуда это взялось (ребята из маленького города не стали предупреждать о своем оригинальном решении в области кроссбраузерной верстки);

  5. что с этим надо смириться.




Подумайте. Сайт рассматривали втроем. Директор предпенсионного возраста и 2 менеджера. Неглупые девочки. Наверняка у девочек есть стена вконтактике и страничка на дейтинг-сайте. А картинку не поняли. Обдумывали. Мне звонили. Это не про них пост. Не про тупых клиентов. Это про нас. Про студии. Про рынок. Про клиентоориентированность.



Не дайте астронавтам от архитектуры запугать вам




С таким названием когда-то давно вышла статья Джоэла Спольски, русский вариант которой можно почитать здесь.

Суть её в том, что сложная архитектура ради архитектуры — большое зло:



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


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





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

Например, нужно сделать загрузку файлов на сервер. Что, скорее всего, нужно сделать? Поставить контрол, который будет загружать файл на сервер, проверить на нулевой размер, формат и сохранить. Но тут подключается архитектурный астронавт и начинает бузить:



  • а что, если файлы будут огромные?

  • а что, если в момент 99,99% загрузки пропадет интернет-соединение?

  • а что, если пользователь зайдет с допотопного браузера?

  • а что, если у пользователя не будет включен Flash/JavaScript/другой нужный компонент?

  • а что, если у пользователя медленное соединение и поэтому нужно показывать динамику загрузки?

  • а что, если у пользователя зависнет браузер?

  • а что, если название файла будет слишком длинное?

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




Список можно продолжать практически бесконечно. В результате вместо 10-минутной задачи вырастает 3-месячный проект. Конечно, каждый пункт сам по себе, может быть, и важный, но сочетание всех факторов не встретится практически никогда (а если и встретится, то ничего катастрофического не произойдет, если пользователь выберет другое изображение).

Не дайте пользователям вас запугать




Есть и другая сторона продукта — ваши пользователи, которые тоже могут вас запугать.

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


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


Вместо заключения




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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Комментариев нет:

Отправить комментарий