Jak zarządzać zmianami w rozwoju systemów z perspektywy prawnej?

W projektach rozwoju systemów często zdarza się, że treść, którą użytkownik wyjaśnił wcześniej, ulega zmianie w miarę postępu prac. Dlatego też, jako dostawca przyjmujący zlecenie, nawet po zawarciu umowy, może pojawić się konieczność dostosowania się do późniejszych zmian w treści umowy.

W tym artykule wyjaśniamy, jak należy postępować z zjawiskiem “zmian”, które następują po fakcie, z prawnego punktu widzenia, w przypadku projektów rozwoju systemów, które nie zawsze przebiegają zgodnie z planem.

Dlaczego projekty rozwoju systemów są “zmieniane” po fakcie?

Rozwój systemów to współpraca między dostawcą a użytkownikiem

Rozwój systemów zazwyczaj obejmuje etap planowania i proponowania, po którym następuje definicja wymagań rozwojowych i zawarcie umowy. Po zawarciu umowy, proces przechodzi przez różne etapy projektowania, implementacji zgodnej z projektem, a na końcu przeprowadza testy. W całym procesie, dostawca, który przyjmuje pracę, oczywiście ponosi szeroki zakres obowiązków jako ekspert od rozwoju systemów, ale na użytkowniku spoczywa również pewien obowiązek współpracy. W szczególności, współpraca użytkownika jest ważna w procesach takich jak identyfikacja funkcji, które powinien posiadać system do stworzenia (definicja wymagań), wygląd i odczucia z użytkowania interfejsu (projekt podstawowy), oraz sprawdzenie, czy wynik jest zgodny z wymaganiami (testowanie lub akceptacja). Szczegółowe wyjaśnienia dotyczące obowiązków, które użytkownik ponosi w rozwoju systemów, można znaleźć w poniższym artykule.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Mimo obowiązku współpracy, użytkownicy często żądają zmian

Jednakże, nawet jeśli użytkownik nie jest specjalistą od rozwoju systemów, nie zawsze jest w stanie przekazać dostawcy wszystkie niezbędne informacje do rozwoju systemu w sposób kompleksowy i bez braków. W rzeczywistości, ze względu na precyzyjność i szczegółowość pracy, często jest wiele rzeczy, których użytkownik nie jest w stanie przewidzieć, takich jak to, jakie fakty mogą mieć decydujące znaczenie w późniejszych etapach. Ironią losu, najważniejsze fakty często pojawiają się stopniowo. Z tych powodów, w rzeczywistych projektach, mimo że ideałem jest “przejście od początku do końca w jednym ciągu”, zakłada się, że po fakcie mogą nastąpić różne zmiany, a kluczowe staje się pytanie, jak zarządzać tymi zmianami.

Co to jest dokument zarządzania zmianami

Okoliczności, w których stosuje się dokument zarządzania zmianami

Dokument zarządzania zmianami to dokument, który użytkownik wykorzystuje do złożenia wniosku do dostawcy o zmianę specyfikacji lub dodanie funkcji, odstępując od wcześniejszych wyjaśnień. Jak wcześniej wspomniano, w fazach takich jak definicja wymagań czy podstawowy projekt, użytkownik ma obowiązek współpracować z dostawcą, ale możliwe jest, że w późniejszych etapach pojawią się różne żądania.

Przykłady sytuacji, w których może być potrzebny dokument zarządzania zmianami, to na przykład:

• Jeśli w definicji wymagań lub podstawowym projekcie pojawiły się braki, a później zostanie złożone żądanie o dodanie funkcji
• Jeśli w trakcie rozwoju nastąpi przegląd polityki biznesowej itp., co wymaga zmiany specyfikacji

To są tylko przykłady.

W związku z tematami takimi jak dodawanie funkcji czy zmiana specyfikacji, co najbardziej interesuje stronę przyjmującą zlecenie, to czy zmiana kwoty wyceny jest dozwolona prawnie. Szczegółowe wyjaśnienia na ten temat znajdują się w innym artykule.

https://monolith.law/corporate/increase-of-estimate[ja]

Dokument zarządzania zmianami stanowi podstawę do oceny słuszności wyceny zawartości podczas dokonywania późniejszych podwyżek wyceny. Tworzenie dokumentu zarządzania zmianami jest ważne, aby uniknąć konfliktów z drugą stroną podczas wystawiania rachunków na podstawie późniejszych podwyżek wyceny (i aby nadać przekonujący charakter własnym argumentom, jeśli dojdzie do konfliktu).

Informacje do umieszczenia w dokumencie zarządzania zmianami

Więc jakie informacje powinny być zawarte w dokumencie zarządzania zmianami z punktu widzenia prawa? Mechanizm umowy, który pozwala na korzystanie z dokumentu zarządzania zmianami, aby zgodzić się na zmianę specyfikacji lub dodanie funkcji, jest już powszechnie rozpoznawany. Dlatego, sprawdzając szablony klauzul umownych prezentowanych przez agencje rządowe, takie jak model umowy Ministerstwa Gospodarki, Handlu i Przemysłu, można zrozumieć, jakie informacje powinny być zachowane jako zapis.

(Procedura zarządzania zmianami)
Artykuł 37 Strona A lub B, po otrzymaniu propozycji zmiany na podstawie artykułu 34 (zmiana specyfikacji systemu itp.), artykułu 35 (zatwierdzenie środkowych materiałów przez użytkownika) lub artykułu 36 (traktowanie niepewnych kwestii) od drugiej strony, w ciągu ○ dni od daty otrzymania, zapisuje następujące informacje na piśmie (zwane dalej “dokumentem zarządzania zmianami“). Strony A i B omawiają, czy taka zmiana jest możliwa na spotkaniu kontaktowym określonym w artykule 12.
① Nazwa zmiany
② Osoba odpowiedzialna za propozycję
③ Data
④ Powód zmiany
⑤ Szczegółowe informacje o zmianie, w tym specyfikacje dotyczące zmiany
⑥ Jeśli zmiana wymaga kosztów, to ich kwota
⑦ Harmonogram prac nad zmianą, w tym okres rozważań
⑧ Inne wpływy, jakie zmiana może mieć na warunki niniejszej umowy i umowy indywidualnej (okres pracy lub termin dostawy, opłata za zlecenie, klauzule umowne itp.)

Bezpośrednie czytanie tekstu prawnego i sprawdzanie zalecanych pozycji do zapisania powinno wystarczyć bez dalszych wyjaśnień. Aby uniknąć późniejszych problemów z “powiedziałem/nie powiedziałem”, powinieneś dokładnie i konkretnie zarejestrować przebieg zmian.

Podając te informacje, wraz z podpisem lub pieczęcią osoby odpowiedzialnej lub decydenta z obu stron – dostawcy i użytkownika – dokument zarządzania zmianami nabiera takiego samego znaczenia jak umowa w przypadku ewentualnego procesu sądowego.

Co warto wiedzieć na temat zarządzania zmianami

Zarządzanie zmianami zazwyczaj powinno być przeprowadzane razem z zarządzaniem problemami

Tworzenie dokumentu zarządzania zmianami ma na celu zarządzanie historią zmian, co prowadzi do osiągnięcia celów projektu (lub uniknięcia niesprawiedliwego obwiniania, jeśli cel nie zostanie osiągnięty). W praktyce, tworzenie dokumentu zarządzania zmianami często odbywa się razem z tworzeniem i aktualizacją tabeli zarządzania problemami. Innymi słowy, po zarządzaniu historią zmian w tabeli zarządzania zmianami, uzgodnione elementy zmian są włączane do tabeli zarządzania problemami jako zadania do podjęcia w przyszłości.

Wskazane jest również ustalenie zasad prowadzenia dyskusji na temat zmian

Nie tylko sposób zarządzania zmianami, ale również sposób prowadzenia dyskusji na temat zmian powinien być określony, co pozwoli na płynne przeprowadzenie zmian. To jest szczególnie ważne, gdy stosuje się metody rozwoju, takie jak rozwój zwinny, gdzie zakłada się, że różne zmiany będą wprowadzane po fakcie. W praktyce, często widzi się przykłady określania, kiedy strona przeciwna powinna odpowiedzieć na prośbę o dyskusję na temat zarządzania zmianami.

Dyskusje na temat zmian i obowiązek uczciwości

Gdy obie strony zgadzają się na zmianę umowy, na którą wcześniej się zgodziły, jest to w zasadzie zawarcie nowej umowy. Z punktu widzenia faktu, że umowa jest oparta na wolnej woli stron, zasada mówi, że dostawca nie ma obowiązku zgadzać się na zmianę umowy. Jednakże, jeśli prawa te są zbyt mocno podkreślane, może to prowadzić do obaw, że projekt rozwoju systemu nie będzie przebiegał płynnie.

Dlatego w praktyce często zapisuje się w umowie, że “istnieje obowiązek uczciwego podejścia do dyskusji na temat zmian”, a jeśli dostawca nie podejdzie uczciwie do zmian, może to prowadzić do roszczeń o odszkodowanie. Przykładowo, zapis może wyglądać tak (poniżej znajduje się przykładowy zapis z “Wzoru umowy podstawowej/indywidualnej” stworzonego przez Japońską Organizację Promocji Przetwarzania Informacji).

Artykuł 4, ustęp 3: W dyskusji na temat zmian, obie strony powinny uczciwie omówić cel zmian, możliwość zmian, wpływ zmian na koszty i terminy dostawy.

Regulacje dotyczące sposobu wprowadzania zmian

Jak wcześniej wspomniano, wprowadzanie zmian jest “bezpieczne” z punktu widzenia prawnego, jeśli za każdym razem odbywa się dyskusja na temat zmian. Jednakże, w przypadku małych projektów, może nie być konieczne ustalanie sposobu prowadzenia dyskusji na temat zmian. W takim przypadku, zamiast ustalać regulacje dotyczące dyskusji, można zdecydować, że zmiany będą wprowadzane dopiero po podpisaniu i pieczętowaniu dokumentu zarządzania zmianami przez odpowiedzialnych menedżerów użytkowników i dostawców. Jeśli zmiany są wprowadzane tylko na podstawie ustnej zgody, może to prowadzić do niejasności co do tego, czy zmiany zostały wprowadzone, co może prowadzić do poważnych problemów w przyszłości. Dlatego zarządzanie dokumentami powinno być przeprowadzane w sposób rygorystyczny.

Jednakże, może być obciążające przygotowywanie osobnych dokumentów za każdym razem, gdy zarządzanie zmianami jest konieczne, a elastyczne podejście może być bardziej pożądane. W takim przypadku, jednym z rozwiązań może być dokumentowanie kwestii związanych ze zmianami w protokołach z posiedzeń. Szczegółowe wyjaśnienia na temat tego, jak zachować protokoły z posiedzeń podczas rozwoju systemu, można znaleźć w poniższym artykule.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Podsumowanie

Na miejscach pracy, gdzie często dochodzi do zmian specyfikacji, rzeczywiście łatwo jest popaść w problemy i konflikty. Jednakże, nawet na takich miejscach pracy, gdzie wymagana jest elastyczność, podkreślanie tylko i wyłącznie “znaczenia zarządzania” może utrudniać wprowadzenie praktycznych środków.

Problem równoczesnego zaspokojenia potrzeby szybkości w biznesie i przygotowania na ewentualne sytuacje awaryjne często ma różne optymalne rozwiązania, w zależności od sytuacji firmy i charakteru projektu. Uważamy, że ważne jest również podejście do poszukiwania odpowiednich metod dla każdej firmy i każdego projektu, biorąc pod uwagę treść tego artykułu.