Podnoszenie jakości a rozwój systemu. Szanse i wyzwania

podnoszenie-jakosci
W poprzednim artykule na temat zarządzania jakością starałem się wytłumaczyć, dlaczego warto czasem ograniczyć jakość w początkowych fazach Customer Development, aby potem rozpocząć podnoszenie jakości. Można się z nim zapoznać tutaj. Natomiast z poniższego artykułu dowiesz się:

– jakie problemy powoduje zbyt niska jakość w kolejnych fazach

– co trzeba robić aby sobie z nimi poradzić

– czy naprawdę warto zarządzać jakością w projekcie IT


Bugs&failures

Pierwszym zderzeniem są błędy i niedociągnięcia funkcjonalne jakie projekt innowacyjny niezmiennie posiada w momencie podjęcia decyzji o udostępnieniu użytkownikom. Do tej pory skupialiśmy się na MVP, które miało zweryfikować idee i wówczas dla klientów akceptowalne były błędy. Teraz gdy nie czują się już „testerami” a raczej pełnoprawnymi użytkownikami, już ich nie zaakceptują. Zatem zanim zaczniemy dodawać nowe funkcje musimy część budżetu przeznaczyć na błędy wieku dojrzewania oprogramowania. Musimy podnieść jakość testowania funkcjonalnego, posprzątać spaghetti code itp.

Długi czas wprowadzania zmian

Kolejnym problemem jaki napotykamy jest rosnący czas wprowadzania zmian, czy nowych funkcji. W fazie początkowej pracowaliśmy w małym zespole, na jednej wersji, nie musieliśmy przy zmianach martwić się zapewnieniem ciągłości działania aplikacji w chwili wgrywania zmian ani przekazaniem wiedzy nowym członkom zespołu. Teraz trzeba o to wszystko zadbać porządkując metodykę planowania pracy i wdrożeń, mnożąc środowiska testowe, wdrażając code review, obszywając kod testami automatycznymi. Pozwoli nam to znów szybko wprowadzać zmiany na rynek, nasz „time-to-market” jest znów dobry.

Problemy z wydajnością

Jesteśmy w fazie, gdy dzięki naszej doskonałej pracy liczba użytkowników i danych rośnie. Dział marketingu wydaje środki na ich pozyskanie i nagle pojawiają się time out’y, a przed większą promocją (czy np. czarnym piątkiem) każdego Product Ownera ogarnia strach i zamiast kawy pije rano melisę. Musimy stawić czoła wydajności i skalowaniu rozwiązania. Czas na optymalizacje, rozrzucanie na wiele serwerów, cache, testowanie wydajnościowe itp. To kolejny element jakości w jaki musimy inwestować aby zarabiać.

Utrzymanie systemu

Kolejne miesiące wytężonej pracy przynoszą efekty i nasza organizacja rośnie. Nie jesteśmy już śmiałym startupem, bez obciążeń przeszłości i zobowiązań, ale naprawdę zarabiamy na projekcie pieniądze. Dotyka nas wtedy problem starzenia się aplikacji, której kod i logika biznesowa rozwijane przez lata stały się skomplikowane. Zespół rozrósł się tak, że ludzie przestają się znać i naturalnie współpracować. Powoduje to rotację ludzi, wzrost kosztów nauki i komunikacji. Konieczne jest uporządkowanie pracy, wprowadzenie narzędzi wpierających DevOps, skupienie się na metodykach i wzrost świadomości, że równie krytyczne jak szybkie wprowadzanie nowych funkcji na rynek jest usuwanie długu technologicznego. Niektóre zmiany są już na tyle skomplikowane, że warto je testować znów jako MVP, a nie od razu decydować się na ich wprowadzenie.

Narzędzia DevOps stosowane w Grupa Unity w 2018 roku

Długofalowe utrzymanie kodu i zespołu

Równolegle dochodzimy do znudzenia starym kodem sprzed kilku lat i brakiem nowych wyzwań technologicznych dla zespołu. Coraz ciężej jest zatrudnić i wprowadzić w kod nowych developerów. Zespól rotuje. Dla nowych ludzi z kolejnych pokoleń liczą się inne aspekty w życiu zawodowym, często zależy im na szybkim rozwoju. Aby temu zapobiec musimy cały czas pracować nad odświeżaniem kodu. Konieczne jest wraz z rozbudowywaniem funkcjonalnym upraszczanie starych elementów, które z powodu zmian stały się skomplikowane. Także pilnowanie wymiany bibliotek bazowych na nowe i aktualne jest konieczne, nawet jeśli stare nadal działają, tak aby wejście w kod dla junior developera nie było zabawą w archeologa. Bardzo istotna jest także praca nad kulturą zespołu, tak aby wszyscy starzy i nowi członkowie mieli wspólny cel i grali do jednej bramki zamiast dzielić się na klany.

Zamiast podsumowania – czy na pewno warto?

Ilość pracy nad szeroko pojętą jakością rozwoju systemu IT jest duża i można się zastanawiać, czy w ogóle warto? A może uda się bez tego wszystkiego? Można spróbować, ale trzeba skalkulować, że brak takiego podejścia oznacza, że wielu nowych funkcji nie wdrożymy, część klientów utracimy, a co kilka lat będziemy musieli kupić nowy system. Gdy policzymy ROI to okazuje się, że jednak warto te koszty ponosić. W Grupie Unity mamy systemy, które działają nieprzerwanie od 10 lat, mają nowe biblioteki, ludzie lubią i chcą przy nich pracować, a klienci są zadowoleni używając ich. Dobrym przykładem mogą tu być nasze realizacje dla Euro RTV AGD:

Wdrożenie platformy e-commerce

M-commerce

Napisz do nas

Potrzebujesz więcej informacji lub jesteś zainteresowany współpracą z nami? Chętnie odpowiemy na każde pytanie. Zapraszamy do kontaktu!
Pola oznaczone * są wymagane.