biznes
sklepy internetowe
strony internetowe
Dlaczego warto zaplanować i poświęcić odpowiednią ilość czasu na wypracowanie dokumentacji projektowej, jeśli zależy nam na sztywnej cenie zlecenia?
Rdzeniem każdego projektu powinna być dokumentacja projektowa. Niestety jest kilka powodów, przez które najczęściej Klientom proces ten wydaje się zbędny i chcieliby pomijając go jak najszybciej rozpocząć prace nad realizacją projektu. Wielokrotnie obserwowaliśmy smutne konsekwencje takiego podejścia. Obie strony powinny mieć świadomość, że dokumentacja projektowa jest kluczowym stadium projektu. Jeśli przemyśleniu projektu i przygotowaniu dokumentacji poświęcimy odpowiednią ilość czasu, to możemy zredukować lub całkowicie wyeliminować późniejsze niepotrzebne koszty i czas realizacji, a co za tym idzie, zaoszczędzić sobie sporo nerwów.
Korzyści płynące z wypracowania dokumentacji projektowej:
Co jest najczęstszym powodem niepowodzenia w realizacji projektów?
Od wielu lat działamy w projektach jako “Fuck-up Managerowie”, gdzie musimy ratować projekty, które z różnych względów zatrzymały się na pewnym etapie, często generując koszty lub będąc na granicy założenia sprawy sądowej przez jedną ze stron. Co łączy większość z nich? Najczęściej jest to właśnie niedopracowana dokumentacja projektowa, która została przygotowana w pośpiechu lub co gorsza, nierzetelnie. Projekty bazujące na takiej wadliwej dokumentacji kończą się z reguły sporem prawnym między zamawiającym a wykonawcą, ponieważ obie strony inaczej wyobrażały sobie wygląd lub działanie poszczególnych funkcjonalności, które zostały zakodowane.
Dyskusja na temat modeli współpracy w realizacjach w sektorze IT oraz dokumentacji projektowej
Poniższa relacja jest fragmentem rozmowy Łukasza Pacha, Dyrektora Zarządzającego i Współzałożyciela Agencji ADream oraz Pawła Sawickiego, Radcy Prawnego, Partnera z Kancelarii Sawicki & Sawicki z Krakowa. Rozmowa dotyczy współpracy stron przy projektach IT, modeli współpracy, dokumentacji projektowej, rozliczeń. Zapraszamy do lektury.
Łukasz:
Cześć Paweł miło mi się z Tobą spotkać i pomówić o różnych spojrzeniach na projekty IT .
Paweł:
Dzięki za zaproszenie. Również miło mi pomówić o projektach IT – mając na uwadze wasze realia. Mam nadzieję, że wspólnie uda nam się skonfrontować wzajemne doświadczenia, wyciągając z tego pozytywne wnioski. Łukasz, jak to zatem wygląda z Twojej strony?
Łukasz:
Paweł, gdy wchodzimy w projekty i próbujemy je prostować – a proszą nas o to zarówno zaprzyjaźnione agencje, jak i poirytowani klienci – to widzimy, że często klienci chcą poruszać się w sferze własnych, nigdzie nieopisanych standardów i tego co pojmują za standard, a coś takiego w IT nie istnieje. Przykładowo, klient zgłasza, że chce mieć rejestrację i wydaje mu się, że standardem jest już np. logowanie przez Facebook. Klientom często zaznaczam, że pewne kwestie nie są oczywiste.
Paweł:
Rozumiem. Czyli źródeł niedomówień, wątpliwości i sytuacji potencjalnie sporów upatrujesz głównie w trudności w zgodnym określeniu tego, co jako agencja macie realizować, a więc zakresu powierzanych prac, sposobu realizacji.
Łukasz:
Załóżmy sytuację, że Klient mówi chciałbym kupić FIATA Pandę. Udaje się do kilku agencji i sprawdza gdzie i ile kosztuje Fiat Panda. Znajduje Agencję która oferuje dla niego korzystną cenę i go zamawia. Agencja sprzedaje mu FIATA Pandę, a Klient mówi wtedy, że chciał FIATA Pandę z 2000 roku, a dostał rocznik 1995. Silnik to ma być 2.0, a nie 1.6. Agencja odpowiada na to: “ale przecież my sprzedajemy tylko auta z rocznika 95.” Jeżeli Klient chce Fiata Pandę z rocznika 2000, a tego nie doprecyzował, to dlaczego Agencja nie miała by mu dać auta z 1995 roku z silnikiem 1.6? Klient musi doprecyzować wszystkie swoje oczekiwania, jeśli chce działać w modelu Fixed Price. Jeżeli nie jest w stanie i potrzebuje doprecyzowywać pewne rzeczy na bieżąco i dopasowywać pewne elementy projektu w czasie jego realizacji, to najlepiej współpracować bazując na rozliczeniu godzinowym za wykonane prace np. z raportami rozliczeniowymi co tydzień lub co dwa tygodnie. My często dajemy klientom link do systemu z opcją podglądu czasu projektu w trybie rzeczywistym. Paweł zatem po czyjej stronie twoim zdaniem leży w takim razie odpowiedzialność za wypracowanie dokumentacji projektowej?
Paweł:
Przede wszystkim żadne przepisy prawa nie regulują wprost kształtu i elementów umów ze sfery IT. Pomijam tutaj aspekt autorski, gdyż nie o nim rozmawiamy. Wzajemne relacje stron takiej umowy (zamawiającego i wykonawcy) opierają się na dość ogólnych przepisach regulujących tzw. umowę o dzieło. Mając to na uwadze musimy przyjąć, że to przede wszystkim strony muszą określić, jak i co chcą realizować. Przy rozliczeniu fixed price (ryczałt) przedmiot umowy IT powinien być precyzyjnie określony już z chwilą jej zawarcia – a więc z jednej strony mówię tu o zakresie prac, z drugiej oczywiście o należnym wynagrodzeniu. Precyzyjna regulacja wzajemnych obowiązków stron będzie przede wszystkim w interesie klienta – gdyż to jemu głównie powinno zależeć, aby projekt był realizowany sprawnie i bez komplikacji. Jeżeli precyzyjne określenie nie jest możliwe z chwilą rozpoczęcia projektu, to model fixed price również nie będzie możliwy.
Łukasz:
Widzisz, problem w tym, że na przykład klienci oczekują, iż w zakładanych 80 godzinach wynikających z początkowej estymacji czasu potrzebnego na wykonanie prac – zostanie wykonane wszystko, aż do ich pełnego usatysfakcjonowania. Nie biorą tutaj jednak pod uwagę, że początkowa estymacja opierała się na wymaganiach i oczekiwaniach zamawiającego zgłoszonych wykonawcy jeszcze przed “startem projektu”. Niejednokrotnie natomiast, już w trakcie projektu i po podpisaniu umowy, wymagają oni rozbudowy funkcjonalności i serwisu o kolejne “nowe pomysły”, które pierwotnie przed projektem nie były uwzględnione. Powoduje to oczywisty wzrost nakładu pracy, a co za tym idzie również kosztów, które musi ponieść Wykonawca. Jednocześnie brakiem własnych sprecyzowanych wymagań z chwili startu chcą często obciążyć wykonawcę. Zdaniem części klientów, to Agencja ma zawsze wiedzieć, czego klient oczekiwał, chociaż w żaden sposób tego nie wyraził. Musielibyśmy tu raczej mówić o czytaniu w myślach, a na to – mimo szczerych chęci – nie jesteśmy gotowi przy opracowywaniu projektu. W naszym agencyjnym świecie mówi się o czymś takim jak “Polish Agile” – czyli “zlecam wszystko, elastycznie, do zadowolenia, ale cena ma być niezmienna” :). To tak nie może działać i w dojrzałej kulturze pracy, zwłaszcza z zachodnimi klientami, o takich problemach nikt nawet by nie pomyślał.
Paweł:
System rozliczeń może być oczywiście ukształtowany dowolnie – poprzez ryczałt (fixed price) lub kosztorys (time and materials). Wynagrodzenie może być określone w sposób mieszany, różne są też warianty i modele finansowania. Istotne są tu dwie kwestie. Przede wszystkim klient powinien sobie określić dopuszczalne ramy budżetowe. Przy wspólnym ustalaniu założeń oraz celów projektu, a w dalszej kolejności przy realizacji projektu, strony powinny mieć budżet cały czas na uwadze. Po drugie, zasady finansowania i idące za tym wynagrodzenie wykonawcy, powinny być dopasowane do sposobu, w jaki realizowany jest dany projekt. Czysty ryczałt (fixed price) sprawdzi się zazwyczaj przy prostych projektach, względem których nie zachodzi ryzyko zmian lub rozbudowy systemu, a klient dostarczył szczegółową specyfikację swoich wymagań lub szczegółową dokumentację projektową. W przypadku, gdy projekt jest rozbudowywany na bieżąco lub jest realizowany bez ścisłej specyfikacji, zwłaszcza w elastycznym podejściu “agile” – nie sposób jest określić wynagrodzenie jako niezmienne i ryczałtowe. W takim przypadku właściwym miernikiem jest głównie ilość czasu (godzin) poświęcona przez zespół specjalistów pracujących nad projektem. Można się umówić również w ten sposób, że dany projekt będzie w wersji bazowej kosztował określoną ryczałtową kwotę, a kolejne dodawane w trakcie elementy będą dodatkowo wyceniane lub rozliczane stawką godzinową. W umowie trzeba jasno określić sposób ustalenia wynagrodzenia, a zwłaszcza – jeśli nie jest to czysty ryczałt – jaka będzie bazowa stawka za każdą godzinę pracy.
Łukasz: Z punktu widzenia zamawiającego, jaką warto posłużyć się zatem metodą rozliczenia? Czy metoda rozliczenia zgodnie z rzeczywistymi nakładami (kosztorysowa, time and material) da się łatwo kontrolować? Co wychodzi korzystniej cenowo?
Paweł: Trzeba sobie przede wszystkim jasno odpowiedzieć, czy jako zamawiający wolimy projekt realizować elastycznie i zaoszczędzić na przygotowaniu kosztownej dokumentacji projektowej (a co jeśli założenia projektu zmienią się w trakcie i dokumentacja nie będzie możliwa do prostej korekty?). Czy też realizujemy projekt etapami lub elastycznie (oszczędzając na szczegółowych działaniach analitycznych i projektowych) rozliczając projekt według faktycznych działań i nakładów. Podkreślę natomiast, że elastyczne podejście nie oznacza braku kontroli nad budżetem. Ta jest zawsze potrzebna i często, zwłaszcza w rozbudowanych organizacjach, podlega ścisłym procedurom wydatkowym i kontrolnym. Również należy zauważyć, że projekt realizowany kosztorysowo bazujący na stawce godzinowej nie oznacza, że jesteśmy pozbawieni kontroli – lub obrazowo ujmując – pływamy po oceanie nie znając jego granic i kresu. Po pierwsze mamy budżet – a więc wszystkie działania powinny być do niego dopasowane. Po drugie, profesjonalnie przygotowany zespół jest w stanie przygotować tzw. estymacje np. określić z góry przewidywany czas, który jest potrzebny na realizację określonych prac lub elementów projektu. Z drugiej strony, zamawiający dokładając kolejne cegiełki do projektu, których początkowo nie wymagał, musi liczyć się z koniecznością dodatkowego rozliczenia. Na taki wypadek lepiej dysponować pewnym marginesem w ramach budżetu (założyć wyższy budżet) – licząc się z tym, że pojawią się nowe i nieprzewidziane elementy wymagające rozliczenia. Lub też można – uznając, że zachodzi priorytet dla prac dodatkowych – zrezygnować lub zabudżetować na kolejny okres inne, mniej pilne prace. Mogę dodać, że rozliczenie Time and Materials może wyjść zdecydowanie taniej niż rozliczenie fixed price (ryczałt). Przede wszystkim można zaoszczędzić na skomplikowanej dokumentacji przedprojektowej i projektowej. Przeważnie też wykonawca będzie przy fixed price proponował wyższą kwotę, gdyż zazwyczaj zakłada spory margines na działania nieprzewidziane. Każdy projekt jest inny i każdy obarczony jest innymi ryzykami. Dlatego dobrze jest zastanowić się nad zasadami współpracy i rozliczeń. Następnie te wszystkie warunki muszą być jasno określone w umowie.
Łukasz: Czym twoim zdaniem szczególnym cechują się projekty IT?
Paweł: Zazwyczaj, jeśli nie mówimy o zakupie licencji na gotowy prosty produkt (np. programu biurowego), mamy do czynienia z pewnym rozbudowanym w czasie procesem wykonawczym, lub patrząc od strony zamawiającego, procesem inwestycyjnym. Do tego proces ten dotyczy dóbr nie tak oczywistych i namacalnych, jak dobra materialne (np. pojazdy i budynki). Mówię tu nawet o takich działaniach, jak wydawać by się mogło zakup gotowego oprogramowania ERP od światowych producentów. Takie oprogramowanie wymaga zazwyczaj skomplikowanego wdrożenia (dostosowania bazowego oprogramowania do potrzeb konkretnego przedsiębiorstwa). Powiedziałbym, że pełna świadomość tego oraz wzajemne zrozumienie i precyzja w uzgodnieniach – są szczególnie ważne w branży IT. Na przykład w branży budowlanej – z uwagi na zdecydowanie namacalny rezultat prac, ścisłe zasady projektowania i wznoszenia konstrukcji – pojawi się rzeczoznawca budowlany, który powie jakie dokładnie roboty zostały wykonane, jakich użyto materiałów i jakie są cenniki (za pomocą standaryzowanych kosztorysów). W branży IT i projektach IT ciężko te normy określić. Musimy tu uwzględnić kilka kwestii. Trudno jest jednoznacznie powiedzieć, dlaczego osoby na takich samych stanowiskach i z takim samym doświadczeniem, jako np. back-end lub front-end developer pracują szybciej lub wolniej i co jest tego dokładną przyczyną. Dodatkowo do tych samych efektów można dojść różnymi drogami z różną efektywnością. Szybciej nie oznacza też zawsze lepiej. Podam przykład. Dwa programy mogą pozornie działać tak samo. Jednakże program wykonany precyzyjniej (z większym nakładem lub przez lepszego specjalistę) może być zoptymalizowany lepiej, co w przypadku działalności np. handlowej może być niezwykle istotne i przekładać się na realne pieniądze. Nie wspomnę już o zapewnieniu bezpieczeństwa danych, walidacji procesów – których to efektów na pierwszy rzut oka w ogóle nie widać, a ewentualne kłopoty z tym związane mogą być niezwykle kosztowne. Kolejna kwestia, to fakt, że działania i projekty IT są efektem niewątpliwie pracy twórczej. Nie bez powodu kod komputerowy i prace programistyczne mają swoją regulację w ustawie o prawie autorskim i prawach pokrewnych.
Łukasz:
Chciałbym, abyśmy chwilę z tej rozmowy poświęcili precyzji uzgodnień. Co się stanie, gdy takiej precyzji zabraknie?
Paweł:
Tu odpowiedź jest dość prosta, proste nie są natomiast rozwiązania takich sytuacji. Jeżeli mamy do czynienia z różnymi zdaniami po obu stronach, to rodzi nam się ryzyko sporu (konfliktu). Jeśli strony same nie dojdą do porozumienia, to naturalną konsekwencją jest konieczność zdania się na rozstrzygnięcie sądowe (sąd powszechny lub arbitrażowy). Zwiększa to oczywiście koszty, a zwłaszcza nie zbliża to stron osiągnięcia celu, z uwagi na który podjęły współpracę. W szczególnie trudnej sytuacji jest zamawiający, to przecież on czeka na gotowe zamówienie – spór rodzi zazwyczaj niepewność co do losów projektu.
Łukasz:
A co jeśli zapisy mimo precyzji budzą kontrowersje? Lub na przykład jedna strona chce je rozumieć inaczej, niż druga?
Paweł:
Często zdarza się, że pomimo precyzji umowy zaistnieje spór. Oczywiście sytuacja taka będzie miała miejsce, gdy to wykonawca umowy nie zrealizuje (podejmie się działania i pomimo należytego finansowania umowy nie wykona lub nie wykona jej w całości). Inną kwestią jest, że to rozliczenia niejednokrotnie powodują spory – zwłaszcza, gdy strony bazują na stawkach godzinowych. Oczywiście w aspekcie procesowym – należy ustalić tzw. zgodny zamiar stron. Umowa jest jedna i nie ma mowy o tym, aby były jej dwie wersje. Gdy strony inaczej rozumieją zapisy umowy, to sąd ustali właśnie ten zgodny zamiar i właściwą treść, rozumienie i sens umowy.
Zasadniczo dochodzimy tu do wszystkich zagadnień, o których wyżej rozmawialiśmy. Z uwagi na swój charakter, brak tego wprost namacalnego materialnego efektu, ocena efektów prac bywa różna. Dlatego podkreślę, co powiedziałem wyżej, że przy projektach IT należy mieć świadomość uwarunkowań dla danego projektu, kierować się wzajemnym zrozumieniem oraz być precyzyjnym na tyle, na ile to możliwe w ramach danego modelu współpracy. Wracając tu do rozliczenia godzinowego, to jest ono dobrym miernikiem – dlatego jest powszechnie stosowane (lepszej i prostszej miary nakładu pracy do tej pory nie wymyślono – i mówię tu nie tylko o działaniach IT). Dla ułatwienia rozliczeń godzinowych powstały dedykowane programy służące ich liczeniu i raportowaniu. W tym kontekście również istotna jest rola kierownika projektu (project manager), który stosując właściwy dla organizacji model zarządzania, również ma wpływ na efektywność pracy (a więc i raportowane klientowi nakłady). Niemniej zdarza się, że rozliczenia są kwestionowane. Zamawiający zadaje sobie pytanie, czy takiej pracy nie można wykonać po prostu szybciej? Oczywiście możliwe jest, że gdzieś znajduje się firma lub specjalista, który byłby w określonych warunkach w stanie wykonać daną pracę szybciej. Zawsze znajdzie się ktoś szybszy – mistrz może być przecież tylko jeden. Niemniej tu musimy zdać się na pewien rozsądek i w ramach tego uwzględnić fakt, że każdy z nas pracuje z różną szybkością. Nie oznacza to, że tylko najszybszemu należy się wynagrodzenie. Mogę podać przykład orzeczenia, gdzie sąd ustalił, że dany specjalista przepracował określoną ilość godzin, zaś druga strona zarzekała się, że jest to niemożliwe i stanowczo przekroczono czas w jakim praca powinna zostać wykonana. Sąd orzekł jednak, że jedni pracują wolniej, a inni szybciej i jest to naturalne. Nieco tu upraszczam – celowo – ale po prostu taki był wydźwięk wskazań sądu.
Łukasz:
Ja mogę podać przykład, gdzie klient miał spisaną z wykonawcą umowę na realizację dedykowanego synchronizatora. Została ona zrealizowana w niecałe 100 godzin dokładnie w sposób, w jaki była początkowo nakreślona. Następnie klient zaczął rozbudowywać dokumentację projektową i im dalej byliśmy w projekcie, tym więcej prac dodatkowych było przez niego zlecanych, aż do jego pełnego zadowolenia. Nie ukrywam, że agencja dla której pracowaliśmy spisała ze swoim klientem dość frywolną umowę. Działaliśmy dla agencji, która stała się zakładnikiem swojego klienta. Agencja otrzymywała kolejne listy roszczeń, które ciągle rosły i w ten oto sposób z 50 godzin prac dodatkowych zrobiło się ich nagle 300. Wyzerowanie oczekiwań ciągle skutkowało kolejnymi oczekiwaniami i następnymi pracami. Niestety nasz zleceniodawca zgadzał się za każdym razem na ich spełnienie, ale informowaliśmy każdorazowo, że wszystkie kolejne prace są pracami dodatkowymi i rozlicza je godzinowo za każdą następną przepracowaną godzinę. Przypadek Pendolino i WI-FI, w którego w nich przez kilka lat nie było, jest tutaj idealnym zwierciadlanym przykładem – niby dla wszystkich wydaje się być oczywiste, że powinno być, ale nie było tego w specyfikacji projektowej i dlatego finalnie go nie było. Tak samo wygląda to w przypadku IT.
Paweł:
Ciężko jest mi się odnosić do konkretnego przypadku bez wglądu w dokumentację i zaznajomienie się ze sprawą – niemniej mogę stwierdzić, że jeśli dane prace nie były przewidziane przy zawarciu umowy (strony nie umówiły się na ich wykonanie), to oczywiście nie ma powodu, aby wykonawcy nie należało się dodatkowe wynagrodzenie za ich realizację. Dlatego tak istotne jest określenie zasad współpracy, w tym przedmiotu umowy, modelu współpracy, zasad rozliczeń. Wygląda na to, że wasz zleceniodawca nie zadbał o właściwe uzgodnienia z zamawiającym lub niewłaściwie zinterpretował umowę (intencjonalnie bądź nie). Być może należało mu się dodatkowe wynagrodzenie, z którego po prostu zrezygnował. Jeśli natomiast mowa o przywołanym przez Ciebie Pendolino i braku Wi-Fi, to będzie tu nieco inna sytuacja, gdyż mówimy tu o zamówieniu publicznym w ramach procedury przetargowej. Inny też jest sam charakter przedmiotu dostawy. Niewątpliwie natomiast (abstrahując od tego konkretnie zakupu składów Pendolino) specyfikacja istotnych warunków tego rodzaju zamówień jest niezwykle rozbudowana. W ramach takich zamówień, to warunki dyktuje zazwyczaj zamawiający i on określa, czego potrzebuje. Jeśli w jego dokumentacji przetargowej brakuje np. Wi-Fi, to jest oczywiście możliwe, że oferta nie będzie tego Wi-Fi uwzględniać. Jest to czynnik cenotwórczy, a skoro zamawiający tego nie wymaga, to nie ma powodu go oferować. Ale jak wspomniałem – zakup odbywał się w ramach przetargu publicznego – co również zmienia warunki gry. Wracając jednak, do zamówień IT, jeśli odbywa się ono między dwiema prywatnymi firmami, to można zrezygnować z przygotowania szczegółowej dokumentacji zamówienia i wybrać elastyczny model współpracy. Dokumentacja może obejmować setki stron i jest oczywiste, że jej przygotowanie kosztuje (czy miałby ją przygotować zamawiający, czy wykonawca – i tak jej przygotowanie jest kosztowne, a koszt musi ktoś ponieść). Zatem można podejść do zamówienia elastycznie tworząc mniej precyzyjną dokumentację (jest to typowy przypadek). Jeśli na tym tle dojdzie do sporu, a więc zwłaszcza, czy dany zakres prac mieścił się w ramach pierwotnej umowy, czy nie, to niestety przepisy Kodeksu cywilnego nie zawierają tu gotowych prostych rozwiązań. Zobowiązanie powinno być wykonane zgodnie z jego treścią, celem społeczno-gospodarczym, zasadami współżycia społecznego, zwyczajami. W aspekcie zaś procesowym, to strona która idzie do sądu i wytacza powództwo musi udowodnić, że ma rację. Na przykład, to niezadowolony zamawiający musi udowodnić wykonawcy, że dany element miał być, a go nie ma. Bez szczegółowej dokumentacji może być to niemożliwe lub utrudnione. Należy założyć natomiast, że wszystkie elementy, które nie są konieczne dla spełnienia warunków zamówienia i nie były zastrzeżone w umowie będa nowym zamówieniem lub pracami dodatkowymi. Dlatego warto zadbać o odpowiednie zapisy w umowie – nawet w przypadku, gdy projekt jest realizowanu elastycznie bez szczegółowej dokumentacji projektowej.
Łukasz:
Chcąc pracować zatem sprawnie i elastycznie, korzystając właśnie z otwartego modelu współpracy – jak zatem wyważyć interesy obu stron?
Paweł:
Jeśli mowa o wynagrodzeniu, to jak wspomnieliśmy przy otwartym modelu współpracy bez szczegółowej dokumentacji, nie będzie ono zazwyczaj możliwe do określenia na zasadzie fixed price (ryczałtowo), chyba że mowa o prostych pracach lub gotowych w dużej mierze rozwiązaniach (sprzedaż przygotowanych produktów lub bazujących na sprawdzonych szablonach lub modelach). Wykonawca w każdym razie musi być pewny w takim wypadku, że sprzedaje swój sprawdzony produkt i w danej cenie jest w stanie go wdrożyć u zamawiającego. Inaczej nie ma to sensu. W przypadku zaś pracy na zasadzie time and material klient musi zaakceptować, że wynagrodzenie bazuje na zmiennych. Oczywiście możliwe są tu do wprowadzenia bezpieczniki, sposoby raportowania, zobowiązania do nieprzekraczania budżetów miesięcznych itp.
Jeśli chodzi zaś o wykonanie, jego zakres, to przy modelu opartym w całości na stawkach godzinowych nie ma większego problemu. Klient płaci, tyle ile zajęło wykonanie dzieła. Jeśli zaś klient wymaga fixed price, to nie może się dziwić, że wykonawca będzie kwestionował zakres oczekiwanych prac, jeśli te nie były pierwotnie wyraźnie przewidziane i nie są one określonym koniecznym standardem. Tu nie ma marginesu na domysły. Zamawiający powinien wykazać, że dany element zamówił i powinien on być uwzględniony przy wykonaniu. Służy do tego dokumentacja (minimum to np. wymagania zamawiającego, makiety albo analizy). Jeśli to wykonawca ma wspomóc zamawiającego z przygotowaniem dokumentacji, to zazwyczaj będzie to element przygotowawczy wymagający oddzielnego rozliczenia. Strony mają dużą elastyczność, konieczne jest, aby były precyzyjne i nie traktowały umowy, jako niewiele nieznaczącą formalność.
Łukasz:
To prawda, w przypadku o którym mówiłem z synchronizatorem, to dokumentacja, która została wstępnie przygotowana uwzględniała założenia i wymagania zamawiającego, ale w żadnym wypadku nie doprecyzowała kolejnych oczekiwań, które pojawiły się w trakcie realizacji całego projektu. Klient podpisał taką dokumentację, a później chciałby rozbudowywać cały czas projekt o zakres funkcjonalności, co do których ta dokumentacja w ogóle się nie odnosiła.
Paweł:
Aby temu zapobiec potrzebna jest z pewnością solidna rozmowa o zasadach współpracy i rozliczeń. Obie strony muszą wiedzieć na co się piszą. Jeśli jednak wymagane jest ze strony klienta fixed price, to musi on na poważnie brać pod uwagę klauzulę w umowie, że: “Warunki techniczne, wymagania lub funkcjonalności, które nie są uwzględnione w zamówieniu, ofercie lub dokumentacji projektowej, nie stanowią elementu zamówienia i będą realizowane jako prace dodatkowe.”. Natomiast wracamy tu do problemu należytego przygotowania zamówienia, dokumentacji projektowej.
Łukasz:
Dokładnie, powiedz proszę, czy z twojego doświadczenia, sąd patrzy tylko na to czy w zrealizowanym projekcie jest funkcja rejestracji poprzez jakiś konkretny ściśle określony przycisk lub element systemu, czy też patrzy na to tylko ogólnie przez pryzmat samej funkcjonalności – jest rejestracja? jest, a więc Wykonawca wywiązał się ze swoich obowiązków.
Paweł:
Przede wszystkim sąd nie jest specjalistą do oceny rozwiązań technicznych i technologicznych. Zawsze w takich sprawach wypowiada się biegły sądowy, a więc osoba o kompetencjach w danej dziedzinie. Prawidłowość wykonania umowy należy również oceniać z szerszego punktu widzenia niż literalny zapis. Ciężko byłoby oczekiwać od biegłego akceptacji wykonania umowy zrealizowanej zgodnie z wymaganiami zamawiającego, jednakże w technologii sprzed 15 lat nieobsługiwanej przez dzisiejsze serwery, nawet jeśli technologii z jakiś przyczyn wprost nie wpisano w umowę. Jeśli jednak zamówienie zostało zrealizowane funkcjonalnie, odpowiada dzisiejszym standardom i uwzględnia wytyczne wskazane przez zamawiającego – to nie ma powodu odmawiania wykonawcy prawidłowości realizacji umowy. Jeśli zaś z powodu indywidualnych upodobań zamawiającego nieuzasadnionych wskazanymi przed chwilą motywami – zamawiający żąda przebudowania systemu (ten samo, ale inaczej) albo żąda dodania nieprzewidzianych elementów, funkcjonalności, interakcji – to takie jego żądanie nie będzie usprawiedliwione i nie mieści się w zakresie obowiązków wykonawcy (czyli nie będzie wchodziło to w zakres jego umowy).
Łukasz:
Czego można oczekiwać od klienta, jeżeli po wykonaniu umowy twierdzi on, że prace mu się po prostu nie podobają i nie dokona ich odbioru oraz nie zapłaci.
Paweł:
Nie ma to tak naprawdę znaczenia. Odbiór prac nie jest konieczny, o tyle o ile projekt faktycznie został przez wykonawcę należycie zrealizowany. Obowiązek zapłaty powstaje przez sam fakt, że wykonawca zrealizował swój zakres obowiązków. Oczywiście zasady rozliczeń mogą być ściśle uregulowane przez strony, w szczególności zasady finansowania projektu w toku. Jeżeli przyjęty harmonogram płatności nie jest realizowany, to zamawiający powinien liczyć się ze wstrzymaniem prac z jego winy, a nawet z odpowiedzialnością odszkodowawczą wobec wykonawcy.
Łukasz:
A co o tym, jak ma coś zostać wykonane mówi prawo? Co z tym, że klient twierdzi, że chce, aby coś działało inaczej mimo, że patrząc zero jedynkowo, jest to zrobione?
Paweł:
Tak jak wspomniałem wyżej, jeśli zamówienie jest funkcjonalne, odpowiada dzisiejszym standardom i odpowiada wytycznym wskazanym przez zamawiającego – to nie ma powodu odmawiania wykonawcy prawidłowości realizacji umowy. Tym samym nie ma on obowiązku wykonywania prac ponownie, ale w inny sposób. Jeśli już, to należy mu się wówczas dodatkowe wynagrodzenie.
Projekty typu przeglądarkowego, zwłaszcza skierowane do klientów naszego zamawiającego, wymagają często przemyślenia oprawy graficznej, ergonomii użytkowania itp. Tu wkraczamy w obszar prac, których ocena może być zależna od indywidualnego gustu i upodobań. Nasz zamawiający może mieć na ten temat zupełnie inne zdanie niż my. Dlatego ważne jest wzajemne współdziałanie stron w toku realizacji projektu. Zamawiający powinien brać czynny udział w kolejnych etapach. Powinien akceptować projekty graficzne, mapy stron itp. Z założenia powinno być to wystarczające zabezpieczenie i powinno to minimalizować ryzyko, że ostateczny efekt nie będzie w tej warstwie odpowiadał zamawiającemu. Niemniej z gustami ciężko dyskutować i sąd również nie będzie z nimi dyskutował. Jeśli coś się po prostu nie podoba zamawiającemu, a odpowiada wyżej wskazanym warunkom, to nie zajdą podstawy, aby kwestionować prawidłowość wykonania prac. Prawo tak daleko nie wkracza. Jeśli mamy dwóch malarzy, lepszego i gorszego, nie oznacza to, że za obraz namalowany przez tego słabszego nie należy zapłacić. Tutaj odgrywają rolę już wyłącznie mechanizmy rynkowe i renoma firm. Firma, której klienci są zadowoleni, z pewnością ma szansę na większy sukces rynkowy, niż konkurencja.
Łukasz:
Paweł bardzo ci dziękuję za nasze spotkanie i przedstawienie swojego spojrzenia.
Paweł:
Dzięki Łukasz było mi bardzo miło się spotkać.
Powyższa rozmowa pokazuje jak ważna w realizacji projektów jest doprecyzowana dokumentacja projektowa, jeżeli zależy nam na otrzymaniu konkretnej oferty ryczałtowej za realizację zlecenia. Jeżeli natomiast nie jesteśmy w stanie wypracować takiej dokumentacji i chcemy zachować pełną elastyczność założeń w projekcie odpowiedzią jest rozliczenia typu Time & Materials. W ADream uważamy dokumentację projektową za podstawę udanej współpracy przy projektach IT. Jeżeli planujesz zlecenie realizacji strony lub sklepu internetowego napisz do nas lub wypełnij jeden z naszych briefów, a pomożemy dobrać odpowiedni rodzaj rozliczeń do Twojego projektu.
