Znalazłeś błąd w piątek na koniec pracy. Co robisz?

„Znalazłeś błąd w piątek w momencie, gdy już nikogo nie ma w biurze. Co robisz?”

Nie jest, to może najpopularniejsze pytanie na rozmowie rekrutacyjnej. Mimo tego chcę je opisać, ponieważ jest bardzo złożone, odpowiedzi na nie zawierają wiele „to zależy”. Podobnie jak z pytaniem o przetestowanie formularza logowania, zaczynamy nie od odpowiedzi, a od pytań 🙂.

Pytania jakie należy zadać, zanim zaczniesz odpowiadać co zrobisz, gdy znajdziesz błąd w piątek.

Na którym środowisku znaleziono błąd?

Zatem zapytany „Co zrobisz?” możesz powiedzieć, po pierwsze to zależy od miejsca znalezienia błędu.

Jeżeli jest to nasze środowisko rozwojowe, na którym prowadzimy testy, to możemy wyluzować nawet przy apokalipsie. Błędy na tym środowisku mogą spokojnie poczekać do poniedziałku.

Gorzej, jeżeli błąd wyłapiemy na środowisku produkcyjnym, w takim wypadku pojawia się kolejne, to zależy :). Kto znalazł błąd?

• Sami go znaleźliśmy.
• Klient go znalazł

W przypadku, gdy sami znaleźliśmy błąd, to koniecznie musimy zidentyfikować prawidłowo priorytet zgłoszenia. Jeżeli jest poważny, a nawet bardzo poważny, to zdecydowanie trzeba dzwonić do Scurm mastera/PMa, z prośbą o wskazanie programisty, który ma dyżur w dany weekend. Oczywiście opisujemy problem, jaki wystąpił i dlaczego uważamy, że trzeba go poprawić natychmiast.

Jeżeli błąd znaleźliśmy sami i priorytet jest niski, to możemy się wstrzymać z rozpoczęciem standardowych procedur opisanych wyżej. Jako że błąd dotyczy produkcji, lepiej poinformować o nim naszego przełożonego (PM/Scrum master). Wystarczy napisać, że na środowisku produkcyjnym bug o priorytecie takim i, takim i Twoim zdaniem można się nim zająć na spokojnie w poniedziałek.

Jak wygląda poprawa błędu znalezionego na produkcji?

I tu znowu nam się temat rozdziela na dwa:

• priorytet wysoki,
• priorytet niski.

Przy priorytecie wysokim programista poprawia defekt, my czekamy na zrobienie retestu no i co dalej? Oczywiście w trakcie poprawiania błędu powinniśmy ustalać razem z klientem możliwość instalacji poprawki na środowisku produkcyjnym, następnie zretestować i zamknąć zgłoszenie. Jednocześnie wyczerpujemy w ten sposób nasz scenariusz.

Przy priorytecie niskim. Musimy poinformować o nim naszego przełożonego, a następnie ustalić harmonogram wdrożenia poprawki na środowisko produkcyjne. W przypadku niskich priorytetów zdarza się, że takie poprawki wchodzą wraz z jakimiś większymi zmianami.

Ok wróćmy teraz do sytuacji, w której to klient znalazł błąd.

Klient znalazł defekt, co teraz? Przeważnie w umowie mamy zapisy dotyczące suportu. Oprócz tego, że robimy fajny soft, fajnie by było, żeby on również działał dłuższą chwilę. Przeważnie w umowie znajduje się tabela z czasami przypisanymi do priorytetów naszych zgłoszeń. Jednym słowem wiemy, jak szybko musimy się podjąć zgłoszenia i jak szybko mamy je dostarczyć klientowi.

Znalazłeś błąd w piątek w momencie, gdy już nikogo nie ma w biurze. Co robisz?

Podsumowując, najpierw zapytałbym o to, na jakim środowisku znaleziono błąd. Następnie sprecyzowałbym priorytet defektu. Na podstawie tych dwóch danych oraz tego kto błąd znalazł, określiłbym, co trzeba w danym momencie zrobić.

Jest takie przysłowie „W piątek zły początek”, zatem dobrym zwyczajem jest na koniec dnia w piątek nie grzebać na wersji produkcyjnej :).