Umowa z softwarehousem: 5 elementów, o których musisz pamiętać

Pandemia COVID-19 pokazała, że nie tylko sektor firm medycznych, lecz także inne branże, muszą ulec przyspieszonej cyfryzacji. W obliczu wyzwań, jakie niesie przyszłość warto już dziś pomyśleć o cyfrowym rozwoju swojej firmy. A to tylko jeden z powodów, dla których biznes coraz częściej sięga po zewnętrznych dostawców usług IT. Jak jednak zadbać o to, by umowa z softwarehousem zabezpieczała Twoje interesy? Podpowiadamy.

Ogromną zaletą zlecania usług IT zewnętrznemu dostawcy są przede wszystkim dużo niższe koszty realizacji projektu oraz większa oszczędność czasu niż w przypadku zatrudnienia specjalisty na własną rękę, która wiąże się z koniecznością wdrożenia go w działalność firmy i specyfikę zadań. O tym, jak powinien przebiegać taki proces, przeczytasz w tym artykule.

Zobacz, na co musisz zwrócić szczególną uwagę, podpisując umowę z dostawcą usług IT.

1. Definicja projektu: Definition of Ready i Definition of Done

Dokładne zdefiniowanie projektu pozwoli uniknąć niedomówień związanych z realizacją zlecenia. U podstaw definiowania projektu leżą dwa kryteria: kryterium gotowości (ang. Definition of Ready, DoR) oraz kryterium ukończenia (ang. Definition of Done, DoD). Oba związane są ściśle z metodykami zwinnymi, które są dzisiaj jednak w rozwoju oprogramowania i usługach IT szeroko stosowanym standardem.

Definition of Ready określa, jakie kryteria powinno spełniać zadanie, by zespół deweloperski mógł rozpocząć jego realizację. Celem tego kryterium jest upewnienie się, że wszystkie zadania, które trzeba wykonać, są jasno i precyzyjnie opisane. W skład Definition of Ready wchodzą:

  • cel zadania – czyli jego opis w kontekście biznesowym lub funkcjonalnym, wskazanie wyniku jego realizacji;
  • przedmiot zadania – czyli odpowiedź na pytanie, czy zadanie dotyczy zmiany istniejącej funkcjonalności, czy dodania nowej? Co dokładnie należy zmienić (w przypadku zadań polegających na modyfikacji istniejących funkcjonalności), ze wskazaniem szczegółów, np. opisu przypadku użycia, procesu, modułu czy formularza, a także opis zadania i oczekiwany sposób realizacji – co dokładnie ma zostać stworzone lub zmienione i w jaki sposób oraz wskazanie reguł biznesowych, których trzeba przestrzegać w czasie pracy;
  • zależności – czyli ustalenie, czy realizacja zadania jest zależna od innych zadań lub wpływa na inne obszary sytemu, które nie zostały opisane w zadaniu;
  • kryteria akceptacji – czyli określenie kryteriów, które muszą zostać spełnione, aby zadanie mogło zostać uznane za ukończone. Jakie zasoby są potrzebne do wykonania zadania?

Definition of Done to lista kontrolna, która pozwala nadzorować postępy prac nad projektem. Zadaniem tego kryterium jest ustalenie, jakie warunki muszą zostać spełnione, by zadanie zostało uznane za zakończone. Dlatego zasadniczo Definition of Done to zbiór odpowiedzi na następujące pytania:

  • czy opracowano kod dla zakładanych funkcjonalności?
  • czy spełniono założenia dotyczące historii użytkownika?
  • czy projekt nie zawiera błędów?
  • czy kluczowe funkcjonalności zostały pokryte testami jednostkowymi?
  • czy projekt został wdrożony w środowisku testowym identycznym jak platforma produkcyjna?
  • czy funkcjonalność jest zgodna z założeniami UX?
  • czy została przeprowadzona kontrola jakości, a ewentualne usterki – usunięte?
  • czy funkcjonalność została przetestowana pod kątem kryteriów akceptacji wskazanych w Definition of Ready?
  • czy funkcjonalność została zatwierdzona przez właściciela produktu?

Prawidłowo sporządzona umowa z dostawcą usług IT powinna uwzględniać oba powyższe kryteria.

2. Kwestie techniczne

Na kwestie techniczne, takie jak sprzęt czy dostęp do narzędzi, z którymi będzie pracować firma outsourcingowa, warto zwrócić uwagę już w trakcie pierwszych rozmów, gdyż mogą one wpływać na ostateczną wycenę współpracy.

Możesz podjąć decyzję o wykorzystaniu konkretnych narzędzi, np. konkretnego narzędzia do zarządzania projektem albo zaoferować swoje serwery lub sprzęt, np. komputery.

Zasady przekazania sprzętu i narzędzi powinny być szczegółowo opisane w umowie i zawierać listę wydawanego oprogramowania i sprzętu wraz ze specyfikacją techniczną każdego z nich. Wskazane jest także dołączenie opisu stanu technicznego przekazywanych elementów.

3. Czas trwania

Czas trwania projektu powinien być uwarunkowany jego specyfikacją. Umowa może dotyczyć konkretnego zadania lub gwarantować wieloletnią współpracę.

Umowy z dostawcami usług IT zazwyczaj zawiera się na czas określony. W ich przypadku warto uwzględnić klauzulę o możliwości wypowiedzenia umowy w razie niezadowolenia z usługi. Okres wypowiedzenia powinien być wystarczający do przeniesienia usług do innego dostawcy.

4. Szacowanie

Szacowanie czasu realizacji zadań jest bezpośrednio związane z czasem trwania projektu. Buduje zaufanie i zadowolenie klienta z postępu prac, umożliwia kontrolę budżetu i czasu.

Dobre szacunki, poprzedzone szczegółową analizą przeprowadzoną przez analityka IT, eliminują ryzyko przekroczenia terminów realizacji projektu.

Przy podpisywaniu umowy, warto zwrócić uwagę, czy to usługodawca ponosi ryzyko wynikające z niewłaściwego oszacowania prac – powinno ono znajdować się po jego stronie, bo to on odpowiada za to zadanie.

5. Prawa autorskie

W celu zapewnienia pełnej ochrony poufności danych, w umowie powinien pojawić się zapis o zobowiązaniu do zachowania tajemnicy zawodowej i nierozpowszechniania otrzymywanych i przetwarzanych danych. Istotne jest, aby zobowiązanie to nie miało ograniczeń czasowych i nie wygasało wraz z zakończeniem trwania umowy.

Na całkowitą pewność zachowania poufności danych pozwala uwzględnienie kary umownej. Jednak, aby uniknąć nieporozumień, procedury wymiany poufnych informacji i sposób komunikacji powinny zostać jasno określone.