Всякий раз, когда мы забываем о том, что на самом деле НУЖНО и ХОЧЕТ пользователь, мы можем попасть в кроличью нору ненужных решений, влияющих на наш конечный продукт.
Когда Пол Льюис, ведущий разработчик Google, проводил сравнительный анализ некоторых из самых популярных, недавно выпущенных веб-фреймворков и библиотек, он заметил, что многие из них фактически замедляют работу пользователей , иногда экспоненциально. Здесь он задался вопросом, почему разработчики обычно устанавливают и используют все, что только что вышло на прошлой неделе, без анализа показателей этих фреймворков.
Затем он понял, после некоторого взаимодействия со многими разработчиками в Твиттере, что эти разработчики были довольны «библиотекой или фреймворком» и выбрали все, что было выпущено на этой неделе, потому что во многих случаях, согласно его опросу, это был модным или забавным.
И весело играть с новейшими инструментами. Он резюмировал свой анализ того, что сказали ему разработчики, следующим образом: «получать удовольствие от написания кода для меня важнее других факторов».
В этом подходе, как выразился Пол Льюис, основное внимание уделяется «эргономике разработчика», а не изучению того, что такое взаимодействие с пользователем и как его можно улучшить, по сути, потребностям пользователя.
«Одержимость чистым кодом»
Дэн Абрамов писал об этом в блоге в посте, озаглавленном Прощай, чистый код, с другой точки зрения: с точки зрения разработчика, с точки зрения команды. Иногда мы, как разработчики, были одержимы написанием чистого кода. До такой степени, что мы можем в конечном итоге переписать большой кусок нашей кодовой базы ради чистоты или правильности.
Я говорю, что вы должны писать «грязный» код? Нет. Я предлагаю глубоко задуматься над тем, что вы имеете в виду, когда говорите «чистый» или «грязный». Вы чувствуете бунт? Праведность? Красота? Элегантность? Насколько вы уверены, что можете назвать конкретные инженерные результаты, соответствующие этим качествам?
- Дан Абрамов
И то, что он говорит, действительно важно. Вы не пишете код для себя, вы не единственный пользователь продукта, который хотите выпустить на всеобщее обозрение. И иногда мы, как разработчики, склонны думать, что наши усилия - это личное достижение и что «правильность» нашего кода - это признание, которое нам необходимо, чтобы подтвердить нас как хороших программистов.
Мы не учитываем правильные факторы
В последние годы я наткнулся на метод оценки, предположительно детерминированным способом, исход событий, который якобы невозможно определить с помощью других принципов. Эта методология в значительной степени опирается на математический и статистический анализ как предыдущей, так и случайной выборки для получения чисто числовых вероятностных оценок. Неудивительно, что этот метод называется «методом Монте-Карло» - да, в честь знаменитого Казино Монте-Карло в Монако.
Теперь я не буду оспаривать ценность правильного анализа закономерностей, статистического агрегирования возможных результатов и определения, формульным способом, вероятных сценариев, которые генерировались числами. Он широко применим в нескольких областях, таких как климат, физика, акции и даже здоровье.
Однако этот подход, основанный только на цифрах, нельзя полностью перенести на науку о человеческом поведении. По крайней мере, не в чистом виде. Человеческое поведение в основном эмпирическое, и, как бы многие ни пытались, вы не можете определить, как человек отреагирует на единичное событие, основываясь на множестве симуляций.
Поведенческая разработка
Я предлагаю привлечь пользователя и рассмотреть его реальные потребности и желания. Всякий раз, когда мы принимаем бизнес-решения, бюджет, планирование, мы имеем законное использование статистического анализа.
Однако позвольте мне процитировать из финансового мира одну из фраз, которые, как мне кажется, применимы ко многим жизненным и, конечно же, деловым ситуациям:
Прошлые результаты не являются гарантией будущих результатов
Количественный вероятностный следует сочетать с анализом чувствительности. Я бы сказал, что нет абсолютно никаких причин, по которым проект должен начинаться без полного и глубокого изучения главной цели, которую вы хотите включить в свой продукт: конечного пользователя.
Способность вызывать доверие к проекту определяется не только количеством и выборкой разрозненных симуляций, но скорее узнаванием того, кто в конечном итоге будет потреблять то, что вы собираетесь производить.
Позвольте пользователю управлять вашим развитием.
Поведенческая экономика и участие пользователя
Это ни в коем случае не новая наука. Фактически, в 2017 году Ричард Талер получил Нобелевскую премию в области экономики за исследование, которое установило, что:
«… Люди предсказуемо иррационально, что противоречит экономической теории»
- Ричард Талер, Нобелевская премия в области экономики
Таким образом, хотя вероятностные модели, математические алгоритмы, статистический анализ могут помочь понять, что произошло в прошлом событии, или смоделировать и оценить возможные сценарии, вы просто не можете пометить всех своих пользователей в электронной таблице. Вам нужно будет пойти в поле и лично убедиться, использовать продукт самостоятельно, поговорить с пользователем, испытать его чувства и взаимодействия.
Пол Льюис закончил свое выступление таким важным выводом:
Если на это у меня уходит дополнительная неделя, но каждый из моих пользователей получает лучший опыт, это того стоило… Вы всегда должны сосредоточиться на людях.
- Пол Льюис, руководитель разработчика в Google.
Данные (или деньги за то, что они стоят) должны быть фактором при принятии решения, но не решающим фактором.
И, кстати, когда Ричарда Талера спросили, как он потратит свои деньги на Нобелевскую премию, он «в шутку» ответил: «Я намерен потратить их как можно иррационально» .
Дальнейшее чтение:
- Инструмент Google's Lighthouse для оценки производительности веб-сайтов в браузере Chrome.
Спасибо за чтение!
