Jak prowadzić protokół z rozwoju systemu z perspektywy prawnej

Gdy jedna firma powierza rozwój systemu innej firmie, często zdarza się, że umowa zawarta między dyrektorami generalnymi za pomocą pieczęci korporacyjnej oraz dokumenty wymagane stworzone przez menedżerów nie są do końca jasne co do tego, co i do kiedy ma być stworzone. Wiele z tych niejasności wynika z codziennych interakcji na poziomie pracowników, takich jak e-maile i rozmowy telefoniczne, a także ze spotkań organizowanych przez menedżerów, na których określa się specyfikacje wcześniej niejasnych elementów, wprowadza zmiany w specyfikacjach zgodnie ze zmieniającymi się okolicznościami, zgłasza prośby o dodanie funkcji oraz prosi o współpracę w rozwiązaniu problemów.

Tworzenie i zarządzanie dokumentacją jest kluczowe dla płynnego prowadzenia projektu rozwoju systemu, a także dla przygotowania się na ewentualne spory.

W tym artykule omówimy, jak prowadzić i przechowywać protokoły i materiały z posiedzeń używanych podczas spotkań dotyczących postępów w rozwoju systemu, z perspektywy prawnej.

Dlaczego zarządzanie dokumentami jest tak ważne w rozwoju systemów?

W projektach rozwoju systemów, utrzymanie zapisów dotyczących treści dyskusji podczas spotkań kontrolnych, postępów i przebiegu projektu jest niezwykle ważne, nawet z punktu widzenia prawa. Możemy wskazać dwa główne powody:

Aby uniknąć problemów w przyszłości

Rozwój systemów to zazwyczaj projekt, który angażuje wiele stron, zarówno po stronie użytkowników, jak i dostawców. Dlatego, jeśli między stroną użytkownika a dostawcą istnieje niezgodność w rozumieniu, jakie role każda strona powinna pełnić i jakie obowiązki powinna podjąć, może to przeszkadzać w dalszym postępie projektu.

Wieloosobowy projekt oznacza również, że łatwo może dojść do problemów komunikacyjnych, takich jak subtelne różnice w tym, co mówią różne osoby, i niepewność, kto ma rację.

Utrzymanie zapisów treści uzgodnień jest wartościowe nie tylko dla potwierdzenia, czy nie ma niezgodności w rozumieniu między stronami, ale także dla utrzymania jednolitego kierunku dla wszystkich zainteresowanych stron, umożliwiając im (w swoim własnym tempie) sprawdzenie tych samych materiałów.

Przy okazji, wykorzystanie wiedzy prawnej jako środka zapobiegania konfliktom jest czasami nazywane “prawem prewencyjnym”.

Jako środek zaradczy w przypadku konfliktów

Jeśli chodzi o wyjaśnienie znaczenia zarządzania dokumentami z nieco innego punktu widzenia niż prewencyjne prawo, jak wspomniano wcześniej, można również wskazać “zarządzanie kryzysowe” jako możliwość rozważenia w kontekście rzeczywistych konfliktów.

Załóżmy, że wystąpił jakiś problem, projekt został przerwany przed ukończeniem produktu końcowego, lub nie udało się dotrzymać pierwotnego terminu. W takim przypadku, zarówno po stronie użytkownika, jak i dostawcy, nawet jeśli chcielibyśmy powiedzieć, że “mamy coś do powiedzenia na temat tego, co się stało”, jeśli zapisy nie są udokumentowane, nie będziemy mogli udowodnić naszej strony historii, co może prowadzić do niekorzystnego traktowania w sądzie.

Szczególnie w przypadku problemów wynikających z “niedotrzymania terminu”, kwestie takie jak “kiedy i w jakich okolicznościach odkryto problem”, “kiedy pojawiła się prośba o zmianę specyfikacji”, “jak dostawca próbował zareagować na prośbę o dodanie funkcji od strony użytkownika” często stają się kluczowymi punktami, które mogą wpływać na wynik procesu. Jeśli w takiej sytuacji pojawi się wiele problemów związanych z “powiedziałem, nie powiedziałem”, trudno będzie oczekiwać sprawiedliwego rozwiązania konfliktu.

Co jest szczególnie ważne w protokołach z posiedzeń dotyczących rozwoju systemu?

Rodzaje spotkań w rozwoju systemu

W projektach rozwoju systemu często organizowane są różne spotkania. To nie jest nic dziwnego, biorąc pod uwagę, że w projekcie uczestniczy wiele osób. Programiści i inżynierowie, którzy implementują program na miejscu, często organizują regularne spotkania, aby sprawdzić postęp prac. Może również wystąpić sytuacja, w której przegląda się rzeczywisty kod, aby sprawdzić, czy nie ma problemów, takich jak słaba utrzymania czy podatność na zagrożenia bezpieczeństwa.

Ponadto, oprócz spotkań na poziomie osób odpowiedzialnych za rozwój, mogą odbywać się również spotkania, w których uczestniczą dyrektorzy firmy i osoby z uprawnieniami. W takim przypadku, spotkanie często koncentruje się na ogólnym kierunku i polityce projektu. Takie spotkania na poziomie osób odpowiedzialnych, które “trzymają w rękach” ważne sprawy, nazywane są komitetami sterującymi.

Spotkanie, na które należy zwrócić szczególną uwagę, to Komitet Sterujący

Jak już wspomniano, na miejscu rozwoju systemu organizowane są różne spotkania w zależności od pozycji osób zaangażowanych i celów. Jednak z punktu widzenia prawnego, spotkanie, które należy szczególnie uwzględnić, to Komitet Sterujący. W porównaniu do spotkań na poziomie osób odpowiedzialnych, takich jak spotkania postępowe i przeglądowe, Komitet Sterujący jest szczególnie ważny z punktu widzenia zapobiegania różnym konfliktom i podejmowania działań w przypadku ich wystąpienia. Powody, dla których powinniśmy to zrozumieć, to:

1. Komitet Sterujący jest spotkaniem organizowanym przez osoby na poziomie kierowniczym, co często prowadzi do ważnych decyzji. Jest to ważne z punktu widzenia prawnego, ponieważ pokazuje, jakie są rozumienia obu stron – użytkowników i dostawców.
2. Jeśli chodzi o spotkania na poziomie osób odpowiedzialnych, zazwyczaj treść tych spotkań jest później odzwierciedlana w różnych dokumentach projektowych i specyfikacjach, więc problem “braku dokumentacji” jest trudny do przewidzenia w praktyce. (Chociaż, jeśli nawet dokumentacja tych elementów jest niewystarczająca, prawdopodobnie będzie konieczne wprowadzenie poprawek.)

Możemy podać te punkty jako przykłady.

Przypadki sądowe związane z protokołami z posiedzeń Komitetu Sterującego

Poniżej przedstawiamy jeden przypadek, w którym protokół z posiedzenia Komitetu Sterującego był traktowany jako istotny dowód w rzeczywistym procesie sądowym. Przypadek, do którego odnosi się poniższy cytat z wyroku, dotyczy sytuacji, w której projekt rozwoju systemu został przerwany w trakcie realizacji, a naruszenie obowiązków zarządzania projektem przez dostawcę zostało uznane. Treść protokołu z posiedzenia miała bardzo duże znaczenie w procesie sądowym, pokazując początkowe zrozumienie sytuacji zarówno przez dostawcę, jak i użytkownika.

Dostawca, opierając się na protokole z posiedzenia Komitetu Sterującego, stwierdził, że przebieg rozwoju systemu nie odzwierciedlał rzeczywistości, ponieważ treść protokołu została zmodyfikowana przez użytkownika. Jednakże, Komitet Sterujący został ustanowiony w celu podejmowania decyzji na najwyższym szczeblu zarządzania rozwojem systemu, z udziałem odpowiedzialnych za realizację projektu rozwoju systemu zarówno ze strony dostawcy, jak i użytkownika, aby dokonać ogólnej oceny, podzielić się rzeczywistymi wynikami i problemami związanych z harmonogramem i postępem prac, oraz podejmować decyzje w sprawie kluczowych kwestii. Następnie, główne punkty omówione podczas posiedzenia były rejestrowane przez dostawcę w protokole do godzin przedpołudniowych dnia roboczego następującego po dniu posiedzenia, rejestrowane w bazie danych protokołów, a ostateczne decyzje z posiedzenia były dokumentowane za pomocą tego protokołu. Przy zatwierdzaniu protokołu, zarówno dostawca, jak i użytkownik, przy pełnym zrozumieniu znaczenia dokumentowania prac za pomocą protokołu, rozważali jego treść i wyrażenie, i uznawali go za odzwierciedlający rzeczywistość posiedzenia. Szczególnie dostawca, jako osoba prowadząca rozwój systemu, z pewnością dobrze znał znaczenie i sposób tworzenia takiego protokołu. Dlatego też, można powiedzieć, że zatwierdzony protokół jest traktowany jako odzwierciedlający rzeczywistość pracy Komitetu Sterującego, i jest to odpowiednie, chyba że istnieją szczególne okoliczności, wówczas treść zapisana w nim jest uznawana za podsumowanie pracy Komitetu Sterującego na daną datę.

Sąd Najwyższy w Tokio, 26 września 2013 roku (rok 25 ery Heisei)

Stanowisko sądu wydaje się sugerować, że jeśli protokół z posiedzenia jest tworzony za zgodą obu stron – dostawcy i użytkownika, może on mieć pewną moc dowodową jako “dowód”. Z innej perspektywy, należy zachować ostrożność, ponieważ zbyt lekkomyślne wpisy do protokołu mogą stanowić bezpośredni dowód, co wiąże się z ryzykiem.

Konkretne elementy, które powinny zostać uwzględnione w protokole z posiedzenia

Protokół z posiedzenia ma istotne znaczenie jako dowód w przypadku ewentualnego procesu sądowego (a także w przypadku negocjacji między stronami, nawet jeśli nie dochodzi do procesu sądowego). Ale co konkretnie powinno zostać udokumentowane i zapisane w protokole z posiedzenia? Poniżej przedstawiamy kilka punktów.

Elementy, które powinny zostać zapisane z perspektywy dostawcy

Dostawca ma obowiązek zarządzania projektem jako specjalista od rozwoju systemów. Szczegółowe informacje na temat tego obowiązku można znaleźć w poniższym artykule.

https://monolith.law/corporate/project-management-duties[ja]

Biorąc pod uwagę powyższe obowiązki, dostawca powinien szczególnie zwrócić uwagę na zapisanie następujących informacji:

1. Fakt zakończenia poszczególnych etapów rozwoju i daty ich zakończenia
2. Historia odpowiedzi na prośby o zmianę specyfikacji lub dodanie funkcji otrzymanych od użytkownika
3. Środki podjęte w celu uzyskania współpracy, gdy postęp prac rozwojowych jest opóźniony z powodu okoliczności po stronie użytkownika, oraz ich kontekst

Można wymienić te punkty jako przykłady.

W odniesieniu do punktu 3 powyżej, na przykład, jeśli użytkownik nie przeprowadza inspekcji, kwestie, które dostawca powinien rozważyć, są omówione w poniższym artykule. W tym artykule wyjaśniamy, jak bardzo decyzja sądu może się zmienić w zależności od tego, jak bardzo dostawca współpracował w celu wykonania inspekcji przez użytkownika, cytując rzeczywiste wyroki sądowe.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Elementy, które powinny zostać zapisane z perspektywy użytkownika

Oczywiście, użytkownik również ma pewne obowiązki współpracy wobec prac rozwojowych dostawcy, ponieważ jest to system, który będzie używany wewnętrznie przez firmę. Ogólna treść tego obowiązku jest omówiona w poniższym artykule.

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

1. Historia tego, co użytkownik powinien przekazać dostawcy, takie jak pożądane funkcje, wygląd interfejsu użytkownika, itp.
2. Historia różnych problemów, które wystąpiły w procesie dostawcy (na przykład, nagłe odejście członka zespołu, opóźnienia w harmonogramie rozwoju spowodowane brakiem badań po stronie dostawcy, i ich przyczyny)

W odniesieniu do punktu 2 powyżej, szczególnie podatne na nieprzewidziane problemy są sytuacje, w których rozwój nowego systemu jest prowadzony równocześnie z wycofaniem starego systemu. Przenoszenie danych ze starego systemu do nowego jest szczególnie podatne na problemy, ale szczegółowe omówienie problemów prawnych związanych z tymi problemami można znaleźć w poniższym artykule.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Podsumowanie

Powyższe stanowi wytyczne dotyczące prowadzenia protokołów z posiedzeń w miejscu rozwoju systemu z punktu widzenia prawnego. Ważne jest nie tylko praktyczne “jak to zrobić”, ale także pogłębianie zrozumienia związków między takimi tematami jak “prawo”, “rozwój systemu” i “zarządzanie dokumentami”. Ze względu na fakt, że rozwój systemu często angażuje wiele osób i organizacji, łatwo przeradza się w duże transakcje handlowe, dlatego tak ważne jest zapobieganie i przeciwdziałanie konfliktom z nim związanym. A z punktu widzenia prawnego, potrzeba zachowania dowodów oznacza, że obiektywnie potwierdzalna “dokumentacja” ma duże znaczenie.

Na pewno, pełne językowe opisanie wszystkich interakcji i przebiegu projektu może być dużym obciążeniem i nie zawsze jest realne. Jednakże, ważne jest, aby zidentyfikować, co jest ważne z punktu widzenia prawnego, i odpowiednio dokumentować te ważne kwestie. Wydaje się, że ten punkt powinien być powszechnie rozpoznawany przez wszystkich ludzi zaangażowanych w biznes, niezależnie od tego, czy są specjalistami prawnymi, czy nie.