Mimo, że na co dzień stoję po drugiej stronie barykady to wiem, z jakimi problemami spotykają się firmy, które chcą skorzystać z usług firm takich jak nasza. Brak technicznej wiedzy i wysokie stawki w branży IT powodują u klientów stres. Czy nie zbankrutuję? Czy projekt uda się skończyć bez opóźnień? Czy na pewno dobrze się zabezpieczyłem? Poniższym artykułem pokażę, że nie taki software house straszny jak go malują i o czym warto pamiętać, pisząc umowę o współpracy. Poniższy artykuł powstał po analizie kilkudziesięciu umów, które podpisaliśmy z naszymi klientami w Code Apps.
Zacznijmy może od wyjaśnienia, czym jest software house i jak wybrać ten właściwy. W dużym skrócie: to firma, która zajmuje się tworzeniem dedykowanego oprogramowania. Na rynku mamy bardzo dużo firm, ale każda specjalizuje się w innych aplikacjach czy technologiach.
Zanim wybierzesz software house, z którym nawiążesz współpracę, sprawdź jakiego typu oprogramowaniem dana firma się zajmuje. Na przykład, my w Code Apps specjalizujemy się w aplikacjach webowych w technologiach PHP (Symfony) i JavaScript (Vue.js). Mamy w portfolio też inne programy, systemy e-commerce czy strony internetowe, ale główny produkt naszej działalności to dedykowane aplikacje webowe. Każda firma na swojej stronie umieszcza informacje o technologiach i obszarach w których się porusza. Zwróć na to uwagę.
Jeśli już wybrałeś kilka firm, które zajmują się tym czego szukasz, warto sprawdzić portfolio i referencje. Niektórymi projektami firmy nie będą mogły się pochwalić, ale na pewno jest kilka, które będziesz mógł zobaczyć. Zwróć uwagę na zakres obowiązków w tym projekcie i jak długo dany software house współpracuje z tym klientem. To jest bardzo ważne. Oczywiście, zdarzają się małe i krótkie współprace, ale przeważnie projekty informatyczne trwają wiele miesięcy. Przykładowo, w Code Apps mamy klientów, z którymi współpracujemy nieprzerwanie od 4-5 lat.
Ok, przejdźmy dalej. Masz już wybrany software house, jesteście umówieni na spotkanie, aby porozmawiać o Twoim projekcie. Zanim podpiszesz umowę warto zwrócić uwagę na kilka spraw.
Komunikacja
Na samym początku warto określić, jak będzie wyglądała komunikacja między Wami. Czy wszystko będzie przechodziło przez Project Managera, czy będziecie rozmawiać bezpośrednio z programistami.
Kolejnym bardzo ważnym aspektem jest to, w jakim modelu firma udostępni Ci oprogramowania do testów. Jeśli projekt potrwa np. 6 miesięcy i przez ten czas nie będziesz miał w ogóle wglądu w to co firma tworzy, to możesz być pewny, że to co dostaniesz, będzie znacząco różniło się od tego, co chciałeś dostać.
Doskonale sprawdza się metodologia SCRUM. Chodzi o to, aby podzielić projekt na iteracje (sprinty), które potrwają maksymalnie miesiąc. My w Code Apps preferujemy sprinty 2 tygodniowe. Przed każdym sprintem omawiacie z zespołem, co będzie w tym sprincie robione. Po sprincie dostajesz dostęp do aplikacji i omawiacie błędy lub zmiany, jeśli takie wystąpią. Takie rozwiązanie jest idealne, zarówno dla Ciebie jak i dla firmy, która tworzy oprogramowanie.
Warto też określić w jaki sposób będzie przebiegało zgłaszanie uwag, błędów czy nowych funkcji. Przy większym projekcie może to spowodować duży bałagan i niezrozumienie między stronami. Istnieje na rynku bardzo dużo programów, które to ułatwiają. Do takich aplikacji możemy zaliczyć Jira, Asana czy do mniejszych projektów Trello. Dobrze już na początku określić, z czego podczas trwania umowy będziecie korzystać. Przesyłanie wszystkiego emailem czy ustalenia telefoniczne odpadają.
Przydatny może być też zapis, który nakazuje wykonawcy sporządzenie i wysłanie podsumowania po każdym odbytym spotkaniu, które odbyło się osobiście lub za pomocą telekonferencji. Dzięki temu, będziesz mieć historię spotkań i ustaleń.
Warto też wspomnieć o tym, że ustalenia telefoniczne nie są wiążące. Czego nie ma na papierze (czyli w tym przypadku, w emailu) tego po prostu nie było. Bardzo przydatny zapis. Dwie osoby uczestniczące w tej samej rozmowie mogą ją zupełnie inaczej zinterpretować.
Umowa z software house
Może wydawać się to oczywiste, ale bardzo często, powstają konflikty między stronami. Tobie jako zleceniodawcy może wydawać się, że zakres umowy obejmuje znacznie więcej, niż faktycznie obejmuje. Prawdopodobnie będzie wynikało to z niewiedzy lub zaniedbania wykonawcy, dlatego warto o tym pamiętać.
Np. kwestia tego, czy zakres umowy obejmuje wdrożenie aplikacji na serwer po ukończonej pracy nad oprogramowaniem. Tobie może się wydawać, że to oczywiste. Przecież sam tego nie zrobisz. Wykonawca jednak może wyjść z założenia, że to dodatkowa praca, której nie wycenili i nie wchodzi to w zakres jego obowiązków.
Dodatkowo, w umowie muszą zawrzeć się informacje, co dokładnie jest przedmiotem umowy. Czy tylko wytworzenie oprogramowanie i „radź sobie sam”, czy do oprogramowania firma przygotuje również np. testy automatyczne, specyfikację, dokumentację, makiety itp. Ustalcie co dokładnie wykonawca dla Ciebie zrobi i wszystko zapiszcie w umowie.
Jeśli wykonawca będzie korzystał z rozwiązań open source lub rozwiązań firm trzecich, powinno to być opisane w umowie. Do takich rozwiązań oczywiście nie zostaną przekazane Ci prawa autorskie.
Jakość
W umowie powinien znaleźć się też punkt mówiący o tym, że wykonawca posiada wiedzę do wykonania przedmiotu umowy i wykona ten przedmiot zgodnie z najwyższą starannością oraz panującymi na rynku standardami. Chodzi w skrócie o to, aby wykonawca nie mydlił nam oczu swoim doświadczeniem, a dopiero na naszym projekcie uczył się danej technologii.
Każda ze stron powinna również potwierdzić, że ma prawo i zdolność do zawarcia umowy o tym zakresie oraz że ta umowa nie naruszy praw osób trzecich.
Warto dodać też zapisy o tym, że aplikacja, którą firma dla nas stworzy będzie mogła być rozwijana przez innego wykonawcę i że kod źródłowy będzie zrozumiały dla innych programistów. Jeśli dostaniemy kod napisany tak, że tylko firma, która stworzyła naszą aplikację może ją rozwijać, to będzie mogła dyktować Ci warunki i cenę.
Pracownicy i podwykonawcy
Umowa powinna również określać, kto będzie pracował przy projekcie oraz jakie będzie pełnił funkcje. Należy również zadbać o zapis, który mówi o odpowiedzialności. Wykonawca przejmuje odpowiedzialność nie tylko za pracowników etatowych, ale również za podwykonawców. Każda zmiana w zespole, który pracuje nad naszą aplikacją powinna być nam zgłoszona.
Brak tych punktów niestety zostawia spore pole do nadużyć. Przed podpisaniem umowy będzie rozmawiał z Tobą doświadczony programista, a po podpisaniu umowy, firma do naszego projektu przypisze kogoś, kto się dopiero uczy. Określona powinna być też funkcja kierownika projektu, czyli osoby, która odpowiada za projekt i zespół. Tak samo wygląda to oczywiście z drugiej strony. Wykonawca powinien jasno mieć zapisane w umowie, kto jest osobą decyzyjną oraz kto z firmy klienta odpowiada za jaki obszar.
Każdy pracownik i podwykonawca, który będzie pracował nad Twoim projektem, powinien podpisać odpowiednie postanowienie gwarantujące przestrzeganie przez tę osobę przepisów.
Rozliczenia
O metodach na rozliczenia pisałem wcześniej we wpisie „Wycena prac programistycznych”. Przeczytaj ten wpis. Jest tam dużo informacji o tym, w jaki sposób możesz rozliczać się z wykonawcą projektu.
Jeśli umowa definiuje dodatkowo płatne elementy, nieprzewidziane w zakresie umowy, każdy taki element powinien wymagać Twojej pisemnej zgody oraz akceptacji kosztów.
Warto też wspomnieć, z jaką dokładnością wykonawca wyszczególni zakres i czas prac w przypadku rozliczenia Time & Material.
Prawa autorskie
Bardzo ważny punkt, którego nie można zaniedbać. Umowa musi być skonstruowana tak, aby pełne prawa autorskie do projektu zostały Ci przekazane. Warto zadbać też o zapis, że firma nie może bez Twojej wiedzy modyfikować oraz rozpowszechniać dalej przedmiotu umowy, czyli źródeł oprogramowania.
Czas reakcji
Jeśli szukasz partnera do obsługi informatycznej swojej firmy lub planujesz dalszą współpracę z firmą już po uruchomieniu aplikacji, zadbaj o określenie czasów reakcji w przypadku błędów i nowych funkcji. Dopóki aplikacja powstaje i nikt z niej nie korzysta, nie jest to szczególnie ważne, ale jak już klienci zaczną używać Twojego programu, to taki punkt jest niezbędny.
Typy błędów oraz czas reakcji możemy podzielić na:
- Krytyczne – błędy, które uniemożliwiają działania systemu lub mogą wpłynąć na straty poniesione przez Ciebie.
- Znaczące – Wszystko co nie jest błędem krytycznym, ale wpływa na działanie systemu lub może stać się błędem krytycznym.
- Mało ważne – Wszelkie zgłoszenia i błędy, które są mało ważne i nie trzeba zająć się nimi szybko.
Warto dla każdego typu awarii określić zarówno czas reakcji jak i maksymalny czas naprawy lub planu obejścia. Plan obejścia to informacja o procesie naprawienia błędu, jeśli problem jest poważny i wykonawca nie jest w stanie określić. ile zajmie naprawa. Możesz również dodać kary umowne za każdą godzinę opóźnienia w czasie reakcji i naprawy problemu.
RODO
Jeśli w Twojej bazie danych będą dane osobowe, musisz zadbać o zapis mówiący o tym, kto będzie zarządzał tymi danymi. Wykonawca jako podmiot, który będzie przetwarzał dane osobowe musi oświadczyć, że zna wszystkie zasady dotyczące przetwarzania danych osobowych określone w przepisach ustawy i że zobowiązuje się ich przestrzegać.
Wykonawca może przetwarzać dane osobowe wyłącznie w celu prawidłowego wywiązania się z umowy. Nie może wykorzystywać zbioru danych w sposób niezgodny z Twoim interesem lub w sposób sprzeczny z umową. Musi również zachować milczenie o wszelkich faktach związanych z zawartością zbioru.
Powyższe zapisy muszą dotyczyć również pracowników i podwykonawców, którzy będą mieli dostęp do zbioru danych osobowych. A jako, że temat RODO jest bardzo ważny, wykonawca nie może udostępnić nikomu zbioru danych bez Twojej zgody. Nawet swoim pracownikom, którzy pracują przy projekcie.
Wykonawca musi być też zobligowany do niezwłocznego powiadomienia nas, jeśli doszło do naruszenia lub podejrzenia naruszenia zbioru danych osobowych.
Wedle uznania można dodać też zapis o karach finansowych za zaniechania w zakresie przetwarzania danych osobowych.
Zakaz konkurencji
Umowa powinna definiować nie tylko to, co software house ma zrobić, ale też to, czego robić nie może. A nie może prowadzić na rzecz własną lub podmiotów trzecich działalności konkurencyjnej w stosunku do Twojej działalności. Ewentualnie, powinien mieć Twoją pisemną zgodę na takie działania.
Oczywiście, jeśli przedmiotem umowy jest np. stworzenie standardowego sklepu internetowego to taki punkt nie ma sensu. Ale jeśli przekazujesz swoją wiedzę i doświadczenie w danej dziedzinie, warto zabezpieczyć się przed tym, żeby wykonawca nie wykorzystał tego dalej.
Odstąpienie od umowy
Odstąpienie od umowy to temat mało przyjemny, ale musimy o tym pomyśleć wcześniej. W przypadku polubownego rozwiązania umowy, zadbaj o długi okres wypowiedzenia. Jeśli firma stwierdzi, że nie ma czasu już z Tobą współpracować albo będzie chciała znacząco podnieść swoją stawkę, taki zapis da Ci czas na znalezienie nowego wykonawcy.
Mimo, że dodasz zapis o długim okresie wypowiedzenia umowy, musisz zabezpieczyć się też na wypadek sytuacji w której umowę musisz zerwać z dnia na dzień. Takie sytuacje się zdarzają. Umowy pisze się nie na dobre, a na złe czasy. Jeśli uznasz, że wykonawca nie wywiązuje się z umowy lub co gorsze działa na Twoją niekorzyść, musisz mieć możliwość rozwiązania umowy ze skutkiem natychmiastowym.
Konieczny jest też zapis, który zdefiniuje co w przypadku sporu. Taki zapis powinien mówić o tym, że zanim pójdziecie na noże, obie strony wyrażają chęć polubownego załatwienia sprawy za pomocą mediacji.
Gwarancja i odpowiedzialność
Po odebraniu przez Ciebie aplikacji błędy nadal mogą występować. Nawet jeśli wydaje Ci się, że wszystko dokładnie przetestowałeś. Zapis o gwarancji musi się znaleźć i musi jasno określać, w jakich warunkach obowiązuje.
Odstępstwem od gwarancji jest sytuacja, w której w aplikację lub kod ingerowała osoba trzecia, niezwiązana z wykonawcą. W takim przypadku oczywiste jest to, że wykonawca nie ponosi odpowiedzialności za takie działania.
Mimo, że software house bierze pełną odpowiedzialność za to co robi, musimy pamiętać o:
- Sytuacjach spowodowanych siłą wyższą, czyli takich na które kompletnie nie mamy wpływu (np. atak terrorystyczny).
- Błędach na które wykonawca nie miał wpływu (np. chwilowa awaria w serwerowni).
Takie zapisy zaoszczędzą nam sporo czasu i nerwów.
Zadbaj również o zapis mówiący o tym, że za poprawki, za które już zapłaciłeś, a wyszły ponownie nie płacisz kolejny raz.
Gwarancja za to co się wydarzyło to jedno, ale wykonawca musi być też zobowiązany do informowania Cię o wszelkich nieprawidłowościach i sytuacjach, które się wydarzyły, a które mogą mieć wpływ na bezpieczeństwo, wyciek danych osobowych, czy inne sytuacje, które mogą działać na Twoją niekorzyść.
Portfolio
Wykonawca prawdopodobnie będzie chciał chwalić się współpracą z Tobą. Zarówno na swojej stronie, w mediach społecznościowych, jak i różnych prezentacjach. Warto na samym początku określić, co może a co nie może upubliczniać firma, która dla Ciebie pracuje.
Zdarza się często też, że zleceniodawca nie zgadza się na umieszczanie informacji o współpracy z nim. Masz do tego pełne prawo i wykonawca musi to uszanować.
Uwaga! Pamiętaj, że celem tego artykułu jest zwrócenie uwagi na ważne kwestie. Nie jestem prawnikiem i nie mam wiedzy, aby doradzać innym w tym zakresie. Dlatego zawsze skorzystaj z usług prawnika, zanim podpiszesz umowę. To inwestycja, która zawsze się zwraca. Powyższy artykuł ma na celu jedynie pokazanie, na co możesz zwrócić uwagę. Nie może być traktowany jako wzór czy punkt odniesienia przy tworzeniu umowy!
