Czym jest obowiązek współpracy, który spoczywa na użytkowniku jako zamawiającym rozwój systemu?

Praca nad rozwojem systemu wymaga zaangażowania wielu osób i dużego nakładu pracy, zwłaszcza gdy system, który ma być rozwijany, jest na dużą skalę. W związku z tym, obowiązek współpracy spoczywa nie tylko na stronie dostawcy, który podejmuje się rozwoju, ale także na stronie użytkownika, który zamawia rozwój systemu.

To różni się od typowych relacji zamawiającego i wykonawcy. Na przykład, gdy klient (użytkownik) zamawia stworzenie garnituru na miarę u krawca, nie ma on żadnych “obowiązków”. “Obowiązki” spoczywają wyłącznie na stronie wykonawcy, czyli krawca (dostawcy). Struktura ta wynika z faktu, że rozwój systemu IT, który wymaga zaangażowania wielu osób i dużego nakładu pracy, wymaga “współpracy” zarówno ze strony użytkownika, jak i dostawcy.

W tym artykule omówimy, jakie obowiązki prawne spoczywają na stronie zamawiającego w przypadku rozwoju systemu, który nie może być pozostawiony wyłącznie w gestii dostawcy.

Nie można zrzucić wszystkiego na własny system

Nawet w przypadku jednego projektu rozwoju systemu, często wiele osób i organizacji jest zaangażowanych. Oczywiście, inżynierowie i programiści z doświadczeniem w kodowaniu są niezbędni, ale aby skupić ich wyniki pracy w jeden rezultat, ważną rolę odgrywa również menedżer projektu.

Jednakże, niezależnie od tego, jak wysokie umiejętności techniczne i organizacyjne posiada dostawca, rozwój systemu nie może być zrealizowany tylko dzięki siłom dostawcy. Na przykład, nie ma możliwości poznania takich rzeczy jak terminologia używana tylko wewnątrz firmy czy wiedza specyficzna dla danej firmy, tylko dzięki jednostronnym wysiłkom dostawcy. Im większy jest rozwój systemu, tym częściej firma, która go wykorzystuje, jest dużą firmą z wieloma pracownikami i zadaniami. Wiele razy, aby prowadzić projekt rozwoju systemu do sukcesu, organizacja biznesowa jest ważniejsza niż praca na komputerze.

W związku z tym, zamiast być biernym z powodu braku specjalistycznej wiedzy technicznej, strona użytkownika może często sprawnie przeprowadzić projekt, aktywnie dostarczając informacje. W tym sensie, rola, którą strona użytkownika pełni w projekcie rozwoju systemu, nie jest wcale mała.

Obowiązek współpracy użytkownika w świetle orzecznictwa

Więc konkretnie, jakie obowiązki współpracy spoczywają na użytkowniku w projekcie rozwoju systemu? Wiele wskazówek na ten temat pozostawiają poprzednie wyroki.

W sądzie, w sprawie opóźnienia dostawcy (pozwanej) w terminie dostawy, kwestia obowiązku współpracy użytkownika (powoda) w rozwoju stała się punktem spornym ze względu na opóźnienia w podejmowaniu decyzji przez użytkownika. W tej sprawie sąd uznał naruszenie obowiązku współpracy przez użytkownika i zaprzeczył odpowiedzialności dostawcy za niewykonanie zobowiązań. (Chociaż rozwiązanie umowy zostało uznane, również przyznano sześćdziesięcioprocentowe zrekompensowanie błędu.)

W przypadku umowy o rozwój systemu komputerowego, która jest tzw. umową o rozwój systemu na zamówienie, nie jest możliwe ukończenie systemu tylko przez wykonawcę (dostawcę), dlatego zleceniodawca (użytkownik) musi w procesie rozwoju dokładnie koordynować wewnętrzne opinie, zjednoczyć swoje poglądy, jasno przekazać wykonawcy, jakie funkcje chce, wspólnie z wykonawcą rozważyć funkcje, które chce, ostatecznie zdecydować o funkcjach, a następnie zdecydować o ekranie i formularzach, przyjąć wyniki itp. jest konieczne podział ról.

Wyrok Sądu Okręgowego w Tokio z 10 marca 2004 roku (Heisei 16)

Ten wyrok, nie tylko wskazuje, że rozwój systemu sam w sobie jest wspólnym zadaniem z użytkownikiem, ale także wyraźnie mówi, “w jakim konkretnie punkcie powinniśmy współpracować”, co wydaje się być bardzo sugestywne.

Spróbujmy przetłumaczyć powyższy tekst wyroku na język IT używany w rozwoju systemów.

Możemy to zorganizować w ten sposób. Wszystko to, niezależnie od tego, jak zaawansowane jest specjalistyczne podejście do systemu IT, nie jest możliwe do wykonania samodzielnie bez współpracy użytkownika. Funkcje, które są wymagane, i układ ekranu, które są podstawowymi rzeczami, które użytkownik powinien wyjaśnić, a także czy to, co jest wymagane, jest realizowane, tylko użytkownik może to sprawdzić.

Wreszcie, tak jak dostawcy nakłada się obowiązek zarządzania projektem, użytkownikowi nakłada się obowiązek współpracy, więc jeśli użytkownik naruszy obowiązek współpracy w powyższym procesie, istnieje możliwość, że dostawca może złożyć roszczenie o odszkodowanie za niewykonanie zobowiązań lub czyn niedozwolony przeciwko użytkownikowi.

Jak interpretowane są prośby o zmianę specyfikacji po fakcie?

Jeśli założymy, że projekt rozwoju systemu jest wspólnym wysiłkiem użytkownika i dostawcy, rozmowa przechodzi do bardziej zaawansowanej dyskusji. Chodzi o to, kto ponosi odpowiedzialność, gdy użytkownik prosi o dodatkowe funkcje lub poprawki po fakcie, co utrudnia dotrzymanie terminu.

Rozwój systemu zazwyczaj zaczyna się od definiowania wymagań, a następnie przechodzi przez podstawowy projekt, szczegółowy projekt, produkcję (implementację programu) i testy, zawsze dążąc do uniknięcia powrotów do poprzednich etapów (co jest zwykle nazywane modelem wodospadu). Jednak z różnych powodów, jeśli okaże się, że poprzedni proces jest niewłaściwy, powroty do poprzednich etapów są często spotykane w praktyce.

Jak należy myśleć, jeśli nie uda się dotrzymać terminu w takich przypadkach? Analiza poprzednich wyroków sugeruje, że wnioski mogą różnić się w zależności od momentu, w którym pojawiła się dodatkowa praca.

Jeśli dodatkowa praca pojawiła się przed wyjaśnieniem specyfikacji, takiej jak zewnętrzny projekt

Wcześniej cytowany wyrok wskazuje, że samo zgłoszenie takiego żądania podczas podstawowego projektowania (przed etapem implementacji programu) nie jest naruszeniem obowiązku współpracy.

W przypadku projektu rozwoju systemu, jak ten, jest naturalne, że użytkownik ma różne wymagania wobec dostawcy podczas podstawowego projektowania. Ponadto, dla użytkownika bez specjalistycznej wiedzy, trudno jest dokładnie ocenić, czy takie żądanie wymaga dodatkowych opłat lub przesunięcia terminu dostawy, czy przeszkadza w procesie pracy. Dlatego nie można powiedzieć, że użytkownik powinien powstrzymać się od zgłaszania żądań, które mogą prowadzić do dodatkowych opłat lub przesunięcia terminu dostawy. Raczej, jeśli użytkownik zgłosił żądanie, które wymaga dodatkowych opłat lub przesunięcia terminu dostawy, dostawca, który ma obowiązek zarządzania projektem, powinien poinformować użytkownika o tym i poprosić o dyskusję na temat wycofania żądania lub przesunięcia terminu dostawy, aby nie zakłócać pracy rozwojowej.

Wyrok Sądu Okręgowego w Tokio z 10 marca 2004 roku (2004)

W tym wyroku stwierdzono, że użytkownik ma pewne obowiązki współpracy, ale należy również uwzględnić fakt, że użytkownik nie jest specjalistą od rozwoju systemów. Innymi słowy, użytkownik, który nie jest specjalistą od rozwoju systemów, może mieć różne wymagania do momentu, gdy treść systemu stanie się jasna, a nawet może być trudno dla niego zauważyć, że te wymagania wymagają przeglądu terminów dostawy.

Jednak obowiązek dostawcy w tym kontekście oznacza przede wszystkim wysiłek w komunikacji, taki jak prośba o przesunięcie terminu dostawy (lub, jeśli termin dostawy nie może być przesunięty, prośba o wycofanie dodatkowego żądania). Dlatego nie należy interpretować tego jako obowiązku dostarczenia wszystkiego zgodnie z pierwotnym terminem po zaakceptowaniu wszystkich żądań użytkownika. W tym względzie należy zachować ostrożność.

Jeśli dodatkowa praca pojawiła się po potwierdzeniu specyfikacji w procesie produkcji lub testowania

Jeśli odwrócimy treść powyższego wyroku, możemy przewidzieć, jaki byłby wynik, gdyby dodatkowy rozwój nastąpił po potwierdzeniu specyfikacji. W takim przypadku, takie żądania mogą być trudne do spełnienia. Rzeczywiście, różnica w zrozumieniu pracy rozwojowej między użytkownikiem a dostawcą nie zmienia się, niezależnie od tego, czy jest to przed czy po potwierdzeniu specyfikacji.

Jednak zmiana lub dodanie treści zamówienia po potwierdzeniu specyfikacji ma duże prawdopodobieństwo wymuszenia powtórzenia pracy. W takich przypadkach, jest trudno bronić opóźnienia w dostawie spowodowane takimi żądaniami, mówiąc “to jest naturalne, że klient ma różne wymagania”. Co więcej, sytuacja, w której wiele zmian specyfikacji i dodatkowych funkcji pojawia się po fakcie, może również sugerować, że już na wcześniejszym etapie, takim jak podstawowy projekt, który powinien był być już zakończony, mogło być naruszenie obowiązku współpracy ze strony użytkownika.

Z tych powodów, uważa się, że nie jest realne, aby obarczać dostawcę odpowiedzialnością za opóźnienia w dostawie spowodowane zmianami specyfikacji dokonanymi po potwierdzeniu specyfikacji. Wydaje się, że jest to właściwe podejście do interpretacji powyższego wyroku.

Ponadto, takie decyzje są często podejmowane na podstawie nie tylko umowy, ale także protokołów zgodnie z postępem rozwoju systemu. Szczegółowe wyjaśnienia na temat protokołów można znaleźć w poniższym artykule.

Powiązany artykuł: Jak prowadzić protokoły z rozwoju systemu z perspektywy prawnej[ja]

Podsumowanie: Ważne jest, aby nie zapominać, że definicja wymagań jest procesem po stronie użytkownika

Definicja wymagań, choć jest miejscem, gdzie dostawca może pokazać swoje umiejętności, powinna być przede wszystkim procesem po stronie użytkownika. Nawet jeśli system jest tworzony z pomocą zewnętrznych ekspertów, powinien być obszarem, który podlega zarządzaniu firmy i jest uważany za taki z punktu widzenia prawa.

Jeśli strona użytkownika nie współpracuje w procesie rozwoju, nawet jeśli projekt pójdzie źle, sąd może wyrazić surową opinię na temat strony użytkownika. To jest coś, co powinniśmy najpierw zrozumieć.