Не знаю как было раньше, но в начале 00-х информацию собирали по крупицам, реально изучали язык, возможности, чтобы написать программу. Программу, которая работает, и полезна. Больше от неё не требуется, она просто должна стабильно выполнять свою задачу.
Сейчас тенденция совершенно другая. Весь мир разработки оброс кучей.. “мусора” (хотел написать другое слово), который превратил разработку программ в постоянные битвы между управлением, разработкой, тестированием, процессами, и в целом программный продукт стал восприниматься как вещь с завода, с конвейера, а про пользователя почти всегда забывают.
Так вот, простое правило – всё это для людей. Вся эта шелуха про управление, процессы, коллаборацию, всё это в конечном итоге должно приносить пользу конечным пользователям. Если на выходе получается продукт, который глючит или им неудобно пользоваться, то в процессах или в кадрах есть проблемы.
Фразы “для людей” и “приносить пользу”, это значит что человек должен открыть программу, понимать как при её помощи он может решить свои задачи (и решать их), и в любой момент её использования не быть потерянным в ней, не получить дискомфорта от использования, а быть постоянно в курсе что происходит.
Плохой пример – открыли форму авторизации, ввели наш логин и пароль, жмакнули “Войти”, и получили ошибку что логин и пароль не найден. О блин, так логин и пароль же мой?.. а где, куда, почему?.. а всё потому что разработчики не обработали ошибки авторизации, а просто лупанули один текст ошибки в UI на любую ошибку которая прилетит с сервера. И поэтому отсутствие интернета, долгие запросы, проблемы с прокси, падение сервера, деактивация аккаунта, да и миллион других сценариев, всё это работает неправильно. Человек откроет, не поймет, закроет. Ну напишет в поддержку. Хорошо это? Конечно нет. Нормально ли это? В современных процессах часто да, просто потому что “а давайте сделаем на одну фичу больше вместо обработки исключений”.
Еще один плохой пример, лично сталкивался, бесит – открываем интернет-магазин, набираем кучу товаров, пытаемся заказать, и получаем сообщение что требуется регистрация. Не вопрос, сейчас зарегистрируемся и оформим заказ. Регистрируемся, переходим в корзину… а там пусто. Финито. То есть теперь поднимай историю, ищи товары которые просматривал, снова выбирай параметры, добавляй в корзину. Ладно если там 1-2 товара, а если там 10? 50? Я затаривался аптекой во всем известной сети, выбрал 20 позиций, и поймал этот сценарий. Ничего хорошего в этом нет, пользователи страдают от такой работы программы.
Причем, поясню, под программой я имею ввиду не десктопное приложение, или под мобильные устройства, а вообще любой софт, включая веб-приложения, то есть любые сайты которыми мы пользуемся.
Теперь в бочку дегтя добавим ложку меда, приведем хороший пример. Мне лично нравится система загрузки фото. Нажимаем кнопку, видим файловый менеджер, выбираем фотку, и дальше должна начаться загрузка фото. Кажется что это довольно простой сценарий, однако:
Фотки бывают не подходящего размера
Фотки бывают не тех форматов.
Фотки бывают не тех пропорций.
Фотки бывают тяжелыми (как файл).
Фотка может быть битой.
Фотка может быть подделкой (файл).
Фотка может не загрузиться по причинам на стороне пользователя.
Фотка может не загрузиться по причинам на сервере сервера.
Фотка может не отобразиться после загрузки.
Фотка может быть загружена не полностью при попытке её отобразить.
Загрузка просмотра фото может зависнуть по сетевым причинам.
11 пунктов, не считая факта что пункты 7-8 можно развернуть в еще целую кучу сценариев. А еще загрузка фото может быть сопряжена с другими продуктовыми сценариями, из серии продолжения загрузки при потере соединения, при перезагрузке вкладки, при ошибках загрузки, ретраи (повторные попытки) загрузки фоток, и многое другое.
Всё это должно быть правильно обработано. Я видел сервисы которые реально всё это нормально обрабатывают. Ну, большую часть. Это очень круто, когда ты можешь отправить на загрузку 100 файлов за раз, и не переживать что из-за глюка в приложении ты потеряешь данные, состояние загрузки, историю, или еще что, и всегда уверен что в любом случае ты по максимуму завершишь загрузку. Именно поэтому я использую это приложение.
На практике обычно не так. Дело в том, что чтобы загрузка фото работала, при условии что всё работает штатно, у пользователя стабильный интернет, сервер работает вечно и без падений, провайдер огонь, и так далее – достаточно лишь провалидировать файл, отправить на сервер. а дальше всё, ждем ответа сервера полные уверенности что всё будет хорошо. Так себе это представляет бизнес, и когда управлению скажут что оно работает, но что-то может пойти не так, и на обработку этого не так надо еще +N дней, то есть увеличить время разработки фичи, например, в 2 раза, то обычно чаша весов склоняются в сторону “если не должно быть, в теории, то и не делаем, не критично”. И вот это не критично выливается в удобство использования и многочисленные негативные возгласы в отзывах на продукт.
Вобщем, думаю вы поняли о чем речь. Всё это следствия подхода к разработке продукта, как к конвейеру на заводе. Задача бизнеса выпустить и собрать сливки, заработать денег. Пользователи же наоборот, хотят пользоваться удобным и работающим продуктом. Так вот, я думаю что такие задачи бизнеса это прямое противоречие интересам пользователя, если является основной целью бизнеса когда они думают про выпуск продукта. В большинстве случаев, на моей практике, компании именно стремятся выпустить, начать зарабатывать, но совершенно забывают ради кого и чего они это делают. Вот это и есть проблема. Если раньше люди (подчеркну, отдельные люди) писали программы (winrar, виктория, куча другого старого офигенного софта), импровизировали, пытались сделать удобно, хорошо, и не парились о том сколько они на этом заработают, потому что это прежде всего творчество, сейчас наоборот, программа воспринимается как продукт на полке магазина – главное выпустить и продать.
Теперь немного выдохнем (фух). Подумаем как с этим быть разработчикам.
Всё понятно, есть задачи, есть цели компании, мейлстоуны, надо сделать 100 фичей за 3 месяца, и всё это выпустить к релизу пропиаренному маркетингом. Что я могу сказать.. Если прямо, то рыба гниет с головы. Разработчик может 1000 раз быть прав, стараться сделать хорошо, но решения принимает не он. Даже если встать в позу зю и сказать “или так и сделаем хорошо, или никак”, скорее всего будет эскалация с последующей заменой разработчика. Поэтому обычно все разработчики всё понимают, но делают как надо бизнесу.
Бывает и другая ситуация, и честно говоря, сильно чаще. Это когда сам разработчик не понимает что фича не доделана. Он берет требования, делает как написано в бумажке, а то что там отвалится, или как это будут поддерживать другие разработчики, или все ли сценарии обработаны, он не продумал. Часто это нехватка опыта, особенно заметно у начинающих или средних (какое странное слово) разработчиков. Здесь всё просто – просто спрашивайте себя “что может здесь пойти не так?”, и ищите сценарии при которых что-то может отвалиться. Это и есть исключительные сценарии работы программы. Кроме того, отличный вопрос это "А что здесь может потребоваться пользователям еще?". И еще один отличный способ найти пропущенные исключительные сценарии, это просто пройти по всем путям кода в данном участке программы, и проследить необработанные пути. Обычно это или отсутствие else, или switch без дефолтного кейса, потерянная обработка события, и так далее.
Лично мое мнение, что разработчики почти бессильны в условиях когда управление диктует свои приоритеты и правила, и именно управление выбирает набор того что делаем, или не делаем (реализуем) в программе, на уровне реализации фичей, а не верхнеуровнево из серии “хочу систему регистрации”. Именно поэтому весь этот текст по большей части для управленцев, особенно для технарей которые управляют своими командами, и менеджерам – не забывайте что программа в конечном итоге должна помогать пользователям решать их задачи. Это единственная причина почему они используют вашу программу. А комфорт от использования, удобство, обработки ошибок, всё это в сумме создает опыт использования, и если он положительный, то люди придут именно к вам, а не к вашим конкурентам. Поэтому принимайте решения из расчета на реальных людей, ваших пользователей, а не на бюджеты, сроки, релизы, проблемы в процессах, давление сверху. Всё это пути к хреновым продуктам.
Данным текстом выражаю две вещи:
Разработчики, не пишите код для того чтобы написать код. Творите программу, пишите для людей, думайте про людей, это конечная цель в разработке продукта. Документы, дизайны, и вся остальная шелуха, всё это лишь инструменты производства, а не панацея. Думайте про использование продукта, думайте со стороны пользователя, и делайте продукты лучше. Не ориентируйтесь на то что написано в документах как на догму, всё переосмысливайте, перечитывайте, изучайте продукт, сценарии использования, исключительные сценарии, и результатом своей работы помогайте пользователям.
Управленцы, всё что вы делаете должно иметь целью облегчить жизнь пользователям в их задачах. Процессы, давление сверху, релизы, маркетинг, всё это ходит вокруг идеи выпуска качественного продукта, и поэтому подгоднять процессы, требования, бюджеты, сроки, лишь бы успеть и выпустить, это движение в обратную сторону. Это как жать педаль газа и тормоза одновременно, и зависимости от того что сильнее, туда и приедете. Так нельзя. Движение должно быть только максимально вперед, даже если релиз будет позже и дороже.
У меня всё.
Всем спасибо!
Комментарии (31)
maxzh83
22.12.2022 00:12+16Забудьте про корпоратив, делайте для людей
Подумал, что речь будет про новогодний корпоратив. Читал и думал как же от программ для людей перейдем к отмечанию НГ.
В остальном статья полезная. К сожалению, в отдельных направлениях тренд такой, что количество фичей важнее их качества. Возможно, скоро это прекратится, как гонка мегапикселей в фотоаппаратах.
jerboa85
22.12.2022 04:35Подумал, что речь будет про новогодний корпоратив. Читал и думал как же от программ для людей перейдем к отмечанию НГ.
Наверно смысл будет тот же, что и с программами - руководители, делайте интересное времяпрепровождение для людей, вместо уже осточертевших бухло-тамада-пошлые конкурсы. :)
tandzan
22.12.2022 02:32С чем недавно столкнулся. На госуслугах предлагают пройти детям пройти курсы программирования. Требуется пройти предварительное тестирование. Тест на логику с ограничением по времени. В конце теста облегченно выдыхаешь и жмешь "отправить" и ничего не происходит. Открыл главную страницу сервиса в другом окне - похоже просто по таймауту разлогинивает. (Переписал ответы с повисшей страницы в блокнот, залогинился, быстро забил ответы и отправил, уф)
shadovv76
22.12.2022 10:20востребованность ПО определяется уникальностью функционала, а остальные ПО-миньоны обречены соревноваться в милоте.
Такие компании как Apple, к примеру, легко убеждают своего пользователя как ему будет удобнее и люди адаптируются и адЕптируются.
имел ввиду упомянутые Госуслуги в той части где их ничем не заменить.
idelgujin
22.12.2022 03:02-3Основная задача программы, да и любой автоматизации - приносить деньги. Если пользователю неудобно - его проблемы. Он получает за это з/п, пусть терпит. Если ПО из за неудобства теряет конкурентное преимущество, то подключаются маркетологи. А тратить время/деньги чтобы кому-то там было удобно, бизнес не намерен.
Denis_Chernyshev
22.12.2022 08:31+1Деньги бизнесу приносит работа человека, или автомата. И от качества программы зависит производительность человека, приносящего прибыль.
А от качества программы, управляющей автоматом зависит вообще все. При работе с автоматами у вас нет права на баги и глюки.
idelgujin
22.12.2022 10:48-1Вы мыслите как потребитель программы. А мой комментарий - мысли разработчика. Зачем мне как бизнесмену вкладывать деньги в удобство и качество? Конечно, если удобство и качество помогут принести дополнительную прибыль - я только за. Но гораздо проще нанять маркетологов и юристов. Первые объяснят что программа - лучшая на свете и альтернативы нет, а другие, в случае убытков от неправильной работы ПО скажут что вы сами виноваты.
Denis_Chernyshev
22.12.2022 11:31А что они будут объяснять родственникам пассажиров Боинг 737 max?
idelgujin
23.12.2022 02:05"Это была трагедия. Мы вам сочувствуем." и вытрут слёзки 100-долларовыми купюрами
shadovv76
22.12.2022 10:13Соцсети?
idelgujin
22.12.2022 10:53Да, соцсети. Посмотрите во что превратился ВК. Сделали хуже. И всё ради бабла.
shadovv76
22.12.2022 11:19+1не пользуюсь ВК, ну следуя вашей логике в статье, там не должно быть пользователей...
ну вы, как бы, сами себе подобрали антипример. разве востребованность этому ПО придает "сделанность для людей"?
следуя моей логике Ваш пример ВК подтверждает, что востребованность ему придает уникальность функционала, а именно возможность общения с более полным количеством нужных лиц не смотря на монетизацию.
sergeykonshin
22.12.2022 08:40Ни заказчик ни исполнитель результатами своего труда не пользуются, следовательно делается всё на откуп KPI
Отсутствует независимая площадка для получения обратной связи от пользователей. Чаще по политическим причинам (все помнят урны для отзывов)
У пользователей нет желания самостоятельно кооперироваться и решать неудобные для них моменты , перекладывая ответственность на других (социальный феномен выученной беспомощности или банальная лень)
Зачем тратить нервы на решение бытовых it-вопросов в организации, если проще поменять организацию (дополнительный стимул к развитию)
В конце концов инициатива покарает инициатора, если кто-нибудь осмелится довести решение проблемы до конца.
И проблема тут вовсе не в плоскости it. Капитализм-с
18741878
22.12.2022 09:46+1Программистам этот KPI ни в одно место не сдался. Как можно оценить его работу? Сделал вовремя, но плохо? Сделал отлично, но задержал со сроками? Конечно, лучший вариант: отлично и вовремя, но так бывает совсем-совсем не часто и практически всегда вины программиста в низком качестве и срыве сроков нет (о чем чуть ниже). Что выберет пользователь (внимание - ПОЛЬЗОВАТЕЛЬ, но не "эффективный" менеджер, коих расплодилось больше, чем тараканов в квартире алкашей)?
И, как обещал, несколько слов, почему программисту редко удается сделать качественно и уложиться в сроки. Помимо "эффективных" менеджеров, есть масса совершенно неподготовленных людей, которые в той или иной степени курируют постановку требований и процесс разработки. Сидит такое создание, надувает щеки, бизнес-требования прочел (если прочел) по диагонали, их требований не понимает. Его главная цель - собственный KPI, который должен быть закрыт вовремя и с заранее известными показателями. То, что работа фактически не делается - неважно. Делается видимость работы: созвоны, совещания, перетирания одного и того же. При этом такие менеджеры по существу ничего ни сказать, ни сделать, ни договориться не могут. Они выполняют функции координатора и поставщика итоговых протоколов и резюме (которые, конечно-же, нашпигованы ошибками, нестыковками, несуразностями и прочим мусором). Но - видимость есть, значит, KPI будет нарисован, премия получена.Все это, разумеется, IMHO. В разработке я почти 30 лет и всякого повидал. Но современные подходы к управлению разработкой просто жуткие: все можно сделать качественнее, быстрее и дешевле без этого "эффективного" планктона. Извините, ежели кого обидел - ничего личного :)
dynamicult
22.12.2022 12:21все можно сделать качественнее, быстрее и дешевле
Пожалуйста, расскажите - как?
18741878
22.12.2022 13:01+1Автор статьи рассказал об этом в конце статьи (пункты 1 и 2). Добавлю от себя. Поменьше прослоек между бизнесом и программистами. Эти прослойки создают эффект испорченного телефона.
День/другой, проведенный разработчиком у заказчика после получения задания и бизнес-требований, дают, как правило, адекватную картину того, что нужно сделать и позволяют оценить сложность и сроки. Хороший тимлид вкупе с вменяемым архитектором и аналитиком организуют все как надо: придумают, нарисуют, проработают варианты. Обычно, самое сложное - не сам код, который нужно написать, а взаимодействие (интеграция) этого кода с уже существующими системами + обеспечение требований безопасности. Непосредственное взаимодействие с заказчиком/бизнесом - работоспособный и надежный вариант.
Иначе - получается кормушка для кучи дилетантовdynamicult
22.12.2022 13:33Правильно я понимаю, что вы предлагаете возложить работу менеджеров на лидов и архитекторов, чтобы они общались с заказчиками, и работу продукт овнеров, как кураторов проекта для программистов? За счет этого предлагается удешевление?
Остается неясным откуда берутся качество и скорость. Работы и ответственности у кого-то только прибавилось.18741878
22.12.2022 14:27Что именно делают менеджеры? Они понимают, что такое разработка? Из чего она состоит? Их задача максимум - заключить договор (если это внешний заказчик) и следить за тем, чтобы оплата поступала в нужных размерах и вовремя.
Вот если заказчик вдруг меняет требования, то их задача - добиться нужных условий по срокам и объемам переработки (за которыми он все равно придет к тимлиду, архитектору и аналитику). Все - большего от него никто не ждет.Что делает оунер? Задача должна быть понятна прежде всего трем перечисленным ролям: тимлид, архитектор, аналитик. Именно они, а не оунер, будут рисовать схемы, разбираться с API, учитывать пожелания заказчика и доносить информацию для разработчика. Именно они огребут если что-то пойдет не так.
Оунер будет блеять, не понимая - а он-то тут при чем.
Кураторы? А это что за категория? Они умеют тестировать, рефакторить, решать проблемы производительности, безопасности, восстановления после сбоев, резервирования и проч? Что они делают?dynamicult
22.12.2022 15:40Product Owner - это владелец продукта со стороны исполнителей. Именно он выступает звеном между Заказчиком (бизнесом) продукта и исполнителями. Все вопросы о видении конечного результата, все бизнес-требования исходят от него, а он их выясняет у бизнеса. Он является ответственным за продукт перед Заказчиком. Именно к нему может обратиться любой конечный программист, двигающий кнопку, когда у него есть вопрос именно к заказчику. А не звонить директору бизнеса.
Еще есть Product Manager - это оновной Руководитель проекта. Он отвечает за ход работы над проектом, контролирует эту работу, распределяет задачи по Командам и отдельным специалистам.
Есть Команды ответственные за те или иные части проекта. У каждой команды есть Лиды. Лиды ответственны за конечные фичи, баги, таски, делегированные его команде и работу этой команды. Лид распределет задачи по конкретным программистам/дизайнерам/прочим исполнителям, которыми руководит.
Еще есть Архитекторы и Аналитики - они все отвечают за Проектирование и работают с Product Manager и Product Owner. Когда проект сугубо технологический, со стороны бизнеса выделяются специалисты, которые находятся в тесном контакте с Product Manager и Аналитиками для уточнения технических требований.
Судя по вашим сообщениям, вы предлагает всю работу по управлению проектом, выяснению требований и контролю за проектом переложить на Лидов, Архитекторов и Аналитиков.
Это, конечно, очень здорово. Только снова не понятно - где тут удешевление? За счет сокращения количества должностей? А будут ли Лиды, Аналитики и Архитекторы брать на себя дополнительную работу и ответственность за дешево. И самое главное, а справятся ли они с такой нагрузкой вдобавок к своей зоне ответственности. И откуда возьмется обещанная скорость и качество?18741878
22.12.2022 15:52+1Спасибо за подборку определений. Но ответьте теперь вы: что такое управление проектом? Что вкладывается в это понятие? Довольны ли тимлиды/архитекторы тем, что они по 2-3-4 часа в день присутствуют на каких-то непонятных им встречах? Довольны ли они тем, что у них не остается времени распределять задачи, проверять их исполнение, рефакторить и выполнять прочую техническую работу? Они этим занимаются. Ночью и в выходные. Пока PO и PM наслаждаются заслуженным отдыхом.
А техлиды/архитекторы если они не будут присутствовать, то 1). им вставят дыню и 2). им донесут информацию в искаженном виде. Они и так эту информацию добудут: быстрее, конкретнее и правдивее. Т.е. в конечном счете - дешевле.
Довольны ли архитекторы, которым приходится искать встречи с заказчиком и конкретно уточнять - что ему, действительно, нужно? Потому что добиться чего-то конкретного на встречах с участием PO и PM и не утонуть в потоке пустопорожней трепотни - невозможно.
У нас с вами принципиально разные взгляды. Вы - смотрите со стороны PO/PM, я - со стороны технарей. Боюсь, мы не столкуемся :)
v3shin
22.12.2022 10:48+1Кстати, есть еще хорошая практика пользоваться результатами своих трудов. Так лучше понимаешь пользователя и видишь, что можно исправить/дописать.
pyrk2142
22.12.2022 11:43Имхо, тут все не так однобоко, как описано в статье, есть ещё минимум два момента:
Сейчас стало довольно много разработчиков, которые живут в практически идеальных условиях: современнейшая техника, последние модели телефонов, постоянный интернет не ниже LTE, устойчивая связь даже на другом континенте. И это приводит к тому, что даже очень плохо написанные сервисы внезапно работают довольно хорошо (у этих разработчиков). И возникает ощущение, что так у всех. Пару лет назад я обсуждал с разработчиками и безопасниками очень известной соцсети, что для того, чтобы получить доступ к практически любому аккаунту достаточно знать номер телефона и прервать доступ человек в интернет на 5 минут. И эти люди (весьма молодые) на полном серьезе говорили, что у них интернет не пропадает, они все уведомления всегда получают, таких проблем нет. И только после обсуждения того, что есть самолёты, есть поезда, есть подвалы, есть даже реанимации, где интернет есть, но пользоваться обычно им не хочется, начался конструктивный диалог. Существует довольно много разработчиков, которые в целом с проблемами не сталкиваются, зачем им писать нормальные (а критерий нормальности - тоже спорная штука)) формы и сервисы.
-
> Так себе это представляет бизнес, и когда управлению скажут что оно работает, но что-то может пойти не так, и на обработку этого не так надо еще +N дней, то есть увеличить время разработки фичи, например, в 2 раза, то обычно чаша весов склоняются в сторону “если не должно быть, в теории, то и не делаем, не критично”. И вот это не критично выливается в удобство использования и многочисленные негативные возгласы в отзывах на продукт.
Довольно часто (не сказал бы, что в большинстве случаев, но встречается нередко) бывает немного другая ситуация: приходит условный бизнес/руководство и говорит, что надо сделать что-то очень хорошо (я это обычно это наблюдаю в вопросах безопасности из-за специфики работы, но это встречается много где), выделяет разработчикам запрошенное время, спрашивает, нужно ли ещё что-то, все ок. А в результате оказывается, что не сделано практически ничего, в худшем же случае резко возникает десяток историй про то, что все хорошо, это коллеги ничего не поняли, все сделано так, как договаривались. Проблема частично в том, что хорошо разрабатывать очень скучно: надо делать много рутинных и обязательных вещей, которые делать лень. Скорее всего, вам самому было бы лень делать проверки на все те случаи загрузки файла, которые описаны в статье, гораздо проще выкинуть ошибку с кодом 200 и написать «Ошибка загрузки». И только самоуважение, серьезная дисциплина разработки, либо неизбежная кара за косяки приводит к тому, что ПО получается довольно качественным хотя бы на уровне отсутствия базовых проблем, вроде непонятных ошибок или постоянных вылетов.
manfredima
23.12.2022 12:00"Тот, кто работает киркой, хочет, чтобы в каждом ее ударе был смысл. Когда киркой работает каторжник, каждый ее удар только унижает каторжника, но если кирка в руках изыскателя, каждый ее удар возвышает изыскателя. Каторга не там, где работают киркой. Она ужасна не тем, что это тяжкий труд. Каторга там, где удары кирки лишены смысла, где труд не соединяет человека с людьми."
// А. де Сент-Экзюпери "Планета людей"
MAXInator
Извините, но примеры - фигня. Я не разработчик сервисов, но если бы им был - я бы ограничился всего двумя ответами: "неверный логин/пароль" и "сервис недоступен". В данном случае ответ вроде "пользователь не найден" отсекает одну из степеней защиты, идентификацию.
С учётом этой ошибки нет доверия компетенции автора в остальном и пропадает желание анализировать остальной текст.
Fen1kz
Нужно так:
AleksandrB
Mishootk
Вот именно, вы не разработчик сервисов. И скорее всего редкий пользовтаель таких сценариев.
Пишем для_людей. То есть на любом этапе работы с сервисом у человека должно быть понимание что сейчас происходит и какое единственное исправление ему надо сейчас сделать, чтобы пройти дальше. Исправление его ошибки должно приводить всего лишь к изменению одного последнего действия пользователя. В случае ошибки не по вине пользователя должна выдаваться четкая инструкция что делать дальше (ждать, писать туда-то, пробовать альтернативный вариант с прямой ссылкой на его начало...)
Неверный логин/пароль. Хе. Расписываю. Ошибка в логине, такого нет. Недопустимые символы в логине (одно устройство позволило завести пользовтаеля с ним, на втором такой вход невозможен - я с этим сталкивался). Ошибочный пароль к этому логину. Недопустимый набор символов в пароле (валидация на форме отлупила раньше чем пошли на авторизацию). Ошибка процедуры авторизации отличающаяся от просто неработающего сервиса. Таймаут формы регистрации.
Это я еще не начал ругать смартфонные формы ввода, когда экранная клавиатура заслоняет форму, заслоняет активное поле, "enter" на клавиатуре делает перевод строки, а не переходит к следующему полю. Или "enter" на клавиатуре жмет "дальше" на форме, не давая ввести дополнительные поля... А пользователю всего лишь вылетает "неверный логин/пароль".
У меня есть жена, сын, куча родни, рядом с которыми я периодически сижу и прошу "давай, показывай как у тебя не получается". Я догадываюсь что там внутри может быть и как с этим справиться. Они - нет. Писать надо так, чтобы не надо было догадываться.
doctorw
В данном случае пример с формой авторизации неудачный, имхо.
На форме авторизации нельзя однозначно сообщать пользователю ошибка в логине или пароле или что такой логин не найден, потому что это упрощает работу злоумышленникам.
А чтобы не приходилось думать над сообщением о некорректных символах в логине/пароле, нужно не допускать даже их ввода как на UI так и проверки на стороне бэкэнда.
Mishootk
В контексте безопасности я с вами полностью согласен.
Пример вне моей области работы тоже, поэтому я так же косячу как и новичек в области безопасности.
Задача сложнее чем казалось бы - нужно одновременно и упростить жизнь пользователю и не понизить взломостойкость. Хотя, мне кажется, удобство пользователя не пострадает, если оставить детализацию по ошибкам, но защищаться от брутфорса другими методами.
mayorovp
С одной стороны, для "классических" систем безопасности вы правы. С другой стороны — я давно уже не видел сайтов где логин был бы и правда секретным! Всегда в качестве логина используется или электронная почта, или номер телефона, или номер счёта, или ник. У злоумышленника куча способов узнать их и помимо формы аутентификации.
doctorw
При поведении без детализации ошибки, если ввести некоторую почту и пароль, то пока не попробуешь восстановить пароль, наверняка нельзя сказать, зарегистрирован ли такой логин вообще в системе, вот в чём суть. Как мне кажется.