Podczas wytwarzania oprogramowania cały zespół pracuje nad wypuszczeniem na produkcję produktu dobrej jakości. Jako programiści dokładamy wszelkich starań, żeby kod był czytelny i dobrze poukładany, piszemy testy, staramy się pracować produktywnie i dobrze planować swoje zadania. Przynajmniej chcę wierzyć, że tak jest w każdym projekcie. W moich dotychczasowych projektach właśnie tak wyglądała nasza praca. Czy to znaczy, że nie było żadnych błędów i wytwarzane oprogramowanie było perfekcyjne? Raczej nie. Czy to oznacza, że jesteśmy słabymi rzemieślnikami? Niekoniecznie. Często poza naszymi umiejętnościami liczą się jeszcze inne okoliczności i zdarzenia, które mogą psuć nam szyki. W tej serii opowiem o trzech typach takich sytuacji.

Pierwszą okolicznością, która często wpływa na jakość wytwarzanego oprogramowania jest tzw. wielki dzień. To może być wyjście na produkcję z nową aplikacją, wdrożenie dużej funkcjonalności albo instalacja po stronie klienta. To coś do czego długo się przygotowujemy, najpierw majaczy nam gdzieś na horyzoncie, potem wprowadza coraz większą presję, aż w końcu spędza nam sen z powiek kilka dni przed. Czujemy, że to jest ważne i ta ważności sprawia, że paradoksalnie popełniamy więcej błędów. To jest trochę taka sytuacja jak gotowanie pierwszego obiadu dla przyszłych teściów. Niby gotujemy codziennie, ale kiedy chcemy się naprawdę postarać, wychodzi odwrotnie niż powinno. Dodatkowo, nie zawsze bierzemy pod uwagę wszystkie ryzyka i tak bardzo skupiamy się na dacie wydarzenia, że odcinamy logiczne myślenie. Kiedy przestajemy się zastanawiać nad tym, co może pójść nie tak, kręcimy się w kółko zabiegani, zamiast skupić się na rzeczach ważnych. Podobnie zrobili twórcy oprogramowania dla londyńskiego pogotowia w 1992 roku1. System powstał po to, żeby obniżyć czas reakcji od zgłoszenia do podjęcia decyzji o wysłaniu karetki do trzech minut. Londyńskie pogotowie obsługiwało ok. 2 tysięcy zgłoszeń dziennie, z czego 60% wymagało wysłania jednej z 200 karetek. Niestety kierownicy projektu tak bardzo skupili się na dostarczeniu oprogramowania, że prawie zapomnieli włączyć do projektu dystrybutorów karetek, którzy mieli być jego użytkownikami. Mimo tego, że to właśnie dyspozytorzy najlepiej wiedzieli jak powinien działać system, zostali zaproszeni do projektu na etapie jego testowania i wdrażania. System nie brał zatem pod uwagę sytuacji awaryjnych, z którymi ludzie całkiem nieźle sobie radzą, ale maszyny już nie. Pamiętajmy, że to nie były czasy sztucznej inteligencji używanej powszechnie, więc cokolwiek nie zostało zaplanowane w trakcie wytwarzania oprogramowania, po prostu nie działało. Pacjenci którzy nie mogli doczekać się karetki dzwonili wielokrotnie i zamiast przyspieszyć proces, przyczyniali się do coraz większych problemów z wydajnością. W konsekwencji cały system się zawiesił. Szacuje się, że od 30 do 45 osób mogło stracić życie przez nieudane wdrożenie nowego oprogramowania.

 

Ja nigdy nie pracowałam w projekcie, od którego zależało ludzkie zdrowie lub życie, ale znam ten stres związany z wielkim dniem. Kiedy pracowałam w startupie jako programistka skupiona na backendzie przygotowywaliśmy m.in. widget2, który miał działać na stronie naszych klientów. Planowane wyjście na produkcję przesuwaliśmy kilkukrotnie, bo chcieliśmy mieć pewność, że wszystkie elementy są najwyższej jakości. Dopisywaliśmy testy automatyczne i wykonywaliśmy mnóstwo testów manualnych na środowiskach testowych, a potem wprowadzaliśmy wszystkie poprawki. Byliśmy nowym, stosunkowo małym zespołem, więc to wydarzenie było dla nas ważne i czuliśmy presję związaną ze „zwodowaniem” owocu naszej kilkumiesięcznej pracy. Kupiliśmy nawet prawdziwego szampana, który chłodził się w lodówce biurze coworkingowym, gdzie wówczas pracowaliśmy. Ponieważ przesuwaliśmy wejście na produkcję kilka razy, nie byliśmy pewni, czy nikt nam tego szampana nie wypije w międzyczasie. W końcu nadszedł upragniony dzień, wyjście na produkcję było częściowo manualnym procesem, ale posprawdzaliśmy wszystkie wskaźniki, którymi wtedy dysponowaliśmy i uznaliśmy, że można wreszcie otwierać szampana. Po pierwszych łykach zadzwonił telefon i nasz szef poinformował nas, że strona jednego z naszych partnerów nie działa przez konflikt w plikach CSS i że musimy jak najszybciej wycofać wszystkie zmiany. Poprawka była trywialna, ale i tak bąbelki szampana zdążyły się ulotnić zanim ponownie weszliśmy na produkcję.

 

Presja wielkiego dnia może być tak duża, że dajemy się ponieść codziennym obowiązkom, naprawianiu błędów z ostatniej chwili i wrzucaniem finalnych poprawek. To co powinniśmy zrobić to zasięgnięcie opinii naszych użytkowników, zespołowa dyskusja i próba rozluźnienia się, żeby usprawnić logiczne myślenie. Nasi użytkownicy mają większe doświadczenie domenowe i potrafią zidentyfikować potencjalne zagrożenia lepiej od nas. Muszą tylko czuć się potrzebni i wysłuchani podczas trwania całego projektu, a nie tylko w jego ostatnich etapach. Pomocna jest też dyskusja wewnętrzna. Jako doświadczeni eksperci wiemy albo czujemy jakie mogą być wyzwania. Jeśli chwilę podyskutujemy, prawdopodobnie uda nam się znaleźć sposoby, żeby uniknąć większości wpadek. Jeśli nie, zawsze możemy się posłużyć usługami zewnętrznych konsultantów. Lepiej spędzić trochę czasu identyfikując zagrożenia i snując czarne scenariusze, niż później pod presją czasu i klientów na szybko poprawiać błędy. To czego często nam brakuje to spokojna, logiczna analiza. Pod wpływem stresu wchodzimy w inny tryb i nie zawsze w pełni wykorzystujemy nasz intelektualny potencjał. Warto zadbać o to, żeby nie wprowadzać dodatkowego zamieszania i spróbować się rozluźnić. Zazwyczaj z perspektywy czasu widzimy, że rozwiązanie było na wyciągnięcie ręki, ale działaliśmy jakby z klapkami na oczach. To właśnie przez poczucie presji i skupienie na samym dostarczeniu oprogramowania, niekoniecznie zastanawiając się nad tym, co może pójść nie tak.

 

 

 

1 Historia londyńskiego pogotowia jest dokładnie opisana w książce: „Kierunek Jakość. Jak Unikać błędów w projekcie”

2 Widżet to element graficznego interfejsu użytkownika, który wyświetla informacje lub zapewnia określony sposób interakcji użytkownika z systemem operacyjnym (OS) lub aplikacją.