Jak często prędkość oprogramowania jest widoczna w oczach klientów?

Teoretycznie klienci powinni odczuwać poprawę wydajności oprogramowania z pierwszej ręki.

W praktyce czasami ulepszenia nie są dostatecznie zauważalne, tak że aby zarabiać na tych ulepszeniach, konieczne jest wykorzystanie wyników marketingowych w celu przyciągnięcia klientów.

Wiemy już różnicę między postrzeganą wydajnością (opóźnienie GUI itp.) A wydajnością po stronie serwera (maszyny, sieci, infrastruktura itp.).

Jak często programiści muszą dokładać dodatkowych starań, aby „pisać” analizy wydajności, dla których odbiorcy nie są innymi programistami, ale menedżerami i klientami?

Chociaż @jwenting ma kilka dobrych argumentów, muszę się nie zgodzić z ogólną oceną.

Użytkownik często nie zauważa niewielkich ulepszeń wydajności.

Z tym mogę się zgodzić.

Gdzie się nie zgadzam, dotyczy tego stwierdzenia:

większość aplikacji skierowanych do użytkowników końcowych spędza większość czasu na oczekiwaniu na wkład użytkownika.

Teraz, zanim skoczysz w górę i w dół, zgadzam się z tym stwierdzeniem! To stwierdzenie podkreśla jednak fakt często pomijany przez tych, którzy nie rozumieją właściwie, w jaki sposób użytkownik postrzega system.

Użytkownik będzie zauważyć, że aplikacja jest powolne, gdy trzeba czekać aż się załaduje. Użytkownik będzie to zauważyć, gdy muszą wstrzymać się do programu w pomiędzy wejściem swoich danych.

Wydajność oprogramowania jest oczywista dla użytkownika, gdy przerywa naturalną i płynną interakcję z systemem.

Użytkownik nie zauważy wydajności systemu tylko wtedy, gdy działa idealnie i nie trzyma użytkownika.

Niektóre ulepszenia wydajności nie są zauważane jako wydajność. Klient zauważy, że system „wydaje się” ładniejszy.

Podświadomość działa z prędkością znacznie większą niż świadomość. Nasze mózgi są zaprogramowane na natychmiastowe sprzężenie zwrotne, a gdy mamy do czynienia z sekwencją zadań, musimy je kolejno jeden po drugim. Niewielka przerwa w sprzężeniu zwrotnym powoduje rozłączenie tego procesu, co zwiększa poziomy stresu. Ludzie automatycznie klikną dwukrotnie przycisk, nie myśląc o tym, jeśli w informacji zwrotnej nastąpi przerwa.

Dość często poprawa wydajności jest tak niewielka, że ​​klient nigdy nie zauważa bezpośrednio. W najlepszym przypadku mogą mieć nieco płynniejszy przepływ aplikacji podczas korzystania z niego, ale nie na tyle, aby być świadomie zauważonym.

Pamiętaj, że większość aplikacji dla użytkowników końcowych spędza większość czasu na oczekiwaniu na dane wejściowe użytkownika, a nie na ich przetwarzanie. Więc nawet jeśli ogolisz 10% na 100 ms potrzebnych do przetworzenia tego kliknięcia przycisku i aktualizacji ekranu, użytkownik ledwo zauważy, że nie zrobi nic z tym zaktualizowanym ekranem przez kolejne 10000 ms.

Kto zauważy, to sysadmin, który widzi zadanie wsadowe, którego wykonanie zajęło 2 godziny, a teraz ukończenie w 90 minut, ale zauważy tylko, że jeśli będzie musiał czekać na wynik i być wściekły, szybszy powrót przerywa mu w połowie drogi przez jego film :)

Jak mówią dziś inni, bardziej chodzi o postrzeganą wydajność i „płynność” niż o rzeczywistą prędkość.

Oznacza to, że możesz uniknąć powolnego (er) systemu po prostu dzięki naturalnemu wyczuciu i rytmowi w interfejsie użytkownika oprogramowania, zamiast mieć pewne rzeczy zbyt szybkie, a inne bardzo wolne. (Jako ludzie zauważamy nieprawidłowości bardzo dobrze, ponieważ może to być tygrys, który się do nas podkrada ...)

Jest to niezbędne w ukrywaniu opóźnień, na które nie można nic poradzić, więc jest to dobra umiejętność do ćwiczenia.

Chciałem tylko wskoczyć tutaj i zaoferować niezwykły przypadek, w którym ...

* _{OBSŁUGA KLIENTÓW O POTRZEBACH WYDAJNOŚCI I ZAWIADOMIENIE O KAŻDEJ MAŁEJ ZMIANIE!} .

To w mojej dziedzinie zajmujemy się renderingiem produkcyjnym, który jest analizowany na śmierć pod względem wydajności przez samych klientów. Spowolnienie wydajności o 2% w porównaniu z mniejszą wersją może równać się spowolnieniu zgłaszanemu masowo w postaci „raportów o błędach”.

Wątki na forum są często rozpoczynane od klientów, którzy porównują swoje sceny z różnymi wersjami oprogramowania, gdzie klienci faktycznie porównują więcej niż sami programiści. „Ta scena zajęła 1 godzinę i 40 minut do renderowania w wersji X. Teraz zajmuje 32 minuty w wersji Y”.

„Załadowanie tej sceny zajęło 18 minut w wersji X, a teraz wczytanie w wersji Y zajmuje 4 minuty”.

Są niezwykle wdzięczni, gdy stosowane są optymalizacje, i to samo może być wystarczające, aby uzasadnić zakup nowej, bardzo drogiej aktualizacji oprogramowania, a czasami z niewielkimi poprawkami, takimi jak skrócenie czasu o 10%.

W niektórych większych kontekstach może również zaoszczędzić ogromne kwoty dla klienta, gdy produkt zostanie przyspieszony, ponieważ niektóre większe studia wykorzystują farmy renderujące, w których muszą płacić za setki maszyn renderujących przez cały dzień, a każda poprawa czasu tutaj może przyspieszyć cały proces produkcji (a być może nawet przynieść lepsze rezultaty, gdy artyści są bardziej produktywni, tworząc sztukę niż czekając na jej renderowanie).

Istnieją więc takie pola, w których klienci naprawdę, naprawdę, naprawdę to zauważają - czasem nawet bardziej niż sami programiści, i to jest poza koncepcjami interakcji interfejsu użytkownika, które bardziej dotyczą opóźnień niż przepustowości.

Jak często programiści muszą dokładać dodatkowych starań, aby „pisać” analizy wydajności, dla których odbiorcy nie są innymi programistami, ale menedżerami i klientami?

W naszym przypadku przez cały czas, z prawie każdym niewielkim wydaniem. Szybkość jest jednym z najważniejszych punktów sprzedaży, a nawet najbardziej techniczne testy porównawcze i analizy wydajności są doceniane i rozumiane przez klientów i menedżerów. Postrzeganie klientów jest często jak wściekłe wilki, spragnione dalszych optymalizacji i próbujące sugerować deweloperom, jak potencjalnie przyspieszyć. W tym przypadku oparcie się na niektórych pragnieniach klientów wymaga dalszej dyscypliny, aby dalej optymalizować i skupić się na innych wskaźnikach, takich jak łatwość konserwacji i ulepszenia funkcji.

Jedyne czasy, z którymi się spotykam to:

1. Oprogramowanie poprawia się, wykonując więcej pracy w tym samym czasie.
2. Renderowanie lub przetwarzanie offline jest znacznie szybsze, ale niewidoczne.
3. Zwiększenie prędkości jest nieco nominalne, ale ulepszenia zapobiegają w przyszłości wąskim gardłom
4. Dla wielu równoległe przetwarzanie, które wykonuje tę samą pracę z tą samą prędkością.
5. Za każdym razem, gdy niezauważalny wzrost prędkości silnie wpływa na wydajność.

Jeśli klient nie zauważy poprawy prędkości, dlaczego programista nad nimi pracował? Prawdopodobnie jest to dobry powód. Po co zarabiać na tej pracy, jeśli jest ona przezroczysta dla użytkownika?

Przykład: Apple pobiera około 130 USD za każdą aktualizację Mac OS X. Z wyjątkiem Snow Leopard, który jest sprzedawany za 30 USD. Programiści ciężko pracowali nad tą wersją, ale jest bardzo niewiele ulepszeń widocznych z punktu widzenia użytkownika. Apple zdecydowało się na minimalną opłatę.

Jak często programiści muszą dokładać dodatkowych starań, aby „pisać” analizy wydajności, dla których odbiorcy nie są innymi programistami, ale menedżerami i klientami?

Uważam, że to zależy od branży. W zwariowanym świecie kontraktowania obronnego robimy to dość często. Mamy określone wymagania, aby produkty działały w określony sposób - a te wskaźniki wydajności nie zawsze są bezpośrednio związane z czymś, czego doświadczył użytkownik końcowy. I generalnie przeprowadzamy własne testy, aby sprawdzić, gdzie produkt się kończy. Oba rodzaje testów są zapisane w raportach z poważnym przemyśleniem, co to znaczy.

To powiedziawszy, nie jestem pewien, czy to prawda w sytuacjach, gdy klient i baza wdrożeniowa jest mniej wyspecjalizowana (np. Świat komercyjny). Biorąc pod uwagę, że kupujemy COTS, które muszą spełniać specyfikacje dotyczące wydajności, mogę powiedzieć, że niektórzy nabywcy proszą o takie specyfikacje dotyczące wydajności, ale z mojego doświadczenia wynika, że ​​firmy COTS, do których chodziłem, nie zawsze mają tak wiele oficjalnych dokumentów dotyczących analizy wydajności dostępny. Wydaje się, że zależy to od branży, wielkości firmy i charakteru konkurencji. Ach ... kapitalizm.

Moim zdaniem, jeśli wzrost wydajności nie jest zauważalny, to nie można go sprzedać. Innymi słowy, dlaczego ktoś miałby płacić więcej za oprogramowanie, które nie jest zauważalnie ulepszone?

Myślę, że marketingowe twierdzenia o niezauważalnej poprawie wydajności skłoniły użytkowników w ogóle do przypisywania niewielkiej wagi takim twierdzeniom. Na przykład, kiedy chciałem zacząć korzystać z rozproszonej kontroli wersji, zignorowałem twierdzenia o wydajności git, ponieważ uważałem, że różnice będą nieistotne. Dopiero wypróbowanie tego na własne oczy przekonało mnie, że są wiarygodne, zwłaszcza w połączeniu z wsparciem inotify.

Zrobię wyjątek dla przyrostów wydajności, które nie są bezpośrednio związane z wrażeniami użytkownika końcowego. Na przykład przepustowość serwera ma znaczenie dla osób, które kupują i utrzymują serwery, nawet jeśli użytkownik końcowy nie zauważy różnicy. W takim przypadku wystarczy prosta „procentowa poprawa w stosunku do X”.

To zależy komu sprzedajesz oprogramowanie.

Częściej niż nie, klient nie jest użytkownikiem końcowym / codziennym. Tak często kończy się tworzenie ładniejszych i lśniących raportów zamiast naprawiania problemów z wydajnością. Ponieważ naprawdę sprzedajesz do zarządzania, a nie do użytkownika końcowego.

Co oznacza, że ​​w takim przypadku będziesz ciężko naciskać na pewne problemy z wydajnością, ale zarobisz najwięcej na automatyzacji tego raportu.