Ile będzie mnie to kosztować? | Blog X-Coding
ile-bedzie-mnie-kosztowac

Ile będzie mnie to kosztować?

3.04.2015 / / E-Commerce

To zdecydowanie pytanie, z którym spotykam się najczęściej, rozmawiając z klientami o prowadzeniu projektu w metodyce zwinnej (Scrum). W zasadzie trudno się dziwić – rynek jest skonstruowany tak, że większość dóbr jest kupowanych po stałej cenie. Możliwość porównania kwoty końcowej, którą wydamy, daje poczucie bezpieczeństwa. W przypadku projektów informatycznych, które w większości przypadków są dedykowanymi rozwiązaniami, często związanymi z innowacją, jest to bardzo złudne poczucie. Temu poświęcę dzisiejszy artykuł.

Kto zarobi, kto straci?

Przede wszystkim, stała cena oznacza tylko tyle, że ostatecznie ją zapłacisz, o ile tylko warunki kontraktu zostaną wypełnione. Weźmy pod uwagę projekt oszacowany na rok pracy zespołu 3-osobowego. Przy takich rozmiarach z pewnością wystąpi jedna z dwóch sytuacji:

  • projekt został przeszacowany kosztowo, a wykonawca zarobi nie tylko na bieżącej działalności, ale także na różnicy wynikającej z oszacowania,
  • projekt został niedoszacowany kosztowo, a wykonawca będzie musiał do niego dopłacić.

Wbrew pozorom to pierwszy scenariusz przyniesie Ci więcej korzyści. Żeby to dobrze zrozumieć, należy już teraz powiedzieć dosłownie trzy słowa o zmianach w zakresie projektu. Mianowicie – zmiany się pojawią. Już teraz powinieneś oswoić się z tą myślą.

Dlaczego zatem właśnie ten pierwszy scenariusz? Z bardzo prostej przyczyny – firma wdrażająca Twoje oprogramowanie w razie potrzeby będzie bardziej otwarta na zmiany w zakresie projektu, bo to Ty pozostajesz jego sponsorem. Firma nie traci (oczywiście zakładając, że nadwyżka z oszacowania nie została wliczona na poczet zysku).

W drugim przypadku to wykonawca będzie sponsorem występujących zmian, na co niechętnie się będzie godził. Wówczas dialog schodzi na drugi plan, a kontrakt staje się “minimum koniecznym i wystarczającym do zamknięcia projektu”. To właśnie słowo “wystarczający” jest tutaj kluczem, a jego negatywny wydźwięk jest jak najbardziej zamierzony. Stąd pochodzi większość przeciętnych projektów, które spełniają swoje zadanie i to właściwie wszystko, co można o nich powiedzieć. Im większy projekt, tym bardziej ta przeciętność będzie kłuła w oczy i zostawiała nieprzyjemny posmak źle zainwestowanego kapitału.

To oczywiste, że obie sytuacje są dla Ciebie złe. Albo przepłacisz, albo otrzymasz coś, czego nie do końca się spodziewałeś.

Koszt projektu

Problem niepełnej specyfikacji

W projektach typu fixed price dokumentacja powstaje przed rozpoczęciem projektu, a podczas jego trwania jest głównym punktem odniesienia postępu prac.

Jestem autorem kilkunastu analiz biznesowych i specyfikacji mniej lub bardziej skomplikowanych projektów informatycznych. To, czego się przede wszystkim nauczyłem, to fakt, że specyfikacja nigdy nie odda w pełni wszystkich oczekiwań, które są stawiane przed systemem informatycznym.

Na potrzeby przykładu przytoczę najprostszy formularz kontaktowy. Pełny opis działania takiego formularza można bez większego problemu rozdmuchać na kilkanaście stron, zaczynając od opisu potrzeby biznesowej, którą będzie realizował, przez możliwe stany, makiety graficzne, przypadki użycia i wymagania funkcjonalne. Jeśli do tego dojdzie integracja z RMA (ang. Return Merchandise Authorization – system zgłoszeń), dorzucamy następne strony opisujące sposób komunikacji.

To prowadzi do dwóch podstawowych problemów:

  • czy na pewno o wszystkim pamiętałem? Wyjdzie w praniu za pół roku, kiedy będę odbierał moduł od wykonawcy.
  • czy na pewno wiem już teraz, że formularz w tym kształcie za pół roku wciąż będzie dokładnie tym, co jest mi potrzebne?

Jeżeli odpowiedź na choć jedno pytanie brzmi “tak”, konieczna będzie zmiana. Teraz wracamy do punktu pierwszego – to, czy Twoje zmiany zostaną uwzględnione, będzie zależało od tego, kto będzie te zmiany sponsorował.

Taka sytuacja najczęściej kończy się orzeczeniem o winie analityka. Nic bardziej mylnego! Takie myślenie świadczy wyłącznie o złym rozumieniu pracy analityka. Przede wszystkim:

  • Dokumentacja powinna być napisana tak, żeby było wiadomo, co w jaki sposób ma działać.
  • Nie każdą myśl da się przelać na papier (określam to zawsze “potrzebą pomachania rękoma”).
  • Częściej klient nieświadomie zataja intencje biznesowe, niż analityk zapomni o czymś w dokumentacji. O każdą potrzebę można dopytać, o ile tylko jest ona zaadresowana.

Każdorazowo po skończonej dokumentacji byłem przekonany, że można jej objętość podwoić, bo zawsze można coś opisać bardziej precyzyjnie. Zawsze też okazywało się, że klient o czymś zapomniał powiedzieć.

Jak wobec tego oszacować projekt?

To wartości budują projekty To wartości budują projekty

Zamiast formalności, skup się na wartościach

Powyższe problemy to jeden z powodów, dla których 90% projektów wykonujemy w metodyce Scrum. Niejednokrotnie przebywaliśmy długą drogę, żeby przekonać firmy, z którymi współpracujemy, do stosowanych praktyk, ale z czystym sumieniem mogę powiedzieć, że każdorazowo decyzja okazała się dobrą.

Odpowiadając zatem na pytanie z tytułu artykułu – stosując metodologię zwinną zapłacisz dokładnie tyle, ile wysiłku poniósł zespół, żeby wykonać projekt, który odpowiada precyzyjnie Twoim oczekiwaniom. Doprecyzowując zakres poszczególnych elementów w trakcie prac, będziesz miał kontrolę nad całokształtem przez cały czas trwania projektu. Co więcej, oznacza to możliwość korekty wtedy, gdy wystąpi taka konieczność, nie po zakończeniu projektu, co wiązałoby się z dodatkowym kosztem

Czy decydujesz się na kota w worku?

Absolutnie nie! W żadnym wypadku nie chodzi o to, by wycena była tajemnicą. Tak jak nie chcesz zdziwić się przy odbiorze projektu po roku prac, tak samo wiem, że nie chcesz być przerażony kwotami na rozliczeniach.

Nie o to w tym wszystkim chodzi. Wręcz przeciwnie – oczekuj oszacowania i oczekuj terminów. Ważne jest jednak, by oszacowanie było oparte o poziom szczegółowości specyfikacji projektu, a ta była aktualizowana i doprecyzowana w trakcie prac. Rozsądne oszacowanie jest możliwe w każdym momencie trwania projektu, o ile tylko firma posiada odpowiednie doświadczenie.

Ta zasada ma szczególne znaczenie w projektach innowacyjnych, gdzie konkurencja nie śpi i po roku może się okazać, że jesteś o rok do tyłu za rynkowymi standardami.

Czy Scrum jest zawsze remedium?

Wspomniałem o 90% projektów. Te 10% nie wynika z tego, że tam się nie udało. To projekty, w których występujemy doraźnie w roli eksperckiej, lub te, w których zmiana przebiega w trybie ciągłym. Wówczas trudno mówić o sprintach.

O tym, gdzie wręcz odradzałbym metodologię zwinną, wkrótce. Tymczasem, jeżeli masz pytania, zapraszam do dyskusji.