Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Приходилось ли вам мочить пользователей в сортире?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

На мысль меня навела вот эта вот статья

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

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

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

Так вот. Должен ли программист учитывать потребности пользователя при построении интерфейса, путь и нелогичные, или программисту известно лучше?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Программист должен и учитывать потребности и предлагать пользователю что-то более простое и логичное на его взгляд. Если пользователь сопротивляется и вопрос не минутный и критичный, то программист должен вывести проблему на уровень CTO. И ждать от него команды — «делать как сказано» или «делать как лучше». Такой алгоритм, мне кажется.

Если пользователь сопротивляется
Это пять. «Федя, шо за херня тут сделана?! Мы теряем пользователей!!!» — «Эээ, ну я учел потребности пользователей и предложил более логичное на мой взгляд...»

Предложил пользователю вариант реализации. А не сделал как показалось лучше.

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

Если программист не имеет контакта с конечным пользователем тогда никакой самодеятельности. Предложения и идеи отдаются «наверх» по служебной лестнице.

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

Должен ли программист учитывать потребности пользователя при построении интерфейса, путь и нелогичные, или программисту известно лучше?
Отвечу вопросом на вопрос (как в Одессе): а должен ли пользователь четко следовать инструкции или рассчитывать что приложение, как хороший муж, должно «само догадаться» что он имел ввиду нажимая 10 кнопок сразу?
Думаю для начала надо выкинуть слово «должен». Во-первых пользователь точно никому ничего не должен: ни инструкции, ни товару, ни его производителю. Во-вторых производитель, в принципе, то же не должен заботиться о пользователе. Его цель получить прибыль, а не порадовать или спасти дурака. Поэтому инструкция прежде всего нужна что бы избежать претензий от тех, кто решил попробовать «нелогичные» способы использования продукта и в результате лишился ценной части тела.
А без «должен» степень «дружелюбности», «эргономичности», «интеллектуальности» и т.д. приложения определяется исключительно экономической целесообразностью.
Если это приложение для нового супер-дорогого «интеллектуального» мерседеса то оно должно работать как вышколенный слуга («Не соблаговолит ли высокоуважаемый сэр произнести название или хотя бы кивнуть в знак одобрения названия нижайше предложенного приложением?»).
А если это бесплатная Убунта то пускай юзер сам найдет какие волшебные заклинания надо набрать в консоли. Если он не любит садо-мазо киберсекс с линуксом, то пускай купит винды.

Вот почему я люблю lowlevel, который не имеет шанса встретиться с пользователями, а только API выставляет.

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

иии кто виноват в сложившейся ситуации?...

История — фуфел, ИМХО. При таком раскладе, чтобы отключиить датчик пола, вовсе не обязательно ждать русо туристо, который по-нашенски залезет на толчок ногами, достаточно запустить п**рать карлика, который сидя по-человечески тупо не достанет ногами до пола, или любого другого чувака, который от нефиг делать будет сидеть и поджимать ноги.

это не Задорнов рассказывал вам эту историю случайно?

Как часто, вместо того чтобы организовать простой сбор потребностей пользователей по пользовании к ПО, мы им просто кастомизируем готовую систему, к которой им приходится привыкать, пусть даже указанный программистом путь решения — полностью правильный, а предыдущий пользовательский — дурацкий.
Полный бред!
Сбором потребностей и согласованием их с юзером программисты не занимаются, это задача BA/PM/sales-ов и прочих любителей красного словца. К программистам требования уже приходят более менее устаканенными и программисты уточняют мелкие детали реализации.
Они не обязаны беспокоиться о том, что будет, если кто-то додумается налить в кастрюлю бензин и поставить кастрюлю в микроволновку.

Программисты — важнейшее, но не единственное звено разработки.
Без BA/QA/dev-ops их труд невозможен.

Должен ли программист учитывать потребности пользователя при построении интерфейса, путь и нелогичные, или программисту известно лучше?
Программист выполняет то, что ему говорят и пишут.
Хорошо когда есть подробное ТЗ, а если нет, то пишут кто как хочет. Кто-то поставит проверочку, а кто-то положит болт и пойдет играть в бильярд.
Потому что собственная инициатива наказуема. Программисту пофиг: есть баг — фикшу, нет бага — не фикшу!
Вы бы лучше спросили чем занимаются бизнес аналитики и QA, которые так плохо протестировали туалет?

Вывод: все что описано в ТЗ программист реализует. То чего там нет......извините.
Нет ТЗ ? — пишите на себя жалобу!

P.S. Если пользователь не читает инструкций, не соблюдает элементарную технику безопасности, а сует голову в неприятности, то я не возражаю. Чем меньше дураков — тем лучше.

все что описано в ТЗ программист реализует. То чего там нет......извините.

Это не программист, а быдлокодер за 500$ из Индии.

или за 2-3-4k$ из Украины.
Вы вообще в курсе какие у программиста обязанности?

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

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

Явного процента нет, но более охотно идет повышение зарплаты. И да в продуктовых повышают зарплату внутри кампаний, а не только при переходе с бошопа в бодишоп.

Т.е. вы хотите сказать, что в противополжном случае разработчики получают процент от прибыли? Сильно сомневаюсь.
Косвенно. Т.е. если компания выходит в ноль — то зп тебе не повысят. А вот если все отлично — то проще будет платить тебе чуть выше рынка, чем искать человека тебе на замену.

Есть большая разница между «качеством» и «функциональностью». Если бы проблема была в том, что унитаз не выдержал тяжести человека — то да, вопросов нет, виноваты «программисты» (а точнее — отдел разработки, и то не факт). А вот если продукт имеет непонятный функционал, а не плохое качество исполнения — то проблема таки у проектировщиков.

А.Райкин — Кто сшил костюм
— К пуговицам претензии есть? — Нет, пришиты намертво, не оторвешь! ... и никто ни за что не отвечает)
www.youtube.com/...h?v=heUq31_Zyd0

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

Программисты — важнейшее, но не единственное звено разработки.
Угу, а колеса — важнейшая часть машины :). Как бы у нас не чесалось ЧСВ, но если навернется хоть одно «звено» — то продукт разработки будет хреновым.
Без BA/QA/dev-ops их труд невозможен.
Для особо впечатлительных управленцев специально написал сразу под низом, ах да, я менеджера не написал сюда, какая жалость.
И программисты — не колеса, а двигатель автомобиля.
И программисты — не колеса, а двигатель автомобиля.
ну если все таки придалбываться к аналогии, то именно колеса осуществляют сам процесс взаимодействия с поверхностью покрытия(в результате чего появляется сила трения,которая и движет автомобиль вперед). А двигатель — всего лишь генерирует крутящий момент.

Так что с точки зрения колес — самые главные все таки они.

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

но если навернется хоть одно «звено» — то продукт разработки будет хреновым.
Вы не поверите, но погроммистов (я не ошибся) в бодишопах не интересует результирующее качество продукта в связи с тем, что заказчик либо сэкономит на сервере и поставит 1 гб памяти + pentium 630 (или просто недостаточное железо для системы), либо захостит в Афганистане, либо натянет на систему ненатягиваемый шаблон и еще 100500 вариантов. Заказчик платит деньги за свои капризы и его никто не осуждает.

Программисты мыслят в рамках своих тасков и всячески стараются сделать их качественно. Если разработчику не доверяют, не посвящают в планы развития системы, не доверяют проектировать/менять архитектуру, то о какой ответственности за продукт идет речь?

Представьте себе хирурга, которому разрешили только сделать надрез, а другому только зашить, а саму операцию никому не разрешили. У программистов все точно также.

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

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

Я пытаюсь донести свою мысль в теме топика о том, что бесполезно винить одно из составных частей: программистов за фейл с туалетом.
Меня почему-то с детства приучали к мысли, что в любом факапе виноват начальник/руководитель проекта, по причинам:
1) плохо руководил, например шатался по офису и пил чай на кухне, не интересуясь процессом разработки продукта
2) не проконтролировал сам качество продукта
3) не нанял дополнительную команду для тестирования, которая необходима для устройств и агрегатов, которые могут нанести вред здоровью и жизни людей.
4) не выбил у начальства денег на команду из п.3

Раз в проекте зачем-то есть руководитель/PM/CTO, но он сам не кодит и не тестит, а условия не создал, то факап — его.

Меня почему-то с детства приучали к мысли, что в любом факапе виноват начальник/руководитель проекта, по причинам
Абсолютно верно. Единственное с чем я был не согласен в вашем изначальном комментарии — это с «самой важностью» программистов (если что — я таки произвожу код, так что имею право себя считать и программистом ещё).

Собственно тут и наблюдается противоречие в логике — если программисты самые важные — то они и ответственность должны нести.

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

Тут возникает несколько вопросов:
1) Если "менеджеры не нужны"© — то почему их держат? Собственнику они нафиг не сдались.

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

3) В чем же роль руководителя? С вашей точки зрения, конечно.

1) Если "менеджеры не нужны"© — то почему их держат? Собственнику они нафиг не сдались.
Чтобы осуществлять коммуникации и создавать условия тем, кто создает продукт.
2) Я не знаю ни одного предприятия, которое вытянули бы рабочие
Я привожу обратный пример — без рабочих менеджеры тоже не нужны.
но знаю много примеров, когда грамотный руководитель спасал положение.
А я за свою жизнь много раз видел, как руководитель подставлял своего подчиненного, и его штрафовали и увольняли.
3) В чем же роль руководителя? С вашей точки зрения, конечно.
Создать нормальные условия работы для подчиненного. Выдать подчиненному таски, оказывать содействия с вопросами по таскам. Оградить от лишних коммуникаций. Все коммуникации — только через него.
Проводить объективное performance review
Я привожу обратный пример — без рабочих менеджеры тоже не нужны.
Не совсем так. Хорошие руководители смогут вытянуть компанию, даже имея не лучших работников (в конце-концов просто заменят). А вот хреновые руководители угробят компанию, не зависимо от качества работников.

И тут вопрос даже не "важности"(глупо рассуждать, о том что более важно — двигатель или колеса) а ответственности.

А вот насчет задачи руководителя — не совсем правильно. Задача руководителя — это управлять (как ни странно).

Есть те, кто считает себя руководителем, но ни чем не управляют — они просто существуют параллельно.

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

И есть те, кто управляет работой: прогнозируют последствия, отбирают исполнителей, создают и направляют процесс(но не людей!) и создают условия для работы. И это, на мой взгляд — лучший вариант руководителя.

«управлять» — такой же термин как женская логика.
Сколько раз не угадывай — все равно не прав.

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

«вытянуть компанию» — все это пафос для книжек по маркетингу и курсов «работай 4 часа в неделю!».
Любой руководитель отстаивает собственные интересы и пока они совпадают с интересами владельца компании, все в шоколаде и эйфории.

А когда начинают расходиться.....начинаются терки, а на Западе даже скандалы с бешеными выходными пособиями.

Сколько раз не угадывай — все равно не прав.
Ну если нет опыта — то да, так и будет.
«вытянуть компанию» — все это пафос для книжек по маркетингу и курсов «работай 4 часа в неделю!».
Правда? ну почитайте биографию того же Джобса, Ли Якокка... да собственно у любого «большого» руководителя были взлеты и падения.
Любой руководитель отстаивает собственные интересы и пока они совпадают с интересами владельца компании, все в шоколаде и эйфории.
Все мы отстаиваем исключительно свои интересы. Вот только разница в том, что у руководителей связь между личным благосостоянием и благосостоянием компании куда лучше прослеживается, соответственно и влияние больше.

ну это только с точки зрения разработчика. а с точки зрения компании (владельцев) именно менеджеры приносят деньги. т.е. именно у менеджерам ставятся задачи «возьми сто тысяч и завтра из них сделай двести», а они уже с помощью программистов их выполняют. программист выступает в качестве молотка? на каком-то уровне абстракции — да. на еще бОльшем уровне абстракции в роли молотка выступает менеджер, так как именно он ассоциируется с конкретным подразделением

С точки зрения владельца он сам делает деньги.
Вложил в бизнес 200, получил 400, вот на эти 2% и живу.

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

по моему у вас не было опыта работы в стартапе

Вы правы. Бодишоп наше все.
Вы твердо убеждены, что туалеты выпускаются стартапами?

Я уверен, что стартапы есть на все.
Даже если это никому не надо.
К примеру, стартап для туалетов с шарингом событий в твитере, типа:
#WC По*рал
#WC По*сал

Без BA/QA/dev-ops их труд невозможен

Вы не застали тех времен, когда программер в одно рыло писал бухгалтерию для небольшого завода. Да и сейчас не весь софт делается в больших фирмах, где есть специально обученные BA/QA/PM-ы. Более того, на основании моего 25-летнего опыта могу сказать, что чем короче цепочка между юзером и программистом, тем полезнее программы получаются.

Как бы да — но где те программы?..
Все, кто так делал — вылетели с рынка.
Полезность оказывается кратковременной, только «на сейчас». И ее необходимо постоянно поддерживать. В результате рано или поздно у вас на руках чемодан без ручки (документации, сопровождения и автора) ...

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

Примеры в студию. Желательно именно про десятилетия.

Хм... Ну ладно, придется. Моя система учета криминологической информации, написанная на Clipper и С в конце 90-х, работала в Запорожском областном УВД влоть до 2005 года, причем 12 лет без моего сопровождения. Пользовали интенсивно: ежедневный ввод информации о преступлениях и происшествиях по области, ежедневная выдача сводок начальству и всяческих отчетов всем заинтересованным службам.

Вот, к слову, не так давно хантили на проект, где несколько опытных буржуйских программистов и нет тестеров. Проект — либа, сдк.

Отсутствие тестировщиков не означает отсутствие тестирования.
DevTest, CodeReview, Unit, Doc — так или иначе что-то ведь делается.

Работал на нескольких проектах без тестеров, тестировали сами, заказчик и пользователи.

да, раньше машины так делали. Без краш-тестов. Тоже только пользователи тестировали...

чем короче цепочка между юзером и программистом, тем полезнее программы получаются.
* Если юзер один. Если их хотя бы 10 — то вы разорветесь, а пользователи будут недовольны

Выход прост: выбрать из них главного юзера, а остальные пусть спорят с ним

Остальные могут считать по другому — и свои разногласия вымещать на исполнителе. Будет «мальчик для битья по клавиатуре» ...

Это вопрос организации. Нужно сразу ограничить доступ к телу (программиста) только уполномоченному представителю заказчика, который заинтересован и знает предметную область. Конечно, по сути получается, что он становится PM-ом и QA :)))))

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

Вопрос о выгоде спорный. Если заказчик — сам QA и PM, вам не надо платить своим QA и PM-у

И не надо получать маржу на этом — да, так действительно проще.
BA/QA/PM — функции, так или иначе кто-то их выполняет. Может повезет, что взлетит, даже если их не делать — но скорее всего не взлетит или разобьется.

Простите, а вы когда нибудь продукт для массового рынка делали?

Ну может быть, можно считать таковым 3-мерный тетрис на J2ME, который скачали более 60000 раз? ;) Ладно, ладно, ребята... Все знаю! Это спор кустаря-сапожника с рабочими обувной фабрики. Времена меняются безусловно

Меня просто задевает, когда низкое качество продукта объясняют спецификой индустрии и чудовищные затраты на эксплуатацию этого кривого продукта полагаются в порядке вещей.

Качество — это понятие расхожее.

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

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

Наверное кто-то сделал свою работу плохо, но это были явно не работяги, которые собирали этот ножик.
Работяги собирали по чертежу.
Или вы думаете, что фрезеровщик Иван Дулин бросится тестировать юзабилити нового изделия?

вот и я о том же. Если изделие чертежу соответствует — то и ок.

А по-другому и быть не может.
Иначе ОТК и отдела Главного Инженера просто не выпустит партию изделий.

Бодишопам выгодно, когда вместо 3 человеко-лет на программу тратится 1000 человека лет и еще 10000 человеко-лет на сапорт. Они же биллят в часах.

Если их хотя бы 10 — то вы разорветесь, а пользователи будут недовольны
"А у кого есть вопросы — задавайте их вон той кирпичной стене! "© South Park
Вы не застали тех времен, когда программер в одно рыло писал бухгалтерию для небольшого завода.
Поступок героический и достойный уважения, но бесполезный.
Я до сих пор вижу что бухгалтера все пересчитывают на калькуляторах, а только ПОТОМ заносят в 1С, в 90-х я видел как многие считали на счетах.
Вопрос — для кого была эта бухгалтерия?
Должен ли программист учитывать потребности пользователя при построении интерфейса, путь и нелогичные, или программисту известно лучше?

Это больше работа дизайнера, чем программиста.

Тоесть программист — этакий джумшут, которого не интересует конечный результат его работы?

Обычно кроме «построения интерфейса» есть много других интересных и важных задач.

Там инструкция на двери туалетов в картинках. Надо читать.

Так ему и надо, ибо нефиг.

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

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

Підписатись на коментарі