Redakcja
Poniżej opisujemy kilka przykładów, w których źle stosowany proces kontroli i zapewnienia jakości przy prostych rozwiązaniach może prowadzić do olbrzymich korzyści projektowych.
Przykład 1.
Organizacja zatrudnia dwóch testerów, którzy nie potrafią testować. Są to osoby bez wiedzy i doświadczenia, delegowane do "nowego" zadania, którego nie potrafią wykonać i prawdopodobnie traktują je jako formę kary. Realne koszty zatrudnienia nie przekładają się praktycznie na żadne zyski, za to powodują frustrację po stronie samych testerów i programistów.
Rozwiązanie (oczywiste) to przeprowadzenie powtórnej rekrutacji na stanowisko testera wśród wcześniej wyselekcjonowanych pracowników. W połączeniu z coachingiem testowym będzie to skutkować zwolnieniem lub przesunięciem jednej z osób do innych zadań. Drugiej osobie może to pomóc w zdefiniowaniu słabych i silnych stron w testowaniu. Odpowiednio skonstruowany plan szkoleniowy pomoże uformować pełnowartościowego testera. W tym projekcie jedna osoba w zupełności wystarczy do osiągnięcia celów i założeń kontroli jakości.
Oszczędności z redukcji kosztów etatu pozwalają na dofinansowanie edukacji w pierwszych miesiącach i prowadzą do dalszych oszczędności.
Przykład 2.
Organizacja stosuje podejście Continuous Integration, polegające na budowaniu wersji oprogramowania po każdym wgraniu nowego kodu do systemu wersjonowania. Na każdej nowej wersji oprogramowania uruchamiane są testy automatyczne, pisane przez testerów. Programiści nie analizują jednak ich wyników i nie naprawiają raportowanych przez automaty awarii. Wychodzą z założenia, że część defektów może być spowodowana przez słabej jakości testy lub przez środowisko testowe. Defekty wracają do automatyków, którzy są zobligowani do zbadania powodu niepowodzenia testu i tworzą zgłoszenie w przypadku, gdy niepowodzenie wynika z problemów związanych z wgranym kodem.
Odpowiedzialność za naprawianie testów leży oczywiście po stronie testerów. Jednak wiele raportów wynikających z wielu wgrywek na serwer wersjonowania utrudnia pracę testerom i wydłuża czas analizy. Przy nieprzejednanym stanowisku programistów modyfikujemy procedury uruchamiania testów. Optymalizacja w tym przypadku zakłada, że testy nie będą uruchamiane po każdym wgraniu kodu, ponieważ ich wyniki i tak nie są analizowane. Kontrolę nad uruchomieniem przejmują testerzy i to oni decydują, kiedy i w jakim zakresie uruchamiane są testy automatyczne. Zysk to nie tylko czas automatyków, ale również mniejsze zużycie zasobów serwerowych i zredukowanie środowisk testowych.
Przykład 3.
W dużej instytucji finansowej zatrudniono pięciu zewnętrznych konsultantów z firmy outsourcingowej, których celem jest testowanie produktów wytworzonych przez programistów. Ponieważ koszty wynajęcia pracowników są znaczne zdecydowano się zatrudnić lidera testów, którego cała praca zorientowana jest na kontrolę pracy podwykonawców. Jednomiesięczny koszt etatu lidera jest mniejszy od kosztu zatrudnienia jednego zewnętrznego testera. Lider jest niezadowolony z efektywności części zespołu i regularnie prosi o "podmianę" danego pracownika. Lider nie ma realnego wpływu na dobór pracowników.
Z takim i podobnym problemem spotkamy się w wielu organizacjach, a wynika on z olbrzymiego obciążenia dla pracodawcy, jakim są umowy o pracę. Pracodawcy wolą więc przepłacać za wynajmowanych pracowników, nawet jeśli nie do końca są zadowoleni z dostarczanych usług. Doświadczenie pokazuje, że własny zespół potrafi bardziej zaangażować się w wykonywaną pracę i wykazać się większą motywacją. Pracownik zewnętrzny nie przywiązuje się do projektu, na który został oddelegowany, ponieważ zazwyczaj nie on dokonuje wyboru, a jest jedynie przypisany do nowego zadania. W tym przypadku rozwiązanie umowy z zewnętrznym dostawcą i zbudowanie wewnętrznego, mniejszego (np. 3-osobowego) zespołu nie odbija się w żaden sposób na jakości usług testowania i pozwala w danym momencie na redukcję kosztów testowania o blisko połowę. Lider w tym mniejszym zespole zostaje odciążony od ciągłej kontroli pracy i może zaangażować się w analizę i projektowanie testów.
Proponowane przez nas rozwiązania często są bardzo proste i na pierwszy rzut oka oczywiste. Wymagają oczywiście analizy obecnej sytuacji projektowej i dostosowania się do kontekstu organizacji. Dzielimy je na dwa typy: szybkie korzyści (ang. quick win) i długoterminową strategię (ang. long term strategy). Oba mają jednak jedną podstawową cechę - nigdy nie są złożone. Jeśli organizacja jest nieformalna, proponujemy drobne zmiany, które mogą poukładać obecne procedury. Jeśli organizacja jest przeformalizowana, to proponujemy drobne uproszenia. W sytuacji, gdy organizacja oczekuje rewolucyjnych zmian, dokładnie analizujemy grunt ich wdrażania i proponujemy rozciągniętą na wiele miesięcy, a czasami lat, strategię.
Co więcej, jesteśmy tak pewni wartości z samej optymalizacji, że swoim klientom proponujemy usługi jedynie za osiągnięty sukces (ang. success fee). Jeśli zaproponowane przez nas zmiany wprowadzą oszczędności, to organizacja, która nas zatrudniła nie płaci nam stawek za pracę, a procent od osiągniętych oszczędności.
