Rozwiązywanie problemów, które przyniosą największe korzyści finansowe [zamknięte]

Chciałem dowiedzieć się, jak kategoryzować błędy w oparciu o to, jak łatwo je rozwiązać i jakie korzyści przyniosą mi. na przykład, jeśli wystąpi błąd, którego rozwiązanie zajmie godzinę (podwójne zamknięcie pliku itp.) w porównaniu z innym, który zajmuje dzień (błąd segmentacji). Ale jeśli rozwiązanie pierwszego błędu nie jest bardzo ważne, prawdopodobnie będę pracować nad drugim.

Czy są jakieś prace badawcze, które kategoryzują błędy na podstawie kosztów i korzyści lub podobnych danych?

Załóżmy, że możliwe jest kategoryzowanie błędów na podstawie cech błędów, np. Luki w zabezpieczeniach, błędów pamięci, błędów logicznych itp. W drugim wymiarze mogą występować parametry takie jak trudność (łatwa, średnia, trudna). Czy są inne wymiary, których powinienem szukać. Aby uprościć rzeczy, mogę założyć dwie rzeczy:

1. Każdy programista w zespole jest w stanie rozwiązać każdy błąd
2. Nie ma terminu

Typowy system śledzenia błędów ma dwa, może trzy pola identyfikujące stosunek kosztów do korzyści błędów:

1. Priorytet (przypisany przez właściciela firmy)
2. Istotność (klasyfikacja błędu - krytyczna do niskiej)
3. Szacowane godziny (zgadnij, ile czasu to zajmie)

Jak zauważasz, pozwala to ustalić, który błąd jest najważniejszy do pracy.

System przedstawiony w PEF / REV: Wielowymiarowy wskaźnik śledzenia błędów dodaje więcej informacji na temat komponentów biznesowych i programistycznych do korzyści związanych z kosztami błędów.

Wszystkie wartości są w skali 1 .. N (ta sama najwyższa wartość dla każdej).

PEF jest identyfikowany przez firmę:

• P ain - Jak bolesny jest błąd
• E ffort - Ile wysiłku zajmuje obejście błędu
• Wymaganie F - jak często występuje błąd

REV pochodzi od autora:

• R isk - Jak ryzykowna jest poprawka do systemu
• E ffort - Ile wysiłku trzeba naprawić błąd
• V erifiability - Jak łatwo jest zweryfikować bug fix

Jeśli na przykład zdarza się rzadko zdarzająca się awaria, którą łatwo obejść (włączyć automatyczne zapisywanie), może to być PEF 7,1,1 (wynik 9). Podczas naprawy może wymagać zmiany modułu podstawowego i mieć REV 9,3,2 (wynik 14).

Z drugiej strony możesz mieć irytację, która zawsze tam jest (3,3,9 - wynik 15), która ma trywialną poprawkę (1,1,3 - wynik 5).

W tym przykładzie irytacja wydaje się być lepszym rozwiązaniem pod względem kosztów / korzyści.

Opisany problem jest bardzo częsty i najlepszą odpowiedzią może być „wykorzystaj swoje jelita”.

Zazwyczaj dzielę błędy na trzy kategorie: awarie, irytujące, kosmetyczne (można je nazwać 1, 2, 3 - to naprawdę nie ma znaczenia), a następnie podam ogólny szacunek czasu potrzebnego na usunięcie każdego błędu (wszystkie błędy muszą zawsze mają przybliżone zaktualizowane dane szacunkowe).

Podczas rozwiązywania błędów Crashing> Denerwujące> Cosmetic, a następnie po prostu wykonuję „najpierw najkrótszą robotę”, aby uzyskać jak najwięcej początkowej wydajności.

Uważam, że BARDZO trudno jest obliczyć jakąkolwiek bezpośrednią korzyść finansową z rozwiązania jakiegokolwiek błędu - chyba że jest to bardzo wąska płatna praca.

Jedna uwaga, której możesz potrzebować, to fakt, że naprawdę powinieneś dotrzymać piątego punktu w teście Joela - na to może mieć wpływ wielkość zespołu i podział na różne inne „lokalne” problemy - ale ogólnie jest to znak dobrej praktyki.

Innym zagadnieniem może być rodzaj organizacji testującej lub testującej, która odkrywa błąd, próbując określić wpływ i koszt błędu i poprawki. Testy jednostkowe lub funkcjonalne mogą wskazywać na coś w projekcie, które należy zmienić, a zatem wczesna korekta byłaby łatwiejsza i mniej kosztowna niż później. Testy systemowe lub integracyjne mogą wskazywać na coś, co wpływa na większą różnorodność klientów. A testowanie standardów, choć często nie jest krytyczne dla dużej części klientów, może prowadzić do utraty certyfikatu, jeśli nie zostanie poprawione i może mieć negatywny wpływ na biznes.

To powiedziawszy, tylko dlatego, że dana organizacja testowa ma błąd testu, nie powinna automatycznie powodować, że błąd jest „krytyczny”. Na przykład może istnieć pokusa, aby powiedzieć coś w stylu „wszystkie testy systemu muszą przejść pomyślnie przed wysyłką, dlatego każdy test systemu, który nie powiedzie się automatycznie, spowoduje błąd krytyczny / o wysokim poziomie ważności”. Mamy nadzieję, że żadna organizacja nie wyda takiego oświadczenia (dobre kryteria wyjścia z testu to inna dyskusja), ale chodzi o to, że „dotkliwość” błędu powinna być oceniana na podstawie jego wpływu na wizerunek klienta, produktu lub firmy, a nie gdzie i kiedy jest odkryty

Jednym z możliwych sposobów rozwiązania tego problemu jest rozróżnienie między „dotkliwością” a „pilnością”. Na przykład, gdy zbliża się data premiery, może pojawić się presja czasu, aby ustalić, czy błąd o pozornie niższym poziomie ważności może wpłynąć na dużą grupę klientów, nadając mu większy „pilność” i podnosząc pracę nad tym błędem nad (niektórymi) innymi osobami w przynajmniej do czasu, gdy będzie można dokonać tego ustalenia. Właściwa równowaga między nimi, wraz z doświadczeniem i dobrym osądem, pomogłyby ukierunkować czas i wysiłek.

Oprócz tego, co inni powiedzieli na temat klasyfikacji błędów itp., Rozważ także spojrzenie na Afferent Coupling (Ca) w celu ustalenia poziomu krytyczności, jaki może reprezentować dany błąd. Jeśli masz błąd w module o wysokiej liczbie Ca, być może zastanowię się nad jego naprawą, ponieważ może to przynieść korzyści innym komponentom w systemie. Ca pomaga określić poziom odpowiedzialności, a odpowiedzialne moduły z błędami szkodzą całej aplikacji (czytaj więcej o Ca tutaj: http://www.ibm.com/developerworks/java/library/j-cq04256/index.html ).

Mając to na uwadze, staramy się kategoryzować błędy i umieszczać je w pierwszej kolejności na podstawie ich wpływu na klienta. Klienci będą się różnić, ale zaangażowanie ich w dyskusję ostatecznie doprowadzi do tego, jakie błędy powinny zostać naprawione w stosunku do innych. To nie jest prawdziwie naukowe, ale jako zespół cały czas dążymy do konsensusu w sprawie priorytetu i kategoryzacji błędów, każdy ma swój wkład w „duże” (wszyscy interesariusze mogą wnieść swój wkład), i stamtąd stawiamy stosy.

Nie można ustalić rzeczywistego kosztu wszystkich błędów. Niektóre możesz, dla wielu jest bardzo trudne do oszacowania. Załóżmy na przykład, że masz błąd, który powoduje, że cały tekst na przyciskach jest nieco źle wyrównany. Sprawia, że ​​twój produkt 1.0 wygląda trochę niechlujnie. Nie powoduje to awarii programu ani utraty danych przez użytkowników. Prawdopodobnie całkiem tani błąd, prawda?

Co jeśli każdy z Twoich klientów zauważy ten problem, a każdy recenzent wspomina o nim w recenzjach Twojego produktu. A jeśli ten błąd zostanie przeniesiony z wersji 1.0 na 1.1 i 1.2. Twoja firma może teraz mieć reputację nieco niechlujnej kontroli jakości. Ile może kosztować ten prosty błąd pod względem potencjalnej utraty sprzedaży dla Twojej firmy w przypadku przyszłych produktów? Lub, w jaki sposób może to wpłynąć na ocenę otrzymywaną przez Twój produkt - produkt może idealnie spełniać potrzeby klientów, ale dostaje tylko 9 na 10, ponieważ wygląda nieco niechlujnie.

Musisz więc spojrzeć nie tylko na koszt konkretnego błędu w kategoriach kosztu naprawy i jego bezpośredniego wpływu na użytkownika, ale musisz wziąć to pod uwagę w szerszym kontekście tego, w jaki sposób wpływa on na postrzeganie Twojego produktu na rynku i jak to postrzeganie wpływa na przyszłą sprzedaż.

To może wydawać się zbyt daleko idące, ale tak nie jest. W chwili, gdy to piszę, możesz przejść do innej witryny internetowej z artykułem o tym, jak Apple przesunął „1” na ikonie swojego kalendarza o jeden lub dwa piksele. Jeśli przeprowadzisz wyszukiwanie, zobaczysz kilka negatywnych artykułów na temat tego małego małego błędu. Oczywiście nie wpłynęło to bezpośrednio na wyniki Apple, ale promują się jako szczyt dobrego projektu, więc błąd w projekcie wpływa na to postrzeganie, nawet jeśli tylko nieznacznie.