Software house informuje, że kolejny etap jest gotowy, i przesyła aplikację do odbioru. Umowa daje zamawiającemu pięć dni roboczych na zgłoszenie uwag. Jeśli ich nie zgłosi, etap uznaje się za odebrany. Po dwóch dniach testów okazuje się, że płatność w aplikacji czasem się zawiesza, jeden z ekranów wygląda inaczej niż w projekcie, a zespół po stronie zamawiającego chciałby jeszcze dodać przypomnienia dla użytkowników. Wykonawca twierdzi, że to ostatnie to nowa funkcja, a zawieszanie płatności wynika z konfiguracji po stronie zamawiającego.
Nagle pojawia się kilka pytań naraz. Czy każdy z tych problemów pozwala odmówić odbioru? Czy pięć dni to wystarczająco dużo? Co się stanie, jeśli zamawiający nie zdąży odpowiedzieć? Odbiór aplikacji mobilnej to moment, w którym te pytania przestają być teoretyczne, a odpowiedź na nie zależy w dużej mierze od tego, jak procedura odbiorowa została opisana w umowie.
W artykule Umowa na stworzenie aplikacji mobilnej – na co zwrócić uwagę przed podpisaniem? procedura odbioru była tylko jednym z punktów. Tutaj omawiam ją szczegółowo.
Odbiór aplikacji mobilnej – co właściwie oznacza w projekcie IT?
Odbiór to mechanizm służący ustaleniu, czy rezultat danego etapu lub całego projektu spełnia uzgodnione wymagania i może zostać uznany za wykonany zgodnie z umową. W praktyce umowy wiążą z nim wiele skutków, na przykład:
- uznanie etapu za wykonany,
- powstanie obowiązku zapłaty wynagrodzenia lub kolejnej transzy,
- rozpoczęcie kolejnego etapu prac,
- początek okresu gwarancji lub serwisu, jeśli umowa go przewiduje,
- przejście autorskich praw majątkowych, jeśli strony tak ustaliły (więcej o tym w artykule Prawa autorskie do aplikacji mobilnej – czy zapłata za aplikację oznacza, że masz prawa do kodu?).
Żaden z tych skutków nie jest automatyczny. Zależą one od konstrukcji konkretnej umowy i od przepisów, które znajdą do niej zastosowanie. Te przepisy zależą z kolei od kwalifikacji umowy. Umowa na stworzenie aplikacji może być umową o dzieło, umową o świadczenie usług albo umową mieszaną. Na przykład przepisy Kodeksu cywilnego o umowie o dzieło przewidują obowiązek odebrania dzieła wydanego zgodnie ze zobowiązaniem, ale mają zastosowanie tylko wtedy, gdy umowa rzeczywiście zostanie tak zakwalifikowana. Dlatego skutki odbioru warto opisać w umowie wprost, zamiast zakładać, że wynikną z przepisów.
Co dokładnie podlega odbiorowi?
Zdanie „zamawiający dokona odbioru aplikacji zgodnej z umową” brzmi sensownie, dopóki nie trzeba go zastosować. Żeby ocenić, czy aplikacja jest „zgodna z umową”, trzeba wiedzieć, z czym ją porównać.
W zależności od modelu projektu punktem odniesienia może być:
- specyfikacja funkcjonalna,
- backlog i opisane w nim user stories,
- wymagania niefunkcjonalne, np. wydajność, obsługiwane urządzenia i wersje systemów, bezpieczeństwo,
- kryteria akceptacji, czyli konkretne warunki, które musi spełnić dana funkcja, żeby uznać ją za wykonaną.
Kryteria akceptacji są z perspektywy odbioru najważniejsze. Zapis „użytkownik może zarezerwować wizytę” pozwala na spór. Zapis „użytkownik wybiera termin z dostępnych slotów, otrzymuje potwierdzenie na ekranie i powiadomienie push, a rezerwacja pojawia się w panelu administratora” pozwala na test.
Pytanie, które warto zadać przed podpisaniem umowy: względem czego będziesz testować rezultat każdego etapu? Jeśli odpowiedź brzmi „względem naszych ustaleń”, procedura odbiorowa będzie miała słaby fundament.
Testy odbiorowe – jak je uregulować?
Testy odbiorowe to etap, na którym zamawiający sprawdza, czy aplikacja spełnia wymagania. Umowa z software house’em może (i zwykle powinna) opisywać:
- moment udostępnienia do testów, czyli kiedy i w jakiej formie wykonawca przekazuje wersję do sprawdzenia,
- środowisko testowe, czyli czy zamawiający testuje na wersji testowej, w dystrybucji beta, czy na urządzeniach wskazanych w specyfikacji,
- czas na testy, liczony od konkretnego zdarzenia,
- zakres testów, czyli czy sprawdzane są tylko nowe funkcje z danego etapu, czy także ich wpływ na wcześniej odebrane elementy,
- osoby uprawnione do zgłaszania uwag w imieniu zamawiającego,
- sposób zgłaszania błędów, np. przez określone narzędzie, a nie w rozproszonych wiadomościach,
- treść zgłoszenia, czyli opis pozwalający odtworzyć błąd: co zrobiono, na jakim urządzeniu, jaki był oczekiwany, a jaki faktyczny rezultat,
- ponowne testy po poprawkach.
Nie ma uniwersalnej odpowiedzi na pytanie, ile dni na testy to dobrze. Termin musi odpowiadać skali etapu. Na sprawdzenie jednego ekranu wystarczy krótki czas, a na przetestowanie modułu płatności z kilkoma integracjami potrzeba znacznie więcej. Warto też uwzględnić, kto po stronie zamawiającego będzie testował. Jeśli to founder, który w tym samym czasie prowadzi firmę, termin, który wygląda rozsądnie na papierze, może być w praktyce nierealny.
Obowiązek precyzyjnego opisania błędu jest korzystny dla obu stron. Wykonawca może szybciej go usunąć, a zamawiający ma dowód, że zgłosił konkretny problem, a nie ogólne niezadowolenie.
Błąd czy nowa funkcjonalność?
To źródło większości sporów przy odbiorach. Warto rozróżnić trzy sytuacje:
- niezgodność z zakresem, gdy aplikacja nie ma funkcji, która była w wymaganiach,
- błąd w istniejącej funkcji, gdy funkcja jest, ale nie działa tak, jak opisano,
- nową funkcjonalność lub zmianę wymagań, gdy zamawiający oczekuje czegoś, czego wymagania nie przewidywały.
Przykład: specyfikacja przewiduje, że użytkownik otrzymuje powiadomienie po dokonaniu rezerwacji. Jeśli powiadomienie w ogóle nie przychodzi, mamy do czynienia najpewniej z błędem albo niezgodnością. Jeśli natomiast zamawiający po testach chce, żeby użytkownik dostawał dodatkowo przypomnienie 24 godziny przed wizytą, to najpewniej rozszerzenie zakresu, a nie błąd.
„Najpewniej”, bo kwalifikacja konkretnego zgłoszenia zawsze zależy od treści wymagań i umowy. Im precyzyjniejsze kryteria akceptacji, tym łatwiej rozstrzygnąć, po której stronie granicy leży zgłoszenie. Zmiany zakresu obsługuje odrębna procedura (change request), którą omówię w osobnym artykule. Na potrzeby odbioru ważne jest jedno: umowa powinna przewidywać, co się dzieje, gdy strony różnie kwalifikują zgłoszenie, np. kto i w jakim trybie to rozstrzyga i czy spór blokuje odbiór całego etapu.
Czy każdy błąd powinien blokować odbiór?
W praktyce umowy często dzielą błędy na kategorie, np. krytyczne, poważne i drobne. Nazewnictwo nie jest narzucone przepisami. Strony mogą same ustalić:
- czym charakteryzuje się każda kategoria (np. błąd krytyczny uniemożliwia korzystanie z kluczowej funkcji, drobny dotyczy wyglądu lub wygody),
- które kategorie blokują odbiór,
- które pozwalają na odbiór z obowiązkiem późniejszej poprawy,
- w jakim terminie wykonawca usuwa błędy każdej kategorii.
Klasyfikacja chroni obie strony. W umowie warto uniknąć sytuacji, w której zamawiający ma obowiązek odebrać aplikację mimo błędów uniemożliwiających korzystanie z jej kluczowych funkcji, takich jak rejestracja czy płatność. Z drugiej strony przesunięty o kilka pikseli przycisk nie powinien pozwalać na bezterminowe blokowanie odbioru całego projektu, a wraz z nim płatności.
Jeśli umowa nie przewiduje kategorii, ocena, czy dany błąd uzasadniał odmowę odbioru, będzie zależała od jej treści, znaczenia błędu i przepisów, które znajdą zastosowanie. Takie spory trudno przewidzieć i łatwo przedłużyć.
Odbiór z zastrzeżeniami
Praktycznym rozwiązaniem jest odbiór z zastrzeżeniami. Etap zostaje odebrany, strony sporządzają listę drobniejszych błędów, a wykonawca zobowiązuje się usunąć je w określonym terminie.
Taki mechanizm dobrze sprawdza się, gdy aplikacja działa w zakresie kluczowych funkcji, a pozostałe uwagi nie przeszkadzają w rozpoczęciu kolejnego etapu czy publikacji. Projekt może dzięki temu iść dalej, a umowa może jednocześnie zachować po stronie wykonawcy obowiązek usunięcia wskazanych w protokole błędów w określonym terminie.
Umowa powinna jednak jasno określać skutki takiego odbioru: czy powoduje on powstanie obowiązku zapłaty w całości, czy część wynagrodzenia jest wstrzymana do usunięcia błędów z listy, oraz co się dzieje, jeśli wykonawca ich nie usunie w terminie.
Milczący odbiór – kiedy brak reakcji oznacza akceptację?
Wiele umów przewiduje klauzulę typu: „Jeżeli zamawiający w terminie 5 dni roboczych od zgłoszenia gotowości do odbioru nie zgłosi uwag, etap uznaje się za odebrany”.
Cel takiego zapisu jest zrozumiały. Wykonawca chce się chronić przed sytuacją, w której zamawiający latami nie odpowiada, a odbiór, a z nim płatność, nigdy nie następuje. Samo milczenie co do zasady nie jest wyrażeniem zgody. Taki skutek może jednak wynikać z wyraźnego postanowienia umowy, które wiąże go z formalnym zgłoszeniem gotowości do odbioru i upływem określonego terminu.
Po stronie zamawiającego ryzyko polega na tym, że może formalnie odebrać etap, którego w praktyce nie sprawdził. Dlatego przy takiej klauzuli szczególnie ważne jest, żeby umowa precyzyjnie określała:
- od kiedy biegnie termin, czyli od konkretnego zdarzenia, a nie np. od „przekazania aplikacji”,
- w jakiej formie wykonawca zgłasza gotowość do odbioru i na jaki adres, żeby zgłoszenie nie zginęło w wątku na komunikatorze,
- czy zamawiający ma wtedy faktyczny dostęp do wersji, którą da się przetestować,
- czy termin jest realny w odniesieniu do skali danego etapu.
Nie da się z góry powiedzieć, że każda taka klauzula zawsze zadziała albo nigdy nie zadziała. Ocena zależy od całej umowy, statusu stron i okoliczności sprawy, np. od tego, czy wykonawca rzeczywiście udostępnił wersję nadającą się do testów.
Warto też pamiętać, że milczący odbiór nie rozwiązuje problemu odwrotnego: zamawiający odpowiada w terminie, ale procedura przeciąga się przez kolejne rundy uwag. Problem ten warto rozwiązać przez jasne określenie zasad kolejnych rund testów, w szczególności ich zakresu i terminów. Można przewidzieć, że ponowne testy koncentrują się na zgłoszonych wcześniej błędach oraz obszarach, na które wprowadzone poprawki mogły mieć wpływ. Mechanizm nie powinien jednak uniemożliwiać zgłoszenia nowych błędów, które ujawniły się dopiero wskutek poprawek albo których obiektywnie nie można było wykryć podczas wcześniejszej rundy testów.
Co dzieje się po zgłoszeniu błędów?
Procedura odbiorowa nie powinna kończyć się na zdaniu „zamawiający zgłasza uwagi”. Umowa może określać:
- termin, w jakim wykonawca odpowiada na zgłoszenie (np. potwierdza błąd albo wskazuje, że jego zdaniem to zmiana zakresu),
- termin na poprawki, najlepiej zróżnicowany według kategorii błędów,
- sposób ponownego udostępnienia wersji,
- ponowne testy, obejmujące poprawione elementy i ich wpływ na resztę aplikacji,
- sposób zamknięcia zgłoszenia,
- skutki braku usunięcia błędów w terminie.
Ostatni punkt łączy się z odpowiedzialnością wykonawcy i zakończeniem współpracy, czyli tematami na osobne artykuły. Na etapie negocjacji wystarczy upewnić się, że umowa w ogóle odpowiada na pytanie: co dalej, jeśli błąd wciąż nie jest poprawiony po kolejnej rundzie?
Odbiór a gwarancja, support i maintenance
Odbiór zamyka etap, ale nie kończy życia aplikacji. Część błędów ujawnia się dopiero przy rzeczywistym korzystaniu, na nietypowych urządzeniach albo przy większym ruchu. Podpisanie protokołu odbioru nie musi przy tym oznaczać, że zamawiający traci możliwość zgłaszania takich problemów. Brak protokołu nie zawsze oznacza też, że do odbioru nie doszło. Wiele zależy od treści umowy i zachowania stron.
Warto więc, żeby umowa rozróżniała:
- procedurę odbiorową,
- usuwanie błędów po odbiorze,
- maintenance, czyli utrzymanie aplikacji w działaniu, np. aktualizacje pod nowe wersje systemów,
- support, czyli pomoc i reagowanie na zgłoszenia,
- dalszy rozwój aplikacji.
Gwarancja nie powstaje automatycznie z samego faktu odbioru aplikacji. Jeżeli strony przewidują w kontrakcie gwarancję lub odrębny obowiązek usuwania błędów po odbiorze, warto precyzyjnie określić jego zakres, czas trwania i procedurę zgłoszeń. Niezależnie od tego mogą znaleźć zastosowanie również uprawnienia wynikające z właściwych dla danego kontraktu przepisów.
Odbiór aplikacji mobilnej – checklista przed podpisaniem umowy
Przed podpisaniem umowy sprawdź, czy potrafisz odpowiedzieć na te pytania:
- Co dokładnie odbieram w każdym etapie?
- Według jakich kryteriów będę oceniać, czy etap jest wykonany?
- Ile mam czasu na testy i od kiedy liczy się ten termin?
- Jak i przez kogo zgłaszam błędy?
- Które błędy blokują odbiór, a które pozwalają na odbiór z zastrzeżeniami?
- Co dzieje się z drobnymi błędami po odbiorze i w jakim terminie zostaną usunięte?
- Kiedy i w jakim zakresie odbywają się ponowne testy?
- Czy brak mojej reakcji w terminie oznacza odbiór i co musi się wcześniej wydarzyć, żeby ten skutek nastąpił?
- Co się stanie, jeśli wykonawca nie usunie błędów?
Jeśli na któreś z pytań nie znajdziesz odpowiedzi w projekcie umowy, to dobry punkt do negocjacji.
Podsumowanie
Dobra procedura odbiorowa nie odpowiada tylko na pytanie „ile dni mam na zgłoszenie uwag?”. Tworzy kompletny mechanizm: co testuję, według jakich kryteriów, jak zgłaszam błąd, co robi wykonawca i kiedy następuje odbiór. Im lepiej ten mechanizm jest opisany, tym mniejsze ryzyko, że odbiór zamieni się w spór o płatność albo w akceptację aplikacji, której nikt nie zdążył sprawdzić.
Negocjujesz umowę z software house’em?
Jeśli otrzymałeś projekt umowy i chcesz sprawdzić, czy procedura odbiorowa chroni Twoje interesy, albo potrzebujesz umowy dopasowanej do sposobu realizacji Twojego projektu, kancelaria Prawnik dla IT przeanalizuje zapisy dotyczące testów, błędów i odbioru. Wskażemy, co warto zmienić przed podpisaniem. Skontaktuj się z nami.