Zakres projektu jest szerszy niż umowa
Sprzedaż obiecała rezultat, delivery widzi zależności po stronie klienta, a dokument nie opisuje odbiorów, change requestów ani tego, co dzieje się przy opóźnieniu.
Prawo IT
Prawnik dla IT i software house’ów
Pomagam układać i negocjować kontrakty technologiczne tak, żeby odpowiadały realnemu delivery. Łączę zapisy umowy z zakresem projektu, odpowiedzialnością, IP, danymi, bezpieczeństwem i tym, co zespół rzeczywiście może dowieźć.
KONTRAKT W PRAKTYCE
Gdzie umowa IT rozmija się z projektem
SLA nie pasuje do architektury
Czasy reakcji, dostępność i odpowiedzialność wyglądają profesjonalnie, ale nie uwzględniają zewnętrznych vendorów, okien serwisowych i realnych możliwości zespołu.
Odpowiedzialność jest jednostronna
Limit odpowiedzialności ma wyjątki, które praktycznie go wyłączają, kary się kumulują, a klient oczekuje odpowiedzialności za elementy pozostające poza kontrolą dostawcy.
Prawa do kodu są niejasne
Nie wiadomo, co jest rezultatem dla klienta, co pozostaje know-how dostawcy, jak traktować komponenty własne, open source, dokumentację i pracę podwykonawców.
ZAKRES
Od umowy do pracy zespołu
Łączymy zapisy kontraktu z delivery, odpowiedzialnością, prawami do kodu i danymi.
Umowy IT i delivery
- umowy wdrożeniowe, utrzymaniowe, serwisowe i outsourcingowe
- zakres, harmonogram, współdziałanie klienta i zależności
- odbiory, kryteria akceptacji i procedura usuwania wad
- change requesty, backlog i zmiana wymagań
- SLA, support, maintenance i okna serwisowe
Ryzyko i negocjacje
- odpowiedzialność, limity, kary umowne i odszkodowania
- wypowiedzenie, exit plan i przekazanie projektu
- komentarze do wzoru drugiej strony i warianty zapisów
- wsparcie podczas rozmów z klientem, vendorem lub podwykonawcą
- tabela ryzyk i rekomendacje dla osób decyzyjnych
IP, dane i bezpieczeństwo
- prawa do kodu, licencje, dokumentacja i komponenty własne
- umowy z developerami i podwykonawcami
- DPA, role RODO, podprocesorzy i transfery danych
- InfoSec, wymagania kontraktowe i security questionnaires
- zasady dotyczące incydentów, audytów i współpracy z klientem
Dla kogo pracujemy
Software house i dostawca IT
Sprzedajesz wdrożenia, rozwój, utrzymanie albo support i potrzebujesz umów, które odpowiadają temu, jak naprawdę działa projekt.
Firma kupująca technologię
Wdrażasz system, zlecasz development albo negocjujesz z vendorem i chcesz wiedzieć, gdzie są ryzyka, zależności oraz punkty decyzyjne.
Zespół produktowy lub CTO
Potrzebujesz przełożyć architekturę, bezpieczeństwo, integracje i proces delivery na język umowy, DPA albo security questionnaire.
Startup przed większym klientem
Klient enterprise przesyła własny wzór, wymagania InfoSec i długą listę załączników. Trzeba ustalić, co można przyjąć, a co negocjować.
Kiedy warto włączyć prawnika
Od przygotowania własnego wzoru po spór o odbiór albo poważną awarię.
- 01
Przed wysłaniem lub podpisaniem umowy
Najłatwiej uporządkować zakres, odpowiedzialność, IP i odbiory, zanim strony przywiążą się do konkretnego brzmienia.
- 02
Gdy negocjacje zaczynają blokować sprzedaż
Pomagam rozdzielić kwestie krytyczne od tych, które można zaakceptować, oraz przygotować warianty zapisów dla biznesu.
- 03
Kiedy projekt przestaje mieścić się w ustaleniach
Change requesty, opóźnienia, brak współdziałania klienta albo spór o odbiór wymagają połączenia umowy z realnym stanem projektu.
- 04
Przy wejściu do klienta enterprise
DPA, wymagania bezpieczeństwa, procedury, ubezpieczenie i rozbudowany procurement trzeba przejść bez obiecywania rzeczy, których organizacja nie dowiezie.
- 05
Przed skalowaniem sprzedaży
Własny standard umowy, załączników i pozycji negocjacyjnych skraca kolejne rozmowy i ogranicza przypadkowe ustępstwa.
- 06
Po incydencie albo poważnej awarii
Trzeba ocenić obowiązki, odpowiedzialność, komunikację i dalsze działania, zamiast czytać pojedynczy paragraf w oderwaniu od całej relacji.
Jak pracujemy nad tematem
Najpierw ustalamy stan projektu i punkty decyzji. Potem przygotowujemy zapisy, negocjacje i sposób wdrożenia.
- 01
Triage
Ustalamy cel, etap rozmów, model projektu i miejsca, w których dziś jest największe ryzyko.
- 02
Warianty
Rozdzielam kwestie krytyczne od negocjowalnych i pokazuję możliwe kierunki działania.
- 03
Dokumenty i negocjacje
Przygotowuję zapisy, komentarze albo cały wzór oraz wspieram rozmowę z drugą stroną.
- 04
Wdrożenie
Przekładamy podpisane ustalenia na proces odbiorów, zmian, SLA, danych i bezpieczeństwa.
Prawo blisko produktu i decyzji biznesowych
Poznaj Macieja LisaMaciej Lis jest radcą prawnym i IOD. Pracuje z firmami technologicznymi, software house’ami, startupami i zespołami kupującymi technologię. Pomaga ustalić ryzyko, przygotować warianty zapisów, przejść negocjacje i wdrożyć uzgodnione zasady.
Lis.Legal to kancelaria dla IT z siedzibą w Szczecinie. Wspieramy firmy technologiczne przy umowach z klientami, wdrożeniach i bieżących decyzjach prawnych. Projekty prowadzimy zdalnie w całej Polsce, a spotkania stacjonarne odbywają się po wcześniejszym umówieniu.
Powiązane publikacje
Cyber Resilience Act a aktualizacje bezpieczeństwa
Dlaczego podatności, maintenance i aktualizacje stają się częścią produktu oraz kontraktu.
Czytaj artykułCVE to problem procesu, nie tylko biblioteki
Co podatność w komponencie oznacza dla supportu, odpowiedzialności i komunikacji z klientem.
Czytaj artykułIP w startupie przed due diligence
Praktyczna checklista praw do kodu, dokumentacji, repozytoriów i pracy wykonawców.
Czytaj artykułMasz umowę IT albo negocjacje, które utknęły?
Napisz krótko, czego dotyczy projekt i na jakim etapie są rozmowy. Podczas 30-minutowej konsultacji ustalimy cel, najważniejsze ryzyka i sensowny następny krok.
Napisz w sprawie konsultacji