Makiety i ich zbawienny wpływ na satysfakcję klienta

Makiety i ich zbawienny wpływ na satysfakcję klienta

Mimo coraz większej liczby zwolenników zwinnych metodyk wytwarzania oprogramowania (np. Scrum), w dalszym ciągu dużą popularnością cieszy się metodyka tradycyjna oparta na udokumentowanej specyfikacji wymagań i sztywnym budżecie. Względem projektów prowadzonych przy użyciu Scrum, główną wadą metodyki tradycyjnej jest większe prawdopodobieństwo na powstanie rozbieżności pomiędzy wyobrażeniami klienta o zamówionym oprogramowaniu, a końcowym rezultatem projektu, co jest sytuacją wysoce niepożądaną w tak istotnych zagadnieniach jak np. wdrożenia systemów CRM.

Na szczęście, w tego typu przypadkach przychodzą nam z pomocą makiety i prototypy. W zależności od stopnia skomplikowania projektu i preferencji klienta, możemy tutaj mówić o pełnej gamie opcji prezentowania odbiorcy zaplanowanej funkcjonalności zamówionego oprogramowania: od prostego szkicu interfejsu wykonanego przez analityka aż do proof of concept. Mimo skrajnie różnego stopnia skomplikowania i czasu potrzebnego na wytworzenie makiet danego rodzaju, ich wspólnym mianownikiem jest zbawienny wpływ na końcową satysfakcję klienta.

W przypadku makiet i prototypów oprogramowania tworzonych w ramach projektów realizowanych metodyką tradycyjną, sama nasuwa się analogia do projektowania budynków. Sytuację, w której oprogramowanie wytwarzane jest na podstawie specyfikacji wymagań można porównać do budowania biurowca na podstawie wytycznych inwestorów, którzy znikają w momencie rozpoczęcia budowy i pojawiają się w momencie oddania nieruchomości. Prawdopodobieństwo, że oddawany do użytku budynek spełnia ich oczekiwania jest skrajnie niskie niezależnie od jakości pracy wykonanej przez biuro projektowe i budowlańców. Zgodność biurowca z oczekiwaniami inwestorów byłaby niewątpliwie większa, gdyby mieli oni szansę odnieść się do projektu budynku, komputerowej wizualizacji lub fizycznego, wyskalowanego modelu.

Makiety są równie istotne w rozwoju oprogramowania. Im większy zakres niestandardowej funkcjonalności wprowadzanej w ramach projektu tym większa potrzeba na wytworzenie szkicu lub prototypu pozwalającego zleceniodawcy na skonfrontowanie efektów pracy analityków z jego wyobrażeniami i oczekiwaniami. Nawet z pozoru tak prosta rzecz jak prezentacja interfejsu użytkownika (mock-up) przygotowywanej platformy pozwala na zniwelowanie ewentualnego dystansu pomiędzy wizją klienta, a rezultatami analizy przedwdrożeniowej. Dla najbardziej wymagających klientów istnieje również opcja stworzenia proof of concept (POC), czyli działającego do pewnego poziomu prototypu oprogramowania pozwalającego odbiorcy na zweryfikowanie docelowej funkcjonalności praktycznie nie pozostawiając miejsca na jakiekolwiek niedopowiedzenia. Żeby jeszcze bardziej przybliżyć ideę makiet oprogramowania, przyjrzyjmy się tym dwóm skrajnym opcjom.

Mock-up to zasadniczo zbiór wizualizacji interfejsu użytkownika mający na celu zaprezentowanie kluczowej funkcjonalności na konkretnych przykładach bez wglądu w użytą technologię i zachodzące w ramach systemu procesu. Ten rodzaj makiety bywa nazywany pionowym, ponieważ daje odbiorcy możliwość spojrzenia na statyczny obraz systemu. Mock-upy są szczególnie pomocne przy precyzowaniu struktury nawigacyjnej systemu i relacji logicznych pomiędzy jego poszczególnymi elementami.

POC jest z kolei makietą zdecydowanie bardziej złożoną, dającą klientowi możliwość nie tylko, kolokwializując, przeklikania się przez prototypowy system, ale też zapoznania się z technologią i procesami jakie będą zachodzić w finalnym produkcie. POC można nazwać prototypem horyzontalnym (w przeciwieństwie do wertykalności mock-upu), ponieważ jego celem jest przedstawienie konceptu oprogramowania w najszerszym możliwym zakresie. Po zatwierdzeniu, POC stanowi dla zespołu deweloperskiego zasadniczy i szczegółowy punkt odniesienia co do tego, jak system ma funkcjonować. Ten typ makiety eliminuje niemal każdą możliwość niedopowiedzenia lub rozbieżności i pomimo idących za tym kosztów cieszy się dużym uznaniem i jest często stosowany w przypadku znaczących i skomplikowanych projektów.

Naturalnie, pomiędzy tymi dwiema opcjami istnieje wiele rozwiązań pośrednich, takich jak chociażby wprowadzanie drobnych modyfikacji w wersjach demonstracyjnych istniejących systemów. Wartym odnotowania wnioskiem jest fakt, że dobra makieta drastycznie ułatwia klientowi wyobrażenie sobie przygotowywanego systemu i pozwala zniwelować wątpliwości co do formy i funkcjonalności finalnego produktu. Dzięki temu projekty realizowane metodyką tradycyjna wcale nie musi w tym zakresie odbiegać od projektów scrumowych.



mautic is open source marketing automation

Ta strona korzysta z plików cookie. Więcej informacji

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close