Umowy w branży IT Jak je konstuować, żeby uniknąć późniejszych nieporozumień Tomasz Wiese Łukasz Marszał
Cel prezentacji Pokazanie różnic pomiędzy zakupem oprogramowania w pudełku a stworzeniu go na zamówienie Obalenie błędnych przekonań dotyczących tego, jak współpracuje się z informatykami Pokazanie możliwych sposobów zdefiniowania współpracy klienta z wykonawcą Zdefiniowanie sposobów zabezpieczenia interesów obydwu stron Pokazanie najlepszych sposobów na osiągnięcie wspólnego celu stworzenia produktu/systemu
Sprzeczne interesy? Klient Zamawiający oprogramowanie Posiada WIZJĘ Chce znać harmonogram i budżet Chce poświęcić jak najmniej własnej pracy Chce aby wykonawca samodzielnie przygotował specyfikację Chce egzekwować kary umowne za każde opóźnienie Chce łatwo móc przekazać projekt innemu wykonawcy Chce aby system/program działał niezależnie od środowiska i obciążenia obciążenia Wykonawca Firma IT Nie chce deklarować się co do terminów terminów Chce otrzymać komplet wymagań od od klienta Chce, w razie niekompletnych lub błędnych wymagań przenieść odpowiedzialność na klienta Chce współpracy z klientem przez cały cały czas trwania projektu Chce znać górne ograniczenia rozumiaru rozumiaru systemu (użytkowników, danych itp.) Zakłada, że część projektów się nie uda, uda, więc winduje ceny, żeby pokryć straty
Sprzeczne interesy? Klient nie jest informatykiem nie rozumie (i nie musi) specyfiki pracy wykonawcy. Klient (zazwyczaj) nie potrafi w sposób ścisły wyrazić, czego chce.
Współpraca Określony z góry zakres i cena Rozliczenie za całość lub etap Umowa o dzieło Płynny zakres Rozliczenie time&material Rozliczenie za iterację Umowa ramowa i wykonawcze Jeśli komuś się to nie podoba, to zawsze może stworzyć własny zespół umowa o pracę lub body-leasing.
ZWINNE (AGILE) Normatywność KLASYCZNE Podział metodyk Waterfall PRINCE2 RUP SCRUM XP
ZWINNE (AGILE) Normatywność KLASYCZNE Metodyki klasyczne Ustalone plany Praca zorientowana na zadania i procesy Dokładne planowanie i harmonogram Niska niepewność i ryzyko Średnie lub niewielkie zmiany Waterfall PRINCE2 RUP SCRUM XP
Wady i zalety Zalety: Znajomość całkowitego kosztu i czasu trwania projektu w fazie poczętkowej Niewielkie ryzyko zmiany harmonogramu Małe zaangażowanie w późniejsze fazy projektu Relatywna łatwość przekazania projektu innemu wykonawcy Wady Duże koszty początkowe Duże koszty zarządzania Niewielka możliwość zmian w projekcie Duże zaangażowanie w początkowej fazie projektu
ZWINNE (AGILE) Normatywność KLASYCZNE Metodyki zwinne Plany bardzo ogólne Praca zorientowana na produkty (Deliverables) Waterfall Product Backlog Stała współpraca z klientem Duże ryzyko czasowe i finansowe Duża podatność na zmiany PRINCE2 RUP SCRUM XP
Wady i zalety Zalety: Brak dużych kosztów początkowych Niewielkie koszty zarządzania Duża możliwość zmian w projekcie Duża kontrola nad dostarczanym produktem Łatwość częściowych dostarczeń Wady Trudny do oszacowania koszt Duże ryzyko zmian w harmonogramie Ciągłe zaangażowanie w projekt
Ograniczenia prawne Firma IT może zbankrutować Kary umowne najczęściej są ograniczone kwotowo lub procentowo w stosunku do wysokości wynagrodzenia Aspekty prawne Wynagrodzenie ryczautowe Wynagrodzeine kosztorysowe Autorskie prawa osobiste i zależne Problemy z użyciem zewnętrznych bibliotek
Stała cena i zakres Najczęściej proponowane przez prawników Podobne do projektów budowlanych: Jakiś architekt zrobi projekt (dokładna specyfikacja) Klient dostarcza projekt wykonawcy Klient przeprowadza odbiory i płaci Wykonawca płaci za każde opóźnienie względem harmonogramu Uwaga: domy budujemy od ponad 5 000 lat, a oprogramowanie od mniej niż 76 lat.
Stała cena i zakres Ryzyka: Klient: może dostać projekt zgodny ze specyfikacją, ale nie zgodny z tym, co potrzebuje ryzykuje, że projekt nie będzie w ogóle stworzony Wykonawca: brak zrozumienia klienta i wynikające z tego komplikacje eskalacja wymagań klienta Konflikt: wykonawca chce zrobić jak najmniej a klient jak najwięcej za podaną cenę Praktyka IT Głównie duże firmy Koszty ryzyk (w formie ceny) przeniesione na klienta
Time & Material Umowa (potencjalnie) bardziej korzystna dla firmy IT Wykonawca odpowiada za dostępność i kompetencje zespołu Wykonawca dostarcza w sposób ciągły weryfikowalne efekty swojej pracy Klient ściśle współpracuje z wykonawcą W regularnych odstępach specyfikuje funkcjonalności W sposób ciągły weryfikuje postępy prac Klient wpływa na zakres prac (w zależności od priorytetu i kosztów) przez cały czas projektu Dokładny zakres i czas trwania projektu nie jest ściśle zdefiniowany! Ostateczny koszt i czas wykonania projektu zależy w równej mierze od wykonawcy i klienta Projekt ewoluuje w trakcie jego trwania Klient płaci dokładnie za to, co zostało wykonane bez dodatkowych zysków ani strat
Time & Material Ryzyka: Projekt może ciągnąć się w nieskończoność albo zakończyć bardzo szybko Klient: Zna tylko przybliżony horyzont czasowy Zna tylko wizje projektu oraz wykonane elementy Trudniej przekazać rozpoczęty projekt innej firmie (zazwyczaj mniej dokumentacji) Wykonawca: Brak pełnego zaalokowania zasobów w danej iteracji Mała dojrzałość klienta Brak dodatkowych zysków z tytułu wcześniejszego zakończenia etapu Praktyka: Głównie nowoczesne firmy Szybsze reakcje na sytuacje kryzysowe Opór w środowisku prawniczym brak wypracowanych praktyk Zakłada dużą dojżałość po obydwu stronach Aktywna współpraca po stronie klienta Stałe obiążenie dla klienta
Statystyki Popularność podejść do wytwarzania oprogramowania. Źródło: pmresearch.pl
Statystyki Skuteczność podejść do wytwarzania oprogramowania. Źródło: pmresearch.pl
ATDD Acceptance Test Driven Development Story: Returns go to stock In order to keep track of stock As a store owner I want to add items back to stock when they're returned Scenario 1: Refunded items should be returned to stock Given a customer previously bought a black sweater from me And I currently have three black sweaters left in stock When he returns the sweater for a refund Then I should have four black sweaters in stock Scenario 2: Replaced items should be returned to stock Given that a customer buys a blue garment And I have two blue garments in stock And three black garments in stock. When he returns the garment for a replacement in black, Then I should have three blue garments in stock And two black garments in stock
Podsumowanie Umowy Time&Material są wg nas lepsze Nie wiemy, dlaczego się ich powszechnie nie stosuje...
Dziękuję za uwagę Tomasz Wiese Łukasz Marszał T:784076086 E: inime@inime.org NIP: 6751504218 REGON: 123131534 KRS: 0000512595 Adres: ul. Cystersów 13A/1, 31-553 Kraków