Podejście do poprawiania błędów w stylu macho

Oryginalny post: Hard-assed Bug Fixin'

Autor: Joel Spolsky

Jakość oprogramowania lub jej brak jest czymś, na co ludzie lubią narzekać. Teraz mam swoją firmę i w też postanowiłem coś z tym zrobić. Przez ostatnie dwa tygodnie zatrzymaliśmy wszystko w Fog Creek, aby wydać nową wersję FogBUGZ, mając na celu wyeliminowanie wszystkich znanych błędów (było ich około 30).

Poprawianie błędów to dobra rzecz. Ale czy na pewno? Czy zawsze to dobry pomysł?

Nie!

Warto poprawić błąd tylko wtedy, kiedy zysk z jego poprawienia przekracza koszt wymaganej pracy.

Te rzeczy są trudne, ale nie są niemożliwe do zmierzenia. Pozwól, że przytoczę przykład. Wyobraź sobie, że zarządzasz fabryką kanapek z masłem orzechowym i galaretką. Twoja fabryka produkuje 100000 kanapek dziennie. Niedawno, z powodu wprowadzenia kanapek w nowych smakach (czosnkowe masło orzechowe z ostrym dżemem Habanero), popyt na Twoje produkty poszybował ostro do góry. Niestety maksymalna wydajność Twojej fabryki to tylko 100000 kanapek, podczas gdy rynek byłby wstanie wchłonąć 200000. Ponieważ każda wyprodukowana kanapka przynosi Ci 15 centów zysku, każdego dnia tracisz $15000.

Zbudowanie nowej fabryki kosztowałoby o wiele za dużo. Nie masz na to środków i obawiasz się, że ostre, czosnkowe kanapki są tylko chwilową zachcianką. Nie zmienia to faktu, że tracisz $15000 każdego dnia.

Na szczęście zatrudniłeś Jasona. Jest on czternastoletnim programistą, który włamał się do systemów zarządzających fabryką i wierzy, że znalazł sposób, by dwukrotnie przyspieszyć taśmę produkcyjną. Czytał on kiedyś o podkręcaniu na stronie slashdot. Okazało się, że faktycznie to działa.

Jest tylko jedna rzecz, która wstrzymuje Cię przed wprowadzeniem tych zmian. Mały, malutki błąd, który sprawia, że co godzinę rozwala się jedna kanapka. Jason chciałby go naprawić. Uważa, że jest w stanie tego dokonać w ciągu trzech dni. Pozwoliłbyś mu na to, czy wdrożyłbyś zmianę do systemu z tym małym błędem?

Opóźniając wprowadzenie zmiany o trzy dni zmniejszysz swoje zyski o $45000. Ale dzięki temu zaoszczędzisz koszt wyprodukowania 72 kanapek (w obu przypadkach Jason poprawi błąd w ciągu 3 dni). Cóż, nie wiem ile kanapki kosztują na Twojej planecie, ale na Ziemi ich łączna cena nie przekroczy $625.

O czym to ja mówiłem. Aha. Czasami nie warto poprawiać błędu. Przytoczę kolejny błąd, który nie jest wart poprawienia. Program wywala się podczas otwierania dużych plików. Występuje on tylko u jednego użytkownika, który ma zainstalowany system operacyjnego OS/2 i który nawet nie używa, z tego co wiesz, dużych plików. Cóż, nie naprawiaj go. Podobnie przestałem przejmować się ludźmi z 16 kolorowymi ekranami lub używającymi Windows 95 bez żadnych uaktualnień od 7 lat. Tacy ludzie nie wydają dużo pieniędzy na oprogramowanie. Uwierz mi.

Niemniej w większości przypadków, warto poprawiać błędy. Nawet jeśli są to "nieszkodliwe" błędy. Mogą one podważyć reputację Twojej firmy i Twojego produktu, co na dłuższą metę będzie miało znaczący wpływ na Twoje zyski. Ciężko jest poprawić reputację, kiedy ma się produkt pełen błędów. Kiedy chcesz wydać wersję .01, poniżej znajdziesz kilka pomysłów jak znaleźć i naprawić właściwe błędy. To znaczy te, dla których jest to ekonomicznie uzasadnione.

Krok pierwszy: Upewnij się, że masz wszystkie informacje o błędzie.

W przypadku FogBUGZ mamy na to dwa sposoby. Po pierwsze: wyłapujemy wszystkie błędy z naszego darmowego serwera demo, zbieramy tyle informacji, ile to możliwe i wysyłamy e-mail do całego zespołu programistów. Dzięki temu znaleźliśmy wiele błędów. Na przykład odkryliśmy kilka osób, które nie wpisały dat na stronie "Fix For". W tej sytuacji nie wyświetlaliśmy nawet komunikatu o błędzie. Program po prostu się wywalał (co w przypadku aplikacji webowej objawia się tym, że wyświetlana jest paskudna strona zawierająca szczegóły błędu). Ojej.

Kiedy pracowałem w Juno, mieliśmy nawet fajniejszy system do automatycznego zbierania danych o błędach od użytkowników. Instalowaliśmy handler wykorzystując bibliotekę TOOLHELP.DLL tak, aby za każdym razem kiedy Juno się wywalił, żył on na tyle długo, aby zapisać obraz stosu wywołań do pliku. Podczas następnego uruchomienia program łączył się z Internetem i wysyłał e-mail z załączonym plikiem. Podczas beta testów zbieraliśmy te pliki, gromadziliśmy wszystkie nieobsłużone wyjątki i wprowadzaliśmy je do bazy śledzenia błędów. Pozwoliło nam to znaleźć dosłownie setki błędów, które powodowały nieprawidłowe działanie programu. Kiedy masz milion użytkowników, niesamowite jest to, co może być powodem błędu. Często wynikało to z poważnych problemów z pamięcią lub bardzo gównianych komputerów (czy potrafisz przeliterować Packard Bell?). Wyobraź sobie, że Twój program zawiera poniższy kod:

  int foo(object& r)
  {
   r.Blah();
   return 1;
  }
 

Może się on wywalić, ponieważ referencja r miała wartość NULL, nawet jeśli jest to niemożliwe i nie ma czegoś takiego jak referencja NULL, bo C++ to gwarantuje. Nie musisz mi wierzyć, ale kiedy czekasz wystarczająco długo, masz milion użytkowników oraz fanatycznie zbierasz ich zrzuty pamięci, odkryjesz, że program może wywalić się w takich miejscach jak to i nie uwierzysz swoim oczom. (I nie naprawisz tego.Użytkowniku, spraw sobie nowy komputer i tym razem nie instaluj każdego fajnego sharewarego oprogramowania, które znajdziesz. Kurde!).

Po drugie: każde (bez wyjątku) wezwanie wsparcia technicznego jest traktowane jako przejaw błędu. Kiedy je obsługujemy, próbujemy znaleźć sposób, aby wyeliminować podobne zgłoszenia. Na przykład, stary instalator FogBUGZ zakładał, że FogBUGZ będzie uruchomiany na koncie użytkownika anonimowego. To było poprawne założenie w 95 i błędne w 5 procentach przypadków, ale każdy z tych 5% kończył się telefonem do naszego wsparcia technicznego. Zmodyfikowaliśmy instalator tak, by pytał użytkownika o konto, na którym ma być uruchomiony FogBUGZ.

Krok drugi: Upewnij się, że dostajesz ekonomiczny feedback

Możesz nie być w stanie dowiedzieć się dokładnie, jaką wartość ma poprawienie każdego błędu, ale jest coś, co możesz zrobić: pobierać opłaty za obsługę techniczną od działu produktowego. Na początku lat 90-tych w Microsofcie odbyła się finansowa reorganizacja, która ustanowiła, że każdy dział produktowy będzie obciążany pełnym kosztem wszystkich wezwań wsparcia technicznego. Działy produktowe zaczęły nalegać, by PSS (wsparcie techniczne Microsoftu) dostarczał regularnie listę 10 najczęstszych błędów. Kiedy zespół programistów skoncentrował się na nich, koszt obsługi technicznej drastycznie spadł.

Zaprzecza to trochę nowemu trendowi, w którym dział obsługi technicznej jest samodzielnie finansowany. Tak robi większość dużych firm. W Juno oczekiwano od działu obsługi technicznej pobierania opłat za pomoc techniczną. Przez przeniesienie na użytkowników ekonomicznego bałaganu związanego z finansowaniem błędów, tracisz tę ograniczoną możliwość sprawdzenia szkód, które wyrządzają. (Zamiast tego masz zirytowanych użytkowników, którzy odmawiają zapłaty za Twój błąd, którzy rozpowiadają o tym swoim znajomym i nawet nie możesz zmierzyć, ile to wszystko Cię kosztuje. Aby być sprawiedliwym wobec Juno: produkt był bezpłatny, tak więc przestań narzekać.)

Jednym ze sposobów rozwiązania tego problemu jest nie pobieranie opłat od użytkownika, kiedy zgłoszenie spowodowane jest błędem w Twoim własnym produkcie. Microsoft tak robi i jest to całkiem przyjemne. Nigdy nie zapłaciłem za wsparcie techniczne Microsoftu. Zamiast tego, pobierz od grupy produktowej $245 lub tyle, ile kosztuje poprawienie zgłoszenia przez programistę. To zniweluje ich zysk za produkt, który ci sprzedali (kilkukrotnie) i tworzy właściwe motywacje ekonomiczne. Przypomina mi to o jednym z powodów, dla których gry DOS były strasznym biznesem. Aby sprawić, by wyglądały dobrze i działały szybko, potrzebowały zazwyczaj dziwnych sterowników kart graficznych. Jedno wezwanie pomocy technicznej na ich temat mogło zniwelować zysk ze sprzedaży 20 kopii twojego produktu, zakładając, że Egghead, Ingram i reklama na MTV nie pochłonęły wszystkich Twoich zysków.

Krok trzeci: Dowiedz się, ile jest dla Ciebie warte poprawienie wszystkich błędów

Ponieważ Fog Creek Software jest malutką firmą (poza naszymi umysłami), zespół programistów zajmuje się też wsparciem technicznym. Każdego dnia poświęcaliśmy temu 1 godzinę. Kosztowało nas to około $75000 rocznie (bazując na cenach naszych konsulatacji). Byliśmy pewni, że możemy ograniczyć ten czas do 15 minut, gdyby udało nam się poprawić wszystkie znane błędy.

Używając bardzo nieprecyzyjnych liczb: wartość bieżąca netto z oszczędności wynosiłaby około $150000. To uzasadnia koszt 62 roboczodni. Jeśli można to zrobić szybciej, to warto to zrobić.

Korzystając z wbudowanych w FogBUGZ wygodnych funkcji do estymacji obliczyliśmy, że potrzeba 20 roboczodni (dwie osoby przez dwa tygodnie), aby naprawić wszystkie błędy. Co równało się $48000 wydanych za $150000 zaoszczędzonych pieniędzy, co jest wielkim zwrotem z inwestycji w redukcję kosztów obsługi technicznej.

Nie zacząłem nawet liczyć zysków z posiadania lepszego produktu, ale mogę zacząć to robić. W lipcu mieliśmy 55 awarii na serwerze demo (gdzie był stary kod), które dotknęły 17 użytkowników. Wyobraź sobie, że przynajmniej jedna z tych osób nie zdecydowała się kupić licencji na FogBUGZ, ponieważ kiedy korzystała z dema pomyślała, że produkt jest przepełniony błędami (chociaż nie ma realnych statystyk, by to poprzeć). W każdym razie te awarie prawdopodobnie kosztowały nas pomiędzy $7000 a $100000 (jeśli jesteś dociekliwy, nie będzie Ci trudno znaleźć prawdziwą kwotę).

Następne pytanie. Czy możesz sprzedawać drożej produkt, który ma mniej błędów? Przypuszczam, że w sytuacjach ekstremalnych liczba błędów wpływa na cenę, ale ciężko mi znaleźć przykład ze świata produktów pudełkowych, gdzie miało to miejsce.

Proszę, nie pobij mnie!

Ludzie czytają eseje jak ten i nieuchronnie dochodzą do niemądrych wniosków: "Joel uważa, że nie powinieneś poprawiać błędów". W rzeczywistości uważam, że poprawianie większości błędów jest ekonomicznie uzasadnione. Ale może jest coś innego, co przyniesie Ci więcej pieniędzy, niż poprawianie kilku ostatnich błędów. I jeśli musisz wybrać pomiędzy poprawianiem błędu dla faceta z OS/2 a dodaniem nowej funkcjonalności, dzięki której sprzedasz 20000 kopii Twojego oprogramowania do General Electric, zignoruj tego faceta. Jeśli jesteś wystarczająco durny, by nadal uważać, że ważniejsze jest poprawienie tego błędu, niż dodanie nowej funkcjonalności, możesz wylecieć z rynku.

Mając to wszystko na uwadze, jestem optymistą i uważam, że produkowanie wysokiej jakości oprogramowania niesie ze sobą wiele ukrytych korzyści, które niełatwo ogarnąć. Twoi pracownicy będą bardziej dumni. Mniej twoich klientów zwróci ci pocztą CD, którą uprzednio potraktowali mikrofalówką i porąbali siekierą. Mam tendencję do przesadzania z dbałością o jakość produktu (faktycznie, naprawiliśmy każdy znany błąd w FogBUGZ, nie tylko te znaczące) i bycia z tego dumnym. Czuję się pewnie, ponieważ dzięki całkowitej eliminacji błędów z serwera demo mamy stabilniejszy i bardziej niezawodny produkt.

Data publikacji oryginału: lipiec 31, 2001

2 komentarze:

Anonimowy pisze...

szkoda ze nie po polsku

mg pisze...

Dziękuję za komentarz. Poprawiłem trochę tłumaczenie. Będę wdzięczny za dalsze uwagi.

Prześlij komentarz

Related Posts with Thumbnails