Klienci firm IT co do zasady lubią mieć zamknięte budżety, chcą wiedzieć że poszczególne projekty nie przekroczą określonej przez dyrektorów finansowych górnych pułapów budżetu. Działa to trochę jak w branży motoryzacyjnej, księgowi decydują o wszystkim 😉

To problem bardzo często występujący w praktyce moich klientów i zdarza się że jest przyczyną wielu nieporozumień i konfliktów.

Zacznijmy jednak od początku, czym różni się Fixed Price od Time & Material ?

Zacznijmy od Fixed Price, w dużym skrócie sprowadza się to do modelu wynagrodzenia ryczałtowego, od początku jako zamawiający znamy budżet. Nie ważne co dzieje się w trakcie projektu, dodatkowe wynagrodzenie dla wykonawcy nie należy się. Z góry znamy zakres pracy i harmonogram. Często używa się porównania, że praca jest w tym przypadku wykonywana wodospadowo.

Tak jak pisałem, ta metodyka pracy jest popularna, ale ma też istotne wady. Logicznie rzecz biorąc nie leży przecież w interesie wykonawcy pokazywanie, po etapie analitycznym, klientowi zbyt dużo. Nie daj Boże dojdzie do rozszerzenia zakresu prac, a nikt nie lubi robić w tej samej cenie więcej niż na początku założył. Walka zaczyna się na etapie odbioru oprogramowania 🙂

Alternatywą jest metodyka pracy określana jako Time & Material, jest to przyrostowa metodyka zarządzania projektami. Projekt jest dzielony na mniejsze części tzw. sprinty lub itercje. Każdy sprint jest przedmiotem analizy, testów, i finalnie dany pakiet jest instalowany na instancji produkcyjnej klienta. To warunek przejścia z pracami dalej. Co istotne jednak, jest to bardzo partnerski model zarządzania projektem. W tym przypadku tworzony jest zespół z przedstawicieli obu stron, wymagane jest więc po stronie zamawiającego odpowiedni zaplecze IT. Wymagania zamawiającego często ewoluują, na bieżąco testowane są określone rozwiązania. W takim wypadku siłą rzeczy, nie ma zamkniętego budżetu, wynagradzane są poszczególne etapy prac, w zależności od sumy stawek godzinowych zespołu projektowego.

Moje doświadczenie z obsługi kilku firm z branży IT wskazują na przewagę modelu T&M. Zdarza się że projekt startuje jako Fixed Price, jednak zamawiający dojrzewa w toku prac, uznając wyższość modelu T&M, choć ostatnio zaliczyłem casus odwrotny, dla prawnika to mały koszmar 🙂

Photo Credit: Umberto Fistarol via Compfight cc

W poprzednim wpisie pisałem o tym, że proces powstawania oprogramowania na zamówienie (lub dostosowanie już istniejącego) jest wieloetapowy, co siłą rzeczy znajduje swoje odzwierciedlenie w umowach regulujących te kwestie.

Niniejszy wpis ma za zadanie pokazać Ci jak wyglądają poszczególne etapy, ze szczególnym uwzględnieniem określenia wymagań użytkownika.

Informatycy cykle życia oprogramowania określają następująco:

1. Określenie wymagań użytkownika,
2. Wytworzenie oprogramowania,
3. Wdrożenie,
4. Eksploatacja,
5. Serwis

Jest to tym samym rozkład jazdy dla każdego projektu IT.

Jak widzisz, etapem wyjściowym jest określenie wymagań użytkownika. Ma to sens. Najpierw, bowiem należy zidentyfikować potrzeby klienta, a więc: jaki jest cel powstania oprogramowania, jakie ma ono spełniać zadania, jak ma być używane (prostota obsługi, interfejs, szybkość działania), oraz w końcu zapewnić zgodność z innym oprogramowaniem działającym już u klienta (system operacyjny, inne oprogramowanie współpracujące).

Oprogramowanie, tak jak większość rzeczy, nie może funkcjonować w próżni. Dlatego też następnie przeprowadzane jest tzw. studium wykonalności, tj. ustala się i uwzględnia aspekty organizacyjne klienta, ludzkie, ekonomiczne i wiele innych.

Efektem powyższych działań jest utworzenie dokumentu – specyfikacji wymagań użytkownika. Dokument ten ma fundamentalne znaczenie w dalszych pracach, on zawiera wszystkie założenia, uwarunkowania i szczegóły. To jest, bowiem ten wzór do osiągnięcia, którego firma IT dąży, wykonując zlecenie.

Niestety często zdarza się tak, że w toku prac, po stronie klienta pojawiają się nowe pomysły i kwestie, które nie były pierwotnie brane pod uwagę.

Praktyka wtedy jest dwojaka: albo strony starają się udokumentować te nowe ustalenia w jakiejś formie, (co niestety, prędzej aniżeli później „rozjedzie” nam się z całą resztą), albo też, i to jest wzór do którego powinno się dążyć, należy powtórzyć w niezbędnym zakresie etap 1 opisany powyżej  i to dla dobra obu stron.

Niestety, jak to często w życiu bywa, problemem są pieniądze. Musisz, bowiem pamiętać, że prace firmy IT opisane wyżej, czyli określenie wymagań użytkownika, jest odpłatne, co jest zrozumiałe, bo angażuje zasoby tak czasu jak i pracowników wykonawcy. A nikt nie chce płacić dwa razy za (teoretycznie) to samo, nawet jak konieczność poniesienia tego kosztu jeszcze raz leży po stronie klienta.

Ok wstęp, zatem mamy za nami.

W kolejnym wpisie opiszę Ci kolejne zagadnienie, które często jest przyczyną wielu konfliktów przy projektach związanych z oprogramowaniem, tj wybór konkretnej metodyki pracy firmy IT, co ma bardzo duże znaczenie na wiele istotnych kwestii, w tym zasady ustalania wynagrodzenia.

Photo Credit: Arenamontanus via Compfight cc

Dzisiejszym wpisem chciałbym zapoczątkować serię artykułów dotyczących praw autorskich w branży IT, w tym głównie w zakresie umów o stworzenie oprogramowania lub dostosowania już istniejącego oprogramowania do potrzeb klienta.

Temat jest z pewnością rozwojowy, a mając na uwadze fakt, że obsługuję firmy działające w tej branży, w tym także te o zasięgu międzynarodowym, to i miałem już do czynienia z ciekawymi przypadkami, o których mam nadzieję Ci napisać.

W pierwszej kolejności należy sobie uzmysłowić, że rzadko, kiedy mamy do czynienia jedynie z umową o stworzenie oprogramowania (np. w postaci umowy o dzieło). Najczęściej są to dwojakie sytuacje: albo jest to jedna umowa, swoistego rodzaju kontrakt mieszany, albo w drugim przypadku jest to zbiór umów.

Od strony praktycznej, nie ukrywam, że bardziej przejrzysta jest sytuacja druga: tj. sytuacja, w której poszczególne etapy pracy są dzielone na odrębne dokumenty. Najczęściej, bowiem jest tak, że klient trafia do firmy IT z polecenia, dochodzi do spotkania, czynione są wstępne założenia, następnie dochodzi do analizy sytuacji u zamawiającego, czyli w dużym uproszczeniu firma IT wykonuje swoistego rodzaju audyt u potencjalnego klienta. Dopiero dysponując wiedzą wynikającą z takiego audytu, może dojść do przedstawienia oferty i określenia ram współpracy. Przy założeniu porozumienia obu stron, dochodzi do zawarcia faktycznej umowy, bądź też umowy wdrożeniowej w przypadku dostosowywania już istniejącej umowy do potrzeb klienta.

Bardzo często takim umowom towarzyszą inne umowy np. serwisowe, umowy w zakresie programu szkoleń (ponad z góry określony darmowy pakiet), umowy hostingowe i inne. Wiele też zależy od metodyki pracy firmy IT, czy jest to tzw. Time and Material czy też tzw. SCRUM, to bowiem wpływa na mnóstwo kwestii związanych z zasadnością poszczególnych roszczeń.

To tyle jeśli chodzi o ogólny zarys tematyki, w kolejnych wpisach rozwinę temat.

Photo Credit: qthomasbower via Compfight cc