Wstęp
Ostatni artykuł szybko zaowocował pytaniem:
A jeżeli klient nie ma kompetencji do opisania projektu i musi kogoś z takimi kompetencjami wynająć, to jak ustalić cenę za tę usługę? (pytanie do artykułu Budżet na projekt IT).
Jeżeli klient nie ma kompetencji do opisania projektu (z reguły tak jest, bo firmy utrzymują kompetencje niezbędne do bieżącego funkcjonowania) to powinien po pierwsze ocenić co chce osiągnąć. Klient powinien co najmniej opisać po co to robi, np. „chcę zwiększyć sprzedaż do końca roku o 10%, albo „chcę usprawnić produkcję i obniżyć jej koszty o 15% w ciągu dwóch lat, itp. Z tych procentów, znając wartość sprzedaży czy koszty produkcji, łatwo oszacować progowy budżet rentowności tego projektu. Bywa, że to trudne, wtedy czasami łatwiej ocenić „ile stracę np. w ciągu roku jeśli nie wprowadzę tej zmiany”. Jednak konkretna wartość powinna być określona.
Wycena
Wycena kosztów analizy może być ustaleniem stałej kwoty, będącej ocenioną pracochłonnością i rozliczeniowym kosztem dnia analityka (tu jednak ktoś musi tę pracochłonność określić). Można opisać produkt, to jest oczekiwaną treść dokumentu wymagań, kto ma to jednak zrobić skoro klient tego właśnie nie wie. Tu można posłużyć się standardami, np. uznać, że produktem analizy wymagań jest dokument o zawartości opisanej przez IIBA (tu powinny powstać: modele procesów całej firmy, model dziedziny systemu, opis zakresu projektu, specyfikacja przypadków użycia i ich ograniczeń, specyfikacja reguł biznesowych) jednak do ustalenia jest cel analizy a z tego wynika jej stopień szczegółowości. Potem szukamy wykonawcy takiego opracowania.
Inna, często stosowana, metoda to analiza ryzyka i wynagrodzenie typu success-fee (premia za korzyści). Klient, na ile potrafi i jak, opisuje swoje potrzeby i wysyła takie wstępne zapytanie w rynek. Zbiera oferty i oblicza np. medianę (mediana jest bezpieczniejsza od średniej arytmetycznej) ich wartości. Tu pojawia się ryzyko, że „nieprofesjonalnie” opisane wymagań rękami klienta wymuszą (i słusznie) na oferentach narzuty na ryzyka tak opisanych wymagań. Ustala z analitykiem, że potrzebny mu dokument, którego nie potrafi sam opracować, koszt jego opracowania ustala się z góry np. na 10% wartości ww. mediany oferowanych kosztów dostarczenia oprogramowania.
Kolejny etap to wykonanie tego opracowania (analizy wymagań wg. metody ustalonej przez analityka) oraz wysłanie kolejny raz zapytania w rynek, tym razem w imieniu analityka 😉 (żeby się dostawcy nie zorientowali). Znowu zbieramy oferty i liczymy medianę. Następnie obliczamy różnicę pomiędzy ofertami i jeżeli są dla klienta korzystniejsze, to np. 20% tej różnicy wypłacamy analitykowi jako wynagrodzenie za korzyści. Jeżeli nie są korzystniejsze uznajemy, że dobrze wykonano pracę ale „nie przyczyniła się znacząco do poprawy sytuacji”.
Procenty są ustalone na bazie wiedzy z badań, mówiącej, że źle wykonana analiza przeciętnie podnosi koszty dwukrotnie a bywa, że znacznie więcej.
W pierwszej metodzie ryzyko w całości bierze na siebie klient, w drugiej jest rozłożone mniej więcej równo na obie strony: klienta i analityka. Ja w praktyce stosuję obie te metody a czasem metodę pośrednią (z góry ustalam wartość analizy ale na bazie znanych z badań ryzyk). Moim zdaniem wycena polegająca w 100% na metodzie „czas i materiał” jest ryzykowna gdyż zachodzi poważne ryzyko wykorzystania niewiedzy klienta do zawyżania jej wartości. Dobrą metodą jest zawarcie w umowie z analitykiem zapisu, że w trybie tak zwanego nadzoru autorskiego analityk uczestniczy w projekcie do końca, co powinno go zmotywować do jak najlepszej pracy a także klient zyskuje mediatora.
Najgorsze moim zdaniem rozwiązanie to podjęcie decyzji o wyborze produktu bez analizy, tylko na podstawie prezentacji systemu i zlecenie jego opracowania dokumentu wymagań, by na jego podstawie wdrażać (tworzyć) oprogramowania. Ta sytuacja to praktycznie całkowita utrata kontroli nad projektem przez klienta, oraz bardzo duże ryzyko, że zostanie to wykorzystane przez dostawce do budowania jego marży lub zawyżania pracochłonności. To klasyczna patologia, w której ktoś sam sobie stawia zadania, realizuje je i ocenia czy je wykonał, gdyż klient, jak już na samym początku stwierdzono, nie ma do tego kompetencji.
Praktyka pokazuje, że koszt analizy i projektowania w dobrze zarządzanym projekcie stanowi ok. 20% wartości całego projektu dostarczenia, dopasowania lub wykonania oprogramowania. Do tego może być wymagana dodatkowa analiza organizacji w celu oceny możliwości jej usprawnienia (optymalizacji procesów) i ustalenia wspomnianego progu rentowności. Projekty takie są tańsze od prowadzonych „typowymi metodami” o 30 – 50%. Te typowe metody to ankietowe (warsztatowe) pozyskiwanie wymagań i ich nieformalny zapis w postaci tabel, strukturalnego tekstu itp. zależnie od wykonawcy, te proste metody dają mniej lub bardziej opasłe, i niestety mało przydatne dokumenty.
Opisywane tu nie raz metody bazujące na modelowaniu przyszłego systemu (jego logiki biznesowej) i testowaniu czy model pozwala na spełnienie celu biznesowego dają oszczędności nawet 50%, a bywa, że znacznie większe, jeśli okaże się, że uniknięto zakupu jakiegoś zbędnego oprogramowania lub modułu. Koszt dobrze opracowanej analizy z dużym zapasem pokrywają oszczędności wynikające z braku wielu prototypów.
Podsumowanie
Analityka zawsze warto zatrudnić, poprzedzając to kontrolą tego co wytworzy. Dobry analityk zawsze wyceni projekt jako umowę o dzieło o konkretnym terminie i koszcie. Projekty w rodzaju czas i materiał to projekty w rodzaju „na początku nikt nic nie wie”. Warto je robić tylko w przypadkach, gdy tej wiedzy faktycznie nie ma, spodziewamy się systemu o wartości setek tysięcy złotych lub kosztowniejszych i zainwestowanie nawet kilkudziesięciu tysięcy w analizę, która pozwoli oszacować ryzyko wydania tych kilkuset, może mieć sens. W takich przypadkach i tak ustalamy (należy to zrobić) próg kosztów i ryczałtowe wynagrodzenie dla analityka, przy których uznamy, że dalsze prace już niczego nowego nie wniosą.
Załóżmy, że wysyłamy do wybranych potencjalnych dostawców zapytanie ofertowe z pewnym opisem wymagań do zrealizowania. Z artykułu wynika, że możemy dostać wycenę + narzut za ryzyko, co zwiększa koszt dla klienta. Jednakże jest też druga sytuacja, że padną pytania od potencjalnego dostawcy i wtedy: zwiększa się koszt po obydwu stronach, ale z równoczesnym miejmy nadzieję obniżeniem narzutu na ryzyko. Pytanie co jest lepsze? Gdzie jest granica dokładności wysyłanego zapytania? Bardziej dokładne może powodować, że nie uzyskamy „optymalnego” rozwiązania. Mniej dokładne może spowodować wzrost kosztów procesu ofertowania i wzrost ryzyka w projekcie.
Ja na to patrze „jak budowlaniec” – jeżeli architekt i murarz to kumple z jednej firmy przy jednym biurku, to dokumentacji faktycznie trzeba mało, ale powstanie produkt, którego konstrukcja będzie jak najdroższa i jak najprostsza, aby tego uniknąć wystarczy by to klient zatrudnił architekta.…. wtedy co prawda powstanie relatywnie kosztowny projekt ale nie ma ryzyka, że ta para będzie pracowała na siebie a nie na klienta… sprawa się jeżeli ktoś „z zewnątrz” oczekuje dokumentacji poddającej się audytom (sponsor projektu).
Dokładność zapytania, czyli dokumentacji, jest moim zdaniem kompromisem pomiędzy kosztem jej wykonania a zyskiem z obniżenia ryzyka, to własnie podlega negocjacjom pomiędzy analitykiem a klientem.
Taki model o którym Pan pisze tylko pozornie zmniejsza ryzyko. Tak trochę demagogicznie Pan to przedstawia.
Jeżeli odpowiedzi na zapytanie ofertowe mają sprowadzać się do tego, że oferent składa wycenę realizacji bardzo dokładnego projektu (który analityk zapewnia, że oczywiście jest bezbłędny) to komkurencja pomiędzy oferentami sprowadza się wyłącznie do kwestii ceny. Patrzy Pan na to jak budowlaniec, więc dobrym przykładem mogą być Chińczycy i autostrada A2.
Prezentowany przez Pana model zakłada też, że analityk/projektant pracuje zanim do pracy przystąpią wykonawcy. Skąd więc analityk ma czerpać wiedzę na temat tego, co ma projektować? Brak tego kontaktu prowadzi to do tego, że analityk/projektant zaczyna odstawać wiedzą. Może chodzić na prezentacje, szkolenia ale nie zastąpi to realnego uczestnictwa w projekcie a nie tylko „nadzoru”. Pisze Pan, że patrzy na to „jak budowlaniec”, ale w budowlance też się już na to tak nie patrzy. No może jeszcze w projektach państwowych, a z tymi jak jest, każdy widzi. Ma Pan jakieś większe doświadczenie z „budowlanką”, żę tak się Pan na to powołuje?
Nie widzę tu żadnej demagogii…
Poprzedzający artykuł zawiera opis: analityk modeluje (projektuje) nie oprogramowanie a logikę (biznesową), którą oprogramowanie ma realizować. Zaprojektowanie oprogramowania (implementacja) lub „trafienie” na rynku w gotowe pasujące, to inny element. Rolą analityka jest np. dokładne wyspecyfikowanie tego czym jest faktura VAT i jakimi się rządzi prawami wewnątrz, podobnie inne dokumenty. Jeżeli różne dokumenty są jakoś ze sobą powiązane, to rolą analityka jest opisać logikę tych powiązań, jeżeli zaś ich tworzenie jest czymś ograniczone, to rolą analityka jest te ograniczenia (reguły biznesowe) wyspecyfikować. Nie jest rolą analityka projektowanie oprogramowania.
Rzecz w tym, by ten opis (wymagań) dla wykonawcy nie był stekiem akapitów tekstu i tabel a modelem (obiektowym dziedziny), bo to dużo bardziej „jednoznaczny” opis. Dlatego preferuję podejście DDD i wzorzec projektowy MVC.
Tak więc jeszcze raz: ja nie daję „dokładnego projektu oprogramowania”, daję „dokładny opis tego jakie informacje i jak” ma ono przetwarzać. Nie jest więc to autostrada A2 (pomijam, że Chińczycy przesadzili z niską ceną by wygrać przetarg, to coś co nagminnie robią także firmy IT!).
Co do konkurencji: oferent składa ofertę na to w jakim czasie i jakim kosztem dostarczy oczekiwaną funkcjonalność, a co jeszcze może zaoferować (nie licząc referencji czyli ryzyka, że mówi prawdę w tej ofercie)?
Co do doświadczenia z budowlanką: mam za sobą projekty wymagań na systemy np. dla Echo Investment SA i Eco-Park SA.