Sprawna komunikacja między klientem a firmą wdrożeniową w przypadku projektów informatycznych jest jednym z ważniejszych czynników decydujących o sukcesie projektu.

Wdrożenia systemów informatycznych są zazwyczaj przedsięwzięciami bardzo skomplikowanymi i długotrwałymi. Jeśli zawczasu nie określimy dokładnych protokołów wymiany informacji między zleceniodawcą a zleceniobiorcą – bardzo szybko dojdzie do rozminięcia się oczekiwań i stworzenia systemu który nie będzie spełniał wymagań.

Jako klient firmy wdrożeniowej trzeba zdać sobie w tym momencie sprawę, że żaden dedykowany czy też mocno dopasowywany system nie powstanie, bez aktywnej i zaangażowanej postawy klienta. Stopień zaangażowania będzie inny w  zależności od wybranej metodyki prac (największe zaangażowanie klienta w przypadku metodyk zwinnych – np. SCRUM, mniejsze przy podejściu kaskadowym – jak w skrajnym przypadku RUP). Stopień zaangażowania będzie też inny w zależności od etapu na którym znajduje się projekt.

Myślimy o komunikacji już na etapie umowy

To umowa określa podwaliny pod naszą współpracę w ramach wdrożenia. Często, że dużo precyzyjnych ustaleń jest podejmowanych po jej podpisaniu. Sposoby komunikacji stanowczo powinny być jednak zawarte w kontrakcie.

Najważniejsze elementy które powinny znaleźć się w umowie (w kontekście protokołu komunikacyjnego) to z mojego doświadczenia:

  • wyznaczenie osób kontaktowych po obu stronach – jeśli nie są wyznaczone a w komunikacje zostaje zaangażowanych kilka osób po każdej ze stron prędzej czy później dochodzi do paraliżu. Nie wiadomo z kim co ustalać, kto może podjąć decyzje. Po stronie zarówno klienta jak i firmy wdrożeniowej musi być wybrana jedna osoba koordynująca działania. Pomiędzy tymi osobami będą wymieniane najważniejsze ustalenia, te osoby będą też delegowały konkretnych specjalistów do zadań. W umowie powinny znaleźć się dane kontaktowe (telefon, mail) do tych osób.
  • wymagajmy systemu gromadzenia wiedzy o projekcie – przechowywanie wszystkich informacji w mailach jest tragiczne w skutkach jeśli do projektu dochodzi nowa osoba, ponieważ traci dostęp do całej obecnej wymiany wiedzy. Jeśli chcemy rozliczyć wykorzystane godziny lub sprawdzić postęp prac –również przy użyciu maili może okazać się to niemożliwe. Najlepszym rozwiązaniem jest skorzystanie z systemu ticketowego i pomiaru czasu pracy. Wybór narzędzi jest ogromny – Redmine, ActiveCollab, Basecamp … Zazwyczaj narzędzia oprócz minimum funkcji takiego jak zgłaszanie zagadnień (ticketów) i błędów, śledzenia poświęconego czasu oraz postępu prac umożliwiają gromadzenie wiedzy w postaci repozytorium plików oraz wiki. Project Managerowie po obu stronach powinni dbać o to aby cała wiedza o projekcie – w tym aktualne harmonogramy i specyfikacje zawsze były dostępne w takim narzędziu. Korzystanie z systemu nie obciąża czasowo nikogo z zespołu – przeciwnie, oszczędza czas potrzebny na samodzielne organizowanie informacji czy to po stronie programistów czy też osób na stanowiskach kierowniczych,
  • wyznaczmy harmonogram dostarczania materiałów i akceptacji – umowa musi jasno precyzować w jakich terminach klient i wykonawca umowy dostarczą jakie materiały. Musimy też jasno określić jaki terminy obowiązują na odpowiedzi na zadawane pytania (np. brak materiałów wymaganych do przejścia dalej) oraz na akceptacje prac. Dzięki temu unikniemy stresujących przestojów. Z umowy powinno też jasno wynikać w jaki sposób opóźnienia w dostarczaniu materiałów skutkują w opóźnieniu realizacji prac. Często firmy wdrożeniowe zakładają, że jeden dzień opóźnienia klienta skutkuje większą ilością dni opóźnienia prac po ich stronie, ponieważ zaburzenie harmonogramu wymaga przeplanowania prac i realokacji zasobów.

Etap analityczny i projektowy

Jest jasnym, że przed zaczęciem jakichkolwiek prac wdrożeniowych w projektach IT powinien nastąpić etap analityczny w czasie którego nie tylko zostaną doprecyzowane wymagania – ale także powstanie pełen projekt aplikacji wg. którego będzie mogło nastąpić wdrożenie.

W niektórych projektach – zwłaszcza małego i średniego rozmiaru (2-3mc) pojawia się pokusa rezygnacji z etapu analitycznego i chęć przejścia „do konkretu” jakim są prace programistyczne i wdrożeniowe. Moim zdaniem to podstawowy błąd w komunikacji z firmą wdrożeniową który może rzutować na całokształt systemu. Wyobrażenia o działaniu systemów informatycznych są bardzo różne po obu stronach kontraktu. Znalezienie wspólnej wizji i zaakceptowanie zakresu funkcjonalnego daje nam dopiero podstawę do wykonania prac, potem odbioru projektu i stwierdzenia, że odnieśliśmy sukces lub też nie.

Na samym początku firma wdrożeniowa powinna poznać jaki jest cel projektu – i  co będzie oceniane jako sukces (kluczowe czynniki mierzenia sukcesu).

Podczas etapu analitycznego powinniśmy wymagać od siebie wzajemnie (firma wdrożeniowa – klient) minimum kilku spotkań lub chociaż telekonferencji.  Podczas takich rozmów powinniśmy udostępnić firmie wdrożeniowej cały zespół który będzie z naszej strony nie tylko odpowiadał za wdrożenie ale potem też używał systemu. Standardem jest przeprowadzenie wywiadów, zebranie różnych spojrzeń na funkcje które były podstawowym przedmiotem wymagań.

Firma która wykonuje etap analityczny następnie powinna dokonać analizy konkurencji, sprawdzić jak wyglądają podobne systemy oraz przedstawić projekt – interfejsu użytkownika, opis (chociażby skrócony) procesów biznesowych i działania funkcji. Na samym końcu powinna zostać dokonana analiza techniczna oraz analiza integracji – jeśli system ma współdziałać z innymi po stronie klienta lub firm trzecich. Szczegółowy opis co powinno zostać zrealizowane w etapie analitycznym znajdziesz w rozdziale „Co minimalnie powinien zawierać projekt funkcjonalny?“ oraz „Jak skutecznie zebrać wymagania biznesowe? „

Ponieważ na tym etapie kształtuje się to jak docelowo system będzie wyglądał i działał – klient powinien bardzo ściśle współpracować z firmą wdrożeniową i nanosić uwagi do każdego elementu jeśli tylko ten nie spełnia jego wymagań. Nanoszenie zmian w projekcie jest nieporównywalnie tańsze niż na wykonanym już wdrożeniu.

Jak już wspominałem na tym etapie najsprawniejszą komunikację uzyskamy poprzez bezpośrednie rozmowy i warsztaty – ponieważ w ten sposób najszybciej podzielimy się wątpliwościami i zgłosimy nawet luźne uwagi, które mogą nie być bez wpływu na kształt projektu.

Testy i odbiór

Jak już wspominałem  – w czasie trwania etapów często komunikacja może zostać nieco ograniczona. Wystarczą statusowe maile lub telefony raz na tydzień. Jeśli dobrze określiliśmy wymagania na tym etapie firma wdrożeniowa potrzebuje często tylko czasu aby je zrealizować.

W momencie oddawania produktów po końcu etapu czy iteracji klient powinien znowu zaangażować się w dużym stopniu – angażując odpowiednio dużo zasobów i czasu aby dobrze zweryfikować oddawany produkt.

Harmonogram realizacji powinien zawierać odpowiednio dużo budżetu i czasu na wprowadzanie poprawek. Fikcją jest to, że w czasie testów zgłaszane będą tylko błędy. Zawsze okazuje się, że nie wszystkie wymagania zostały wystarczająco dobrze doprecyzowane – lub mimo, że bardzo uszczegółowione – były po prostu zaprojektowane błędnie. Często zdarza się, że niektórych interakcji nie da się zaprojektować i sprawdzić tylko na etapie analitycznym.

Uważam, że w tym etapie całość komunikacji powinna odbywać się poprzez system ticketowy. Zarówno project-managerowie jak i programiści nie znoszą chaosu. Z drugiej strony – testowanie oprogramowania często niesie ze sobą pokusę częstych i chaotycznych zgłoszeń błędów – typu „przesuńmy przycisk o 10 pikseli w prawo”, „ w tym miejscu nie może pojawiać się popup”. Takie zgłoszenia są zazwyczaj trafne i cenne ale przez swą formę mogą się zagubić lub nie być odpowiednio zrozumiane. Trzeba mieć na uwadze, że każdy błąd którego nie poprawimy prędzej czy później zaatakuje naszych użytkowników i przyczyni się do obniżenia oceny systemu w ich oczach.

Każde zgłoszenie powinno być zaewidencjonowane w systemie kontroli zgłoszeń. Dobra praktyka nakazuje aby zgłoszenia błędów zawierały opis gdzie błąd występuje (np. adres URL), zrzut ekranu oraz opis kroków które doprowadziły do jego powstania. Chociaż na pierwszy rzut oka wygląda to na sporo pracy do wykonania, okazuje się, że w rutynie testów gromadzenie takich informacji zaczyna odbywać się automatycznie  i nie spowalnia testowania. Za to bardzo przyspiesza diagnozowanie i poprawienie usterek.

Zazwyczaj błędy są zgłaszane najpierw do project managera po stronie klienta (przypisanie do niego na systemie zgłoszeń) który dokonuje analizy – czy błąd faktycznie występuje, czy nie jest to zmiana wymagań (jeśli tak powinna zostać np. dodatkowo wyceniona) i przypisuje zgłoszenie do programisty czy też np. grafika lub webmastera – którzy powinni zająć się wprowadzeniem odpowiednich zmian.

Po wprowadzeniu zmian zagadnienia nie powinny być od razu zamykane przez osobę która wykonała prace. Dobrym zwyczajem jest przypisanie zgłoszenia z powrotem do osoby zgłaszającej lub niezależnego testera (jeśli nim dysponujemy). Dopiero po wykonaniu retestu (ponowny test danej funkcji) dokonujemy zamknięcia zgłoszenia, mając pewność, że błąd na pewno został wyeliminowany.

Po zakończeniu etapu testów – podczas którego klient tak naprawdę dobrze poznaje swój nowy system powinniśmy podpisać protokół odbioru lub w innej firmie zakomunikować firmie wdrożeniowej, że więcej uwag już nie ma i można iść dalej z pracami.

Utrzymanie

Dalsze utrzymanie systemu (powdrożeniowe) i rozwój to etap gdzie roli komunikacji nie sposób przecenić.

Uważam, że na tym etapie – tak jak i podczas testów – cała komunikacja powinna odbywać się poprzez system kontroli zgłoszeń. W tym etapie klienci często płacą za zużyte godziny (rozliczanie time-material) lub korzystają z wykupionego w ramach ryczałtu pakietu godzinowego. Dla uniknięcia frustracji po obu stronach bardzo ważne jest rzetelne rozliczanie godzin oraz zyskiwanie akceptacji na prace.

Zazwyczaj tok prac wygląda podobnie jak podczas testów – z tą różnicą, że zgłoszenia rozwojowe (zapotrzebowanie na nowe funkcje) są przed przypisaniem do osoby odpowiedzialnej za realizację wyceniane godzinowo. Po wycenie zgłoszenie powinno być przypisane z powrotem do klienta w celu zaakceptowania przez niego szacunku godzinowego. Klient przypisuje zgłoszenie z powrotem do przedstawiciela firmy wdrożeniowej a ten planuje konkretny termin i oddaje zadanie do realizacji. Systemy kontroli zgłoszeń umożliwiają programistom wpisywanie czasu spędzonego nad zadaniem – dzięki czemu bardzo łatwo możemy rozliczyć ilość wykorzystanych godzin rozwojowych (na podstawie wygenerowanego raportu).

Powyżej opisane metody są bardzo proste – dzięki temu mają szansę sprawdzić się podczas codziennej pracy nad projektami. Jestem osobiście przeciwnikiem bardzo formalnych metod komunikacji i „papierologi” ponieważ uważam, że rzadko kiedy metody te wpływają na uzyskanie lepszej jakości wytworzonego produktu. Natomiast często obniżają zaangażowanie i motywację zespołu – nie możemy o tym zapominać.