Spór o odbiór oprogramowania należy zacząć od oddzielenia wady od nowej potrzeby oraz ustalenia, które kryteria i wersje zakresu były wiążące. Sama informacja, że system „nie działa”, nie zastępuje opisu testu, zgłoszenia i dokumentu, do którego strony się odwołują.
Zachowaj umowę, ofertę, specyfikację lub backlog, uzgodnione zmiany, protokoły, wyniki testów i chronologię zgłoszeń. Przy każdym zgłoszeniu wskaż datę, funkcję, kryterium oraz odpowiedź drugiej strony. Nie zmieniaj historii narzędzia projektowego po powstaniu sporu. Materiał nie ocenia jakości kodu; porządkuje dokumenty dla sporu o wdrożenie IT.
Dwie częste pomyłki
Nie każde zgłoszenie użytkownika jest wadą, a nie każda zmiana w backlogu jest zaakceptowanym rozszerzeniem zakresu. Przykładowo strona może oczekiwać funkcji opisanej w prezentacji, lecz nieobjętej uzgodnioną wersją specyfikacji. Przed sformułowaniem stanowiska trzeba porównać dokumenty z datami i sprawdzić, kto zaakceptował zmianę. To nie zastępuje opinii technicznej o działaniu systemu.
Dokumentacja materiału
Źródła i podstawy prawne
Przy opracowaniu artykułu korzystaliśmy z poniższych aktów prawnych i oficjalnych materiałów. Przy każdym źródle wskazujemy dokładny zakres, który odnosi się do opisywanego tematu.