Inwestycja w jakość – jak rozmawiać z biznesem językiem korzyści

Wprowadzenie

Jako początkujący tester bardzo często byłem świadkiem rozmów na temat tego, że biznes nie zgadza się na testy, nie zgadza się na nowe narzędzie, nie zgadza się na nowy sposób pracy…

Byłem także obecny na spotkaniach, na których była tłumaczona potrzeba wprowadzenia automatyzacji testów, która spowoduje, że będziemy swoją pracę wykonywać lepiej. Mówiliśmy o potrzebie dodatkowych narzędzi, które pozwolą nam zarządzać testami. Staraliśmy się wdrożyć branżowe nowinki, zmienić sposób testowania np. wprowadzając BDD czy TDD, na które biznes czasem się godził, a czasem, ku naszemu zaskoczeniu, nie.

Zastanawiałem się nad tym:

Dlaczego biznes nie chce się zgodzić na proponowane przez nas rozwiązania?

Przecież dobrze wiemy, że bez tych rozwiązań, nie tylko zespół deweloperski, ale również i zespół biznesowy będzie mierzył się z konsekwencjami tej decyzji.

Jak mamy rozmawiać z biznesem, żeby zgodził się zainwestować w jakość?

Z czasem zmieniłem swoją rolę. Z osoby, która zajmowała się testami automatycznymi, stałem się osobą, która prowadziła warsztaty i badania, a nie zajmowała się kodem. W swoich projektach w ramach WUD Silesia, Badaczy i działalności produktowej dowiedziałem się kim jest i jak pracuje biznes.

W ramach tego artykułu będę głównie skupiał się na dwóch dość szeroko pojętych grupach ról:

• Biznes – wszelkie role, które bezpośrednio wpływają na zakres prac w projekcie. Osoby te decydują, które wymagania będą brane pod uwagę, w jaki sposób będą rozwiązywane i jak będą weryfikowane. To one ustalają kierunek projektu i biorą odpowiedzialność za jego powodzenie lub porażkę. Osoby te przyjmują role Product Ownerów, analityków biznesowych, CEO, COO, managerów. W przypadku projektów outsourcowych mogą to być również inżynierowie od strony klienta.
• Zespół deweloperski – wszelkie role, które są związane z wytwarzaniem systemu informatycznego, w tym programiści, architekci systemu, specjaliści QA, Scrum Masterzy.

Jeżeli chcemy rozmawiać z biznesem o jakości, musimy najpierw zrozumieć czym jest jakość dla biznesu. Chciałbym, żebyście potrafili mówić o tej jakości wspólnym językiem z Waszymi klientami, osobami reprezentującymi biznes i dzięki temu dostarczali rozwiązania, które wpływają na sukces biznesowy.

Kolos na glinianych nogach

Załóżmy, że pracujemy nad nową aplikacją. Biznes z jakiegoś powodu nie godzi się na testy jednostkowe lub nie chce wprowadzać automatyzacji testów funkcjonalnych. Dbanie o jakość aplikacji najlepiej zleciłby programistom z informacją, żeby nie było błędów 🙂 Biznes ma jak najbardziej prawo do podjęcia takich decyzji.

Takie podejście będzie działać przy pierwszym release, może pierwszych parę miesięcy, jednak po pewnym czasie zauważalne będzie spowolnienie pracy. Czas potrzebny na kolejne wdrożenie będzie się wydłużał i początkowa radość z szybkiego, pierwszego wydania, odejdzie w zapomnienie. A im dalej projekt będzie brnął w tym kierunku, tym gorzej. Pojawi się presja czasu i ktoś ze strony biznesu zacznie się niecierpliwić. Zapewne wystąpią pierwsze, na tyle widoczne błędy w środowisku produkcyjnym, że zostaną zauważone przez naszego zleceniodawcę.

Budujemy kolosa, który zacznie upadać, a z każdym kolejnym upadkiem będziemy tracić zaufanie, renomę, a w przyszłości być może stracimy nawet tego klienta.

Możliwe, że zaczniemy się zastanawiać, czy biznesowi w ogóle zależy na jakości i sukcesie projektu? Przecież to on podjął decyzję, by nie wprowadzać pewnych narzędzi, które mają stabilizować system.

Różne definicje jakości

Po latach pracy jako analityk biznesowy (w skrócie BA – Business Analyst) przy projektach produktowych wiele razy musiałem podejmować decyzje związane z jakością i widziałem, że jakość jest definiowana na różne sposoby. Inaczej jakość postrzega zespół deweloperski, a inaczej zespół biznesowy.

Jak Ty definiujesz jakość w swoim projekcie? Zastanów się nad tym chwilę i spróbuj to sformułować.

Szukając definicji jakości posłużyłem się glosariuszem ISTQB, który definiuje aż 7 rodzajów jakości:

• Quality,
• Product based quality,
• Manufacturing-based quality,
• Transcendent-based quality,
• User-based quality,
• Value-based quality,
• Software quality.

Nie będę zagłębiać się w szczegóły każdej z nich. Definicji jakości możecie znaleźć bardzo wiele szukając poza ISTQB. Wybrałem jednak to jako początek, ze względu na popularność i rozpoznawalność certyfikatu ISTQB.

Definicje jakości

Chciałbym zwrócić uwagę na dwie definicje.

Manufacturing-based quality – a view of quality, whereby quality is measured by the degree to which a product or service conforms to its intended design and requirements. Quality arises from the process(es) used.

Zauważyłem, że jeżeli zespół deweloperski jest daleki od biznesu, to jakość traktowana jest rzemieślniczo.

Jako zespół deweloperski wiemy jak spowodować, żeby rozwiązanie było zgodne z wymaganiami i z designem. Proponujemy przez to pewne standardowe procedury i narzędzia, które pozwalają nam badać, czy rozwiązanie działa zgodnie z przygotowanym wcześniej planem. Brakuje nam jednak informacji o użytkowniku, interesariuszach, a problem, który ktoś chce rozwiązać naszą pracą, jest daleki.

Takie sytuacje się zdarzają, nie zawsze biznes będzie chciał dzielić się z zespołem deweloperskim wszystkimi swoimi sekretami. Wtedy oczekiwaniem biznesu nie jest rozwiązanie problemu, ale budowa narzędzia, które zostało zaprojektowane po stronie klienta – który zna i bada problem.

ISTQB definiuje również pojęcie “jakości”:

Quality – the degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations.

I na tej definicji jakości będę pracował.

Dekompozycja jakości

Żeby zrozumieć punkt widzenia jakości przez biznes, przyjrzyjmy się dogłębnie podanej definicji. Spróbujmy zrozumieć co oznacza każdy element definicji.

Degree it meets specified requirements and expectations – jakość, to pewien stopień. Oznacza to, że jakość może być wykryta jako pewien zakres (stopnie), czyli może być zmierzona. Sam proces mierzenia nazywamy testem.

Żeby wykonać test, muszą być zdefiniowane warunki, które jednoznacznie określają, czy wynik testu jest pozytywny lub negatywny.

Zgodnie z tą definicją, jakość mierzy stopień spełnienia wymagań i oczekiwań.

System, component, proces – Czym są te pojęcia? Według ISTQB system to kolekcja elementów, które wchodzą ze sobą w interakcję, żeby spełnić pewną funkcję lub zestaw funkcji. Czy nasze rozwiązanie jest systemem? Tak, jest to jeden z rodzajów systemów, który możemy nazwać systemem informatycznym.

Element większej całości

Jeżeli wytwarzany przez nas system informatyczny ma za zadanie umożliwić automatyczny zakup biletu, to ten system informatyczny jest częścią większego systemu, którego celem jest skrócenie czasu wymaganego do przemieszczenia się pasażerowi z miejsca, w którym się aktualnie znajduje, do miejsca, w którym chce się znaleźć.

Na dany system będzie składał się:

• Nasz system informatyczny,
• Punkt sprzedaży biletów,
• Usługa dostarczania biletów do punktu sprzedaży,
• Sposób rozliczania zysków i strat,
• System rachunkowy pozwalający wysłać pensję kierowcom,
• System zarządzania pracą kierowców,
• Kierowcy, sprzedawcy biletów, kontrolerzy, serwis autobusowy, itd.,

System jest dużo szerszy, niż tylko wytwarzane przez nas rozwiązanie, a brak jednego z komponentów tego systemu może doprowadzić, że cel nie zostanie spełniony.

Biznes nie porusza się tylko między interfejsami naszego systemu informatycznego. On porusza się między ludźmi, interakcjami między pracownikami, a klientami, pomiędzy swoimi partnerami biznesowymi, umowami i oczekiwaniami. Biznes bada zmiany w prawie, które wymuszają zmianę sposobu pracy lub rozliczenia, bada zmiany rynkowe i konkurencję, która będzie wpływała na proponowane ceny. Jeżeli cokolwiek będzie wpływało na sukces lub porażkę jego produktu, będzie to w centrum zainteresowania biznesu.

Czy my, jako osoby techniczne, powinniśmy znać cały ten system? Niekoniecznie. Im jednak więcej będziemy rozumieć czym jest ten system, ilu interesariuszy w nim występuje i którzy z nich są kluczowi dla biznesu, tym łatwiej będzie nam rozmawiać wspólnym językiem i dobierać rozwiązania, które będą w stanie im pomóc.

O interesariuszach i mierzeniu wartości biznesowej możecie przeczytać w innym moim artykule: Mierzalne wartości projektu.

Prawdziwi użytkownicy systemu

Users, clients: W połączeniu z definicją systemu użytkownik przestaje być tylko użytkownikiem wytwarzanego przez nas narzędzia. Użytkownikiem staje się każda rola w systemie zdefiniowanym przez biznes.

Klient w tym kontekście niekoniecznie jest osobą, która nam płaci za wykonaną pracę. Jest to osoba, która płaci za wynik działania całego lub części systemu. Nie muszą go interesować techniczne sprawy, jak np. w jaki sposób dostarczane są bilety do punktów sprzedaży czy w jaki sposób nasz system informatyczny jest testowany.

Biznes patrzy szeroko na stawiane przed nim problemy. Stara się dostarczyć wartość swoim konkretnym interesariuszom, wprowadzić usprawnienie, które pozwoli zmienić coś w ich życiu. Pamiętajmy też, że biznes również jest interesariuszem swojego projektu i jednym z jego kluczowych celów będzie możliwość uzyskania zwrotu z inwestycji.

Jakość dla biznesu, to wartość dostarczana interesariuszom. Więcej na ten temat poczytasz tutaj:
Value – how well the Product-Function performs as experienced by Stakeholders. – Tom Gilb

Przestań przekonywać biznes

Wróćmy do naszego galopującego projektu. Projekt dalej się jednak rozwija i problemy związane z wdrażaniem nowych funkcjonalności narastają.

Jak więc znaleźć wspólny język i przekonać biznes do naszych rozwiązań?
A może zamiast przekonywać, może lepiej zrozumieć biznes?

Chciałbym, żebyście i Wy spróbowali zrozumieć na czym zależy biznesowi.

Za każdym wymaganiem czai się jakiś problem, za każdym User Story – jakaś historia. Być może osoby, które są dedykowane dla Was od strony biznesu, nie do końca potrafią sformułować to, czego potrzebują. Nie potrafią sprowadzić swoich wymagań do postaci, która dla zespołu deweloperskiego będzie odpowiednia. Jest to szczególnie trudne, gdy biznes ma przygotować informacje dla grupy inżynierów, którzy wymagają konkretów.

Osoby biznesowe niekoniecznie wpadną na niektóre techniczne problemy, które zespół deweloperski jest w stanie zidentyfikować dużo wcześniej. Być może biznes nie ma takiej wiedzy, albo niektóre kwestie techniczne nie mają dla niego znaczenia.

Poznanie całości

Zrozumienie biznesu i zrozumienie historii, które kryją się za stawianymi przed nami wymaganiami, wymaga pokory i otwartego umysłu.

Jako inżynierowie chcemy, żeby cel biznesowy został osiągnięty. Mamy wiedzę i narzędzia, które pozwolą przybliżyć klienta do tego sukcesu. Biznes ma obrany kierunek, ma możliwość sprawdzenia które wymagania jego interesariuszy są spełnione. Dzięki temu może nas nakierować na odpowiedni tor.

Jeżeli poznamy aspiracje (cele) zespołu biznesowego oraz jego definicję jakości i systemu, będziemy mówić tym samym językiem korzyści. Będziemy mogli, jako zespół deweloperski, przekazać jak możemy biznesowi pomóc w osiągnięciu ich celów. Będzie nam łatwiej wykonać projekcję, w której przedstawimy jak proponowane przez nas techniczne narzędzia (testy regresji, testy jednostkowe, test plany, narzędzia devops i wiele innych) wpłyną na sukces projektu.

Zarządzaj ryzykiem

Wyobraźmy sobie, że reprezentacja biznesu przychodzi do nas z takim wymaganiem:

“Po przyłożeniu karty z biletem do czytnika bilet ma zostać zaktywowany w nie dłużej niż 250 milisekund”.

Wymaganie wydaje się jasne. Jesteśmy w stanie doprowadzić do sytuacji, w której ta część systemu informatycznego będzie spełniała życzenie biznesu.

Czy potraficie odpowiedzieć na pytanie jakie biznes poniesie konsekwencję, jeśli to wymaganie nie będzie spełnione? Jeśli nie macie wiedzy na ten temat, to jak udowodnicie biznesowi, że Wasze środki ograniczające to ryzyko są adekwatne do problemu? Może być to trudne.

Jaki problem rozwiązujemy?

Możecie zapytać klienta dlaczego to wymaganie jest dla niego ważne:

W trakcie większych imprez sportowych zauważyliśmy, że ludzie kupują bilety na ostatni moment. Wszyscy na raz! W obecnej wersji, gdy przekraczamy pułap 30 zakupów na sekundę, czas nabycia biletu zaczyna mocno się wydłużać. W takich przypadkach zajmuje to tyle czasu, że osoby zdążą już odsunąć swoją elektroniczną kartę od czytnika. Kontrolerzy wystawili bardzo dużo mandatów, które musiały zostać cofnięte. Pasażerowie w trakcie kontroli byli mocno zdenerwowani, a lokalna prasa temat bardzo dobitnie opisała w swoich artykułach. Aktualnie przy takich imprezach oferujemy darmowe przejazdy. Gdy po raz pierwszy błąd wystąpił, Urząd Miasta żądał wyjaśnień. Nie tylko nie zarobiliśmy tego dnia, ale również musieliśmy zapłacić karę i przepraszać osoby, które niesłusznie otrzymały mandat.

Czego się dowiedzieliśmy?

• Opis systemu:
  • Jaki problem występuje?
  • W jakich warunkach?
  • Kogo dotyczy problem?
    • Osób kupujących bilet,
    • Kontrolerów biletów,
    • Osoby sprzedające bilety,
    • Urząd Miasta,
    • Lokalna prasa.
• Czynniki wpływające na jakość biznesową:
  • Biznes jest zobowiązany do zapłaty kary w przypadku wystąpienia problemu.
  • Pasażerowie myśląc, że mają skasowany bilet, są spisywani przez kontrolerów.
  • Prasa źle się wypowiada o instytucji, której biznes oferował rozwiązanie.

Znając punkt widzenia biznesu, jesteśmy w stanie wytłumaczyć co możemy zrobić, żeby zminimalizować ryzyko wystąpienia danej sytuacji:

• Przygotować plan testowy – opisać jakie warunki muszą zostać przetestowane, które odpowiadają warunkom produkcyjnym.
• Napisać testy jednostkowe – minimalizujemy ryzyko, że ktoś przez przypadek wprowadzi niechcianą zmianę.
• Zaplanować testy wydajnościowe na środowisku testowym – będziemy wiedzieć, czy w warunkach, które przewidzieliśmy w planie testowym, rozwiązanie działa dobrze,
• Monitorować wydajność na środowisku produkcyjnym – będziemy wiedzieć jak zachowuje się rozwiązanie na żywo i będzie to dla nas źródłem wiedzy o przypadkach nieprzewidzianych w test planie.
• Przygotowanie maszyn zastępczych w razie awarii – jeśli sprzęt zawiedzie, poprzez posiadanie maszyn zapasowych minimalizujemy czas braku dostępu do systemu.
• Gotowość zespołu deweloperskiego w trakcie imprez masowych – minimalizacja czasu wyłączenia rozwiązania,
• Budować rozwiązanie w sposób pozwalający na powrót do wcześniejszej, stabilnej wersji,
• Zmienić warunki umowy – wynegocjować zmniejszenie kary za ewentualne problemy na środowisku produkcyjnym,
• itd.

Minimalizacja ryzyka

Znając kontekst biznesowy podajemy rozwiązania, które minimalizują ryzyko biznesowe, minimalizują stratę, którą może ponieść biznes i maksymalizujemy szansę na osiągnięcie ich celu. Zauważcie, że nie wszystkie rozwiązania technicznego problemu są techniczne. Czasami biznes może wynegocjować ze swoimi partnerami i klientami procesy pozwalające na minimalizację ryzyka i warto je również brać pod uwagę.

Biznes podejmuje wtedy decyzję co jest złotym środkiem, na jakie ryzyko może sobie pozwolić. Dzięki Waszej analizie będzie mógł powiedzieć, na które metody minimalizacji ryzyka jest skłonny poświęcić środki. Nie każde ryzyko musi być rozwiązane przez zespół deweloperski. Żeby jednak zarządzić ryzykiem, biznes musi być świadom tego ryzyka.

Ten konkretny przykład nie jest hipotetyczną sytuacją. Niejednokrotnie byliśmy świadkami jak ogromne systemy informatyczne wpływały na życie milionów osób. Słyszymy o awariach bankowości internetowej, które mogą spowodować, że ktoś nie zapłaci raty kredytu na czas, awariach sieci elektrycznych, czy awariach systemów lotów, które doprowadzają do ogromnego zamieszania wśród klientów, przez co firmy tracą wizerunek, klientów i pieniądze.

“The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”

– Frederick P. Brooks , Jr. (1931- ) ‘No silver bullet’, 1987.

Podsumowanie

Jeden cel, wiele ról

Zespół biznesowy i zespół deweloperski mają wspólny cel – chcą, by rozwiązanie osiągnęło sukces.

Trzeba być świadomym potrzeb każdej ze stron, żeby zacząć mówić wspólnym językiem. Wypatruję tutaj Twojego zaangażowania. Jako świadomy członek zespołu wytwarzającego rozwiązanie powinieneś rozumieć czym ono jest, jaki problem ma być rozwiązany i jakimi ryzykami zarządza biznes. Dzięki temu będziesz mógł uargumentować dobór narzędzi i metod, które mają doprowadzić do dostarczenia jakości biznesowej przez jakość techniczną.

Brak znajomości systemu przeszkadza

Jeżeli nie znamy kontekstu biznesowego i systemu, w których wytwarzane przez nas narzędzie ma działać, ciężko jest udowodnić jak zaproponowane przez nas rozwiązania wpłyną na cel biznesowy.

Zespół deweloperski ma lata doświadczenia w kwestiach związanych z technologią, śledzi najnowsze rozwiązania na rynku, pragnie próbować nowych rzeczy. Biznes też śledzi najnowsze trendy – które rozwiązania się sprzedają, czego żądają klienci, jaki wpływ ma zmieniające się prawo i umowy na jego cel biznesowy.

Biznesowi jest trudno zrozumieć kontekst techniczny, ale wysłucha Cię, jeżeli powiesz jak rozwiązanie technicznie wspomoże jego cel.

Nie zawsze biznes chce się podzielić swoimi informacjami. Ma do tego pełne prawo. Jeżeli znalibyście cały kontekst biznesowy, to czy nie istnieje pewne prawdopodobieństwo, że staniecie się za parę lat konkurencją? Jesteście również ryzykiem, którym biznes musi zarządzić i zdecydować jak wiele chce powiedzieć. Czasem umowy zakazują dzielenia się pewnymi informacjami z firmami trzecimi. Na uzyskanie zaufania biznesu również trzeba czasu.

Dlaczego to rozwiązanie?

Jako zespół techniczny nie powinniśmy się zamykać na jednym rozwiązaniu. Rozwiązania techniczne, które są aktualnie na topie, nie zawsze będą zbliżać nas do celu biznesowego. Możemy forsować pewne koncepty, jednak jeżeli nie potrafimy udowodnić, że to rozwiązanie jest korzystne dla biznesu, to dlaczego je forsujemy?

Jeżeli dowiemy się jaka jest historia danego wymagania i jakie potencjalne konsekwencje będzie ponosił biznes, będziemy w stanie ocenić co z punktu technicznego najkorzystniej wpłynie na cel biznesowy.

W projekcie zespół biznesowy i techniczny wzajemnie się wspomagają. Wszystkie podejmowane decyzje powinny zbliżać oba zespoły do celu biznesowego. Jeżeli poświęcimy czas, żeby zrozumieć ten cel, będziemy w stanie dobrać najkorzystniejsze na dany moment rozwiązanie i przedstawić je biznesowi w sposób, który uzna je za potrzebną inwestycję.

Zachęcam również Ciebie do wyjścia poza techniczne ramy. Branża IT kształtuje przyszłość, jednak to zmieniający się świat dostarcza wyzwań dla branży IT.

Życzę więc Tobie, żebyś zrozumiał jak najwięcej wyzwań otaczającego świata i dzięki temu pozwolił rozwinąć się sobie i Twoim zespołom deweloperskim i biznesowym.

Bibliografia

• Jak przekonać biznes do usprawnienia kodu?
• Value Planning by Tom Gilb, Chapter 10 Quality Management
• 20 Tough Questions every Project Manager and Product Owner should have in their Arsenal. These questions come with warnings
• ISTQB Glossary
• Mierzalne wartości projektu
• Paweł Nowak: Granice Systemów

Kasjan Kotynia Business Analyst, profil na LinkedIn Analityk biznesowy, współtwórca szkoły Useful Knowledge i współorganizator WUD Silesia, współtwórca projektu Badacze WUD Silesia. Swoją przygodę z obszarem IT rozpoczął w 2011 roku jako QA, gdzie zgłębiał wiedzę odnośnie automatyzacji procesów tworzenia oprogramowania. Od ponad 6 lat zajmuje się analizą biznesową w projektach offshoringowych i produktach. W ramach działań związanych z WUD Silesia pracuje przy projektach silnie skoncentrowanych na ludziach. Posiada doświadczenie z produktami opartymi na Machine Learningu w branży retail i security. Zapalony motocyklista i gracz 😉