20.07.2018
Autorzy:

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” 

Platon, Źródło: Wikipedia

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 Development, Źródło: Custdev.com

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.

Customer Development a Agile

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ść.

Zmiana udziału kosztów IT w całości kosztów projektu innowacyjnego oraz problemy jakie występują w poszczególnych fazach

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.

Nasi eksperci
/ Dzielą się wiedzą

Ilustracja przedstawiająca robota reprezentującego sztuczną inteligencję, otoczonego symbolami wyzwań i błędów w sztucznej inteligencji. Obraz zawiera pomarańczowy mózg, zepsutą żarówkę i cyfrowe piksele, symbolizujące dane i zagrożenia etyczne związane z awariami sztucznej inteligencji
30.10.2024

Wpadki AI / Gdy sztuczna inteligencja wymyka się spod kontroli

AI

Sztuczna inteligencja rewolucjonizuje wszystkie branże, oferując naprawdę imponujące możliwości w zakresie wydajności, szybkości i innowacyjności. Jednak w miarę jak systemy AI stają się coraz bardziej zintegrowane z procesami biznesowymi, staje się oczywiste, że narzędzia te nie są również pozbawione wad. Od małych błędów po poważne...

AI w optymalizacji łańcucha dostaw materiałów budowlanych
28.10.2024

Zastosowanie sztucznej inteligencji w optymalizacji łańcucha dostaw materiałów budowlanych 

E-Commerce

Czy sztuczna inteligencja może zrewolucjonizować zarządzanie łańcuchami dostaw materiałów budowlanych? Dowiedz się, jak AI może pomóc w optymalizacji prognozowania zapotrzebowania, zarządzaniu zamówieniami i stanami magazynowymi, a także zminimalizować ryzyko i spersonalizować ofertę dla klientów. Odkryj przyszłość AI w branży...

08.10.2024

Magento Open Source vs Adobe Commerce / Który system e-commerce wybrać?

E-Commerce

Wybór odpowiedniej platformy e-commerce to kluczowa decyzja, która może zaważyć na sukcesie Twojego biznesu w handlu online. Magento Open Source oraz Adobe Commerce to dwa popularne rozwiązania, oferujące różne możliwości dostosowane do potrzeb przedsiębiorstw. Podczas gdy Magento Open Source to elastyczna platforma z otwartym kodem...

Ekspercka wiedza
dla Twojego biznesu

Jak widać, przez lata zdobyliśmy ogromną wiedzę - i uwielbiamy się nią dzielić! Porozmawiajmy o tym, jak możemy Ci pomóc.

Napisz do nas

<dialogue.opened>