Rzeczywistość gryzie
Można — czasem nawet z pożytkiem — zajmować się fundamentalnymi kwestiami procesu QA, narzędzi, sposobu myślenia, etosu i kompetencji. I bardzo dobrze. Tematy te wymagają poważnego wysiłku intelektualnego od każdego prawdziwego specjalisty QA lub osoby dopiero przygotowującej się do tego zawodu. Nadają się również na dobre wystąpienia TED, więc to także działa na ich korzyść. Można przecież publikować te nagrania w mediach społecznościowych aż do nadejścia Ragnaröku.
Jednak czasami trzeba również zająć się drobiazgowymi realiami kolejki górskiej QA, nawet jeśli zajmowanie się nimi jest wyłącznie ćwiczeniem z czystego pragmatyzmu i nie wymaga żadnych kwantowych skoków w rozumieniu procesu ani myślenia nieszablonowego.
Ale dokładnie odwrotnie: zejścia w błoto i dramat tego, czym dokładnie przepełnione jest to pudełko, nie da się uniknąć poprzez myślenie poza nim. Bo to wcale nie jest pudełko. To Kopuła Gromu.
I właśnie o tym jest ten artykuł. Nie oferuje niczego nowego ani „przełomowego”, a jedynie bardzo praktyczne przemyślenia i porady oparte na moich własnych, trzymających w napięciu doświadczeniach jako lidera QA na przestrzeni kilku dekad oraz na lekcjach, które z nich wyciągnąłem. Moja własna szczerość kierownika QA, że tak powiem. Lekcje te oczywiście możecie swobodnie ignorować, podważać lub wyśmiewać, jak uznacie za stosowne.
Dla każdego, kto przez dłuższy czas zajmował się przywództwem w QA, jest jasne, że centralną traumą tego doświadczenia są negocjacje podczas osławionego spotkania „wdrożyć czy nie wdrożyć”. I przetrwanie go.
Bo właśnie wtedy wszystko dochodzi do punktu kulminacyjnego, a QA jest przesłuchiwane jak podejrzany o morderstwo, podczas gdy detektywami są wszyscy pozostali „interesariusze” (eufemizm, jeśli kiedykolwiek istniał). I jak wszyscy detektywi, chcą od was tylko jednego: żebyście podpisali zeznanie.
Ale wcale nie musi tak być. Wszystko, czego potrzebujecie, to alibi nie do podważenia. Piszę ten artykuł, aby wam je zapewnić.
Czas na opowieść
Największym błędem popełnianym przez liderów QA przed spotkaniem „wdrożyć czy nie wdrożyć” jest brak przygotowania. A właściwie brak skutecznego przygotowania.
Większość liderów lub kierowników QA przychodzi na to spotkanie „przygotowana” przede wszystkim, a często wyłącznie, z metrykami dotyczącymi błędów. Liczba otwartych problemów, liczba otwartych problemów kategorii A, liczba otwartych problemów kategorii B i tak dalej. Czasami, jeśli reszta zespołu ma szczęście, lider QA potrafi przedstawić mgliste, impresyjne wyobrażenie o tym, jaki zakres testów QA udało się osiągnąć do tego momentu. Zwykle jednak dane wykorzystywane w tym celu są po prostu spisem przeprowadzonych testów i skryptów testowych. To w żadnym razie nie jest miara rzeczywistego pokrycia testami. Są to metryki nakładu pracy, a nie prawdziwe metryki jakości.
Błąd tkwiący u podstaw tej strategii wykracza poza wykorzystywanie niejednoznacznych lub pozbawionych znaczenia metryk do przedstawienia (jakiejś?) argumentacji za wdrożeniem lub przeciw niemu. Popełniany tutaj błąd jest znacznie bardziej fundamentalny.
Decyzja QA opisana powyżej opiera się bowiem na oczywistym błędzie kategorialnym. Kierownictwo QA w tym scenariuszu zakłada, że celem spotkania „wdrożyć czy nie wdrożyć” jest przedstawienie danych, które inni mają przeanalizować i na ich podstawie samodzielnie podjąć decyzję. Nic bardziej mylnego ani bardziej szkodliwego dla autorytetu QA.
To, czego reszta zespołu produktowego oczekuje od kierownictwa QA podczas tego spotkania, to nie kolejna porcja danych. Oczekuje jasnego i autorytatywnego werdyktu w sprawie tego, czy wdrożyć produkt. Teraz. Dzisiaj.
Oczywiście dane dotyczące testów i defektów będą potrzebne, aby uzasadnić i uzyskać poparcie dla werdyktu eksperckiego QA, jaki by on nie był. Jednak QA musi przedstawić autorytatywny werdykt.
W przeciwnym razie QA uchyla się od swojej wyjątkowej odpowiedzialności wobec organizacji zajmującej się dostarczaniem produktu oraz od swojego autorytetu w jej ramach. Jest to z natury unikowe i pasywno-agresywne. Nie przyczynia się to do umocnienia pozycji QA w tej samej organizacji.
Z czasem staje się to spiralą śmierci dla szans QA na uzyskanie równego głosu w procesie rozwoju. To sytuacja, na którą QA bez końca narzeka, a jednak często z tego właśnie powodu samo staje się autorem własnej nieistotności.
Oznacza to, że kierownictwo QA musi przyjść na spotkanie „wdrożyć czy nie wdrożyć” z jasną i przekonującą historią prowadzącą do jednoznacznej rekomendacji. Innymi słowy, trzeba wejść na to spotkanie w gotowości i z wolą podpisania się pod przedstawianą rekomendacją własną cyfrową krwią. Bez zabezpieczania się na wszelkie ewentualności. Bez chowania się za spódnicą wiarygodnego zaprzeczania.
Bo jeśli tego nie zrobicie, wy i wasz zespół stracicie całą wiarygodność w organizacji. Co gorsza, narazicie się na ponoszenie całej winy, jeśli inni będą musieli podjąć tę decyzję za was, a rezultatem okaże się katastrofa jakościowa w środowisku produkcyjnym. I bądźmy szczerzy — dokładnie tego chcą pozostałe działy. Chcą obarczyć was winą za wszystko i wykorzystać wasze własne niezdecydowanie w kwestii jakości produktu jako dowód przeciwko wam.
Jednym z kluczowych czynników umożliwiających to pasywno-agresywne podejście do decyzji „wdrożyć czy nie wdrożyć” jest przekonanie — często oportunistycznie wykorzystywane — że „nie ma znaczenia, co powiem, i tak wdrożą”. To nastawienie, to strategiczne przyjęcie bezsilności, dokładnie podtrzymuje organizacyjną bezsilność QA. Mówimy tu o samospełniającej się przepowiedni!
Pomijając politykę i autodestrukcyjną psychologię, strategia ta opiera się na fundamentalnym niezrozumieniu tego, czego oczekuje się od QA podczas tego spotkania. W rzeczywistości nie oczekuje się bowiem od QA wydania nieodwołalnej decyzji „wdrożyć czy nie wdrożyć”, nawet jeśli decyzja, o której publiczne podjęcie jesteście proszeni, przybiera właśnie taką publiczną formę.
I tak, nadal musicie przedstawić autorytatywny werdykt. Aby to jednak zrobić, musicie zrozumieć pytanie, na które faktycznie macie udzielić autorytatywnej odpowiedzi.
Pytanie, na które kierownictwo QA naprawdę musi odpowiedzieć, brzmi: Jakie jest ryzyko — jego prawdopodobieństwo wystąpienia i dotkliwość w praktyce — związane z wydaniem produktu dzisiaj? W przeciwieństwie do, powiedzmy, wydania go dopiero w przyszłym miesiącu? Innymi słowy, oczekuje się od was przedstawienia oceny ryzyka, która umożliwi wyższemu kierownictwu racjonalne podejmowanie ryzyka w danym momencie.
Oznacza to, że wasza ostateczna odpowiedź podczas spotkania dotyczącego wydania lub niewydania produktu jest ostatecznie odpowiedzią dotyczącą ryzyka. Nie tego, czy nacisnąć przycisk uruchamiający rakietę w przestrzeń kosmiczną.
Co z kolei oznacza, że przedstawiana przez was podczas tego spotkania historia jakości musi ostatecznie opierać się na scenariuszach. Innymi słowy, nie będzie to proste „tak” lub „nie”, niezależnie od tego, jak bardzo wszyscy pozostali chcieliby takiej odpowiedzi, aby umyć ręce od odpowiedzialności za decyzję (co przecież nigdy nie ma miejsca, prawda?). Schematycznie rzecz ujmując, wasza prezentacja powinna składać się z dwóch części:
- Po pierwsze, autorytatywnego, *znacząco* opartego na danych, przedstawienia bieżącego stanu jakości produktu. Popartego odpowiednimi metrykami. Uwaga, spoiler: aby to zrobić, będziecie potrzebować czegoś więcej niż metryk błędów.
- Po drugie, autorytatywnej oceny ukrytej jakości, która pozostanie niewykorzystana, jeśli zapadnie decyzja o wydaniu produktu teraz. Czy jest ona na tyle duża, że warto wydłużyć harmonogram wydania, aby spłacić ten dług jakościowy? Jeśli tak, jakie kompromisy między czasem a jakością rekomenduje QA? I na jakich konkretnych obszarach funkcjonalności produktu należałoby się skupić podczas tego przedłużenia oraz skąd będziemy wiedzieć, że ukryta jakość została osiągnięta?
W rzeczywistości nie jest to sposób na uniknięcie odpowiedzi na zadane pytanie. Jest to sposób na udzielenie odpowiedzi w pełnym kontekście wszystkich parametrów, zmiennych i kosztów związanych z tą decyzją — podjętą dzisiaj, w przyszłym tygodniu lub w przyszłym miesiącu.
Albowiem — i jest to prawda, którą musicie wypalić w swojej świadomości QA — waszym prawdziwym odbiorcą podczas tego spotkania nie są pozostali liderzy funkcyjni. Jest nim wyższe kierownictwo. Niezależnie od tego, czy fizycznie uczestniczy ono w spotkaniu. To, co powiecie, zostanie mu niezwłocznie przekazane. Zaufajcie mi.
I działa to wyłącznie na waszą korzyść. Ponieważ prezesi i dyrektorzy operacyjni najbardziej lubią, gdy przedstawia się im konkretne możliwości poparte konkretnymi faktami i danymi. Najbardziej nie znoszą natomiast sytuacji, w której słyszą tylko: „Eee, nie jesteśmy gotowi do wydania. I nie możemy dokładnie powiedzieć dlaczego. Ale być może będziemy mogli to zrobić za cztery miesiące”. Właśnie dlatego prezesi zaczynają poszukiwać nowych przejęć — aby zdobyć zupełnie nowy zespół dostarczający produkt.
Odwieczną skargą zespołów dostarczających produkty jest to, że wyższe kierownictwo narzuca odgórnie sztywną datę wydania, na którą nie chce się zgodzić na żadne ustępstwa. Być może warto zadać sobie pytanie, dlaczego robi to tak konsekwentnie.
Dzieje się tak dlatego, że nigdy nie mogą uzyskać jednoznacznej odpowiedzi na temat stanu jakości produktu, a jeśli nie można dotrzymać preferowanej przez nich daty wydania, to także informacji, kiedy będzie to możliwe. Dlatego narzucają własną datę. Zespół produktowy nie pozostawił im bowiem żadnych znaczących alternatyw.
Dlatego na spotkanie dotyczące wydania lub niewydania produktu musicie przyjść z przekonującą, trójwymiarową historią opartą na faktach i scenariuszach, prowadzącą do autorytatywnego zestawu rekomendacji, który może obejmować konkretne opcje dotyczące kosztów i korzyści jakościowych związanych z decyzją o wydaniu produktu — lub o jego niewydaniu. Mamrotanie przez kilka minut o metrykach błędów, a następnie pozostawienie decyzji wszystkim pozostałym, nie jest taką historią.
Oczywiście, aby to zrobić, będziecie musieli zadbać o to, by własna metodologia QA, szkolenia i metryki były w doskonałym stanie. W innych miejscach (np. na LI) napisałem szczegółowe artykuły na te tematy, ale ponieważ dotyczą one teorii procesów, wykraczają poza pragmatyczny zakres tego artykułu.
Szczęśliwe zakończenie
To, co napisałem powyżej, może wydawać się zniechęcające, a być może na pierwszy rzut oka nieco sprzeczne. Pozwólcie więc, że zakończę ten artykuł opisem mojego doświadczenia z bardzo udanym spotkaniem dotyczącym wydania lub niewydania produktu. Przebiegło ono nieco inaczej niż opisałem powyżej, a nawet inaczej, niż się spodziewałem.
Mój zespół testował zupełnie nowy produkt. Nie tylko nowy produkt, ale także taki, który odpowiadał na potrzeby niszy produktowej, z którą firma nie miała wcześniej żadnego doświadczenia. Od samego początku był to więc maraton ukrytych zagrożeń, nieznanych niewiadomych i nieprzyjemnych niespodzianek.
Nadszedł czas spotkania dotyczącego wydania lub niewydania produktu. Na początku mojej kadencji jako dyrektor QA wprowadziłem ścisły reżim definiowania metryk jakości, w tym metryk pokrycia testami, które opierały się na wymaganiach, a nie na modułach lub skryptach testowych. Mieliśmy również nie tylko metryki błędów, lecz także metryki trendów błędów oraz metryki szybkości zmian w kodzie, aby wzmocnić przedstawianą przez nas historię.
I wszystkie te metryki były bezsprzecznie pozytywne. Wszystkie systemy były gotowe. Nie były potrzebne żadne scenariusze „jeśli/to/inaczej”. Po raz pierwszy nie widziałem powodu, by nie powiedzieć głośno i wyraźnie: „Wydajmy go!”, bez żadnych zastrzeżeń.
Jednak formalnie nie należało to do mojej roli. Ponieważ projektem kierował jeden z moich menedżerów QA, to właśnie na nim spoczywał obowiązek wydania tego autorytatywnego werdyktu. Menedżer ten dokładnie podsumował wszystkie metryki i przyznał, że były one pozytywne.
Następnie, ku mojemu zaskoczeniu, zaczął się wahać i zastanawiać, czy produkt jest gotowy do wydania. Zaskoczyło mnie to, ponieważ oczywiście przed wejściem na spotkanie omówiliśmy stanowisko QA. (Ważna uwaga: Nigdy nie zaskakujcie swojego szefa podczas spotkania.)
Zapytałem menedżera: „Co sprawiłoby, że czułbyś się komfortowo, rekomendując decyzję o wydaniu? Jeśli nie dzisiaj, to w przyszłości?”
Ponownie ku mojemu zaskoczeniu kierownik nie potrafił — albo nie chciał — odpowiedzieć na moje pytanie. Stało się dla mnie jasne, że ten kierownik po prostu nie chciał wziąć odpowiedzialności za podjęcie tej decyzji, za podpisanie się pod nią. Co uznałem za skrajnie rozczarowujące.
Była to również zniewaga dla kierownika zespołu inżynierskiego pracującego nad projektem, który nieustannie wspierał działania QA i stworzył produkt najwyższej klasy. Nie zasługiwał na to, by tak go zaskoczono. Ja również nie.
Wkroczyłem więc i powiedziałem: „Nie widziałem ani nie usłyszałem żadnego dobrego powodu, by nie wprowadzić tego produktu na rynek DZISIAJ. Taki jest werdykt QA, a ja, jako dyrektor QA, biorę pełną odpowiedzialność za podjęcie tej decyzji”.
Wydawało mi się, że kierownik zespołu inżynieryjnego zaraz mnie pocałuje. Jednak po tym spotkaniu QA zyskało ogromne uznanie i szacunek ze strony działów inżynierii, zarządzania projektami i zarządzania produktem.
Bo drogą do tego, by traktowano nas poważnie w naszym świecie, jest publiczne branie odpowiedzialności. W tamtej chwili czułem się całkowicie bezpiecznie, podejmując ją, ponieważ nasza opowieść była przygotowywana od samego początku. I została napisana z myślą o szczęśliwym zakończeniu.
Produkt po wprowadzeniu na rynek wykazał się wysoką jakością w rzeczywistych warunkach i odniósł wielki sukces. Opóźnienie jego premiery w celu uniknięcia odpowiedzialności za decyzję o wprowadzeniu produktu na rynek lub jego niewprowadzaniu przyniosłoby jedynie minimalny wzrost jakości produktu, przy niewspółmiernych kosztach finansowych i opóźnieniu wejścia na rynek.
To, jak tego dokonaliśmy, to opowieść na inny dzień.
Jak zawsze, życzę powodzenia w działaniach QA.
Powiązany podcast: PRACA ZESPOŁOWA, AI I KONTENERYZACJA (Z MICHAELEM RITCHSONEM Z NASA)