- dokonano przeglądu infrastruktury technicznej klienta.
W wyniku analizy powstaje raport przedwdrożeniowy, a w ujęciu prawnym „rodzi się” przedmiot umowy wdrożeniowej.
A może lepiej pójść na żywioł?
Taka pokusa aktualizuje się w dobie popularnych obecnie zwinnych metodyk zarządzania projektami IT (Agile). Skoro zamawiający nie wie, czego chce, a często nawet, czego właściwie nie chce, bo dynamicznie zmienia się otoczenie biznesowe, ewoluują wymagania klientów, a rozwój technologii jest gwałtowny, to poprzestanie na przedstawieniu dostawcy swoich motywacji i zarysu wizji biznesowej oraz budżetu do zakontraktowania. Dopiero podczas realizacji projektu, przy współpracy z dostawcą, dowie się, jakie właściwie funkcjonalności może otrzymać. Prace w takim projekcie najczęściej wykonywane są w ramach następujących po sobie sprintów, czyli etapów o ustalonej długości, trwających - dla uzyskania regularności - maksymalnie miesiąc. Metodyki zwinne to ziszczenie się pięknych snów specjalistów branży IT i przedstawicieli biznesu, bo zakładają bliską i efektywną współpracę, bieżące reagowanie na zmiany oraz minimum dokumentacji. Zarazem to koszmar prawników, bo nie definiują z góry, na co strony się umówiły.
Upieranie się, że nie ma tutaj miejsca na działania analityczne jest jednak wypaczeniem założeń tych metodyk. Okres przydatności szczegółowego raportu przedwdrożeniowego w jego tradycyjnym ujęciu jest bardzo krótki, zaledwie kilkumiesięczny. Techniki zwinne nie zakładają więc sporządzenia „u wrót” projektu kilkusetstronicowej dokumentacji zawierającej specyfikację abstrakcyjnego oprogramowania. Dobrą praktyką jest jednak spisanie w umowie przynajmniej głównych potrzeb zamawiającego oraz odpowiadających im kluczowych funkcji systemu. Konieczne jest też jednoznaczne ustalenie, jakie warunki muszą być spełnione, żeby prace na danym etapie uznać za wykonane (Definition of Done, DoD). Zdarza się, że strony rozpoczynają projekt zwinny od sprintu analitycznego prowadzącego do zdefiniowania zasadniczych założeń projektowych oraz określenia sposobów ich realizacji i kryteriów sukcesu. Warto odbyć kreatywne warsztaty Product Discovery z udziałem osób bezpośrednio zaangażowanych w projekt i pełniących w nim różne funkcje, jak również przyszłych kluczowych użytkowników wdrażanego systemu. Podczas takich warsztatów opracowuje się ogólną wizję rozwiązania, która znajduje wyraz w pierwszej wersji Backlogu będącego uporządkowaną i ewoluującą listą prac do wykonania.
Unikaj zbędnego ryzyka.
Niezależnie od metodyki prowadzenia projektu IT, bagatelizowanie działań analitycznych jest błędem. Stanowi jedynie pozorną oszczędność czasu i pieniędzy. Generuje natomiast poważne ryzyko prawne i biznesowe - i to nie tylko po stronie zamawiającego, który kupuje przysłowiowego kota w worku. Przykładowo, Sąd Apelacyjny we Wrocławiu, rozstrzygając w dniu 28 sierpnia 2013 r. na niekorzyść dostawcy sprawę przeciwko zamawiającemu o zapłatę wynagrodzenia (sygn. akt: I ACa 796/13), wskazał, że dostawca dedykowanego rozwiązania planowania zapotrzebowania zakupów nie zadbał, ażeby na etapie zawierania umowy została sporządzona osobna, szczegółowa specyfikacja spornego modułu.
Dopiero podczas realizacji projektu dopracowywano tę kwestię. W takim stanie rzeczy dostawca, który profesjonalnie zajmuje się wykonywaniem tego typu systemów, nie może skutecznie powoływać się na to, że wyłącznie po stronie zamawiającego leżały przyczyny i odpowiedzialność za to, że system finalnie nie został wykonany. Jeżeli dostawca podjął się wykonania umowy bez dokładnego określenia jej istotnych elementów (przedmiotu umowy), to wziął na siebie negatywne skutki takiego ułożenia relacji z kontrahentem.
