No cóż, pozostaje mi przyznać się także i do tego: właśnie mam za sobą umowę polubownie rozwiązaną. Czyja wina? Biorąc pod uwagę, że jestem na tym rynku od lat: moja wina. Zatrudniono mnie i uwierzyłem w cel. Ale po kolei…

Swego czasu w dyskusji o kontraktorach jeden z dyskutujących, napisał:

Projekty realizowane przez kontaktorów (nie mylić z patologicznym samozatrudnieniem na śmieciowych umowach) są z reguły wyższej jakości. Jest to efekt – moim zdaniem – w mniejszym stopniu formy zatrudnienia jako takiej, a raczej przyjętej konwencji: kiedy zatrudnia się kogoś do rozwiązania konkretnego problemu, ten ktoś ma o tym pojęcie, motywację, czas, środki i brak uzależnienia od dziesiątek innych rzeczy i ludzi – to pracuje bardziej efektywnie; jakość z tym przychodzi w pewnych aspektach niemal z automatu… Tyle że firm chcących i potrafiących zlecać i rozliczać projekty zadaniowo… no cóż, ze świecą szukać. (forum na temat metod zatrudniania)

Tym razem „[[Lessons Learned]]” czyli „uczmy się na błędach”

Przebieg projektu analitycznego opisano tu nie raz, przypomnę więc tylko kluczowe etapy: zdefiniowanie (wskazanie) celu biznesowego, analiza biznesowa, opisanie rozwiązania (specyfikacja wymagań). Zamawiający ma analizę, na bazie tak wytworzonej dokumentacji,  prowadzi wybór dostawcy rozwiązania. Podstawowe narzędzie zarządzania zakresem i jego weryfikacji to tak zwane śladowanie czyli wywodzenie  treści kolejnego etapu projektu z poprzedniego.

W czym był problem? Ano zgodziłem się, pod presją zamawiającego, na ograniczenie zakresu i czasu trwania projektu. Cel projektu został został „zadeklarowany” a projekt rozpoczął się od razu od „analizy biznesowej”.  Niestety cel pozostał tylko „omówiony” i „zadeklarowany” przed podpisaniem umowy.

Nauczka: brak celu i jego uzasadnienia to brak „początku” do którego „śladujemy” wszystkie następne efekty pracy. Efekt? Żaden następny produkt pracy nie poddaje się „dowodzeniu” słuszności, jest więc tym samym nieweryfikowalny. Skoro tak, nie da się obronić poprawności powstającej treści, nie da się także  „odrzucić” podrzucanych w trakcie „pomysłów”, bo skoro nie można dowodzić słuszności treści powstającej, to nie da się także „odrzucić” żadnej treści „podrzucanej”.

Prawdziwy cel zamawiającego był odkrywany w trakcie trwania projektu: najpierw okazało się, że tak na prawdę chodziło  o zatrudnienie kogoś kto ma doświadczenie w precyzowaniu kryteriów wyboru dostawcy tak by „osiągnąć cel”. OK. Projekt w toku.

Udało się uzasadnić zatrudnienie kogoś z zewnątrz, pomimo przydzielenia do projektu osoby „z dużym doświadczeniem w IT” (jeden z kierowników projektu z działu IT). Cudzych lat pracy w branży nigdy nie neguję, jednak skoro zatrudnia się kogoś z zewnątrz i uznaje że ma to sens, to dublowanie roli „analityka i nadzoru” własnym pracownikiem już nie ma sensu. Uwagi w rodzaju „ja bym to zrobił inaczej” są bez sensu, bo po pierwsze „trzeba było zrobić samemu”, po drugie uwagi recenzenta powinny raczej zaczynać się od słów: nie prawda jest, że … dlaczego…, nie rozumiemy stwierdzenia…, naszym zdaniem pominięto …  model jest niezgodny z… itp. a takie uwagi to były rodzynki w masie całości (i akurat nie osoba z IT była ich autorem).

Nie będę tu opisywał szczegółów tego projektu, ważne są wnioski a nie ta czy inna firma:

1. pominięcie któregokolwiek etapu projektu analitycznego, w szczególności pierwszego,  powoduje, że całość staje się nieweryfikowalna, ryzyko rośnie,
2. ukrycie prawdziwego celu projektu przed analitykiem (jest to możliwe, jeżeli dojdzie to tego co powyżej) powoduje, że większość jego czasu pracy nie służy projektowi,
3. po zanegowaniu efektów pracy analityka, obrona takiego projektu jest niemożliwa bo brak kluczowego narzędzia: śladowanie (przypomnę, że usunięto pierwszy etap – zdefiniowanie celu).

Co było prawdziwym celem projektu? Okazało się, że „nie chcemy by przetarg wygrała firma XXX i jej produkt”. W trakcie pierwszych problemów z „uznaniem” specyfikacji wymagań dostałem listę wad posiadanego oprogramowania.  Ku mojemu zaskoczeniu były tam nawet błędy rachunkowe (inne tu pominę, choćby niezgodność programu z prawem). Pytam: jakim cudem to zostało odebrane i zapłacone? Cóż…

Kilka porad dla Zamawiających (i analityków także)

Osoba z zewnątrz, zatrudniona do wykonania usługi (pracy)  to najczęściej z góry znany koszt i produkt (zakres pracy, umowa o dzieło).  Jest to nie raz o tyle wygodne, że praktycznie każda praca realizowana przez własnego pracownika to „kontrakt czas i materiał”, umowa o dzieło z osobą z zewnątrz (bo o tym mowa), to z góry znany koszt i czas (nie licząc ryzyka porażki projektu jak wyżej).  Zacytuje pewien bardzo pouczający artykuł (gorąco polecam cały do przeczytania):

Wynagrodzenie freelancera to zwykle ściśle określona kwota za zrealizowany projekt. Pracodawca nie ponosi z tego tytułu wydatków związanych ze stworzeniem etatu, takich jak stałe wynagrodzenie, obowiązkowe świadczenia, wypłacanie wynagrodzenia w czasie urlopu czy przestoju w pracy. Nie jest też konieczne przeszkolenie pracownika ani zapewnienie mu stanowiska i narzędzi pracy takich jak komputer, służbowa komórka czy samochód. Wszystko to jest bowiem po stronie najemnego pracownika. Freelancer ponosi też pełną odpowiedzialność za ewentualne naruszenie praw autorskich. Może to mieć znaczenie w przypadku zleceń dotyczących kreowania unikalnego kontentu, tworzenia projektów etc. […]

Jakie są minusy współpracy projektowej z freelancerem? Problemy wynikają z reguły z nieprzemyślanego formułowania kontraktów. Jeśli nieprecyzyjne określimy zakres merytoryczny i czasowy obowiązków i świadczeń ze strony freelancera, może to prowadzić do konfliktów i nieporozumień. […] Od tego już tylko krok do realizacji projektu w sposób niezgodny z koncepcją zleceniodawcy.

Drugim częstym błędem jest brak odpowiedniej koordynacji ze strony firmy. Współpraca z wolnym strzelcem wymaga bowiem wyznaczenia konkretnej osoby odpowiedzialnej za kontakty z nim i kontrolującej projekt.

Decydując się na freelancera powinniśmy też pamiętać, że osoba, z którą współpracujemy podchodzi zadaniowo do projektu i z reguły nie identyfikuje się z firmą i jej kulturą organizacyjną. ( Zleć zadanie specjaliście ? freelancer po polsku).

Dodam tu od siebie: ani z kulturą orgaznizacyjną ani w szczególności z jej brakiem. Wytłuszczenia są moje, tak interpretuję przyczyny opisanej tu mojej porażki.  To ja powinienem upilnować „sformułowanie zadania”, konkretnie nie godzić się na uproszczenie. Zlecający zaś,  powinien pamiętać, że osoba z zewnątrz nie „tkwi w żadnych wewnętrznych układach” i jest to ogromna zaleta. Jednak, istnienie jakichkolwiek niemerytorycznych celów projektu szybko „wychodzi” w toku analizy. Dlatego jednym z powodów, moim zdaniem, problemów był drugi cel projektu: wdrożyć zamawiane oprogramowanie tylko w jednym dziale na potrzeby jego kierownika, w zupełnym oderwaniu od innych, biegnących projektów, co jest pomysłem praktycznie nie do obrony.

I co mamy? Skutki dla Zamawiającego:

1. Poniesiony koszty
2. Poświęcony czas
3. Nieuzyskanie tego co zamówiono

Czyja wina? Moja bo się podjąłem dzieła i Zamawiającego, bo ukrywał prawdziwy cel projektu. Za co mi zapłacono? Analiza biznesowa została wykonana. Dobra umowa to uczciwa umowa: jednakowo chroni i Zamawiającego i Wykonawcę przed nierzetelnością drugiej strony lub przed siłą wyższą.