Jak kończyć na czas projekty internetowe

09.09.2010 Michał Prysłopski

Przez jedenaście lat kierowania projektami internetowymi dla dużych korporacji i dla mniejszych klientów, ciągle spotykam się z pytaniami: ,,Pomocy! Prosty projekt z agencją X ciągnie się w nieskończoność.'' albo ,,Dlaczego nasz 20-osobowy zespół prześcignęła dwójka maturzystów?''. Na szczęście, ponieważ jest to problem globalny, rozwiązanie już dawno znaleziono. Zadziwiająco mało firm je stosuje

Zobacz także: Jak radzić sobie z ograniczeniami strukturalnymi w korporacjach

„Ż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.

Problemy techniczne sprowadzają się z grubsza do jednego punktu:

Programowanie jest częścią matematyki i jego problemy są jak Wielkie Twierdzenie Fermata. Albo zna się rozwiązanie i można je dać od ręki, albo się nie zna i wtedy może jest bardzo proste i zmieści się na marginesie książki, ale jego rozwikłanie może też zająć pokolenia

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.

Trzeba też pamiętać o różnicy między estymacją czasu a zobowiązaniem do deadline’u

Koszty komunikacji rosną wykładniczo wraz z liczbą osób w projekcie

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.)

Nowoczesne prowadzenie projektów według Agile Manifesto, 2001

  • 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

Przykładowa metodologia oparta na Scrum

  • 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

    Problemy z typowym kontraktem: umówiona suma + koszty poprawek

    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.

    Problemy z kontraktem za godzinę pracy

    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
    • Umowa ramowa + za story point

      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.


Lorem ipsum po polsku, z polskimi znakami Przetestuj mój popularny generator. Nie pierwszy tego typu, ale posługuje się zmielonymi tekstami współczesnymi. Można wybrać jeden z kilku stylów: teksty polityczne, naukowe, przyrodnicze. Losuje też nazwiska autorów tekstów. »
Polecamy: Blog o tym, że Polska jest Najładniejsza (ładne zdjęcia)