Odbiór projektu IT – Co musi zrobić klient, a co software house? 5 rzeczy, o które warto zadbać

Cześć, dzień dobry. Witam was w podcasie IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce. Podcast IT i Biznes kieruje do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 43. Odbiór projektu IT.

Co musi zrobić klient, a co Software House? Pięć rzeczy, o które szczególnie warto zadbać. Jakie decyzje trzeba podjąć na początku, by projekt zakończył się sukcesem? Jakie są twoje prawa, drogi kliencie, a co leży po stronie Software House’u? Odbiór projektu IT to moment, w którym finalnie sprawdzasz, czy wszystko działa zgodnie z ustaleniami. To nie tylko podpisanie dokumentu, ale także kluczowy etap, który może wpłynąć na przyszłe funkcjonowanie twojego systemu i może też wpłynąć na twój biznes.

No to co, nie przedłużając, serdecznie zapraszam do części głównej dzisiejszego odcinka. Cześć, dzień dobry. Dzisiaj odcinek ważny i istotny, bo będziemy rozmawiać o czymś, co dotyczy absolutnie każdego, kto ma do czynienia z projektami IT.

W poprzednich odcinkach rozmawialiśmy o tym, jak zorganizować projekt, jak wybrać odpowiedniego partnera technologicznego, jak dobrać dobrą technologię do danej specyfikacji, skali i momentu rozwoju biznesu. Mówiliśmy też o tym, jak projekt powinien przebiegać, jak wyłapywać red flagi na etapie realizacji. Ale wiecie co, ostatnio usłyszałem coś, co naprawdę mnie zszokowało.

Bo naprawdę myślałem, że tego typu sytuacje to już jest serio przeszłość, no ale jednak okazało się. Dowiedziałem się, że pewien partner technologiczny jednego z naszych potencjalnych klientów obarczył swojego klienta testami projektu. Ale co gorsza, wszystkie realizowane poprawki były wliczane również jako dodatkowy koszt dla projektu, bo wszystko było traktowane jako rzeczy dodatkowe.

No i tak, dobrze słyszeliście. Wszystko było traktowane jako rzeczy dodatkowe. Nawet to, że klient wchodzi do zakładki, zakładka nie działa.

No i trzeba od razu zgłosić błąd, a błąd okazuje się rzeczą dodatkową. Totalna abstrakcja. No i oczywiście, że klient powinien testować projekt, czy raczej odbierać projekt.

Natomiast to, w jakim stanie projekt powinien zostać dostarczony do odbioru, no to to jest właśnie sprawa pierwszorzędna. No i do tego dzisiaj właśnie chcę porozmawiać o tym, jak powinna wyglądać finalna część współpracy z partnerem technologicznym, albo finalna przynajmniej w obszarze jakiegoś etapu, czyli właśnie proces testów i odbioru projektu, co powinno leżeć po stronie klienta, co powinno leżeć po stronie Software House’u i jak uniknąć sytuacji, w których zamiast cieszyć się z zakończenia projektu, zostajemy obciążeni dodatkowymi kosztami i niejasnymi wymaganiami. Przede wszystkim pierwsza sprawa, która zaczyna się już na samym początku prac, bo tak naprawdę odbiór projektu to jest coś, co jest wynikiem końcowym tego, w jaki sposób zaplanujemy realizację projektu.

I pierwsza sprawa to jest ustalenie metodyki i tak powinniśmy na to patrzeć, czyli że odbiór projektu zaczyna się już w momencie jego planowania do realizacji, bo to właśnie wtedy ustalane są wszystkie kryteria, wszelkie funkcjonalności, wszelkie zasady współpracy, no i też wszystkie niezbędne aspekty, które właśnie później sprawiają, że zakończenie projektu przebiega płynnie i sprawnie, bez niedomówień i konfliktów. Co do zasady, im lepiej zaplanowany projekt, tym łatwiejsza realizacja, im częstsze feedbacki, tym też łatwiejsze późniejsze końcowe odbiory. Ale żeby jasno określić proces odbioru projektu, musi też być podjęta taka kluczowa decyzja, w jakiej metodyce będzie projekt realizowany.

Najpopularniejsze metodyki prowadzenia projektu jest ta, którą omawiałem w odcinku numer 17, pod tytułem Scrum Kanban Waterfall, która metodyka najbardziej opłaca się biznesowo. Więc jeżeli jeszcze nie słuchałeś, bo nie słuchałaś odcinka na temat metodyk i jesteś jeszcze przed rozpoczęciem realizacji prac i po prostu słuchasz tego odcinka, żeby zabezpieczyć się na przyszłość, na moment kiedy będziesz odbierać lub odbierała swój projekt, no to właśnie zachęcam jeszcze do przesłuchania tego odcinka 17, bo tam można o metodykach posłuchać. Generalnie metodyka to jest niejako punkt wyjścia do tego, jak zarządzać realizacją projektu, jakie będą nasze oczekiwania w zakresie terminów, testów, dokumentacji i tego co generalnie otrzymamy.

Przykładowo Scrum wymaga częstszej weryfikacji na każdym etapie, co jest bardzo dobre z perspektywy projektu. Pojawiają się regularne spotkania, regularne retrospektywy i na bieżąco jest dostosowywany kurs trwania projektu, przy czym trzeba dobrze zarządzać zakresem no i trzeba na bieżąco potwierdzać, że faktycznie to co otrzymujemy jest dla nas dobre. Waterfall ma bardziej taką zamkniętą, taką liniową strukturę, w ramach której realizujemy dany etap, zgodnie ze specyfikacją raczej ją zamrażamy, więc z reguły jest tak, że odbiór projektu w ramach metodyki waterfallowej odbywa się dopiero po zakończeniu danego takiego dużego etapu.

W Scrumie można to robić jednak częściej, ale tutaj koniec końców metodyka musi być naprawdę dobrze dobrana pod projekt i nie jest to raczej taka decyzja, którą można podjąć w ciemno i też nie jest tak, że każdy projekt można zrealizować w każdej metodyce, no bo oczywiście można, ale czy będzie to efektywne? Niekoniecznie. Dlatego tutaj jeżeli chodzi o metodykę odsyłam do odcinka 17 i co do zasady, tutaj jeżeli chodzi o odbiory projektu, no to im częściej jest ten projekt odbierany, im częściej jest feedbackowany, oczywiście zdroworozsądkowo, tym lepiej. I tutaj jeżeli chodzi o punkt dotyczący metodyk, zwróciłbym po prostu uwagę na to, żeby móc ten projekt odbierać jak najczęściej, czyli żeby nie zostawiać sobie bardzo dużych zakresów pracy, takich oficjalnych odbiorów, tylko żeby jak najczęściej jednak weryfikować, czy projekt spełnia nasze założenia i oczekiwania biznesowe.

Słowo klucz. Druga sprawa to są prawa autorskie. Jest to taka istotna kwestia, która może teraz wydawać się oczywista, ale uwierzcie mi, to co teraz widzimy jeżeli chodzi o projekty doradcze i to jak często zapominamy o tym, żeby przenieść, mieć przenoszone prawa autorskie, czy też udzieloną licencję chociaż na stworzone oprogramowanie, to jest totalny szok.

Może teraz sobie pomyślicz, że przecież to jest podstawowa sprawa, to prawnik o to zadba, ale uwierz mi, wiele osób nawet nie zdaje sobie sprawy, że o tym trzeba pamiętać już na początku projektu i zweryfikować ten punkt jeszcze na jego końcu, czyli jeżeli zaczynamy projekt, to musimy upewnić się, że będziemy mieli przekazane prawa autorskie, majątkowe do tego, żeby faktycznie móc nad tym naszym oprogramowaniem działać, bądź odpowiednią licencję, jeżeli tak się tutaj dogadaliśmy z danym wykonawcą, bo powinniśmy mieć prawa do tego, żeby móc oczywiście używać oprogramowania, ale też, żeby móc je modyfikować, sprzedawać, czy tak naprawdę cokolwiek chcemy z nim robić, żebyśmy mogli to zrobić, no bo po to zlecamy oprogramowanie i jego budowę, żeby zwyczajnie w świecie móc z niego korzystać. Tutaj nic więcej do dodania nie ma, ale jeżeli sobie tego nie ustalimy na początku i nie dopilnujemy na końcu projektu, że faktycznie te prawa autorskie zostały prawidłowo przekazane i nie mamy pełnej własności nad tym produktem, mimo, że za niego zapłacimy, no to wpadamy w taką częstą pułapkę, o której się po prostu zapomina, dlatego naprawdę warto o to zadbać i mimo, że projekt będzie formalnie odebrany końcowo, to też mieć po prostu pewność, że te prawa faktycznie do nas przejdą. Kropka.

Nic tu więcej do dodania nie ma, prawa autorskie muszą być, lub przynajmniej odpowiadająca nam licencja, z którą świadomie godzimy się, że chcemy po prostu działać na licencji, a nie mieć przekazane prawa autorskie. Trzeci punkt. Proces testowania kontra proces odbioru projektu.

I tutaj przechodzimy do tematu, który niejako stał się inspiracją dzisiejszego odcinka. Bo trzeba sobie powiedzieć jasno, testy funkcjonalne i testy regresji to coś, co stanowczo powinno leżeć po stronie Software House’u. Czyli co do zasady, przetestowanie każdego z zadań, które jest realizowane, potwierdzenie, że to zadanie działa, to jest naprawdę coś, co Software House powinien po swojej stronie wykonać.

I od tego odstępstw, jeżeli chodzi o dzisiejsze standardy, nie powinno. Natomiast po Twojej stronie drogi kliencia, czy drogi użytkowników końcowe danego oprogramowania, będzie należał odbiór projektu. Czyli zobacz, to nie jest tak, że programiści coś napiszą, tester to sprawdzi i już jest okej.

Bo testowanie i wyłapywanie nieprawidłowości to jest niejako nieodłączny element tworzenia oprogramowania. I zazwyczaj wygląda to tak, że projekt trafia do testera, czy dane zadania z projektu trafiają do testera, tester je sprawdza, wykrywa jakieś błędy, zwraca jeszcze to do programistów, programiści poprawiają, to ponownie wraca do testów i tak się dzieje pewnie niejednokrotnie i kilka razy. I to jest normalne, tego trzeba być świadomym.

Natomiast kluczowa sprawa jest taka, że każda taka iteracja testów i poprawek jest częścią procesu tworzenia oprogramowania i powinna być zrealizowana po stronie Software House’u. Bo zarówno jeżeli chodzi o samo sprawdzanie i wykrywanie tego typu ustarek, jak i też o koszty tych poprawek, to to nie są rzeczy dodatkowe, to jest kompletny standard. I tak powinniśmy to tutaj mieć też oczywiście potraktowane w umowie, więc to sobie warto jeszcze sprawdzić, jeżeli projekt dopiero startuje.

Natomiast dlaczego tak bardzo tutaj to podkreślam? No bo zdarza się, że jeszcze kończąc wątek związany z testami, bo kiedy system przejdzie wewnętrzne testy, a tester nie wykryje już żadnych nieprawidłowości, to czy to projekt, czy dany etap projektu powinien trafić do Ciebie lub do osoby odpowiedzialnej po Twojej stronie, np. product ownera, czy kogoś, kto po prostu po Twojej stronie za projekt odpowiada, do odbioru i tutaj trzeba sobie już po swojemu wszystko sprawdzić. I tu właśnie zaczyna się odbiór projektu przez klienta.

I teraz zdarza się, co właśnie ostatnio obserwujemy jeszcze bardziej jakoś tak, nie wiem, nagminnie, że projekty są prowadzone przez software house’y bez testerów, którzy, testerzy nie pojawiają się w zespołach klienta, co powoduje, że w momencie kiedy programiści coś zrealizują i niekoniecznie sprawdzą to tak od A do Z, tylko sprawdzą swój dany kawałek, a w zespole z np. trzech programistów każdy zrobi jakiś kawałek oprogramowania, każdy sprawdzi swój i jego swój w rozłączeniu, że tak powiem działa, to jednak w całości nikt tego nie testuje, bo to finalnie trafia do klienta i to klient ma przetestować, czy działa. I teraz tutaj jest ogromna różnica między odbiorem projektu, a testami projektu.

To znaczy według naszej definicji, którą my stosujemy w realizowanych projektach, testy projektu to jest rzecz, którą powinien wykonać ktoś po stronie software house’u oczywiście według realizacji zadań, kryteriów odbioru zadań, scenariuszy testowych jeżeli takowe zostały spisane, czy przynajmniej jakiejś takiej też ogólnej checklisty całościowej testującej projekt od A do Z i według tego typu checklist, scenariuszy testowych i kryteriów odbioru zadań osoba po stronie software house’u w roli właśnie testera powinna ocenić, czy te funkcjonalności działają poprawnie. Następnie np. wspólnie z project managerem, czy product owner’em powinno się dokonać wewnętrznego odbioru projektu w ramach takiego demo na podstawie którego to demo sprawdza się po prostu od A do Z, czy projekt spełnia oczekiwania biznesowe, wszelkie założenia i czy faktycznie realizuje cele biznesowe projektu.

I teraz jeżeli faktycznie je spełnia i po stronie software house’u i testy zadań i testy regresyjne i testy według scenariuszy testowych takich integracyjnych od A do Z są OK, wszystko jest nazwijmy to na zielono, to dopiero wówczas ten projekt powinien trafić do Ciebie jako do klienta do Twojego odbioru i teraz Twój odbiór jako klienta powinien być już taki mocno biznesowy czyli nie skupiasz się na tym, że wchodzisz do jakiejś zakładki i ona na dzień dobry nie działa i to są te takie testy pięciominutowe na zasadzie wchodzę, sprawdzam, nie działa, OK zgłaszam błąd i tyle, bo to oznacza jeżeli tego typu sytuacji się znajdujesz, to to oznacza, że po prostu oprogramowanie nie przechodzi prawidłowego procesu jakościowego po stronie software house’u i na to należy zwrócić po prostu na spokojnie, ale jednak konkretnie uwagę, że taki proces jakościowy powinien powstać szczególnie jeżeli to jest na przykład trzecia, czwarta iteracja i cały czas są zwracane Ci rzeczy, które po prostu nie są sprawdzone po stronie software house’u dokładnie wówczas warto na pewno na to zwrócić uwagę, żeby ten proces jakościowy został poprawiony, natomiast kiedy już dokonujesz odbiorów faktycznie jako klient, to Twój odbiór powinien być naprawdę mocno biznesowy, czyli sprawdzasz działania aplikacji i pełnienie jej roli czy spełnienie jej roli, czy ona faktycznie odpowiada na Twoje cele biznesowe, czy ludzie użytkownicy końcowi, którzy będą z niej korzystać faktycznie mogą dobrze wykonać swoje zadania z pomocą tej nowej aplikacji, nowego systemu i to będzie Twoja rola, ale właśnie konkretnie te rzeczy, czyli już jak ta aplikacja czy dany system w praktyce działa, czy ona faktycznie spełnia swoje oczekiwania czy Twoje oczekiwania biznesowe, czy spełnia po prostu założone oczekiwania biznesowe, czy cele biznesowe, czyli zmierzam do tego, że Software House powinien aplikację dobrze przetestować po swojej stronie na podstawie zadań, które wcześniej też powinieneś bądź powinnaś akceptować lub mieć przynajmniej do nich wgląd, wtedy jest już dużo mniejsze ryzyko tego, że powstanie projekt bezużyteczny, czyli działający, ale bezużyteczny i następnie po Twojej stronie jako klienta powinna być jak najbardziej odpowiedzialność za sprawdzanie od strony już biznesowej takiej użytecznej, funkcjonalnej czy faktycznie system dany dostarczony czy aplikacja oprogramowanie po prostu działa zgodnie z Twoimi oczekiwaniami i tutaj powinieneś bądź powinnaś naprawdę to sobie potwierdzić i na tym etapie trzeba być świadomym tego, że mogą wyniknąć jakieś rzeczy dodatkowe, które faktycznie tutaj mogą się pojawić. Teraz rzeczy dodatkowe na tym etapie to będą rzeczy, które są faktycznie nowe. Nowe mam na myśli takie, które wynikają niekoniecznie bezpośrednio z celu biznesowego, ale z tego, że rzeczywiście nagle okaże się, że jednak można by coś zrobić lepiej inaczej i o tym nie było mowy.

To są rzeczy nowe i teraz trzeba wziąć pod uwagę to, że na tym etapie to Project Manager z Software House na Twoje zgłoszenie powinien Ci powiedzieć, że słuchaj ta rzecz to będzie coś nowego, bo zmieniamy to z uwagi na to, że wcześniej ustaliliśmy tak, a teraz ustalamy tak, więc to będzie coś nowego i teraz powinno to się odbyć w taki sposób, że jeżeli zgłaszasz tego typu rzeczy, to powinieneś bądź powinnaś otrzymać wcześniej informację, że to jest zmiana, tak zwany Change Request i teraz ile ten Change Request będzie Cię kosztował i dlaczego? Przede wszystkim to jest rozumiane przez Software House jako Change Request i taka transparentność w projekcie to jest ogromna podstawa, bo jeżeli coś jest błędem, to te poprawki powinny być w cenie, natomiast jeżeli to jest coś zupełnie nowego, o czym wcześniej nie rozmawialiście, to nadal masz prawo podjąć świadomą decyzję, czy chcesz w to inwestować, czy na przykład zrobić to na późniejszym etapie po wdrożeniu. I teraz powiem Ci coś, co w ogóle Cię może zaskoczyć. Każdy produkt, nawet jeśli jest testowany na tysiąc sposobów, może ujawnić jakieś błędy dopiero po wdrożeniu i niestety to też jest normalne oczywiście przy zachowaniu pewnej racjonalnej skali.

Bo teraz tak, testy po stronie Software House zakładają pewne scenariusze, ale z reguły nie przewidzą absolutnie wszystkich możliwych interakcji użytkowników w wersji systemów, przeglądarek i w ogóle wszystkiego. Bo niestety musimy założyć po prostu coś takiego, że na 100 osób korzystających z systemu akurat jedna zrobi coś w zupełnie nieprzewidziany sposób i może się pojawić jakiś błąd. I teraz pytanie, co wtedy? Tutaj każdy Software House, który działa uczciwie wie, że takie rzeczy się zdarzają i powinien dać gwarancję na naprawę tego typu rzeczy również takich w sytuacji brzegowych czy po prostu występujących rzadko.

I tutaj warto sobie sprawdzić, czy macie coś takiego zagwarantowane w swoich projektach, czy ktoś Wam jasno przekazał i na etapie oferty i na etapie umowy, jak długo możecie zgłaszać błędy po wdrożeniu i jakie poprawki wchodzą w zakres takiej gwarancji. Jeżeli czegoś takiego nie ma, to warto jeszcze na etapie odbioru projektu sobie to potwierdzić, żeby po prostu po odebraniu projektu nie zostać z niczym, czyli po prostu bez zrealizowanych poprawek tam, gdzie one jeszcze będą konieczne. Co ważne, gdyby się okazało, że po odbiorze tych poprawek jest stanowczo za dużo, czyli to nie są pojedyncze sytuacje, tylko jest ich nie wiem kilkadziesiąt przy skali jakiejś powiedzmy większego projektu, no to należy na pewno się jeszcze zastanowić, z czego wynikają przyczyny tych problemów i tą taką główną przyczynę też odkryć.

Może się tak tutaj pojawić, że na przykład system został jednak z jakiegoś powodu źle napisany, jeżeli chodzi o architekturę, albo zbyt dużo modułów od siebie zależy, albo czegoś jeszcze nie przewidziano, jeżeli chodzi o logikę i warto się nad tym zastanowić głębiej na etapie już nawet po odbiorze, jeżeli na etapie odbioru to nie wyjdzie. Żeby się tutaj nie okazała sytuacja, w ramach której po wdrożeniu produkcyjnym tych błędów jest po prostu za dużo, kropka. Punkt czwarty, dokumentacja.

No i teraz temat, który potrafi umknąć w całym tym procesie, no a potem kiedy projekt jest już wdrożony, nagle okazuje się, że brakuje instrukcji, brakuje informacji, nowy zespół, albo ktokolwiek inny, kto chce dołączyć do projektu, niekoniecznie jest w stanie go zrozumieć. No i teraz, co powinieneś, bądź powinnaś dostać na koniec projektu? Oczywiście to na co się umówisz, na etapie podpisywania umowy, czy po prostu podejmowania ustaleń na początku projektu. I co to powinno być? Powinno to być po pierwsze instrukcja użytkowania, czyli coś co pozwoli twojemu zespołowi nietechnicznemu korzystać z systemu bez potrzeby dzwonienia, dopytywania software house’u z pytaniami jak coś działa.

Po drugie dokumentacja techniczna, to jest kluczowe, zwłaszcza jeżeli w przyszłości będziesz chciał lub będziesz chciała rozwijać ten projekt lub na przykład przekazać go innemu zespołowi, albo po prostu software house będzie chciał wdrożyć, nie wiem, nowego człowieka, który będzie programował w tym projekcie. Dokumentacja taka powinna opisywać jak system działa pod spodem, na tak zwanym back-endzie od strony kodu, jakie ma integracje, gdzie to jest zapisane, jakie technologie są użyte. Czyli generalnie wszystko co pozwala innemu, nowemu programiście wejść w taki projekt i nie dostać przy tym zawału.

I teraz najważniejsze, i to jest po twojej stronie, oczywiście nie prowadzenie tej dokumentacji, ale dopilnowanie, żeby software house ją w ogóle prowadził. Czyli dostęp do takiej dokumentacji powinieneś, bądź powinnaś mieć na etapie realizacji prac, żeby już na etapie współpracy się upewniać, czy dokumentacja jest tworzona, gdzie będzie prowadzona, w jakim systemie, jak często będzie aktualizowana, kto będzie za to odpowiadał. No i po twojej stronie jako klienta jest dopilnowanie sobie tego, żeby ta dokumentacja była faktycznie tworzona na bieżąco.

No bo potem na końcu projektu możesz usłyszeć, że a no my tego nie robiliśmy, tego nie zakładaliśmy, że będzie w dokumentacji i to będzie dla ciebie później problem. Więc to jest ważne, żeby, zwłaszcza jeżeli w przyszłości będziesz chciał lub będziesz chciała rozwijać ten projekt, to żeby faktycznie tą dokumentację mieć. I teraz jeżeli chodzi o punkt piąty.

Punkt piąty to jest już moment, kiedy będziesz wdrażać system do swojego biznesu i do swojego zespołu i niejako zarządzać też zmianą. I co w ramach tego etapu warto sobie zadbać i być może przygotować na etapie odbioru, czy zaraz po odbiorze projektu, różnego rodzaju szkolenia. Czyli już na etapie współpracy z Software House’em warto też ustalić, czy może będą prowadzone szkolenia dla twojego zespołu, czy dostaniesz jakieś materiały, może jakieś wideo tutoriale wspomagające onboarding do systemu.

To trzeba ustalić, no bo Software House też powinien to wycenić i mieć to uwzględnione w zakresie pracy. A to są rzeczy, które są super pomocne, jeżeli chodzi w ogóle o zarządzanie zmianą i takie właśnie wdrożenie. Na pewno warto sobie zadbać jeszcze o wsparcie na starcie, czyli takie pierwsze tygodnie działania nowego systemu to zawsze jest moment, w którym mogą się pojawiać jeszcze jakieś pytania, wątpliwości, wzmożone awarie, no bo to wszystko musi się wygrzać, jak to mówią klienci, wygrzać, uleżeć.

Więc kto będzie na te pytania odpowiadał? Czy masz już do tego jakąś osobę? Czy będziesz skorzystać też tutaj ze wsparcia Software House’u? No bo to też warto ustalić. Następna rzecz, plan wdrożenia i zarządzania zmianą. Znowu do ustalenia, czy będziesz dodawać system jakimiś etapami, czy w całości, czy twój zespół będzie rzucony na głęboką wodę, czy będziesz miał jakiś czas, żebyś nauczyć systemu, jak będzie się go uczył.

I tutaj też czasem stopniowe wdrożenie pozwala uniknąć chaosu i daje przestrzeń na wyłapanie ewentualnych błędów, więc warto tak do tego podchodzić, ale też nie zawsze tak się da, więc to też warto tutaj, jeżeli chodzi o tego typu plan wdrożenia, poprosić Software House’a o wsparcie w tym, jak to powinno się faktycznie realizować, jeżeli Software House czymś takim też się akurat tutaj zajmuje. Kto będzie odpowiadał za komunikaty do użytkowników i czy owe komunikaty w ogóle są jasne? Czyli to też jest taka kwestia UX-owa, o której na etapie planowania systemu, no niejednokrotnie się zapomina, bo jest poczucie, że ten UX nie jest aż taki ważny, więc na etapie odbioru projektu warto się zastanowić, czy te komunikaty, które system zwraca są faktycznie takie użyteczne, zrozumiałe dla użytkowników końcowych. Gwarancja i wsparcie powdrożeniowe, czyli co leży tutaj po stronie Software House’u? To tak jak wcześniej rozmawialiśmy o testach i gwarancji powdrożeniowej, to też warto omówić, jak zareagować, jeśli mimo wszystko będą pojawiały się problemy albo nawet już po gwarancji.

I tutaj po stronie Software House’u leży ustalenie jasnych procedur zgłaszania błędów czy awarii, poprzez jaki kanał, w jaki sposób to one będą przyjmowane, w jakim czasie. I ten temat omówiliśmy w ogóle w odcinku 26 na temat umowy SLA i na co zwrócić szczególną uwagę, jeżeli chodzi o SLA, czyli właśnie taki Service Level Agreement, czyli taki proces, który właśnie pozwala nam potwierdzić sobie z Software House’em w jakim czasie i w jaki sposób będą podejmowane reakcje na różne błędy, awarie, problemy. Więc jeżeli chcesz trochę więcej dowiedzieć się na temat SLA, to odcinek numer 26 śmiało sobie zakolejkuj.

Tutaj serdecznie polecam. Wracając jeszcze do tych rzeczy, o które warto byłoby zadbać, jeżeli chodzi jeszcze o kwestie samych odbiorów. To jest taki jeden duży punkt, ale on zawiera kilka ważnych podpunktów.

Oprócz SLA warto jeszcze się zastanowić nad dedykowaną osobą do kontaktu, czyli potwierdzić, kto będzie opiekunem projektu już na etapie powdrożeniowym, jakie będą kanały zgłoszeń i jak powinniśmy zgłoszeń dokonywać, jakie będą priorytety i czasy reakcji, co nam wynika z SLA, jak będzie wyglądał proces obsługi zgłoszeń i jaka będzie dostępność wsparcia. I czy to oznacza, że te punkty są w jakiś sposób narzucone z góry i czy nie ma już innego wyjścia, jak tylko się do nich dostosować? No nie, to jest wszystko oczywiście kwestia indywidualnych negocjacji i nie każdy projekt oczywiście wymaga reakcji natychmiastowej 24 na 7, ale też są takie projekty, gdzie jednak liczy się każda minuta i to po naszej stronie, czyli po stronie Software House’u leży odpowiedzialność za to, żebyś dokładnie wiedział bądź wiedziała, jakie masz możliwości i co zrobić, jeśli coś się wydarzy. Jeżeli takich informacji wcześniej nie otrzymałeś bądź nie otrzymałeś od swojego Software House’u, to warto też o to dopytać, żeby mieć jasno określone kroki, czego się spodziewać, gdzie zgłosić ewentualne problemy, pytania i w jakim czasie dostaniesz rozwiązanie.

I teraz bonusowy punkt, co tak naprawdę dostaję po zakończeniu projektu? Bo nie chodzi tylko o działający system, znaczy u niego przede wszystkim, ale chodzi też jeszcze o kwestie, które są nie zawsze zadbane, a też super istotne, bo powinniśmy mieć też dostęp do kodu źródłowego, czyli powinniśmy oprócz prawa autorskich mieć także ten dostęp do kodu źródłowego. Idealnie, jeżeli system jest zainstalowany na naszych serwerach, to też warto od razu sprawdzić i potwierdzić. Mamy tą dokumentację techniczną, o tym wspominaliśmy i schemat architektury systemu i informacja, jak został skonfigurowany serwer.

To też są rzeczy, które powinniśmy mieć po to, żeby oprócz wsparcia powdrożeniowego, oprócz prawa autorskich, oprócz odebrania projektu, a nie tylko jego testowania, zachować pełną kontrolę, bo na koniec warto pamiętać, że po zakończeniu projektu, to ty jesteś właścicielem całego rozwiązania i masz pełną kontrolę, przynajmniej powinieneś bądź powinnaś mieć i mieć prawo do dalszego rozwijania systemu. I na koniec, pół żartem, pół serio, działający system taki, który jest w pełni funkcjonalny, spełnia założone cele i jest gotowy do codziennego użytku, a do tego nie ma wad prawnych i ma dostęp do kodu źródłowego, to jest taka sytuacja idealna. I myślę, że teraz mamy już dość jasny obraz tego, jakie punkty są absolutnie niezbędne w każdym projekcie na etapie odbioru, reszta to już dodatkowe rzeczy, to kwestie ustaleń, które mogą się pojawić w trakcie współpracy i zauważ, że odpowiedzialność za projekt nie jest podzielona na to my, to wy, to bardziej taka wspólna robota, gdzie zarówno Software House, jak i ty jako klient wkładacie swoją część w to, jak to wszystko finalnie na etapie odbioru będzie wyglądać.

W praktyce cały proces tworzenia lub modernizacji systemu, to jest właśnie ta współpraca, to ciągłe omawianie, doprecyzowanie, sprawdzanie, feedbackowanie się wzajemnie, a czasem dostosowywanie kierunku, jeżeli on z jakiegoś powodu musi zostać zmieniony, aż osiągnie się końcowy efekt i to naprawdę kluczowa jest dobra komunikacja, więc przede wszystkim warto pamiętać, że na początku jeszcze przed startem zacznij od wizji końca, zastanów się jak będziesz projekt odbierać i na podstawie tego wszystko dokładnie ustali spisz i dzięki temu nawet jeśli później pojawią się jakieś nieporozumienia czy wątpliwości, to zawsze będziecie mieć do czego się odwołać i chodzi o to, aby na wypadek jakichkolwiek wątpliwości móc wskazać konkretne punkty i mieć pewność, że obie strony patrzą na tę samą stronę, więc jeżeli czujesz, że Twoje projekty mogłyby wyglądać lepiej, szybciej, bezbędnych problemów, to również zapraszam do kontaktu, chętnie przeanalizujemy Twoje potrzeby, doprecyzujemy co jest najważniejsze i zapewnimy Ci wsparcie na każdym etapie, a tymczasem zapraszam Cię do subskrybowania podcastu, na który niezmiennie omawiamy wszystkie istotne kwestie w obszarze technologii i biznesu. No i co? Ja bardzo dziękuję za dzisiaj i do usłyszenia za tydzień we wtorek. Cześć!