Get what you pay for - temat "wałkowany" w wielu dziedzinach, ale niestety do wielu prominentnych decydentów biznesowych nadal nie dociera, że zawsze otrzymuje się to, za co się płaci. Statystyka współpracy wielu firm realizujących projekty z ich klientami pokazuje, że brak zrozumienia zasady "get what you pay for" najczęściej prowadzi przedsięwzięcia do katastrofy po obu stronach.
Podstawy prowadzenia projektów, które osoba na decyzyjnym stanowisku musi znać, powinny pomóc w zrozumieniu powagi tytułu tego artykułu. Zlecenie opracowania skomplikowanego tematu słabemu wykonawcy, nieposiadającemu odpowiednich zasobów, doświadczenia czy wiedzy do realizacji, ale za to taniemu, zwykle doprowadzi do fiaska projektu. Zawsze budzi się ta myśl, "przecież mnie się uda, nie ma zagrożeń, jestem wyjątkowy". Jeśli tak się myśli, trzeba się posłać na kurs zarządzania ryzykiem ;)
Fundamentalną podstawką każdego projektu jest trójkąt ograniczeń projektu zwany również żelaznym trójkątem, którego zasady muszą być znane obowiązkowo zarówno po stronie zamawiającego, jak i wykonawcy. Pamiętajmy "(...) mnie oszukasz, przyjaciela oszukasz, mamusię oszukasz ale życia nie oszukasz (...)" i trójkąta ograniczeń projektu też nie oszukasz :)
Odwołując się do macierzy kompromisów projektowych jeden z czynników jest stały, drugi optymalizowany, a dwa negocjowalne. Parametry jakie mamy do dyspozycji to: zakres, czas, budżet, jakość. Zmiana jednego z parametrów ma zawsze wpływ na pozostałe. Od obu stron wymaga się kompromisu, ale to zamawiający powinien ustalić kluczowy parametr stały, z czym bywają problemy.
Znany jest (prawdopodobnie) cel biznesowy, przygotowujemy projekt i określamy zakres, czas i spodziewana jakość oraz budżet (zleceniobiorca kryje się z nim zwykle do ostatniego momentu ze względu na negocjacje). Jeśli jest to projekt informatyczny, nietrudno go zawalić. Wg zleceniodawcy to normalnie taki cudny projekt, normalnie modelujemy cały otaczający świat, MATRIX, komputery wszystko same zrobią, rewelacja, same oszczędności, nie trzeba będzie pracować! Zleceniobiorca wycenia realizację wymagań... i zderzenie z rzeczywistością... Koszmar! Czemu tak drogo? Jeszcze ten czas realizacji! To nieakceptowalne! Zleceniodawca jeszcze często myśli Chcecie nas oszukać, albo naciągnąć! Nie ze mną te numery.
Wówczas jest szansa na brak przemyślenia, brak wybrania kluczowego parametru ze strony zamawiającego. Górę biorą emocje związane ze środkiem płatniczym. W negocjacjach, o ile wtedy do nich dojdzie zwykle zadominuje podejście - negocjujmy budżet, a reszta pozostaje stała, nie ustąpimy. Nic dziwnego, na środku płatniczym opiera się w naszej gospodarce wszystko. Z wielką chęcią rozmarzony zleceniodawca zostałby przy niezmienionych pozostałych parametrach. I tu miejsce na pułapkę. Mamy konflikt, dzięki emocjom zapomina się o teorii gier.
U zleceniodawcy pojawia się wtedy ktoś "kreatywny" i mówi "weźmy studenta" lub "weźmy tą mikro firmę, są w gotowości, zrobią dla nas wszystko, a bez nas nic nie znaczą" lub "to prosty projekt, na przykład chłopaki w telekomunikacji są sprytne, zrobią to w tydzień, prawie za darmo" i liczy w głowie dolary, jakie już zaoszczędził dzięki temu wspaniałemu pomysłowi. On jest pewny, że pierwotny wykonawca to za dużo chce, chce za dużo zarobić na jego krwawicy. On już nie negocjuje. On myśli "zawsze patrzę w oczy, kiedy z kimś rozmawiam, nigdy nie wykonuję niepotrzebnych ruchów". On jest twardy, jest człowiekiem z miasta. I właśnie ironicznie "(...) On jeszcze nie zdaje sobie sprawy, że wkrótce będzie miał pełne portki (...) jego słaba psychika już wysłała mu maila do nadciągającej kupy, że spotkanie jest w spodniach".
Gdy nadciąga termin zakończenia projektu: czy okaże się że albo budżet został kilkukrotnie przekroczony, albo faktyczny termin dostarczenia jest nierealny, albo to co zostało zrobione do niczego się nie nadaje, a może student wyjechał, albo firma bez zasobów gospodarczych upadła, bo zleceniodawca ją wykończył? Jeśli tak się może stać, mamy do czynienia z porażką zespołu. Jest ona jednym z krytycznych obszarów projektu. Jeśli pośród innych obszarów krytycznych nie zostanie ona odpowiednio wcześnie zauważona, ryzyko porażki projektu wzrasta do 85%.
Całe szczęście, że wśród małych i średnich firm wiele na takie ryzyko stać ;) Przepłacają za projekty dzięki dumie, zarozumiałości i skąpstwie swoich pracowników. Niektórym cudze błędy nie wystarczają, bo "Nothing fails like success because we don't learn from it. We learn only from failure". Trzeba się uczyć na cudzych błędach i nie liczyć na łut szczęścia. Za darmo nic nie ma.
Dygresja... Jeśli myśli ktoś, że przecież wolne oprogramowanie jest darmowe, to nie do końca jest. Ktoś poniósł koszt, ktoś to wyprodukował, a teraz udostępnia (są różne powody i zawsze jakiś cel). Wad jest kilka, chociażby brak dokumentacji lub serwisu lub helpdesk (lub jest płatny), brak gwarancji, często używając wolnego oprogramowania trzeba swój produkt udostępniać darmo, albo zderzamy się z rzeczywistością, gdy nagle instytucja/organizacja, która kiedyś udostępniła swój produkt na licencji LGPL, w nowej wersji odchodzi od tego i cały skomplikowany projekt oparty częściowo na komponencie na tej licencji musi mieć zwiększony budżet (piszemy własny komponent lub kupujemy nową wersję). Ludzie muszą egzystować, a do tego potrzebne są środki płatnicze. Gdy komuś ich zabraknie, to przestanie być altruistą, a stanie się bardziej egoistą.
Wykonawca projektu może oczywiście zapłacić za dodatkowe zmiany prezentując coś zleceniodawcy, ale zawsze ktoś płaci. Powtórzę - życia nie oszukasz! Nie istnieją super promocje. Każda z nich ma w tle cel biznesowy lub jakieś braki. Jak ktoś robi za darmo, ma w tym cel, coś chce w zamian. Kupując drukarkę z wielkiej promocji może się okazać, że będzie ona np. bez głowicy drukującej, która leży na półce obok i kosztuje 90% wartości drukarki, a kabel USB trzeba dokupić za 5% wartości drukarki ;)
Trzeba być realistą i odpowiednio ważyć ryzyko. Kupowanie tanich rozwiązań jest domeną ludzi posiadających nadmiar gotówki i czasu.
piątek, 6 marca 2009
Subskrybuj:
Komentarze do posta (Atom)
Brak komentarzy:
Prześlij komentarz