Zakup wytwarzania oprogramowania
jak kupić rozwiązanie, a nie uzależnienie od dostawcy
Zamawianie oprogramowania na pierwszy rzut oka może wyglądać podobnie do kupowania innych usług. Ustalamy zakres, termin, cenę, podpisujemy umowę i oczekujemy gotowego rezultatu. W praktyce jest jednak znacznie bardziej skomplikowane, ponieważ źle zakontraktowany system może przez wiele lat uzależniać firmę od jednego dostawcy, nawet jeśli sam projekt został formalnie odebrany i zapłacony.
Jeżeli zamawiamy budowę hali i wykonawca przestanie istnieć, hala nadal stoi. W przypadku oprogramowania sytuacja może wyglądać zupełnie inaczej. System może obsługiwać sprzedaż, zakupy, produkcję, magazyn, finanse, relacje z klientami albo inne ważne procesy. Jeżeli po kilku latach okaże się, że tylko jedna firma potrafi go rozwijać, posiada wszystkie dostępy, przechowuje kod i zna sposób jego uruchomienia, problem staje się biznesowy, a nie informatyczny.
Dlatego przy zakupie usług związanych z tworzeniem oprogramowania warto patrzeć szerzej niż tylko na cenę, harmonogram i listę funkcji. Trzeba od początku odpowiedzieć sobie na kilka prostych pytań. Czy oprogramowanie naprawdę będzie nasze? Czy będziemy mogli przekazać jego rozwój innej firmie? Czy będziemy mieli dostęp do kodu źródłowego? Co stanie się, jeśli wykonawca upadnie? Czy nowy dostawca będzie potrafił przejąć system? Kto odpowiada za jego bezpieczeństwo? I wreszcie, czy naprawdę kupujemy rezultat, czy tylko czas pracy programistów?
Co właściwie kupujemy
Jednym z pierwszych wyborów jest sposób rozliczenia projektu. Najczęściej spotykamy model, w którym z góry ustalamy zakres, cenę i termin wykonania. Z punktu widzenia zakupów brzmi to bardzo dobrze, ponieważ mamy konkretny budżet i określony rezultat. Problem pojawia się wtedy, gdy przed rozpoczęciem prac nie da się dokładnie przewidzieć wszystkich potrzeb, a w większych projektach informatycznych jest to sytuacja bardzo częsta.
Klient może uważać, że pewna funkcja jest oczywistą częścią zamówienia, podczas gdy wykonawca uzna ją za zmianę zakresu. Wtedy zaczynają się rozmowy o dodatkowych kosztach, nowych terminach i tym, czy dana rzecz była w zamówieniu, czy nie. Im bardziej skomplikowany projekt, tym częściej takie sytuacje się pojawiają.
Drugim popularnym podejściem jest kupowanie czasu pracy zespołu. Płacimy za programistów, testerów, projektantów i inne osoby zaangażowane w rozwój systemu. Ten model daje większą elastyczność, ponieważ można na bieżąco ustalać priorytety i zmieniać kolejność prac. Ma jednak również słabą stronę. Jeśli rozliczamy wyłącznie godziny, dostawca zarabia tym więcej, im dłużej trwa projekt.
Dlatego samo kupowanie czasu także nie jest najlepszym rozwiązaniem. Znacznie rozsądniejsze jest połączenie elastyczności z kontrolą rezultatów. Możemy płacić za pracę zespołu, ale jednocześnie ustalać, co ma powstać w kolejnych etapach, jakie są zasady odbioru, jakie wymagania jakościowe muszą zostać spełnione i w jaki sposób będzie kontrolowany postęp. Nie powinniśmy kupować wyłącznie godzin programistów. Powinniśmy kupować kontrolowany proces prowadzący do powstania konkretnego efektu biznesowego.
Czy kod naprawdę będzie nasz
To jedna z najważniejszych kwestii w całym kontrakcie. Sam zapis, że prawa autorskie przechodzą na klienta, może być zbyt ogólny. Umowa powinna jasno określać, do czego klient otrzymuje prawa i co może później zrobić z oprogramowaniem.
Powinniśmy mieć możliwość korzystania z systemu, jego zmieniania, rozwijania i przekazania dalszych prac innej firmie. To szczególnie ważne wtedy, gdy po kilku latach chcemy zakończyć współpracę z dotychczasowym dostawcą. Jeżeli w takim momencie okazuje się, że potrzebujemy jego zgody na dalszy rozwój systemu, oznacza to, że od początku nie zadbaliśmy odpowiednio o swoje interesy.
Trzeba też pamiętać, że oprogramowanie to nie tylko sam kod. W ramach projektu powstają również projekty ekranów, dokumentacja, struktura danych, instrukcje instalacji, testy, opis połączeń z innymi systemami, konfiguracja serwerów oraz rozwiązania potrzebne do wdrażania kolejnych wersji. Umowa powinna więc obejmować cały efekt pracy, a nie tylko pliki z kodem programu.
Warto również sprawdzić, czy wykonawca sam posiada prawa do wszystkiego, co nam przekazuje. Software house może korzystać z pracowników, osób prowadzących własną działalność albo podwykonawców. Klient powinien mieć pewność, że firma, z którą podpisuje umowę, ma prawo przekazać mu efekty ich pracy. W przeciwnym razie po kilku latach może pojawić się problem z częścią rozwiązania stworzoną przez osobę, której klient nawet nie zna.
Terminy muszą uwzględniać także pracę zamawiającego
Przy planowaniu harmonogramu projektu warto pamiętać, że terminy nie zależą wyłącznie od firmy tworzącej oprogramowanie. Bardzo częstą przyczyną opóźnień są braki po stronie zamawiającego, na przykład niegotowa analiza potrzeb, zmieniające się wymagania, brak decyzji biznesowych, niedostępność osób odpowiedzialnych za proces, opóźnione przekazywanie danych albo długi czas akceptacji kolejnych etapów. Dlatego harmonogram powinien od początku uwzględniać także zasoby klienta i jasno wskazywać, jakie działania oraz decyzje muszą zostać wykonane po jego stronie i w jakim terminie. Warto również określić osoby odpowiedzialne za poszczególne obszary oraz czas potrzebny na konsultacje, testy i odbiory. Dzięki temu znacznie łatwiej później ocenić, czy opóźnienie rzeczywiście wynika z pracy dostawcy, czy z tego, że projekt czekał na decyzję, dane lub dostępność zespołu zamawiającego.
Gotowe elementy i zewnętrzne biblioteki
Współczesne programy prawie nigdy nie powstają całkowicie od zera. Programiści korzystają z gotowych bibliotek, narzędzi i innych elementów przygotowanych wcześniej przez inne firmy lub społeczności. To normalne i pozwala znacznie szybciej tworzyć dobre rozwiązania.
Problem zaczyna się wtedy, gdy klient nie wie, z czego właściwie zbudowany jest jego system. Może się po pewnym czasie okazać, że jedna z używanych bibliotek ma poważną lukę bezpieczeństwa albo że zmieniły się zasady jej używania. W takiej sytuacji firma powinna być w stanie szybko sprawdzić, czy problem dotyczy również jej systemu.
Jeżeli jedyną odpowiedzią na takie pytanie jest „musimy zapytać naszego dostawcę”, oznacza to, że klient ma zbyt małą kontrolę nad własnym rozwiązaniem. Przy większych projektach warto więc wymagać informacji o najważniejszych zewnętrznych elementach wykorzystanych w systemie oraz o zasadach, na jakich można z nich korzystać.
Co jeśli dostawca upadnie
To pytanie warto zadać jeszcze przed podpisaniem umowy, a nie wtedy, gdy firma przestanie odbierać telefony. Sam zapis, że w przypadku upadłości dostawca przekaże klientowi kod, może okazać się niewystarczający. W momencie, w którym firma ma już problemy finansowe, wyegzekwowanie takich obowiązków może być bardzo trudne.
Znacznie bezpieczniej jest tak zorganizować współpracę, aby klient przez cały czas posiadał aktualny dostęp do kodu i najważniejszych zasobów. Kod nie powinien znajdować się wyłącznie na serwerach dostawcy. Najlepiej, jeśli miejsce jego przechowywania jest kontrolowane przez klienta, a wykonawca otrzymuje do niego odpowiednie uprawnienia.
Podobnie warto podejść do praw autorskich. Nie należy odkładać ich przekazania na koniec kilkuletniego projektu. Bezpieczniejsze jest stopniowe przechodzenie praw wraz z kolejnymi wykonanymi i opłaconymi etapami. Dzięki temu nawet jeśli po dwóch latach wykonawca przestanie istnieć, klient nadal posiada efekty prac wykonanych do tego momentu.
Sam kod źródłowy może nie wystarczyć
To bardzo częsty błąd w myśleniu o zabezpieczeniu interesów klienta. Załóżmy, że kończymy współpracę z dostawcą i otrzymujemy cały kod programu. Czy nowa firma będzie potrafiła od razu przejąć system? Niekoniecznie.
Może się okazać, że nie ma aktualnej dokumentacji, nie wiadomo, jak przygotować serwer, jak uruchomić kolejną wersję, gdzie znajdują się klucze dostępu albo z jakimi zewnętrznymi usługami system jest połączony. Formalnie posiadamy wtedy kod, ale praktycznie nie potrafimy z niego korzystać.
Dlatego wraz z systemem klient powinien posiadać także wiedzę pozwalającą innemu kompetentnemu zespołowi przejąć jego rozwój. Dobrą zasadą jest zadanie prostego pytania: gdybyśmy jutro zakończyli współpracę z obecnym dostawcą, czy inna firma byłaby w stanie uruchomić system i zacząć go rozwijać na podstawie tego, co już mamy? Jeśli odpowiedź brzmi „nie”, jesteśmy zbyt mocno uzależnieni od wykonawcy.
Konta i dostępy powinny należeć do klienta
Bardzo częsty problem pojawia się wtedy, gdy firma informatyczna zakłada na siebie konta potrzebne do działania systemu. Może to być konto na serwerze, w usłudze chmurowej, miejsce przechowywania kodu, domena, certyfikat albo inna usługa techniczna.
Dopóki współpraca przebiega dobrze, nikt nie widzi w tym większego problemu. Prawdziwe trudności zaczynają się dopiero przy zmianie dostawcy. Wtedy może się okazać, że formalnym właścicielem najważniejszych kont jest firma, z którą właśnie chcemy zakończyć współpracę.
Bezpieczniejsza zasada jest prosta. Jeżeli dana usługa jest kluczowa dla naszego systemu, konto powinno należeć do naszej organizacji. Dostawca powinien otrzymywać tylko taki poziom dostępu, jaki jest mu potrzebny do wykonania pracy.
Cyberbezpieczeństwo nie może być tylko ogólnym zapisem
W wielu umowach pojawia się zdanie, że wykonawca będzie stosował dobre praktyki bezpieczeństwa. Brzmi rozsądnie, ale w praktyce niewiele z tego wynika. Co dokładnie oznaczają dobre praktyki? Kto sprawdza, czy są stosowane? Jak często? Co dzieje się wtedy, gdy zostanie wykryta poważna luka?
Znacznie lepiej określić konkretne zasady. Klient powinien wiedzieć, kto ma dostęp do systemu, kto może zobaczyć dane produkcyjne, czy każdy administrator posiada własne konto, czy działania administratorów są zapisywane, czy stosowane są dodatkowe zabezpieczenia logowania oraz czy środowisko testowe jest oddzielone od produkcyjnego.
Warto również wiedzieć, czy programiści mają bezpośredni dostęp do systemu produkcyjnego, czy wykorzystywane biblioteki są regularnie sprawdzane pod kątem znanych luk i jak szybko wykonawca ma reagować na poważne problemy. Nie trzeba być ekspertem od bezpieczeństwa, aby zadawać takie pytania. Wystarczy patrzeć na nie z perspektywy ryzyka biznesowego.
Największe zagrożenia często są niewidoczne
Klient zazwyczaj odbiera to, co widzi. Sprawdza, czy działa formularz, raport, wyszukiwarka albo proces akceptacji. To oczywiście ważne, ale część najpoważniejszych zagrożeń znajduje się pod powierzchnią.
Może się na przykład okazać, że kilku programistów korzysta z jednego wspólnego konta administratora. Jeśli coś się wydarzy, nie wiadomo później, kto wykonał daną operację. Innym problemem może być stały dostęp programistów do systemu produkcyjnego, mimo że nie jest im potrzebny do codziennej pracy.
Czasem firmy kopiują prawdziwe dane klientów do środowiska testowego, bo tak jest łatwiej sprawdzać nowe funkcje. Wtedy dane mogą trafić na dodatkowe serwery albo na komputery programistów. Innym ryzykiem jest wpisywanie haseł i kluczy dostępu bezpośrednio do kodu programu albo pozostawianie aktywnych dostępów osobom, które już nie pracują przy projekcie.
Klient może przez lata nie mieć pojęcia, że takie sytuacje w ogóle występują. Dlatego cyberbezpieczeństwo nie powinno opierać się wyłącznie na zaufaniu do wykonawcy. Powinno być opisane konkretnymi zasadami i okresowo sprawdzane.
Bezpieczeństwa nie sprawdza się tylko raz
Jednym z najczęstszych błędów przy tworzeniu oprogramowania jest potraktowanie testu bezpieczeństwa jako jednorazowego etapu wykonywanego tuż przed uruchomieniem systemu. W praktyce bezpieczeństwo powinno być sprawdzane wielokrotnie podczas całego rozwoju rozwiązania, ponieważ każda większa zmiana, nowa funkcja, integracja czy aktualizacja biblioteki może wprowadzić nowe ryzyko.
W naszych projektach GOODMAN podchodzimy do tego właśnie w taki sposób. Bezpieczeństwo nie jest jednym testem wykonywanym na końcu projektu. Przy kolejnych wersjach systemu wielokrotnie sprawdzamy, czy nie pojawiły się nowe luki, czy użytkownik nie może uzyskać dostępu do danych, do których nie powinien mieć dostępu, czy mechanizmy logowania i uprawnień działają poprawnie oraz czy zmiana w jednym miejscu nie osłabiła zabezpieczeń w innym. W praktyce oznacza to często dziesiątki kolejnych kontroli wykonywanych w trakcie rozwoju tego samego rozwiązania.
Szczególnie ważne jest sprawdzanie nie tylko samego kodu, ale również sposobu działania całego systemu. Można mieć poprawnie napisany fragment programu, a mimo to stworzyć lukę wynikającą z niewłaściwego połączenia kilku funkcji. Dlatego testować trzeba między innymi uprawnienia użytkowników, dostęp do danych innych osób lub organizacji, możliwość wykonywania operacji bez odpowiednich praw, przesyłanie plików, obsługę błędów, logowanie, sesje użytkowników oraz zachowanie systemu przy nietypowych lub celowo błędnych działaniach.
Ważne jest również ponowne sprawdzanie bezpieczeństwa po wprowadzeniu poprawek. Naprawienie jednego problemu może nieświadomie spowodować powstanie innego. Dlatego po zmianach warto wykonywać testy powtórne i sprawdzać, czy wcześniejsze zabezpieczenia nadal działają. W dojrzałym projekcie nie chodzi więc o odpowiedź na pytanie: „Czy kiedyś wykonano test bezpieczeństwa?”, ale raczej: „Jak bezpieczeństwo jest sprawdzane przy każdej kolejnej wersji systemu?”.
Z punktu widzenia zamawiającego warto więc już w umowie określić, że bezpieczeństwo podlega regularnej kontroli podczas całego okresu rozwoju oprogramowania. Dostawca powinien potrafić wykazać, jakie testy wykonuje, jak reaguje na znalezione problemy i w jaki sposób sprawdza, czy poprawki rzeczywiście je usunęły.
Dobrze zaprojektowany proces bezpieczeństwa nie polega na tym, że raz otrzymujemy raport z testu i odkładamy go do dokumentacji. Polega na ciągłym sprawdzaniu, czy system pozostaje bezpieczny wraz z jego rozwojem. W przypadku oprogramowania obsługującego ważne procesy biznesowe właśnie takie podejście daje znacznie większe bezpieczeństwo niż pojedynczy test wykonany raz na kilka lat.
Warto oprzeć wymagania bezpieczeństwa na uznanych standardach
Wymagania dotyczące bezpieczeństwa nie muszą być tworzone od zera. Istnieją uznane na świecie normy i rekomendacje, które mogą stanowić punkt odniesienia zarówno dla wykonawcy, jak i zamawiającego. Jedną z najbardziej znanych jest ISO/IEC 27001:2022 dotycząca zarządzania bezpieczeństwem informacji w organizacji. Uzupełnia ją ISO/IEC 27002:2022, która opisuje dobre praktyki dotyczące między innymi kontroli dostępu, zabezpieczania informacji i reagowania na incydenty.
Trzeba jednak uważać na bardzo częste uproszczenie. Sam fakt, że firma informatyczna posiada certyfikat ISO/IEC 27001, nie oznacza jeszcze, że napisane przez nią oprogramowanie jest bezpieczne. Norma dotyczy sposobu zarządzania bezpieczeństwem informacji w organizacji. Jest to ważny sygnał, ale nie zastępuje testów konkretnego systemu, sprawdzania kodu ani kontroli jego zabezpieczeń.
W przypadku samego tworzenia oprogramowania bardzo wartościowym punktem odniesienia są rekomendacje NIST, czyli amerykańskiego Narodowego Instytutu Standaryzacji i Technologii. NIST opracował Secure Software Development Framework, w skrócie SSDF, który zakłada, że bezpieczeństwo powinno być częścią całego procesu tworzenia i rozwijania oprogramowania, a nie pojedynczym testem wykonywanym tuż przed uruchomieniem systemu. Co ciekawe, NIST wskazuje również, że te zasady mogą być wykorzystywane przez zamawiających podczas współpracy i kontraktowania dostawców oprogramowania.
Bardzo praktycznym źródłem jest również OWASP, jedna z najbardziej rozpoznawalnych światowych organizacji zajmujących się bezpieczeństwem aplikacji. Szczególnie przydatny dla zamawiających jest OWASP ASVS, czyli standard pozwalający określić, jakie zabezpieczenia aplikacji powinny zostać sprawdzone. OWASP wprost wskazuje, że ASVS może być wykorzystywany także przy zakupie oprogramowania i do określania wymagań bezpieczeństwa w umowach. Aktualną stabilną wersją jest ASVS 5.0.0.
Innym podejściem OWASP jest SAMM, które pomaga organizacjom oceniać i rozwijać cały proces bezpiecznego tworzenia oprogramowania. Nie koncentruje się więc na pojedynczym teście, ale na tym, czy bezpieczeństwo jest rzeczywiście częścią codziennego sposobu rozwijania systemu i czy organizacja potrafi ten proces mierzyć oraz poprawiać.
Właśnie dlatego w naszych projektach GOODMAN nie traktujemy bezpieczeństwa jako jednego badania wykonywanego na zakończenie prac. Wielokrotnie wracamy do kontroli bezpieczeństwa podczas rozwoju systemu, sprawdzamy kolejne zmiany, ponownie testujemy poprawione miejsca i weryfikujemy, czy nowe funkcje nie otworzyły możliwości dostępu do danych lub operacji, które powinny pozostać niedostępne. Takie podejście jest zbieżne z kierunkiem rekomendowanym przez NIST i OWASP, czyli włączaniem bezpieczeństwa w cały proces tworzenia oprogramowania, a nie traktowaniem go jako jednorazowego odbioru.
Z punktu widzenia zakupów daje to jeszcze jedną ważną wskazówkę. Zamiast wpisywać do umowy ogólne zdanie, że „system powinien być bezpieczny”, można wskazać konkretne standardy i wymagania, według których bezpieczeństwo będzie oceniane. Dzięki temu zarówno klient, jak i wykonawca wiedzą od początku, czego należy oczekiwać i według jakich zasad będzie później oceniana jakość rozwiązania.
Dokumentacja, która pozwala przejąć system
Dokumentacja techniczna nie powinna być traktowana jako dodatek przygotowywany dopiero na koniec projektu. Jej podstawowym celem jest zapewnienie, że system może być utrzymywany i rozwijany także przez osoby, które nie uczestniczyły w jego tworzeniu. Powinna więc opisywać najważniejsze elementy rozwiązania, sposób jego uruchomienia, zależności, integracje z innymi systemami, strukturę danych oraz procedurę wdrażania kolejnych wersji.
Nie chodzi przy tym o tworzenie setek stron dokumentów, których nikt później nie aktualizuje. Znacznie ważniejsze jest ustalenie minimalnego, praktycznego standardu dokumentacji oraz obowiązku jej bieżącego uzupełniania wraz ze zmianami w systemie. Dobrze prowadzona dokumentacja ogranicza uzależnienie od konkretnych osób i znacząco ułatwia przejęcie projektu przez inny zespół.
System powinien mówić, co się z nim dzieje
Ważnym, a często pomijanym elementem jest odpowiednie rejestrowanie zdarzeń w systemie. Jeżeli pojawia się błąd, awaria albo podejrzenie incydentu bezpieczeństwa, powinniśmy móc ustalić, co się wydarzyło, kiedy do tego doszło i kto wykonał daną operację. Bez odpowiednich zapisów analiza problemu może sprowadzać się do zgadywania.
W przypadku ważniejszych systemów warto również ustalić zasady monitorowania ich działania. Powinniśmy wiedzieć, kto otrzymuje informację o awarii, niedostępności, nietypowym zachowaniu albo znaczącym wzroście wykorzystania zasobów. Samo uruchomienie systemu nie oznacza jeszcze, że ktoś faktycznie obserwuje jego stan i reaguje na problemy. Im większe znaczenie system ma dla biznesu, tym ważniejsze jest ustalenie tych zasad już na etapie kontraktowania.
Dane muszą dać się zabrać
Przy zakupie lub tworzeniu systemu łatwo skoncentrować się na tym, jak dane będą do niego wprowadzane. Równie ważne jest jednak pytanie, jak można je później z niego wyprowadzić. Firma powinna mieć możliwość pobrania swoich danych w formie, która rzeczywiście pozwala je wykorzystać w innym rozwiązaniu.
Sama kopia bazy danych może nie być wystarczająca, jeżeli jej struktura jest zrozumiała wyłącznie dla dotychczasowego dostawcy. Dlatego warto wcześniej ustalić zasady eksportu danych, ich format oraz zakres informacji, które klient otrzyma po zakończeniu współpracy. Jest to szczególnie istotne w przypadku systemów rozwijanych przez wiele lat, w których zgromadzona historia może mieć dużą wartość biznesową.
Dobrze zakontraktowany projekt powinien więc obejmować nie tylko plan uruchomienia systemu, ale również plan bezpiecznego wyjścia z niego.
Wdrożenie nie może zależeć od jednego programisty
Jeżeli publikacja nowej wersji systemu zależy od jednej osoby, która zna odpowiednią kolejność czynności, pamięta potrzebne hasła i wie, jakie polecenia należy wykonać, firma posiada poważne ryzyko operacyjne. Problem może pojawić się nie tylko przy zmianie dostawcy. Wystarczy urlop, choroba albo odejście jednego pracownika.
Proces wdrażania kolejnych wersji powinien być możliwie powtarzalny, opisany i tam, gdzie ma to sens, zautomatyzowany. Dzięki temu nie opiera się wyłącznie na wiedzy konkretnej osoby. Podobnie warto zadbać o to, aby wiedza o najważniejszych częściach systemu była dzielona między kilka osób, a nie pozostawała wyłącznie w głowie jednego specjalisty.
Takie podejście jest korzystne zarówno dla klienta, jak i dla wykonawcy. Zmniejsza ryzyko przestojów, ułatwia rozwój systemu i sprawia, że przejęcie rozwiązania przez inny zespół staje się znacznie prostsze.
Środowisko testowe powinno być oddzielone od produkcyjnego
Zmiany w systemie nie powinny być sprawdzane bezpośrednio na środowisku, z którego korzystają pracownicy lub klienci. Środowisko produkcyjne, testowe i deweloperskie powinny być od siebie odpowiednio oddzielone, a dostęp do nich kontrolowany.
Szczególną ostrożność trzeba zachować przy danych. Kopiowanie prawdziwych baz klientów lub innych poufnych informacji na środowiska testowe może znacząco zwiększać ryzyko wycieku. Jeżeli wykorzystanie takich danych jest konieczne, powinno odbywać się według jasno określonych zasad, a tam, gdzie to możliwe, dane powinny być odpowiednio zmienione lub zastąpione danymi testowymi.
Wydajność trzeba określić, zanim stanie się problemem
System może działać bardzo dobrze podczas odbioru, kiedy korzysta z niego kilku użytkowników i znajduje się w nim niewielka ilość danych. Po kilku latach sytuacja może wyglądać zupełnie inaczej. Liczba użytkowników rośnie, pojawiają się kolejne integracje, a ilość przechowywanych informacji zwiększa się wielokrotnie.
Dlatego przy ważniejszych rozwiązaniach warto ustalić podstawowe oczekiwania dotyczące wydajności. Można określić między innymi oczekiwaną liczbę jednoczesnych użytkowników, przybliżoną ilość danych czy akceptowalny czas wykonywania najważniejszych operacji. Pozwala to uniknąć sytuacji, w której dostawca twierdzi, że system formalnie działa poprawnie, mimo że w praktyce jego szybkość uniemożliwia wygodną pracę.
Jakość kodu również powinna podlegać kontroli
Klient nie musi samodzielnie analizować tysięcy linii kodu, ale może oczekiwać od wykonawcy odpowiedniego procesu kontroli jakości. Warto ustalić, że istotne zmiany są sprawdzane przez drugą osobę, wykonywane są automatyczne testy, a przed wdrożeniem przeprowadzane są podstawowe kontrole jakości i bezpieczeństwa.
W większych lub szczególnie istotnych projektach można również przewidzieć możliwość niezależnego przeglądu kodu. Nie musi on być wykonywany przy każdej zmianie. Sam fakt, że klient posiada takie uprawnienie, zwiększa przejrzystość współpracy i ogranicza ryzyko powstawania przez lata trudnego w utrzymaniu rozwiązania.
Dostęp do danych wymaga szczególnej uwagi
Klient powinien wiedzieć, kto po stronie dostawcy może zobaczyć jego dane i na jakich zasadach. Samo stwierdzenie, że dostęp ma „dział techniczny”, jest zbyt ogólne.
Warto ustalić, czy programista może wejść do systemu produkcyjnego bez zgody klienta, czy może pobrać bazę danych, czy prawdziwe dane są wykorzystywane do testowania oraz czy mogą być kopiowane na komputery pracowników dostawcy. Równie ważne jest to, co dzieje się z danymi po zakończeniu współpracy.
Nie chodzi przy tym wyłącznie o dane osobowe. System może zawierać cenniki, warunki handlowe, umowy, dokumenty finansowe, plany produkcyjne, informacje o klientach i dostawcach albo inne dane stanowiące tajemnicę przedsiębiorstwa. Ich wyciek może być dla firmy równie poważnym problemem jak utrata danych osobowych.
Kopia zapasowa to jeszcze nie bezpieczeństwo
Jednym z częstych pytań przy ocenie systemu jest: „Czy robicie kopie zapasowe?”. Odpowiedź bardzo często brzmi: „Oczywiście, codziennie”. To jednak nie oznacza jeszcze, że po awarii uda się system odtworzyć.
Znacznie lepsze pytanie brzmi: „Kiedy ostatnio odtworzyliście cały system z kopii zapasowej?”. Może się bowiem okazać, że kopie są wykonywane od kilku lat, ale nikt nigdy nie sprawdził, czy naprawdę działają.
Dobrze jest również ustalić, jak często powstają kopie, jak długo są przechowywane, gdzie się znajdują, kto może je pobrać oraz ile czasu powinno zająć odtworzenie systemu po poważnej awarii. W przypadku systemów ważnych dla działania przedsiębiorstwa jest to element ciągłości biznesowej, a nie tylko techniczna sprawa dla informatyków.
Bezpieczeństwo nie kończy się w dniu uruchomienia systemu
Oprogramowanie może zostać dobrze wykonane i bezpiecznie uruchomione, a kilka miesięcy później może pojawić się nowa luka w jednej z używanych bibliotek. Wtedy trzeba wiedzieć, kto ma ten problem zauważyć, kto ma poinformować klienta i kto odpowiada za poprawkę.
W umowie warto więc jasno określić, jak wygląda obsługa problemów bezpieczeństwa już po uruchomieniu systemu. Czy takie poprawki są częścią utrzymania? Jak szybko dostawca powinien reagować? Czy za usunięcie błędu bezpieczeństwa trzeba dodatkowo płacić? Te rzeczy najlepiej ustalić wtedy, gdy współpraca dopiero się zaczyna, a nie dopiero po wykryciu poważnego problemu.
Warto pozwolić na niezależne sprawdzenie systemu
W przypadku ważniejszych systemów dobrze jest przewidzieć możliwość niezależnego sprawdzenia bezpieczeństwa przez inną firmę. Wykonawca nie powinien być jedyną stroną, która ocenia jakość własnej pracy.
Ważne jest również ustalenie, kto odpowiada za poprawienie znalezionych problemów. Jeżeli niezależny test wykryje poważny błąd wynikający z niewłaściwego wykonania systemu, trudno uznać za rozsądne, aby klient musiał kupować kolejne godziny pracy tylko po to, aby dostawca naprawił własny błąd.
Odbiór powinien obejmować więcej niż same funkcje
Odbierając projekt, łatwo skupić się tylko na tym, czy działa to, co widać. Formularz zapisuje dane, raport się generuje, użytkownik może wykonać swoją pracę, więc podpisujemy odbiór.
Warto jednak patrzeć szerzej. Odbiór powinien oznaczać również, że kod został przekazany, dokumentacja jest aktualna, potrzebne dostępy są po stronie klienta, system można uruchomić na podstawie posiadanych materiałów, wykonano wymagane testy i nie ma znanych poważnych problemów bezpieczeństwa.
Dopiero wtedy mamy pewność, że rzeczywiście odbieramy kompletny rezultat, a nie tylko działającą na dziś wersję programu.
Odpowiedzialność dostawcy powinna odpowiadać ryzyku
W kontraktach informatycznych często pojawiają się ograniczenia odpowiedzialności wykonawcy. Samo ich istnienie jest normalne, ale warto sprawdzić, czy są rozsądne.
Jeżeli dostawca ma dostęp do systemu zawierającego ważne dane firmy albo obsługującego kluczowe procesy, a jego maksymalna odpowiedzialność wynosi równowartość jednej miesięcznej faktury, może się okazać, że takie zabezpieczenie jest w praktyce symboliczne.
Nie każdy problem powinien być traktowany tak samo. Zwykłe opóźnienie w realizacji niewielkiej funkcji jest czymś innym niż utrata danych, ujawnienie informacji poufnych, poważne zaniedbanie bezpieczeństwa czy naruszenie cudzych praw autorskich. Odpowiedzialność powinna być rozsądna, ale również proporcjonalna do możliwych skutków dla biznesu.
Dobra umowa powinna działać również wtedy, gdy kończy się dobra współpraca
Podczas podpisywania kontraktu obie strony zazwyczaj zakładają, że współpraca będzie długa i udana. I bardzo dobrze. Problem w tym, że umowa jest najbardziej potrzebna właśnie wtedy, gdy sytuacja zaczyna się komplikować.
Dostawca może upaść, zostać sprzedany, stracić kluczowych pracowników albo znacząco podnieść ceny. Klient może również zdecydować, że chce rozwijać system samodzielnie albo z inną firmą. W każdej z tych sytuacji powinien móc bezpiecznie przejąć swoje rozwiązanie.
Dlatego przy kontraktowaniu oprogramowania warto zadać sobie nie tylko pytanie: „Czy dostawca stworzy dla nas dobry system?”. Równie ważne jest drugie: „Czy będziemy potrafili z niego korzystać i rozwijać go także bez tego dostawcy?”.
Jeżeli odpowiedź na oba pytania brzmi „tak”, jesteśmy znacznie bliżej dobrze zakontraktowanego projektu. Bo przy zakupie oprogramowania nie chodzi wyłącznie o to, żeby system działał dzisiaj. Chodzi również o to, żeby firma zachowała nad nim kontrolę jutro, za trzy lata i wtedy, kiedy współpraca z obecnym wykonawcą już się zakończy.
