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

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

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

Ми вже знаємо різницю між сприйнятою продуктивністю (затримкою графічного інтерфейсу тощо) та продуктивністю на сервері (машини, мережі, інфраструктура тощо).

Як часто програмістам потрібно пройти додаткову тривалість, щоб «написати» аналіз ефективності, для якого аудиторія - це не колеги-програмісти, а менеджери та клієнти?

Хоча @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. За винятком снігового леопарда, який продається 30 доларів. Розробники наполегливо працювали над цією версією, але вдосконалень, які можна побачити з точки зору користувача, дуже мало. Тому Apple вирішила стягнути мінімум.

Як часто програмістам потрібно пройти додаткову тривалість, щоб «написати» аналіз ефективності, для якого аудиторія - це не колеги-програмісти, а менеджери та клієнти?

Я вважаю, що це залежить від галузі. У дурному світі оборонних контрактів ми робимо це досить часто. Ми маємо конкретні вимоги до того, щоб продукти працювали певним чином - і ці показники ефективності не завжди безпосередньо пов'язані з чимось досвідченим кінцевим користувачем. І ми зазвичай робимо власне тестування, щоб побачити, де продукт знизується. Обидва типи тестів записуються у звіти з серйозною думкою про те, що це означає.

З цього приводу я не впевнений, що це стосується ситуацій, коли база клієнтів та розгортання є менш спеціалізованою (тобто, комерційним світом). З огляду на те, що ми купуємо COTS, які повинні відповідати технічним характеристикам, я можу сказати, що деякі покупці просять про такі характеристики, але, на моєму досвіді, компанії COTS, до яких я поїхав, не завжди мають так багато довідок щодо аналізу ефективності. в наявності. Здається, це залежить від галузі, розміру компанії та характеру конкуренції. Ах ... капіталізм.

На мою думку, якщо підвищення продуктивності не помітно, вони не є товарними. Іншими словами, чому б хтось платив більше за програмне забезпечення, яке не помітно покращується?

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

Я зроблю виняток для підвищення продуктивності, безпосередньо не пов'язаного з кінцевим користувачем. Наприклад, пропускна здатність сервера матиме значення для людей, які купують і підтримують сервери, навіть якщо кінцевий користувач не помічає різниці. У цьому випадку достатньо простого "відсоткового покращення порівняно з X".

Це залежить, кому ви продаєте свій програмний продукт.

Частіше, ніж ні, ваш клієнт не є кінцевим користувачем. Тому часто ви робите більш приємні та блискучі звіти замість того, щоб виправляти проблеми з ефективністю. Тому що ти справді продаєш менеджменту, а не кінцевому користувачеві.

Що означає, що в цьому випадку вам буде важко натиснути, щоб визначити деякі проблеми, пов'язані з ефективністю, але ви заробляєте найкращий долар на автоматизації цього звіту.