Określenie co jest trudniejsze, a co łatwiejsze jest względne, jednak dla potrzeb wpisu przyjmę, że za nieco trudniejszy projekt internetowy można uznać produkcję i wdrożenie aplikacji internetowej o ilości podstawowych scenariuszy użycia nie mniejszej niż 15 z której korzysta nie mniej niż 500 tyś. unikalnych użytkowników dziennie.

Problem z jakością

Na początek dwa charakterystyczne wymagania w projektach internetowych.

Od aplikacji internetowych oczekuje się prawidłowego funkcjonowania w wielu konfiguracjach sprzętowo-przeglądarkowo-operacyjno-sieciowych. Gdyby tylko uwzględnić 6 przeglądarek, 3 systemy operacyjne, 2 typy łącz to otrzymujemy 36 kombinacji. W przypadku dużej ilości użytkowników dochodzi także znaczna ilość unikalnych scenariuszy użytkowania.

oraz

Od twórców aplikacji internetowych, oczekuje się szybkiego przekazania produktu do użytkowania.

Nawiązując do koncepcji trójkąta projektowego (na bokach zakres, czas oraz budżet, a pole trójkąta jako jakość) można odtworzyć sytuację, jaka występuje w większości projektów. Zwykle zespół projektowy otrzymuje zadanie: proszę przygotować produkt o zadanym zakresie, na wskazany termin. Tak postawione oczekiwania w kontekście trójkąta projektowego determinują wymiar kosztów i jakości. Innymi słowy sztywne określenie z góry dwóch wymiarów (czas i zakres) powoduje, że dwa pozostałe, tj. koszty, a w szczególności jakość będą „jakieś”, ale prawdopodobnie nie takie, jakie by można uznać za akceptowalne.

Można pójść krok dalej i postawić tezę, że w przypadku produktu zdefiniowanego na początku wpisu (aplikacja internetowa o ilości podstawowych scenariuszy użycia nie mniejszej niż 15 z której korzysta nie mniej niż 500 tyś. unikalnych użytkowników dziennie), w 7 na 10 przypadków jakość wdrażanego produktu będzie niedostateczna.

Jakość produktu jest precyzyjnie zdefiniowanym wymiarem projektowym (np. definicje Philip-a Crosby), jednak bez powoływania się na definicje oczywiste jest, że przekroczenie pewnej granicznej ilości zgłoszeń o usterkach świadczy o brakach w jakości. Przyjmijmy, że świadectwem niedostatecznej jakości dla produktu zdefiniowanego na początku wpisu będzie więcej niż 100 zgłoszeń dziennie.

Identyfikując ryzyko, że wdrażany produkt może mieć problemy z jakością należy przygotować plan działań zapobiegawczych (realizowanych w czasie produkcji) oraz działań alarmowych (realizowanych, gdy ryzyko się urzeczywistni).

Walka o jakość podczas produkcji

W czasie produkcji można na wiele sposobów pozytywnie wpływać na końcową jakość produktu. Zwrócę uwagę na trzy aspekty, które w mojej ocenie są kluczowe: zarządzanie zakresem i ryzykiem oraz metodologia testowania.

Zarządzanie zakresem

Źle przygotowany zakres to jedna z głównych przyczyn problemów w czasie trwania projektu oraz problemów z jakością produktu końcowego.
Dla uproszczenia przyjmę, że zakres = zakres funkcjonalny.

Bez względu na to, czy stosujemy podejście projektowe tradycyjne, czy też adaptacyjne, wiedza o tym, co w danym przedziale czasu należy zrobić, musi być pełna, w szczególności chodzi o scenariusze alternatywne. Można przywołać zasadę Pareto i zinterpretować ją w ten sposób, że 80% problemów projektowych zdeterminowanych przez zakres ma swoją przyczynę w 20% wymagań i są to zwykle właśnie wymagania opisane przez scenariusze alternatywne.

Odpowiedź na to, jak przygotować dobry zakres (spójny, jednoznaczny, kompletny) jest bardzo obszerna i nie jest przedmiotem tego wpisu. Pewne jest jednak, że praca nad zakresem powinna się kojarzyć z dużym wysiłkiem, według mnie największym wysiłkiem na jednostkę produkcyjną spośród wszystkich działań projektowych.

Podsumowując, nie ma harmonogramu, nie ma zarządzania zmianą, nie ma zarządzania jakością i nie ma zarządzania ryzykiem, jeśli nie ma dobrze przygotowanego zakresu.

Zarządzanie ryzykiem

Zarządzając projektem z perspektywy ryzyk zwiększa się szanse na przygotowanie produktu o odpowiedniej jakości.
W kilku słowach zarządzanie projektem z perspektywy ryzyk można scharakteryzować jako realizację trzech typów działań:

  1. Identyfikowanie i wymiarowanie ryzyk
  2. Tworzenie i pielęgnowanie planów zapobiegawczych i alarmowych
  3. Realizacja działań projektowych oraz podejmowanie decyzji w kontekście listy ryzyk

Czasami zarządzanie ryzykiem zaczyna się i kończy na zidentyfikowaniu i zwymiarowaniu ryzyk. Takie podejście powoduje, że w sytuacji gdy ryzyko się urzeczywistnia, z braku czasu podejmuje się decyzje nieprzemyślane lub krótkowzroczne. Bez trudu można przewidzieć jak takie decyzje wpływają na końcową jakość produktu.

Metodologia testowania

Zagadnienie planowania i realizacji testów jest bardzo szerokie i nie sposób w kilku zdaniach opisać nawet przybliżonego obrazu wszystkich aspektów tego zagadnienia.
Nie ulega jednak wątpliwości, że w kontekście produktu rozważanego w tym wpisie szczególnie kluczowe z punktu widzenia skutecznej metodologii testowania jest:

  1. Zapewnienie odpowiedniej szerokości testów czyli realizacja testów dla wielu konfiguracji sprzętowo-przeglądarkowo-operacyjno-sieciowych. Istnieje realne prawdopodobieństwo, że zapewnienie odpowiedniej szerokości testów będzie wykraczać poza możliwości działu jakości producenta. W takiej sytuacji niezwykle pomocny jest outsourcing testów (fragmentu lub całości) do jednostek specjalizujących się w takiej działalności.
  2. Realizacja zarówno testów funkcjonalnych klasycznych (na podstawie scenariuszy testowych) oraz testów eksploracyjnych. Nie sposób nie zwrócić uwagi, że najskuteczniejsze testy eksploracyjne to takie, które są wykonywane przez inne osoby niż te które realizują testy klasyczne.

Po udostępnieniu

Przygotowując plan działań alarmowych będących odpowiedzią na urzeczywistnienie się ryzyka niedostatecznej jakości należy mieć świadomość, że po udostępnieniu pojawią się zgłoszenia od użytkowników, którzy wskażą m.in.:

  1. Usterki w funkcjonalnej konstrukcji produktu (błędy w zakresie)
  2. Usterki związane z użytecznością (błędy w projektowaniu)
  3. Usterki w działaniu, które udaje się powtórzyć
  4. Usterki w działaniu, których nie udaje się powtórzyć

W tym miejscu nie sposób nie zauważyć, że najtrudniejszy wymiar problemu z niedostateczną jakością związany jest z usterkami niepowtarzalnymi.

Przygotowując się na taką okoliczność należy przygotować:

  1. Mechanizmy rejestrowania (logowania) danych diagnostycznych
  2. Narzędzie monitorujące
  3. Narzędzie do testów regresji

Mechanizm rejestrowania

Jedną z najskuteczniejszych metod poszukiwania przyczyn niepowtarzalnych usterek jest analiza danych diagnostycznych.

Identyfikacja, jakie dane powinny być rejestrowane jest w gestii developerów, jednak kierownik projektu powinien zarezerwować czas w trakcie produkcji na przygotowanie i podpięcie mechanizmów rejestrujących.

Od razu można przyjąć, że prawdopodobnie zakres rejestrowanych danych będzie niedostateczny, aby zidentyfikować przyczyny wszystkich problemów, dlatego również na etapie wsparcia powdrożeniowego należy przewidzieć czas na rozbudowę zakresu rejestrowanych danych.

Z rejestrowaniem danych w przypadku aplikacji dla większej ilości użytkowników jest jeszcze jeden problem, a mianowicie: gdyby zdecydować się na zbieranie wszystkich możliwych danych od wszystkich użytkowników, to bardzo szybko serwery danych zostałyby zapełnione. Dla niektórych produktów internetowych byłaby to kwestia kilku sekund, dlatego mechanizm rejestrowania danych diagnostycznych powinien umożliwiać m.in. zapis danych dla wskazanych użytkowników, np. tych zgłaszających problemy.

Narzędzie monitorujące

Głównym przeznaczeniem narzędzia monitorującego powinno być kumulowanie wszystkich danych w jednym miejscu oraz dostarczanie informacji o trendzie.

Narzędziem monitorującym może być zwykły arkusz kalkulacyjny, w którym powinno się gromadzić szerokie spektrum danych. Poczynając od logów na poziomie backendu, logów warstwy pośredniej, a kończąc na logach warstwy frontowej.

W takim arkuszu powinny się znaleźć również dane dotyczące ilości korzystających użytkowników oraz ilości zgłoszeń jakie od nich pochodzą.

Dane powinny mieć właściwą dla sytuacji granularność np. przedziały godzinowe, dzień, tydzień.

Odpowiedzią na zgłoszenia od użytkowników będą sukcesywnie wdrażane poprawki. Dzięki narzędziu monitorującemu można oceniać jak zmienia się sytuacja po kolejnych wdrożeniach.

Narzędzie do testów regresji

Poprawianie jakości produktu już po udostępnieniu wiąże się z kolejnymi wdrożeniami, które również powinny być zapisywane w narzędziu monitorującym. Oczywiste jest również, że tak naprawdę każde wdrożenie to z jednej strony szansa na poprawę, ale z drugiej ryzyko pogłębienia niestabilności produktu.

W tym miejscu dochodzimy do kolejnej właściwości złożonych projektów. W przypadku takich projektów musi być przewidziane wykorzystanie automatycznego narzędzia do testów regresji. Początkowo może się wydawać, że to tylko zwiększy koszty, jednak w momencie walki z problemami już po udostępnieniu takie narzędzie wydaje się bezcenne.

Podsumowanie

  • Produkty internetowe, w szczególności aplikacje przeznaczone dla dużej grupy użytkowników są i będą udostępnianie w stanie, w którym ich jakość będzie niedostateczna. Jest to niezależne od jakości procesu wytwarzania.
  • W etapie produkcji największy wpływ na uzyskanie dobrej jakości ma:
    • Dobrze przygotowany zakres
    • Właściwe zarządzanie ryzykiem
    • Skuteczna metodologia testowania
  • Trzeba być przygotowanym, że po udostępnieniu produktu pojawią się zgłoszenia od użytkowników, a najbardziej uciążliwe do wyeliminowania będą usterki trudne lub niemożliwe do odtworzenia w środowisku firmy produkującej i testującej.
  • Kluczowym orężem w fazie wsparcia powdrożeniowego dla każdego projektu, ale w szczególności dla projektów dostarczających złożone produkty są:
    • Mechanizmy rejestrujące dane diagnostyczne
    • Narzędzia monitorujące
    • Narzędzie do testów regresji

Arkadiusz Lubaś
kierownik projektów