Zarządzanie jakością w IT – dopasowanie jakości do fazy rozwoju organizacji
Wyobraź sobie, że współpracownik pyta Cię na początkowym etapie analizy, jakiej jakości projektu oczekujesz. Najprawdopodobniej już w pierwszym odruchu odpowiedziałbyś: najwyższej! I właściwie nikogo by to nie zdziwiło. Czy jest to jednak najlepsza z możliwych odpowiedzi? Czy kiedy kupujesz ciastko to ma być najsłodsze, a samochód najszybszy?
Z tego artykułu dowiesz się:
- czym jest jakość
- jak zarządzanie jakością można odnieść do modelu rozwoju innowacyjnego biznesu
- czy w projektach IT warto zaczynać od niskiej jakości
Co to jest jakość?
Tematem jakości interesowali się już klasyczni myśliciele. Platon pisał: „jakość (gr. poiotes, łac. qualitas) to pewien stopień doskonałości”
Już samo to powinno dać nam wyraźny sygnał, że jakość jest czymś nie tylko stopniowalnym, ale także mocno relatywnym. Jeśli jednocześnie pochylimy się nad samą ideą zarządzania, to ona również nie mówi o tym, aby wszelkie aspekty i czynniki bezrefleksyjnie zwiększać. Należy raczej dopasować środki do celów, aby rzeczy mogły się efektywnie „zadziać”. Zatem biorąc pod uwagę choćby same kwestie definicyjne dowiadujemy się, że trzeba dopasowywać jakość, a nie ślepo brnąć ku najwyższej.
Ale jak przełożyć zarządzanie jakością na praktykę prowadzenia projektów IT?
Zarządzanie jakością a model rozwoju innowacyjnego biznesu
Świat w którym żyjemy jest coraz bardziej zmienny, złożony i pełen niepewności. Wielu ekspertów określa go jako VUCA World (Volatility, uncertainty, complexity and ambiguity). Wymusza to stosowanie metodyk o wysokiej adaptacyjności, czyli metodyk zwinnych (Agile). W przypadku prowadzenia projektu IT występuje kilka metodyk opierających się na zwinności jak np. używany przez nas zestaw AgilePM i Scrum.
Coraz częściej metodyki zwinne wykorzystuje się także w rozwoju czy zarządzaniu firmą. Wywodzą się one ze świata start-up’ów, ale dotyczą każdego rodzaju inicjatywy innowacyjnej jaka prowadzona jest w małej lub dużej organizacji. Mam tu na myśli szczególnie metodyki Customer Development czy Lean Customer Development.
Dla chcących zapoznać się szczegółowo z tymi metodykami polecam książki “Podręcznik startupu. Budowa wielkiej firmy krok po kroku” autorstwa Steve Blank, Bob Dorf, czy „Lean Customer Development” autorstwa Cindy Alvarez.
W kilku słowach – w pojęciu Customer Development chodzi o szybkie weryfikowanie z rynkiem hipotez oraz stopniowe poprawianie i rozwijanie wszystkiego co dotyczy produktu/projektu (dla pracujących Agile na pewno brzmi to znajomo ;))
Customer Discovery
Nie zaskoczę Cię pisząc, że cały rozwój biznesu zaczyna się od opracowania hipotez dotyczących klientów, ich potrzeb, kanałów dotarcia, a na końcu MVP (Minimum Viable Product) pozwalający zweryfikować te hipotezy z klientami.
Customer Validation
Weryfikacja często prowadzi do zmian (pivot), które trzeba wykonać szybko i tanio. Dopiero gdy faktycznie uda nam się zweryfikować, że nasz produkt jest dla wybranych klientów właściwy, opracowujemy końcowy model biznesowy (np. wg modelu The Business Model Canvas opisanego przez Alexander Osterwalder) razem z planem sprzedaży i marketingu, a następnie zaczynamy wychodzić z produktem na rynek.
Kolejne dwie fazy to już skalowanie biznesu. A zatem Customer Creation, czyli pozyskanie wystarczającej liczby klientów, aby uzyskał on miejsce na rynku poza grupą „early adopters”. Gdy jesteśmy gotowi stwierdzić, że działania sprzedażowe są efektywne, budujemy organizację pozwalającą na powtarzalne dostarczanie produktów, czyli dochodzimy do fazy Company Building.
Faza Customer Development, a jakość rozwiązania IT
Jak to się jednak ma do wytworzeniu kodu produktu?
W pierwszych dwóch fazach istnieje mniejsze prawdopodobieństwo, że projekt się uda, niż że okaże się pomyłką całkowitą lub wymagać będzie weryfikacji i zmian. Nie udać może się właściwie wszystko, począwszy od nietrafionego konceptu biznesowego czy technologicznego, poprzez źle dobrany skład zespołu, aż po utrudnienia finansowe. Doświadczył tego każdy, kto uczestniczył w projekcie innowacyjnym czy budował start-up. To normalne.
Tak więc w tej fazie często nie liczy się jakość, ale jak najtańsze wykonanie MVP. Może to powodować, że kod będzie „nieutrzymywalny”, tylko jedna osoba będzie się na nim naprawdę znała, będzie niestabilny i niewydajny, nie będzie miał wszytych testów…. Jednym słowem będzie pełen długu technologicznego, autor będzie wstydził się, że coś takiego zrobił, a w SonarQube wszystko będzie się „świecić” na czerwono niemal krzycząc, że software się do niczego nie nadaje.
Mimo wszystko szybko i tanio dostarczone MVP na podstawie którego zweryfikowaliśmy rozwiązanie jest często najrozsądniejszym wyjściem – z kilkoma zastrzeżeniami. Sprowadzają się one do zrozumienia i współpracy między techniczną, a biznesową częścią zespołu lub po prostu do gotowości zespołu do wykonania danego zadania.
Wielu doświadczonych developerów unika takiego podejścia, gdyż ma złe doświadczenia z przeszłości – „zrobiliśmy na prośbę biznesu projekt quick-and-dirty, a potem kazali nam to utrzymywać”. Sam widziałem takie sytuacje, gdy uznano, że projekt działa funkcjonalnie więc można śmiało go zaimplementować, a potem w fazie rozwoju pojawiały się frustracja i wzajemne pretensje. Lecz przy wspólnym zrozumieniu celów jesteśmy w stanie zrobić prototyp. Oczywiście mając świadomość, że wejście w fazę skalowania oznacza de facto stworzenie systemu od nowa, bez dodania nowej dla użytkownika funkcjonalności. I jest to często najlepsze rozwiązanie.
Jeżeli wierzymy, że system się sprawdzi – możemy zaryzykować stworzenie „od razu” wysokiej jakości produktu, gdyż hipotetycznie suma kosztów zrobienia dobrego systemu jest niższa niż stopniowych udoskonaleń. Tyle, że w IT produkowanie na zapas często się nie sprawdza, bo świat VUCA jest pełen zmian i na ogół w praktyce lepiej zwiększać funkcjonalność przyrostowo, minimalizując koszt nietrafionych pomysłów.
Dodatkowym problemem projektu z długiem technologicznym jest fakt, że dobrzy programiści nie chcą produkować kodu niskiej jakości, bo jest to dla nich praca uwsteczniająca, a nie rozwijająca. Jednak gdy zespół współpracuje i ma świadomość, że to koszt rozwoju potencjalnie perspektywicznej aplikacji i wszyscy czują korzyść, są na ogół gotowi na takie podejście.
Jakość w momencie skalowania biznesu
W fazie tworzenia i testowania idei biznesowej cały czas należy zwracać uwagę na minimalizację wydatków i raczej na bieżący cashflow niż docelowy zysk. To, co w Excelu wygląda na ogół zachęcająco, w rzeczywistości może się nigdy nie wydarzyć, a środki finansowe zostaną realnie wydane.
Gdy już wychodzimy z pomysłem na rynek składamy klientowi obietnicę marki. Deklarujemy, że dostarczymy jakość i wartość. Wtedy nie możemy sobie pozwolić na niską jakość, gdyż klient się zniechęci. Złamana obietnica marki to coś, czego klienci nie wybaczają.
Dlatego od tego momentu konieczne jest drastyczna zmiana podejścia do jakości aplikacji i następuje gwałtowny wzrost kosztu jej wytworzenia i utrzymania.
Refleksja jest nieunikniona. Musimy zdać sobie sprawę, że dostarczenie i utrzymanie danego modułu systemu jest dla nas coraz bardziej kosztowne. Co gorsza, przychody i inne koszty rosną coraz szybciej, a zatem więcej kosztuje nas niedziałający system, utrata przychodów i klientów, niż wyższa (i droższa) jakość.
Czy zawsze warto zaczynać od niższej jakości?
Podsumowując, od niższej jakości zaczynamy, gdy jest to projekt naprawdę innowacyjny i nie jesteśmy pewni jego sukcesu. Jednak gdy robimy np. automatyzację procesu jaki już istniał, czy wymianę starego niewydajnego systemu (legacy system) na nowy, to w takim wypadku od razu konieczne jest stosowanie wysokiej jakości, gdyż działamy od razu w etapie company builiding.
