Jak kończyć na czas projekty internetowe

,,Żaden plan nie wytrzymuje kontaktu z wrogiem” — von Moltke
,,Plany są niczym, planowanie wszystkim” — Dwight D. Eisenhower
,,Inżynierowie zawsze mówią prawdę, chyba że pytanie dotyczy czasu” — Scott Adams

Przy pracy nad projektami internetowymi pojawiają się trzy rodzaje problemów. Najmniej ważne są problemy techniczne, najbardziej komunikacyjne i te związane z umową, czyli różnymi interesami klienta i wykonawcy.

Częstym źródłem nieporozumień jest to, że dla laików zrobienie dziesięciu podobnych stron powinno zajmować i kosztować z grubsza dziesięć razy tyle, ile zrobienie jednej (z ewentualną zniżką hurtową). Tymczasem w rzeczywistości, jeżeli strony różnią się tylko elementami tworzonymi automatycznie, to zrobienie stu stron trwa tyle, co zrobienie jednej, która jest szablonem. Natomiast jeżeli szczegóły różniące strony wymagają stworzenia nowego szablonu, to może się okazać, że zrobienie dwóch stron zajmuje pięć razy tyle, co zrobienie jednej, w zależności od skomplikowania nowego szablonu.

Dlatego często klienci przecierają oczy ze zdumienia, że pozornie taka sama praca może zająć tydzień i kosztować tysiąc złotych, albo trzy miesiące i kosztować sześćdziesiąt tysięcy złotych w zależności od tego, czy chcą mieć jakiś niepozorny przycisk na stronie.

Dobry szef projektu będzie tak pracował ze zleceniodawcą, żeby wybrać do realizacji te szablony i stories (więcej piszę o tym dalej), które dadzą najlepszy efekt biznesowy.

Projekty internetowe, jak to projekty związane z programowaniem, wymagają dużej precyzji i synchronizacji. Dlatego każdy musi się komunikować z każdym, przez co liczba komunikacji rośnie z grubsza wykładniczo i szybko staje się nie do opanowania.

Próby ograniczenia komunikacji do wybranych osób kończą się jeszcze gorzej, bo rozpoczyna się zabawa w głuchy telefon i biurokratyczne leżenie papierów na biurku „aż nabiorą mocy urzędowej” i zostaną przekazane dalej.

• Komunikacja, kontrola i proces akceptacji trwają dłużej niż nawet skomplikowane kodowanie
• Często prace „wiszą” czekając na akceptację klienta/prawników/prezesa/…
• „Dylemat szachisty”: są momenty, kiedy wszyscy czekają, myśląc że ruch należy do kogoś innego
• W klasycznej pracy według długiej specyfikacji nie da się skończyć etapu wcześniej:
  

- nie ma z tego powodu żadnych bonusów dla programisty
- musi on zsynchronizować pracę z innymi
- i ma rację, bo po wprowadzeniu prawdziwych danych i tekstów okazuje się, że trzeba zmodyfikować projekt struktury stron, bo np. nie mieszczą się linki w nawigacji

• „Problem maszynisty”: Ponieważ nie da się skończyć żadnego etapu wcześniej, a opóźnienia zawsze się zdarzają, to nie ma jak ich nadrobić i projekt może się jedynie przedłużać
• Klienci są sfrustrowani, bo nie mają żadnych konkretnych zysków z osiągania przez projekt „kamieni milowych”. Zyski można czerpać jedynie z dostarczonych użytkownikom internetu, gotowych funkcjonalności /~stories

Dlatego trzeba z jednej strony ograniczać liczbę osób pracujących nad projektem (też przez metodologiczne ograniczanie codziennego zaangażowania Wyższych Czynników) a z drugiej zbierać wszystkie możliwe informacje w jednym, ogólnie dla wszystkich dostępnym miejscu (tablica na ścianie, wiki, Basecamp itp.) 

• Bezpośredni kontakt osób zamiast procesów i narzędzi
• Działające produkty zamiast bujnej dokumentacji
• Współpraca z klientem zamiast przepychanek z umową
• Dostosowywanie się do zmian zamiast twardego trzymania się planu

• Główną częścią specyfikacji jest analiza docelowych użytkowników i tego, jakie zadania będą chcieli realizować w serwisie
• Zadania te dzieli się na stories czyli konkretne funkcjonalności typu „chcę przeczytać artykuł”, „chcę polecić artykuł znajomym na Facebooku”, „chcę mieć anonimowy koszyk w sklepie”
• Produkt wykonuje się krótkimi etapami zwanymi „sprintami” o zamkniętej liście stories a także określonym z góry czasie realizacji i zamkniętych kosztach
• Każdy sprint kończy się w pełni działającym serwisem realizującym jakąś część stories
• Po każdym sprincie klient ma możliwość weryfikowania realizowania przez produkt celów biznesowych i podjęcia decyzji o kolejnych inwestycjach
• Listę zadań do kolejnych sprintów priorytetyzuje się przy użyciu modelu Kano:
  

- Funkcje kluczowe dla użytkownika
- Funkcje, które produkt musi mieć, ale inwestowanie w nie ponad minimum nie zwiększa wartości dla użytkownika
- Funkcje ważne dla użytkownika tylko jeżeli będą bardzo dobrej jakości (wisienki na torcie)
- Funkcje nie zwiększające wartości dla użytkownika, a więc i nie realizowane

Tego typu kontrakt jest standardowym efektem przetargu, w którym zleceniodawca ogłasza szczegółowo, jak ma wyglądać serwis i wybiera dostawcę według ceny i tego, jak komu z oczu patrzy. Teoretycznie ryzyko ponosi dostawca. W rzeczywistości:

• klient ponosi ogromne ryzyko, że produkt nie spełni jego celów biznesowych
• bardzo niska jakość kosztownej specyfikacji tworzonej z góry sprawia, że produkt jest gniotem…
• … chyba że dostawcy zapłaci się haracz za poprawki w stosunku do specyfikacji

Często prace nad prezentacją specyfikacji w Power Poincie zajmują więcej czasu, niż później prace nad samym serwisem. A taka prezentacja to też koszty pracy uczestników zebrań, często na wysokich szczeblach.

Widziałem kosztorys projektu, w którym serwis kosztował 60 tys. złotych, z czego tylko 12 tys. poszło na prace nad nim samym, a reszta to delegacje zarządu, zakup zdjęć skaczących, uśmiechniętych ludzi do prezentacji szkicu serwisu itp.. Sam szkic serwisu był zrobiony tabelkami w Wordzie i w ogóle skopiowany Ctrl+C/Ctrl+V z innego projektu nie do końca adekwatnie.

Popularną alternatywą jest umowa, według której płaci się za godzinę pracy według raportu na koniec miesiąca. Jest to rozwiązanie lepsze, ale wymaga dużej wiary w uczciowość dostawcy, który jest praktycznie bezkarny. A bezkarność korumpuje…

• duża elastyczność zwiększa szansę osiągnięcia celów biznesowych przez finalny produkt
• dostawca ma interes w przeciąganiu prac, co powoduje wzrost kosztów frustrację klienta
• nawet jak ufamy, że prace były wykonane, to nie da się w praktyce skontrolować, które z nich były rzeczywiście potrzebne

A można podpisać umowę, która jest skuteczną hybrydą obu podejść zachęcająca do współpracy. Kontrakt ustala tylko ogólne zasady typu prawa autorskie, osoby kontaktowe czy wyłączenia odpowiedzialności. Koszty i zakres prac określane są dla etapów (Prince2, Scrum, …) i uzgadniane po każdym etapie. Każdy etap kończy się działającym dla użytkowników produktem.

• duża elastyczność podzielona na sztywne „sprinty” dające szansę coś realnego skończyć
• wygodna kontrola kosztów po obu stronach
• weryfikacja celów biznesowych i szybkości prac po każdym etapie
• jednostką rozliczeniową jest story point, który najlepiej odpowiada prawdziwej naturze projektów informatycznych, niż godzina pracy czy linia kodu
• ponieważ dostawca nie wie, czy dostanie zlecenie na kolejny sprint, musi się starać 
(każdy etap kończy się działającym produktem, więc nie jest powiedziane czy i z kim klient będzie chciał prace kontynuować)
• poważna wada dla wielu klientów: dostawców nie da się wybrać w prostym przetargu cenowym. Trzeba znaleźć firmę, której doświadczeniu się ufa i z którą nadaje się na podobnych falach.