środa, 11 czerwca 2014

Zadwolenie klientów 2

ZARZĄDZANIE CELAMI BIZNESOWYMI: SATYSFAKCJA KLIENTA I JAKOŚĆ ZINTEGROWANA

czyli wstęp do Market Driven Requirements Enineering, o którym napiszę więcej

Uwaga: tekst jest napisany celowo nudziarsko - szedł na konferencję akademicką ;-)

Tradycyjne podejście do zapewnienia jakości oraz do testowania oprogramowania, określa jakość jako zgodność z wymaganiami funkcjonalnymi, oraz nielicznymi niefunkcjonalnymi (wydajność, dość wąsko rozumiana użyteczność).

Z punktu widzenia jakości doświadczanej przez klienta-użytkownika jest to podejście niewystarczające: produkt informatyczny spełniający wymagania projektu, w trakcie którego powstał, często nie jest udanym produktem z punktu widzenia marketingowego, a wiele dobrych programów czy urządzeń zawierających oprogramowanie wbudowane, mimo swojej niezawodności, nie zadowoliło klientów, nie odniosło sukcesu rynkowego, ani nie przyczyniło się do usprawnienia procesów biznesowych, które miały wspierać.

Jak połączyć ze sobą te dwa obszary? – to temat niniejszego artykułu.

1. TRADYCYJNE PODEJŚCIE DO JAKOŚCI OPROGRAMOWANIA

1.1. JAKOŚĆ PRODUKTU

Tradycyjne podejście do jakości produktu znajdujemy - przykładowo - w norie ISO 9126 [1]. Norma ta określa model atrybutów jakości oprogramowaia, zarówno funkcjonalnych jak i niefunkcjonalnych; określa także pojęcie jakości wewnętrznej (z punktu widzenia producenta oprogramowania) i jakości zewnętrznej (z punktu widzenia klienta i użytkowników). Norma zaznacza także istnienie różnych interesariuszy jakości (ang. stakeholders), dla których te same obiektywne miary jakości oznaczają odmienną subiektywną jakość. Zagadnienia te są dobrze znane, opisane m.in. w książkach Andrzeja Kobylińskiego [2] lub Normana Fentona [3].

Należy jednak zaznaczyć, że zasady zarządzania jakością produktu, dostępne i opisane w normach, lub w książkach, nie przystają często do realiów przemysłu informatycznego, gdzie jakość oprogramowania – wbrew zaleceniom teorii - traktuje się niestarannie.

Dużym problemem w praktyce jest po prostu zaniedbywanie wymagań; prawie każdy z etapów procesu inżynierii wymagań (pozyskiwanie, analiza, modelowanie, specyfikacja, walidacja, zarządzanie zmianami) [4][3] jest w wielu projektach albo pomijany, albo realizowany nieprawidłowo [5].

Rzadko spotyka się w projektach informatycznych prawidłowo realizowany proces zwany śledzeniem związków wymagań (ang. requirements traceability), pozwalający poprawnie identyfikować relacje wymagań z innymi powstającymi w projekcie artefaktami, takimi jak komponenty architektury oprogramowania, moduły kodu źródłowego, czy przypadki testowe. W związku z tym, ocena, na ile zakończony projekt rzeczywiście spełnia zawarte w wymaganiach założenia, jest w wielu projektach fragmentaryczna, a często robiona po prostu na wyczucie.

Choć istnieje szereg komercyjnych narzędzi wspierających śledzenie związków wymagań [6], to bardzo rzadko udaje się je wykorzystywać łącznie z narzędziami służącymi do zarządzania projektem (jednym z nielicznych wyjątków jest aplikacja Concerto [7]), co powoduje, że wiedza na temat poziomu realizacji wymagań nie jest w pełni wykorzystywana w zarządzaniu projektami.

Innym, spotykanym w praktyce problemem jest niedostateczne uwzględnienie istnienia różnych interesariuszy (udziałowców) wymagań. Na przykład, znanym zjawiskiem w wielu projektach jest eksplozja propozycji zmian interfejsu użytkownika pod sam koniec projektu, w trakcie testów akceptacyjnych, co spowodowane jest ignorowaniem użytkowników końcowych podczas pozyskiwania wymagań, gdzie dominują z jednej strony przedstawiciele biznesu, z drugiej – analitycy systemów.

Dalej, często zaniedbywane są inne wymagania niż funkcjonalne; wyjątkiem są wymagania dotyczące wydajności i osiągów, zwykle starannie określane i testowane, zwłaszcza dla aplikacji webowych. Przykładem szczególnie dotkliwych zaniedbań, przybierających wręcz tragikomiczne proporcje, jest określenie wymagań użyteczności [8].Zamiast mylącej, choć w inżynierii oprogramowania powszechnie używanej, nazwy użyteczność, niektórzy autorzy [8] posługują się szerszym pojęciem interakcja.

Mimo istnienia szeregu dobrze opisanych zasad zarówno projektowania, jak i testowania użyteczności [10][11][12], interakcja wielu systemów z użytkownikami jest niedostateczna.

Zapomina się często, lub świadomie ignoruje taki kluczowy atrybut jakości, jak łatwość utrzymania [16], przez co wiele niepoprawnych z punktu widzenia łatwości utrzymania, a często stosowanych rozwiązań architektonicznych i programistycznych, praktycznie uniemożliwia elastyczne i szybkie dostosowywanie oprogramowania do zmieniających się potrzeb biznesowych.

Adam Kolawa, założyciel firmy Parasoft, porównuje w swojej książce [9] takie rozwiązanie żartobliwie do przyspawania koła do osi samochodu, zamiast przymocowania go śrubami. Niedostateczna łatwość utrzymania, pod pewnymi względami tożsama z brakiem jakości wewnętrznej, jest jednak zarazem istotnym niedostatkiem jakości zewnętrznej, ponieważ pociąga za sobą i duże koszty zmian, i niemożność ich realizacji dostatecznie szybko dla potrzeb biznesu, co oczywiście odbija się negatywnie na doświadczeniu klientów.

Niedocenianie znaczenia niektórych atrybutów jakości wiąże się pośrednio z
niedostatecznym zaangażowaniem wielu procesów biznesowych w proces informatyczny, o czym mówimy w rozdziale [1.3].

Szczególne z punktu widzenia jakości oprogramowania są rozmaite techniki zwinne (ang. agile) [13][14], czy programowanie ekstremalne [15]. Nie negując ich praktycznej skuteczności, w każdym razie w małych i średnich przedsięwzięciach informatycznych, nie sposób określić ich metodyki inaczej, niż jako osiąganie jakości metodą prób i błędów, co choć bywa skutecznie, nie zawsze jest sprawne, i nie w pełni pozwala na trafne przewidywanie czasu trwania projektów. Metodyki zwinne, choć z jednej strony mocniej niż tradycyjne angażują przedstawicieli użytkowników w procesie wytwarzania oprogramowania, z drugiej strony, jednak - pomijając systematyczny proces inżynierii wymagań - utrudniają uwzględnienie wszystkich interesariuszy oraz kompleksowe spojrzenie na różna aspekty jakości:



1.2. JAKOŚĆ PROJEKTU I PROCESU INFORMATYCZNEGO

Dążenie do osiągnięcia większej sprawności, skuteczności i przewidywalności projektów informatycznych pojawiło się już dawno. Powstały normy i metody pomiaru nie tylko jakości produktu, ale także projektu, tworzącego produkt. W szczególności, metody oszacowania i pomiaru przebiegu projektu zaczęły służyć trafniejszej estymacji pracochłonności projektów, już to na podstawie atrybutów projektu (np. metoda COCOMO [17]), już to na podstawie atrybutów wymagań (np. analiza punktów funkcyjnych [18]).

Kolejnym krokiem było określenie zasad, pozwalających ocenić zdolność danej organizacji do realizacji projektów, na podstawie w łaściwości procesu (organizacji, procedur, wzorców, przy pomocy których realizuje się projekty informatyczne). Istnieje wiele standardów, służących do oceny tzw. dojrzałości procesów: CMM, SPICE (ISO/IEC 15504), SixSigma, TQM, rodzina standardów ISO 9001, i wiele innych. Nie podajemy dla nich wszystkich odsyłaczy do literatury, gdyż bibliografa stałaby się zbyt obszerna, wykraczająca poza ścisłą tematykę tego artykułu.

Metody te, określające wymagania wobec procesów oraz testujące (metodą audytu), na ile dany proces te wymagania spełnia, mają swoich zwolenników i przeciwników. Argumentem, często podnoszonym przez przeciwników tych metod, jest brak empirycznie potwierdzonego powiązania przyczynowo-skutkowego (a nawet tylko słabe dane o istnieniu korelacji) między wysokimi wynikami jakości procesów, a jakością zarówno projektów, jak i produktów [2][3]. Istnieje wiele anegdot ilustrujących, że dobry proces nie zawsze przekłada się na skuteczny i sprawny projekt, ani na dobry produkt [19]:


Metodyką udoskonalania procesów, dość unikalną, jest ADP [19], choć nie można zaprzeczyć, że pewne elementy takiego podejścia zawiera w sobie zarówno SixSigma [20], jak i szeroko rozumiana metoda TQM [21]. Podstawowe dwa elementy ADP to jej (1) skalowalność; (2) stosowanie osiąganej jakości produktu oraz sprawności projektów jako głównej miary jakości procesów, w miejsce używanej przez inne metodyki miary zgodności istniejących procedur z przyjętymi wzorcami.

Metoda ADP jest próbą przeniesienia na grunt inżynierii oprogramowania klasycznych metod ulepszania procedur, stosowanych m.in. w przemyśle motoryzacyjnym, w celu stworzenia swoistej, przewidywalnej taśmy produkcyjnej wytwarzania oprogramowania.



ADP odwołuje się do klasycznych prac Deminga [22] i Jurana [23].

1.3. JAKOŚĆ INNYCH PROCESÓW OPRÓCZ INFORMATYCZNEGO

Nie trzeba być specjalistą od zagadnień jakościowych, aby spostrzec, że o sukcesie rynkowym produktu lub usługi informatycznej decyduje nie tylko – wąsko rozumiana – jakość samego produktu, ani nawet procesu, który produkt stwarza, lecz także (a może przede wszystkim) szereg innych procesów: sprzedaż, marketing, współpraca z kooperantami, zarządzanie wiedzą i zasobami ludzkimi, obsługa klienta, nawet CSR firmy (ang. Corporate Social Responsility - odpowiedzialność społeczna przedsiębiorstw).

Znajduje to swoje odbicie w tym, że np. standardy CMMI oraz SPICE uwzględniają nie tylko jakość (dojrzałość) procesu informatycznego, ale także innych procesów firmy. Jest to istotny krok w kierunku bardziej kompleksowego traktowania zagadnień jakości, choć w praktyce przemysłowej nie stosuje się na razie takiego podejścia, aby uzyskać kompleksowy pomiar jakości wszystkich procedur, otaczających konkretny produkt.

2. POJĘCIE JAKOŚCI W MARKETINGU

W biznesowych realiach, często występuje przepaść między działami marketingu a informatyki, dosadnie opisywana przez liczne anegdoty, których powszechnie znanym przedstawicielem są komiksy z serii „Dilbert”, i wiele innych:


To bardzo niekorzystny stan rzeczy i firmy, które jako pierwsze skutecznie potrafią zbliżyć
do siebie działania obu tych działów, uzyskają istotną przewagę nad konkurencją [9].

Pojęcia stosowane przez marketing do oceny jakości produktów i usług, podobne są w gruncie rzeczy do pojęć stosowanych przez inżynierię oprogramowania (choć inaczej brzmią ich nazwy) [24], natomiast uzupełnione są o kilka nie występujących w inżynierii oprogramowania wymiarów:
• Pojęcie marki, zbioru jakości wielu, często różnorodnych produktów i usług, mającej odrębne miary jakości, nie zawsze identyczne z jakością należących do marki produktów.

• Uwzględnienie zmienności poczucia jakości produktu w czasie i w przestrzeni, zarówno geograficznej, jak i społecznej [25].

• Szczególny nacisk na psychologiczne i społeczne aspekty poczucia jakości przez klientów lub użytkowników, szczegółowo – choć nie w kontekście marketingowym – omówionych w [26]. Marketing w dużym stopniu nastawiony jest na wytwarzanie poczucia jakości poprzez zmiany innych czynników niż techniczna, wewnętrzna jakość samego produktu, co często jest przyczyną oporu inżynierów wobec działań marketingowych, odbieranych jako oszukańcze, czego znakomitym przykładem są ponownie niezawodne komiksy „Dilbert":


• Systematyczne uwzględnienie aspektów kulturowych wpływających na poczucie jakości u klientów [24].

• Wiele działań marketingu nastawionych jest nie tylko na zaspokojenie istniejących, uświadomionych i wyartykułowanych potrzeb klientów, co jest głównym celem zarządzania jakością w inżynierii oprogramowania, lecz także na odkrycie nieuświadomionych potrzeb, lub wręcz stworzenie nowych potrzeb [25].

• Działania mające na celu zapewnienie jakości z punktu widzenia marketingu o wiele rzadziej niż w inżynierii oprogramowania polegają na systematycznym testowaniu, na ile prototyp produktu czy usługa, czy otaczające je procesy, spełniają określone i założone wymagania. Częstszym podejściem jest monitorowanie poziomu zadowolenia klientów z aktualnej wersji, w celu wykorzystania informacji do projektowania kolejnej wersji. Pod tym względem, testowanie produktów informatycznych uprawiane współcześnie w ramach marketingu podobne jest do testowania
użyteczności (interakcji), będącego częściej sposobem na pozyskanie (określenie) wymagań, a nie sprawdzeniem, na ile produkt spełnia wymagania określone zawczasu. Takie podejście realizują również w pewnym stopniu metodyki zwinne.

2.1. ZARZĄDZANIE DOŚWIADCZENIEM KLIENTA

Nowoczesnym podejściem do zagadnień marketingu jest tzw. zarządzanie doświadczeniem klienta (ang. customer experience management, CEM [28]). Podejście to zakłada, że poczucie jakości produktu lub usługi u klienta zależy tylko w części od właściwości tego produktu, a w przeważającej mierze od innych czynników, związanych z procesami reklamy, sprzedaży, instalacji, obsługi posprzedażowej, produkcji, nawet sposobu fakturowania i windykacji, a także od czynników nie dotyczących samego produktu, lecz firmy lub marki, do której produkt należy. Mechanizmy działania takich czynników opisuje w sposób popularny [29].

Choć opisywane w książkach i znane, takie podejście dopiero toruje sobie drogę do rzeczywistości marketingowej w firmach IT.

3. ZINTEGROWANY MODEL JAKOŚCI

W kontekście szerokiego rozumienia jakości przez marketing, zwłaszcza realizowany w postaci zarządzania doświadczeniem klientów, tradycyjny zakres wymagań i testowania oprogramowania wydają się bardzo niedostateczne: kontrolowanie szczegółów technicznych zamiast całokształtu.

Jednak faktem jest, że niespełnienie wymagań jakości w zakresie tych - pozornie drugorzędnych - szczegółów technicznych, bywa czynnikiem decydującym o poczuciu jakości, którego żadne, najdoskonalsze działania marketingowe, sprzedażowe czy inne nie są w stanie zmienić [30], [31].

Marketing / zarządzanie doświadczeniem klienta są – w porównaniu z dyscypliną inżynierii oprogramowania – bardzo nieprecyzyjne, polegające głównie na metodzie prób i błędów, a nie na systematycznym definiowaniu założeń/wymagań ani na systematycznym sprawdzaniu (testowaniu), na ile modele i prototypy spełniają te założenia. Choć istnieje wiele sposobów marketingowego testowania [24] (uwaga: nikt w marketingu nie używa oczywiście terminu „testowanie”), to brak im technik systematycznych, a zwłaszcza formalnych, jakie stosuje się w tradycyjnym testowaniu oprogramowania [32].

Najwyraźniej, wielki potencjał kryje się w połączeniu silnych stron obu branży: technik modelowania i systematycznego testowania inżynierii oprogramowania z kompleksowym, integralnym podejściem marketingu/zarządzania doświadczeniem klientów.

3.1. POSZERZONY MODEL INŻYNIERII WYMAGAŃ

Inżynieria wymagań [4] nie wykorzystuje ani do pozyskiwania, ani do walidacji wymagań, wielu spośród technik i sposobów znanych marketingowi [24]. Dział marketingu bywa najczęściej tylko jednym z wielu interesariuszy wymagań. O wiele więcej na ten temat tego, jak identyfikować interesariuszy i pozyskiwać wymagania, można dowiedzieć się na kursach sprzedaży, niż na szkoleniach dotyczących inżynierii wymagań.


Poszerzenie zakresu inżynierii wymagań o obszary, należące do zarządzania doświadczeniem klienta, pozwoli osiągnąć znacznie lepsze zaspokojenie potrzeb biznesu i potrzeb użytkowników systemów informatycznych.

3.2. POSZERZONY MODEL TESTOWANIA OPROGRAMOWANIA

Testowanie oprogramowania, obecnie dziedzina ograniczona do sprawdzania zgodności oprogramowania z (nietestowanymi) wymaganiami, poszerzone dowymiarów testowania produktów i procedur (procesów) w świetle zarządzania doświadczeniem klienta, czyli zgodnie z poszerzonymi wymaganiami [3.1], może stać się najważniejszym obszarem działania firm, scalającym działania w dotychczasowej praktyce rozdzielone.

3.3. MODEL JAKOŚCI ZINTEGROWANEJ

Poniżej zarysowujemy model jakości zintegrowanej, służący – po wypełnieniu go treścią specyficzną dla danego produktu – jako lista kontrolna do działań realizowanych w projekcie informatycznym, oraz innych działań cyklu życia

Docelowo, taki model powinien mieć strukturę hierarchiczną: różne wersje i pod-wersje modelu dla różnego rodzaju produktów.

Model jest w podstawowej części trójwymiarowy:
  • Atrybuty jakości;
  • Procesy, w których funkcjonuje dany produkt (bezpośrednio i pośrednio);
  • Interesariusze (w każdym z procesów).
Dla każdego obszaru modelu (atrybut/proces/interesariusz) model definiuje metody pozyskiwania stosowanych wymagań, oraz techniki testowania (techniki testowania obejmują zarówno techniki projektowania przypadków testowych, jak i metody ich wykonywania).

Dla każdego z trzech wymiarów modelu, liczba różnych wartości tego wymiaru jest inna dla różnych produktów.

Poniższy przykład ilustruje zastosowanie modelu dla produktu typu „usługa telekomunikacyjna”.

3.3.1. Instalacja usługi dla abonenta
Instalacja usługi dla danej centrali telefonicznej z punktu widzenia: instalatora, kierownika usługi, kierownika obszaru, użytkowników centrali, biura obsługi klienta.

Atrybuty jakości dla każdego interesariusza: łatwość nauczenia się, łatwość wykonywania, konieczność dostępu, stabilność, jakość dokumentacji, czasochłonność, możliwość kontroli wykonania.

3.3.2. Instalacja usługi razem z podłączeniem urządzenia dostępowego
Interesariusze i atrybuty jak wyżej.

3.3.3. Przeniesienie usługi pod inny adres
Interesariusze i atrybuty usługi jak wyżej.

3.3.4. Modyfikacja konfiguracji usługi
Interesariusze i atrybuty jak wyżej.

3.3.5.Wstawienie faktury abonentowi za wykorzystanie usługi w okresie rozliczeniowym.
Ten składnik usługi telekomunikacyjnej jest opisany – poniżej – w pełnym zakresie, uwzględniającym wszystkie aspekty zintegrowanej jakości usługi telekomunikacyjnej.
• Poprawne rozliczenie z systemu bilingowego (zgodna liczba zarejestrowanych i fakturowanych sygnałów, uwzględniająca różne objęte abonamentem taryfy, numery bezpłatne itp.)
• Poprawne rozliczenie z systemu bilingowego dotyczy poprawnego okresu
• Poprawne rozliczenie dotyczy ostatniego okresu
• Poprawne rozliczenie pozwala na łatwą identyfikację rozliczenia, rozpatrywanie niezgodności zgłoszonych przez abonenta oraz jest wygodną podstawą umożliwiającą debugowanie systemu bilingowego, oraz systemu wystawiania faktur.
• Poprawne rozliczenie przetestowane jest pod względem funkcjonalnym dla nietypowych i niepoprawnych klas równoważności (okres niepełny na końcu okresu, okres niepełny na początku okresu, okres pusty, itp.)
• Faktura jest poprawna pod względem prawnym
• Faktura zawiera poprawne dane klienta
• Faktura zawiera numer telefonu klienta
• Faktura jest łatwa do odczytania i zrozumienia: informacje najważniejsze, czyli numer telefonu abonenta, data płatności, suma brutto płatności oraz numer konta, na który należy dokonać płatności, są wyraźnie widoczne.
• Faktura jest wygodnie rozplanowana na papierze wydruku.
• Sumy dodatkowe, np. za instalację, naprawę lub przeniesienie są poprawnie i wyraźnie zidentyfikowane.
• System obsługi faktur (telefoniczny) umożliwia identyfikację faktury zarówno na podstawie numeru telefonu, imienia i nazwiska abonenta, numeru klienta, adresu klienta itp.
• Faktura wysyłana jest na poprawny adres.
• Faktura wysyłana jest na tyle wcześnie, żeby do końca terminu płatności pozostało co najmniej dwa tygodnie.

Proste? Tylko nie znamy na razie operatora, którego faktury spełniają te oczywiste wymagania.

4. LITERATURA DO ARTYKUŁU
[1] ISO 9126: http://en.wikipedia.org/wiki/ISO_9126
[2] Andrzej Kobyliński: Modele jakości produktów i procesów programowych, Oficyna Wydawnicza SGH, Warszawa 2005
[3] Norman Fenton, S. Pfleger: Software Metrics, A Rigorous and Practical Approach, International Thomson Computer Press, 1996
[4] Karl E. Wiegers, Software Requirements, Microsoft Press, 2003
[5] IREB - International Requirements Engineering Board, http://ireb.org (2014)
[6]Lista narzędzi do śledzenia związków wymagań:http://www.paper-review.com/tools/rms/read.php(maj 2011)
[7] Narzędzie Parasoft Concerto: http://www.parasoft.com/jsp/products/concerto/home.jsp (maj 20012)
[8] Alan Cooper: Wariaci rządzą domem wariatów, Wydawnictwo Naukowo-Techniczne 2001
[9] Adam Kolawa: The Next Leap in Productivity, Wiley 2008
[10] Jakob Nielsen: Usability Engineering, Morgan Kaufman 1994
[11] SUMI (Software Usability Measurement Inventory), http://sumi.ucc.ie/
(maj 2013)
[12] WAMMI (Website Analysis and Measurement Inventory), http://www.wammi.com/ (czerwiec 2014)
[13] http://www.agilemanifesto.org/
[14] Robert C. Martin: Agile Software Development, Principles, Patterns, and Practices, Cambridge Press, 1999 (!)
[15] Kent Beck: Extreme Programming Explained - Embrace Change, Addison-Wesley Professional, 2000
[16] Thomas M. Pigoski: Practical Software Maintenance: Best Practices for Managing Your Software Investment
[17] Barry W. Boehm i współautorzy: Software Cost Estimation With COCOMO II, Prentice Hall PTR, 2000
[18] David Garmus, David Herron: Function Point Analysis, Addison-Wesley, 2001
[19] Adam Kolawa, Dorota Huizinga: Automated Defect Prevention – Best Practices in Software Management, Wiley, 2007
[20] Six Sigma: http://en.wikipedia.org/wiki/Six_Sigma
[21] R. Ashley Rawlings: Total Quality Management (TQM) , Author House, 2008
[22] W.E. Deming: The New Economics: For Industry, Government, Education, M.I.T. 1993
[23] Joseph M. Juran: Juran’s Quality Handbook, McGraw-Hill, 2000
[24] Philip Kotler, Gary Armstrong, Veronica Wong, John Saunders: Principles of Marketing
[25] Philip Kotler: Jak kreować i opanowywać rynki
[26] Radosław Hofman: Postrzeganie jakości oprogramowania (referat na KKIO 2009)

Brak komentarzy:

Prześlij komentarz