Wpadł mi niedawno w sieci w oko artykuł o wycenie projektu IT, fragment:

Dlaczego cap? [Cap to nic innego jak maksymalny koszt projektu]

Krótko: daje bezpieczeństwo.

A konkretniej: wykonawca może bezkarnie zawyżyć wycenę projektu (przyjąć jakąś bezpieczną granicę/nadwyżkę do każdego wykonywanego elementu).

Klient zaś czuje, że nie będzie oszukany. Dostanie dokładne raporty godzinowe, z których będzie wynikała kwota, jaką przyjdzie mu zapłacić.

Jeśli:

wykonawca wyceni projekt na swoją niekorzyść (przyjmie za małą liczbę godzin), to klient nie musi się tym przejmować ? zapłaci tyle, ile miał w wycenie

Ok, zapłaci na ile się umówił, ale skoro nie powstał produkt (zbyt mało czasu miał developer), bo wycena była zaniżona i prace przerwano, to za co kurcze zapłacił klient? Co dostał, nie licząc nieużytecznych (nie ukończono pracy) śmieci kodowych (o ile dostał, pytanie jaką licencję na ten kod ma w umowie!)???

wykonawca wyceni projekt na swoją korzyść (przyjmie za dużą liczbę godzin), to klient zapłaci mniej

tego niestety nie zrozumiałem….  dalej:

Oczywiście trzeba tylko zadbać o […] dobry i rzetelny raport godzinowy, który pokazywał będzie ile czasu trzeba było poświęcić na konkretne zadanie

ale klient oczekuje produktu a nie “ciężkiej pracy”….

A jak Tobie się podoba taki sposób wyceny projektu?

Nie podoba mi się…a Wam?

(cytaty: Jak wyceniać projekty IT? ).

Bardzo często widuję (w zasadzie jest to jak by standard)  właśnie takie metody wyceny i zawierania umów. Ludzie – kupujący – obudźcie się…

 

Na zakończenie tego krótkiego wpisu uwaga: nie da się rzetelnie wycenić czegoś co nie zostało jeszcze wymyślone. Poniżej diagram obrazujący poziom ufności oszacowania kosztów w zależności od etapu projektu:

KolajdaPoziomUfnosciWyceny

(źr. Tomasz Kolajda, http://ebookbrowse.com/koszlajda-pdf-d65211461)

Jak widać próba wyceny całego projektu już na samym jego początku to wróżenie z fusów, wykonawca przyjmie wartość bezpieczna dla siebie, a tak określony budżet i tak zostanie skonsumowany (co pokazuje praktyka, tak się składa oferty w przetargach publicznych, taka jest jakość większości zapytań przetargowych!).

Wystarczy wydzielić etap projektowania (analiza i projektowanie to ok. 20% kosztu developmentu) i zawrzeć umowę na etapie co najmniej wstępnego projektu, wtedy “zawyżanie” (narzucanie zapasu na niewiedzę)  spada dwukrotnie. Opracowanie kompletnego projektu przed wyceną prac developmentu to obszar bliski prawej części: estymacja kosztu z bardzo małym błędem.

Wnikliwym polecam cały artykuł pana Kolajdy.

Jarosław Żeliński

Jarosław Żeliński: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.

Ten post ma 20 komentarzy

  1. Karol

    Witaj,

    trochę dodatkowych informacji ode mnie…
    cap nie ma zabezpieczać developera. Cap jest od tego, żeby zabezpieczać klienta, a przede wszystkim projekt/produkt (który jest czymś więcej niż pracą developera).

    Projekt/produkt to przeważnie (przy poważnym podejściu do tematu) również prace graficzne, webmasterskie, budowa contentu, SEO, hosting, domeny, promocja itd. Prace usługowe (w tym developerskie) najtrudniej wycenić. Stąd też często przy nieumiejętnej wycenie projekt/produkt może ucierpieć i nie zostać należycie ukończony (bo jeśli za developerkę wyjdzie do zapłaty więcej aniżeli zakładono, to może nie wystarczyć budżetu na inne – równie ważne(!) – rzeczy).

    Stąd właśnie cap, który ma przed taką sytuacją uchronić i który świetnie się w tej roli sprawdza. Jeśli developer (lub ktokolwiek inny, kto bierze udział w projekcie i odpowiada za jakąś ciężką do wycenienia pracę usługową) źle wyceni swoją pracę (przyjmie za małą liczbę godzin), to będzie miał zapłacone maksymalną stawkę, na którą się umawiał (a jako, że będzie musiał poświęcić większą liczbę godzin, to jego stawka godzinowa de facto się zmniejszy). Projekt musi zostać ukończony(!) Nie ma mowy o tym, że w momencie gdy założona liczba godzin zostanie osiągnięta, developer kończy pracę i oddaje nieskończony projekt (gdyby tak było, to developer nie zasłużyłby na żadne pieniądze).

    1. Jarek Żeliński

      Jeżeli “Projekt musi zostać ukończony(!) Nie ma mowy o tym, że w momencie gdy założona liczba godzin zostanie osiągnięta, developer kończy pracę i oddaje nieskończony projekt (gdyby tak było, to developer nie zasłużyłby na żadne pieniądze).” to skąd budżet na “kończenie”? Postrzegam tak opisany CAP jako “ja jako analityk za jeden milion zrobię każdą analizę”… chyba, że nadal czegoś nie rozumiem. Pan Kolajda to ładnie opisał: narzuty (poziom zaufania wyceny), albo są albo ich nie ma…

  2. Ewelina Pawlak

    Faktem jest, że wykonawcy często zawyżają budżet ponad rzeczywistą wartość projektu, natomiast równie często zdarzają się sytuacje, w których Klient przychodzi z pomysłem na produkt, lecz bez jakiegokolwiek rozeznania w cenach. Wycena przed rozpoczęciem tworzenia specyfikacji wymagań powinna bardziej służyć oszacowaniu kosztów, aby określić skalę projektu.

    1. Jarek Żeliński

      Jeżeli klient przychodzi z pomysłem i budżetem to projekt należy zacząć nie od jego wyceny a od analizy jego wykonywalności…

    2. Ewelina Pawlak

      Analiza wykonalności – jak najbardziej, pod warunkiem, że klient jest świadomy konieczności jej przeprowadzenia. Jednakże dla klienta zazwyczaj jedynym istotnym czynnikiem jest cena i to nie tylko w projektach ‘przetargowych’.

    3. Jarek Żeliński

      To prawda, tacy klienci sami sobie robią krzywdę, jednak gdyby dostawcy jawnie mówili o ryzyku takiego podejścia…;)

    4. Tomasz Tomaszewski

      Dostawca mówi i ostrzega – niestety najczęściej bez skutku. Analizy wykonalności klient nie chce robić, bo … to dodatkowe koszty (no i budżet trzeba by zdradzić, a przecież powinno być jak najtaniej!). O ryzykach słyszy, ale przecież… “inne firmy potrafią na bazie naszych informacji wycenić projekt”!

      Niestety w sektorze MŚP klienci (w takim działa nasza firma) właśnie sami chcą sobie robić krzywdę. Pozostaje nieustanne edukowanie i liczenie na efekty tej edukacji.

      A może Pan, Panie Jarku, ma jakieś sprawdzone sposoby, groźby ;), ryzyka które obrazowo przemawiają do klienta?

    5. Jarek Żeliński

      Generalnie sposób widzę jeden: uczciwa gra w otwarte karty. Jest to niestety coś co wielu “biznesmenów” odrzuca jako “niemęskie negocjacje”. Od lat obserwuje ciekawe zjawisko, naturalny dobór: firmy nieetycznie grające mają z reguły nieetycznych partnerów i odwrotnie. Kluczem jest doskonała znajomość własnego rynku czyli coś czego nie ma większość firm. Jest prosty test: czy dana firma ukrywa ceny transakcyjne swoich umów. Jeżeli tak, to znaczy, ze gra nieuczciwie i nie zna swojego rynku. Gdyby znała swój rynek i zarabiała na nim uczciwie składałaby oferty jawnie. Zresztą fakty są takie, ze nie ma “tajnych” ofert bo np. ja po podpisaniu umowy o poufności mam dostęp także do cudzych ofert, umów i faktur. Bez tego wielu analiz nie da się rzetelnie przeprowadzić.

      Niestety sektor MŚP to w większości przypadków skansen gospodarczy. Moim zdaniem pozostaje bezwzględna uczciwość i szczerość, taki “MŚP biznesmen” najpierw (bardzo często) robi podchody by mnie wykorzystać (np. zapłacić mniej a więcej uzyskać). Ja zawsze najpierw pytam co jest problemem a potem składam ofertę. Praktycznie nie negocjuję żadnych stawek (te znam doskonale, to mój rynek ;)), negocjują wyłącznie zakres projektu. Swojej stawki wyjawiam jako pierwszy krok współpracy, to pierwszy test czy potencjalny klient jest uczciwy, wie co chce kupić i zna rynek na który wchodzi. Praktyka pokazuje, że po zebraniu ofert moich konkurentów szybko się uczy ale to co (kogo) wybierze zależy w dużym stopniu od oceny ryzyka jakiej dokona.

      Moją standardową “groźbą” są powszechnie dostępne statystyki projektów. Ale jeżeli klient uważa, że jego to nie dotyczy to ja mu niczego nie sprzedam. Po drugie zawsze prezentuje to co i jak zrobię (opis metodyki) by wiadomo było skąd te stawki.

      Ważna rzecz w rozmowach z klientami: nie można być desperatem 🙂

  3. Grzegorz K.

    Oczywiście, projekt a potem wykonanie, to elementarz. Ale niestety Większość Zamawiających albo z lenistwa ale także z powodu sposobów finansowania, a co za tym idzie konstrukcji samego zamówienia, wymaga jednej kwoty na całość i jednego wykonawcy (dwie umowy to zbyt wiele zachodu lub refundacja tego nie przewiduje). I to jest problem opisany powyżej. Spotkałem się również z takimi zamówieniami z firm komercyjnych i to “dużych” i znanych, finansujących taką inwestycję ze środków własnych. Ale w takich przypadkach zwykle chodzi o pośpiech ale nie tylko. Czy naprawdę nie można realizować takich projektów jak rozsądek nakazuje? Ale to chyba pytanie retoryczne. A jak nie wiadomo o co chodzi… często wszyscy mają w tym jakiś ;-/ interes.

    1. Jarek Żeliński

      jeden wykonawca nie determinuje jednej kwoty… kupujący żądają jednej kwoty na całość na początku sam się podkłada, a jak nie wiadomo co co chodzi to… cóż…

  4. jacek2v

    Mi też się nie podoba taki sposób wyceny projektu. Aczkolwiek czasami jest to najlepszy sposób.

    1. Jarek Żeliński

      ja nie mam nic przeciwko jeżeli klient, a nie tylko dostawca, brał udział w tej wycenie…

    2. jacek2v

      Powiem więcej najlepiej, aby klient brał udział w wycenie. Dla mnie wycena składa się z dwóch etapów: oszacowanie ile to pracy i jaka stawka. Obie kwestie są całkowicie różnie wyliczane. Pierwsza: inżynieryjno-techniczno-kompetencyjnie, druga: biznesowo-relacyjnie-rynkowo :).

    3. Jarek Żeliński

      O tak, jestem zdania, że klient powinien w 100% rozumieć wycenę i brać w niej udział, ale z jednym się nie zgodzę: negocjacje stawki (dziennej/godzinowej) za człowieka: jeżeli będzie w jakimś projekcie niższa to znaczy, że mniej je, rezygnuje z kina i nie chodzi do knajpy? Ja negocjacji stawki nie dopuszczam 🙂

    4. jacek2v

      Albo jest tylko mniejsza marża 🙂

    5. Jarek Żeliński

      Jeżeli ktoś tak buduje marże, to nie chciał bym mieć z kimś takim nic wspólnego… ;). Marża to cena rynkowa minus koszty, a nie koszty plus naciągnięcie klienta…

    6. jacek2v

      “Cena rynkowa” – to taki byt co to o nim prawie każdy słyszał, ale nikt nie widział :). A to po prostu cena za jaką klient kupi.
      Ja wolę cenę opartą o “wartość dla klienta”. Niestety trudno taką cenę wyliczyć przy przetargach publicznych.

    7. Jarek Żeliński

      Jest bardzo prosty miernik “wartości dla klienta”: nieukrywanie cen… Zobaczyć minę klienta, który dowiaduje się, że to co kupił u swojego partnera (ceniącego wartość dla klienta), za rogiem kosztuje połowę: bezcenne (a zdarzało mi się)… Jak ktoś ma wątpliwości, czy istnieje rynkowa cena, niech przestanie “utajniać” umowy. Co ciekawe niejedna już “została obejrzana” w trybie dostępu do informacji publicznej, miny niektórych? Bezcenne 🙂

  5. jacek2v

    Utajnianie jest problemem w połączeniu z decydującym parametrem: najniższą CENĄ.

    1. Jarek Żeliński

      Nie oceniam przyczyn utajniania a sam fakt, mało mnie obchodzi którego powodu utajniania ktoś się wstydzi, ukrywa cenę i ma jakieś (nieczyste) powody 😉

Możliwość dodawania komentarzy nie jest dostępna.