Как часто скорость программного обеспечения очевидна в глазах клиентов?

10

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

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

Мы уже знаем разницу между воспринимаемой производительностью (задержка GUI и т. Д.) И производительностью на стороне сервера (машины, сети, инфраструктура и т. Д.).

Как часто программистам приходится прилагать дополнительные усилия, чтобы «составить» анализ производительности, для которого аудитория - это не коллеги-программисты, а менеджеры и клиенты?

rwong
источник

Ответы:

20

Хотя @jwenting делает некоторые хорошие замечания , я должен не согласиться с общей оценкой.

Пользователь часто не замечает незначительных улучшений производительности.

С этим я могу согласиться.

Где я не согласен, вращается вокруг этого утверждения:

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

Теперь, прежде чем прыгать вверх и вниз, я тоже согласен с этим утверждением! Однако это утверждение подчеркивает факт, который часто упускают из виду те, кто недостаточно понимает, как пользователь действительно воспринимает систему.

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

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

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

Дэн МакГрат
источник
5
К сожалению, некоторые программисты чувствуют необходимость играть, ожидая от своих пользователей ожидания. Я видел это в производственном коде на днях:Thread.Sleep(1000); //pretend this does more than change a 0 to a 1 in the database.
Бен Л
Это должно быть сделано проверкой кода разумными разработчиками. Это может привести к тому, что людям, которые занимаются продвижением продуктов питания, следует отозвать лицензию на принятие решений.
Дэн МакГрат,
2
@BenL, с другой стороны, я столкнулся с противоположной ситуацией: некоторые операции выполнялись медленно, пока мы не делали быстро, настолько быстро, что пользователи думали, что действие либо не выполнено, либо не выполнено.
Питер Б
2
@BenL: К счастью, современный UX явно рекомендует использовать анимацию вместо вставки произвольных задержек.
rwong
5

Некоторые улучшения производительности не замечены как производительность. Клиент просто заметит, что система «чувствует себя» лучше.

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

Mongus Pong
источник
Да, но есть ограничения. Люди не заметят вещи намного быстрее, чем одна десятая секунды, поэтому любой ответ в 100 мс или меньше - золотой. Снижение отклика, скажем, от 250 мс до 100 мс сделает вещи более гладкими. Переход от 100 мс до 40 мс не будет иметь почти такого же эффекта.
Дэвид Торнли
3

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

Помните, что большинство приложений для конечных пользователей проводят большую часть своего времени в ожидании пользовательского ввода, а не в обработке этого ввода. Таким образом, даже если вы сбрасываете 10% от 100 мс, необходимых для обработки этого нажатия кнопки и обновления экрана, пользователь едва заметит, поскольку он не будет ничего делать с этим обновленным экраном еще 10000 мс после.

Кто заметит, тот системный администратор, который видит пакетное задание, которое раньше занимало 2 часа, чтобы завершить его теперь за 90 минут, но он заметит только то, что если ему придется ждать результата и злиться, быстрое возвращение прерывает его на полпути через его фильм :)

jwenting
источник
С точки зрения системного администратора, это также может означать наличие трех, а не четырех серверов, чтобы справиться с нагрузкой, и это важно. Также было то место, где я работал, где ежедневный пробег занимал 18-20 часов, при условии, что ничего не пошло не так. Менеджер хотел бы сократить это.
Дэвид Торнли
да, это крайние случаи. Работал над одним таким, где работа, которую нужно было выполнять раз в день, требовала 36 часов. Был в состоянии провести рефакторинг до «всего лишь» 20 часов. Клиент был доволен :)
jwenting
2

Как говорят сегодня другие, речь идет скорее о воспринимаемой производительности и «текучести», чем о фактической скорости.

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

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

Маке
источник
2

Я просто хотел прыгнуть сюда и предложить необычный случай, когда ....

* ЗАКАЗЧИКИ БЕСПЛАТНО ЗАБОТАЮТ О ЭФФЕКТИВНОСТИ И УВЕДОМЛЕНИИ КАЖДОГО ИЗМЕНЕНИЯ МАЛЕНЬКОГО! ,

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

Темы форумов часто начинаются с того, что клиенты сравнивают свои сцены с различными версиями программного обеспечения, где клиенты фактически сравнивают друг с другом больше, чем сами разработчики. «Рендеринг этой сцены занял 1 час 40 минут в версии X. Теперь в версии Y это занимает 32 минуты».

«В версии X загрузка этой сцены заняла 18 минут, а в версии Y - 4 минуты».

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

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

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

Как часто программистам приходится прилагать дополнительные усилия, чтобы «составить» анализ производительности, для которого аудитория - это не коллеги-программисты, а менеджеры и клиенты?

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


источник
1

Единственные случаи, когда я сталкиваюсь:

  1. Программное обеспечение улучшается, выполняя больше работы за тот же период времени.
  2. Оффлайн рендеринг или обработка заметно быстрее, но невидимы.
  3. Повышение скорости несколько номинально, но улучшения предотвращают узкие места в будущем
  4. Параллельная обработка, которая выполняет одну и ту же работу с одинаковой скоростью для многих.
  5. В любое время незаметное увеличение скорости сильно влияет на производительность.
Гарет Клаборн
источник
1

Если клиент не заметит улучшения скорости, почему разработчик работал над ними? Вероятно, есть веская причина. Зачем монетизировать эту работу, если она прозрачна для пользователя?

Пример: Apple взимает около 130 долларов за каждое обновление Mac OS X. За исключением Snow Leopard, который продается за 30 долларов. Разработчики усердно работали над этой версией, но с точки зрения пользователя очень мало улучшений. Поэтому Apple решила взимать минимум.

mouviciel
источник
1

Как часто программистам приходится прилагать дополнительные усилия, чтобы «составить» анализ производительности, для которого аудитория - это не коллеги-программисты, а менеджеры и клиенты?

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

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

bethlakshmi
источник
1
Поддерживая множество продуктов COTS, я могу заверить вас, что производительность - это не то, что их волнует. Пользователям все равно, когда они звонят клиенту, и переход от одного экрана к следующему занимает десять минут (на самом деле я имел дело с плохо разработанным COTS-продуктом, стоимость которого превышает 100 КБ). Но производители COTS не имеют прямого отношения к разгневанным пользователям и, следовательно, для них это не важно.
HLGEM
0

Мое мнение: если прирост производительности не заметен, значит, он не годен для продажи. Другими словами, зачем кому-то платить больше за программное обеспечение, которое не заметно улучшилось?

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

Я сделаю исключение для увеличения производительности, которое не имеет прямого отношения к опыту конечного пользователя. Например, пропускная способность сервера будет иметь значение для людей, которые покупают и обслуживают серверы, даже если конечный пользователь не заметит разницы. В этом случае достаточно простого «процентного улучшения по сравнению с X».

Карл Билефельдт
источник
0

Это зависит от того, кому вы продаете свой программный продукт.

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

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

Питер Б
источник