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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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