Czy łatki są złym znakiem dla klienta? [Zamknięte]


14

W biurze właśnie wyszliśmy z długiego okresu, w którym wydawaliśmy łatki zbyt często. Pod koniec tego okresu robiliśmy średnio trzy łatki tygodniowo.

Oprócz tego, że było to bardzo demotywujące dla programistów, zastanawiałem się, co o tym pomyśli klient. Zadałem sobie pytanie i doszedłem do wniosku, że nigdy nie znałem oprogramowania, które było tak często aktualizowane. Jednak w przypadku najbliższego przypadku nie obchodzi mnie to, ponieważ łatki są dość szybko nakładane.

Klienci, którzy otrzymali te łatki, bardzo się od siebie różnią. Niektórzy naprawdę czekali na łatkę, na którą inni tak naprawdę nie dbali, ale wszyscy dostali te same łatki. Czas na aktualizację oprogramowania klienta wynosi mniej niż 30 sekund, więc nie oczekuję żadnych problemów dotyczących czasu. Muszą być jednak wylogowani.

Więc moje pytanie bardziej szczegółowo: czy pobieranie aktualizacji często daje odbiorcy komunikat „negatywny”?

Oczywiście mógłbym zapytać klientów, ale nie jestem w tej pozycji ani nie chcę „Obudź śpiące psy”.

PS: Jeśli jest coś, co mogę zrobić, aby poprawić moje pytanie, proszę zostawić komentarz.


@ downvoter, chcesz wyjaśnić?
Mixxiphoid

6
Jeśli martwisz się postrzeganiem klientów, możesz opisać je jako „aktualizacje”, a nie „łatki”? :)
Chris Taylor

Chociaż nie jest to bezpośrednia odpowiedź, jeśli możesz utrzymać wdrażanie łatek w sposób możliwie jak najbardziej nieinwazyjny i automatyczny (np. Pobierać aktualizacje w tle, mieć uruchomioną usługę aktualizacji w celu zastosowania w stanie bezczynności), możesz zmniejszyć niepokój użytkownika końcowego, nie czyniąc aktualizacje oczywistymi. Na przykład: ile aktualizacji Google Chrome otrzymałeś w ciągu ostatniego miesiąca? (Odpowiedź: wiele ) Mogliby wypuszczać 5 łatek na Chrome dziennie i nikt nie podniósłby brwi. Automatyczne aktualizacje systemu Windows (jeśli są włączone) są kolejnym przykładem.
Jason C

„Czas na aktualizację oprogramowania klienckiego jest krótszy niż 30 sekund, więc nie spodziewam się żadnych problemów dotyczących czasu. Muszą się jednak wylogować”. Co z klientem, który sami testuje łatkę? Nie wiem, z jakim oprogramowaniem pracujesz, ale jeśli jest to dla kogoś krytyczne, będą chcieli przetestować aktualizację przed uruchomieniem jej w środowisku produkcyjnym. Chociaż instalacja łatki może być szybka i łatwa, testowanie zajmie dużo czasu i wysiłku ze strony klienta.
CVn

@ MichaelKjörling Problem polega na tym, że w tym okresie krytyczne funkcje misji nie powiodły się, więc tak naprawdę nie miało znaczenia, czy środowisko produkcyjne czy środowisko testowe zostało najpierw zaktualizowane. Po prostu musiał działać jak najszybciej.
Mixxiphoid

Odpowiedzi:


24

Podobnie jak w przypadku wielu rzeczy w informatyce, to zależy. Jeśli poprawki są odpowiedzią na prośby klientów o nowe funkcje lub ulepszenia, wówczas Twoja firma będzie postrzegana jako elastyczna. Z drugiej strony, jeśli twoje łatki są odpowiedzią na zgłoszenia błędów, twoja firma będzie postrzegana jako niekompetentna.

wprowadź opis zdjęcia tutaj

Testowanie oprogramowania na klientach jest zdecydowanie najdroższym możliwym sposobem wykrywania błędów, bez względu na to, co ktoś mówi. To fałszywa ekonomia; bezpłatna siła robocza, o której myślisz, że jest więcej niż rekompensowana wysiłkami obsługi klienta, przerywaniem cyklu rozwoju oprogramowania i utratą zaufania klientów.


3
Może to powinno być inne pytanie, ale tak czy inaczej: wiedzieliśmy, że testujemy za pośrednictwem naszych klientów, ale nie mogliśmy tego zatrzymać w tym czasie, byliśmy uwięzieni w cyklu. Co możemy zrobić, aby wyjść?
Mixxiphoid

3
Robert, widziałem ten schemat wiele razy wcześniej. Prawdopodobnie było to poprawne, gdy tworzenie oprogramowania odbywało się według czystego modelu wodospadu, ale ponieważ oprogramowanie można opracowywać i wdrażać w małych cyklach, coraz bardziej się myli. Mówiąc dokładniej - w przypadku niewielkiej liczby błędów i oprogramowania tendencja jest nadal prawdziwa, w przypadku wielu błędów jest to zdecydowanie błąd.
Doc Brown

2
@DocBrown: Wykres jest nadal poprawny. Krótsze cykle rozwojowe oznaczają mniejszy koszt cyklu, co jest zgodne z wykresem. Ale to nadal nie oznacza, że ​​powinieneś przetestować oprogramowanie na klientach w wersji alfa, chyba że istnieje wyraźne zrozumienie i zgoda, że ​​jest to część procesu.
Robert Harvey

Koszt wad zmniejsza się, im wcześniej błąd zostanie znaleziony i naprawiony. Szansa na znalezienie błędu rośnie dramatycznie, im wcześniej wyjdziesz z oprogramowania. Nie oznacza to oczywiście, że należy wypchnąć niesprawdzone oprogramowanie do produkcji. Polecam na przykład ten artykuł agileelements.wordpress.com/2008/04/22/cost-of-software-defects
Doc Brown

1
Wystarczy trochę autorefleksji, aby zobaczyć, że sama zasada jest zdrowa, nawet jeśli liczby lub kształt krzywej są tylko zgadywankami. Mamy nawet na to nazwę w języku programowania: Fail Fast.
Robert Harvey

10

Wydaje mi się, że wydanie kilku łatek w bliskiej odległości źle wpływa na firmę. Zawsze mam wrażenie, że nie przetestowali wystarczająco dokładnie z góry, że programiści są niekompetentni lub zarząd nie ma pojęcia, co robią.

To powiedziawszy, drugą stroną tego tokenu jest to, że wydanie kilku łatek blisko siebie pokazuje, że firma proaktywnie podchodzi do swojego produktu i nadal udoskonala swój produkt dla konsumenta.

Bardziej skłonny jestem sądzić, że to pierwsze podejście jest tym, na co najbardziej patrzy się z punktu widzenia konsumenta, ale bezpośrednia rozmowa z nimi będzie (oczywiście) najlepszym wyborem, ale podniesie również problem w bazie klientów, że mogą początkowo nie byłem tego świadomy.


Podsumowując, czy powinniśmy próbować załatać tylko tych klientów, którzy naprawdę tego potrzebują, a pozostałych w późniejszym terminie, aby poprawić nasz wizerunek?
Mixxiphoid

5
Patchowanie dla indywidualnych klientów wydaje się być trudnym zadaniem, szczególnie jeśli istnieje duża baza klientów. Wdrażanie poprawek w regularnych odstępach czasu (co miesiąc, co dwa miesiące itp.) I promowanie poprawek wśród klientów może być dobrym sposobem na wzbudzenie zainteresowania „tym, co będzie dalej” z twojego produktu, a także rozwiązać problemy które są prasowane. Oczywiście odpowiednia dokumentacja i powiadomienia mają kluczowe znaczenie dla komunikowania się z użytkownikiem końcowym za pomocą notatek o poprawkach.
Jack

To naprawdę wiele dla mnie wyjaśnia. Wydaje się, że powinniśmy dołożyć starań, aby wykorzystać nasze łatki do poprawy naszego wizerunku. Do tej pory byłem przekonany, że to niemożliwe. Zawsze widziałem łaty jako zło konieczne.
Mixxiphoid

zależy również od tego, kiedy w cyklu wydania. Jeśli łatki są blisko siebie w pierwszych dniach po wydaniu, daje to inne wrażenie niż wtedy, gdy są (nadal) blisko siebie kilka miesięcy później.
jwenting

7

Coraz więcej firm podąża śladami Chrome i coraz częściej wypuszcza klientów.

Warunkiem wstępnym wdrożenia krótkich cykli wydawania jest bezbolesne uaktualnienie - na przykład w chrome uaktualnienie odbywa się bez interwencji użytkownika przy uruchamianiu aplikacji, a jeśli użytkownik utrzymuje swoją aplikację przez cały czas, otrzymuje niewielką flagę doradzając mu, aby zrestartował aplikację w dogodnym czasie, a następnie aplikacja stara się przywrócić go do poprzedniego stanu po ponownym uruchomieniu.

Ta metoda sprawia, że ​​klient jest szczęśliwy, ponieważ nie musi być świadomy każdej aktualizacji, a ponieważ wydania funkcji pojawiają się często, poprawki błędów będą równie mile widziane.

Z drugiej strony, jeśli łaty pojawią się po rażących błędach show-stoppera i pojawią się w klastrach, ponieważ wcześniejsze nie naprawiły błędu lub stworzyły większy błąd - bądź pewien, że Twoi klienci go wyczują. To z pewnością źle odbije się na profesjonalnej reputacji dostawcy i obniży postrzegane standardy oprogramowania. Ciągła dostawa w dużej mierze opiera się na skutecznych testach jednostkowych i testach integracyjnych, aby zagwarantować jej sukces.

Jeśli chodzi o to, aby nie rozmawiać z klientami, aby „pozwalali śpiącym psom kłamać”, uważam, że jest to zła strategia - klienci nie są ślepi i nie są głupcami. Uważam, że dobra komunikacja z klientami może tylko zapewnić ich, że są Twoim priorytetem i że jesteś otwarty na ich krytykę. Jeśli kilka razy dostarczyłeś złe wydania i nie słyszysz ich narzekania - zdecydowanie powinieneś się martwić - to nie jest tak, że ich nie zauważyli, bardziej prawdopodobne jest, że będą zajęci szukaniem dla ciebie zamiennika ...


2
Daję +1, jako częstemu klientowi oprogramowania, chcę, aby ludzie z częstymi aktualizacjami i dobre sposoby ich wdrażania. Produkty, które stoją w miejscu, są tutaj prawdziwą czerwoną flagą - przynajmniej oznacza to, że sprzedawca nie inwestuje w produkt. Lub zainwestuj w vNEXT, za który chcą, abyś znowu za to zapłacił.
Wyatt Barnett

Rozumiem z twojego ostatniego akapitu, że zawsze powinniśmy być uczciwi i transparentni w naszej komunikacji z klientem. Czy są sytuacje, w których nie powinniśmy (jeszcze) informować klienta o niektórych rzeczach?
Mixxiphoid

1
Oczywiście bycie uczciwym wobec klienta nie oznacza pozostawienia linii otwartej, ponieważ zwołujesz spotkanie paniki, aby złagodzić właśnie znalezioną katastrofę. Powinieneś przekazać te informacje po dokonaniu oceny sytuacji, opracować strategię, aby to naprawić, i możesz szczerze powiedzieć, że wszystko jest pod kontrolą. Być może upiększasz prawdę, ale szczere kłamstwa mogą cię prześladować później ...
Uri Agassi

2

Łatki przeznaczone specjalnie dla klientów, którzy wykryli problem, będą oczywiście musiały wyjść jak najszybciej.

Widziałem oprogramowanie w dużych firmach, a następnie przyjmowałem podejście, że inni klienci otrzymają te łaty jako dodatek Service Pack w regularnych zaplanowanych odstępach czasu. Zwykle dlatego, że łatki wymagają trochę wysiłku, aby zainstalować i przetestować w środowisku klienta, ale w twoim przypadku można go po prostu użyć, aby zmniejszyć potencjalny wpływ efektu, o który się martwisz.

Widziałem także ludzi, którzy zalecają umieszczanie łat w repozytoriach lub na stronach internetowych, na których klienci mogą pobierać i instalować te, które chcą. Może to powodować problemy ze zrozumieniem, jakie łatki mają klienci, więc kiedy dzwonią z problemem, musisz dokładnie określić, jakiego kodu używają, ale z ostrożnością, którą można śledzić. Następnie możesz zmusić ludzi do uaktualnienia do jednego z większych „pakietów”, gdy zostanie wydany, który zawiera wiele łatek.

Wyjątkiem są łatki bezpieczeństwa. Wiadomo, że duża firma z siedzibą w Waszyngtonie wchodzi do ciepłej wody, czekając na trzeci czwartek miesiąca, zanim wyda krytyczne poprawki bezpieczeństwa, a informacje o włamaniu wyciekły i zmusiły ich rękę do jeszcze większego zażenowania.

Google Chrome rozwiązuje ten problem, automatycznie aktualizując bardzo często, one również wymagają cyklicznego uruchomienia programu (uruchom ponownie Chrome lub, w twoim przypadku, wyloguj się). Wprowadzili teraz tę normalną praktykę dla przeglądarek, a ludzie nawet o tym nie myślą. Ale nie każdy może być Google.

Aplikacje SaaS rozwiązują cały problem, wykonując aktualizacje w tle.

Przede wszystkim jednak, chyba że często dokonujesz ciągłej integracji lub aktualizacji o nowe funkcje, o które prosił użytkownik, myślę, że wciąż jesteśmy w czasie, gdy ludzie oczekują, że przed wydaniem wykonałeś przyzwoitą liczbę testów. Jeśli wstydzisz się spotkać z klientami i porozmawiać o częstotliwości naprawiania błędów, prawdopodobnie nie wykonujesz wystarczającej liczby testów. Czy uwolniłeś się od ryzyka, które podejmowałeś przed wydaniem kodu? Istnieje argument za wypuszczeniem bardzo wczesnego kodu błędu, o ile wiesz, że tak właśnie jest, ale myślę, że musisz dobrze rozumieć swoją znaną jakość, co oznacza zrozumienie i kontrolowanie czasu na poznanie jakości.


+1, to jest kluczowy punkt - im szybciej możesz naprawić błąd (i wdrożyć), tym lepiej - o ile użytkownik / klient nie będzie miał dodatkowego wysiłku przy wdrażaniu. Gdy klient musi wdrożyć ręcznie lub aktualizacje zakłócą jego przepływ pracy, ważne jest, aby znaleźć odpowiednią częstotliwość wdrażania. Strony takie jak Facebook będą wdrażać kilka łatek dziennie i większość ludzi nawet tego nie zauważy.
Doc Brown

więc myślę, że mamy szczęście z tej strony. Nasze aktualizacje kosztują nas (oprócz stresu i kodowania i wszystko) tylko 1 lub 2 godziny. Powrót klienta do pracy kosztuje 1 minutę. Przyjrzę się podejściu opartemu na „dodatku service pack”, które może się przydać tym, którzy nie potrzebują bezpośrednio łatki.
Mixxiphoid

Znaleziono to odniesienie dla Facebooka: blogs.wsj.com/cio/2013/04/17/... , więc wydaje się, że są dwie wersje, a nie kilka dziennie. Wciąż imponujące.
Doc Brown

„Słyszałem”, że amazon kod push co 17 sekund. Ale umieszczam to w komentarzu, ponieważ nie pamiętam, kto mi powiedział, a Google go nie pokazuje. :-)
Encaitar

@Encaitar: Racja, architektura Amazon zawiera setki interaktywnych usług. Nie jestem więc zaskoczony, jeśli naciskają coś wyjątkowo często, ale bardzo wątpię, aby każde naciśnięcie miało bezpośredni wpływ na więcej niż jeden komponent. To, co widzisz jako pojedynczą stronę internetową, niekoniecznie ma ogólną wersję. To bardziej jak powiedzenie, że sieć dróg w mieście jest aktualizowana co 17 sekund, ponieważ twoje załogi malują w sumie 5 tysięcy świeżych linii dziennie :-)
Steve Jessop
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.