Распространенные «детские» ошибки на сайтах и причины их возникновения

Когда пользователь заходит первый раз на сайт, он судит его по "одёжке", то есть внешнему виду и дизайну. А первое впечатление о работоспособности складывается обычно при регистрации, если там что-то пошло не так, то это может сильно подорвать дальнейшее доверие к ресурсу.

Распространенной ошибкой разработчиков и самой банальной является неправильное предоставление пользователю его авторизационных данных. Простая очистка пароля от пробелов по обоим сторонам при валидации, как и других авторизационных данных, убрала бы большую часть таких проблем. Как обычно бывает, пароль отправляется на E-mail или в SMS и пользователь может его скопировать вместе с пробелом, или, вдобавок, переносом строки. Это может быть не только пароль, сейчас пароль перестали так просто отправлять в сообщении, последний хранится в зашифрованном виде и недоступен (в идеале) даже выдающей стороне, поэтому это может быть любой код подтверждения, на который должно распространяться такое правило.

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

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

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

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

К недостаткам сайта это имеет следующее отношение. Координированием задач и взаимосвязей между ними разработчики не занимаются. Это может быть инициативой начальника технического отдела, но как исключение, если ему больше занятся нечем. Ведь кроме технических задач там взаимосвязаны и дизайн и наполнение с утверждением, весь этот круговорот задач в природе. В итоге простая задача на проверку пароля может быть поставлена начинающему программисту, так как первостепенно у менеджера есть желание убедить остальных, что эта задача простая. Раздать больше задач и получить премию. Звучит это так: "Но это же простая задача - "исправить все баги на сайте"? Сайт уже есть, значит программировать ничего не надо." Даже если кто-то из более опытных программистов впоследствии заметит недостаток, он создаст заявку на исправление и отправит в бэклог в очередь, где задачи на рефакторинг и технические нужды пропадают как в черной дыре, то и в этом случае итог похожий. Тут можно долго рассуждать, в чьей ответственности находится предотвращение неправильного обращения с паролем у пользователя, постановщика задачи, тестировщика, или программиста, в конце концов, пароль был отправлен пользователю правильный. Эта "слепая зона" в ответственности, как и скорость работы сайта, часто порождает очередной недостаток проекта.

В идеальном мире развитием должен заниматься специальный человек, а не менеджер по работе с клиентами. Но найти такого человека, а здесь важную роль играют личные качества, не только образование, очень трудно. Получается, что развитием продукта в итоге занимаются клиенты. На что пожаловались, что захотели, такая задача переносится в отдел разработки. Мне встречались случаи, что такие хотелки значительно смещали даже тематику продукта, например портал для обучения включает дополнительно и управление клиентами и HR-отдел для клиентов и много чего ещё. Интересно наблюдать, как в таких случаях развиваются компании, они начинают быть похожими на огромных амеб, двигающихся только по направлению к рядом лежащей и немедленной пище.

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