Nie twierdzę, że zlecanie prac na zewnątrz to zawsze zły pomysł. Są sytuacje, kiedy takie rozwiązaniem ma sens. Czasem opisane niżej patologie nie mają miejsca. Dziś jednak postanowiłem opowiedzieć Wam „dlaczego nie?”. Poniższe obserwacje płyną z doświadczeń, jakie zebrałem przez ponad 20 lat pracy w małych i dużych projektach i (niestety) dotyczą znakomitej większości z nich.
Zlecić czy nie zlecić?
Przypuśmy, że masz do przeprowadzenia ważny projekt IT. Szacujesz że zajmie on rok (lub więcej) pracy. Myślisz sobie „moi ludzie są zarobieni, nie tak znowu doświadczeni, projekt jest ważny… może lepiej oddalić od siebie odpowiedzialność i przenieść ryzyka na podwykonawcę”?
Wtedy wbiegam do pokoju i krzyczę „Stój!”.
Zanim zaczniesz szykować dokumenty do przetargu zastanów się dziewięć razy! Dlaczego?
Kiedy decydujesz się na duże wdrożenie siłami firm zewnętrznych, możesz napotkać wiele nieoczekiwanych problemów i wyzwań, które Cię zaskoczą. Oto przykładowe, których sam doświadczyłem (zbyt) wiele razy.
1. Brak pełnej kontroli nad personelem, który będzie pracował nad projektem, duplikowanie ról
Nie zawsze mamy wpływ na to, kto zostanie przydzielony do zespołu wykonawcy. Nie wiemy jakie będą jego prawdziwe (a nie deklarowane na papierze, przykładowo w CV załączonych do oferty) umiejętności, doświadczenie i zaangażowanie.
Taka sytuacja może prowadzić do problemów, gdyż jeśli członkowie zespołu nie są doświadczeni albo zaangażowani w pracę, może to wpłynąć negatywnie na jakość wykonywanych zadań oraz opóźnić realizację projektu.
Co więcej w każdej chwili może nastąpić ryzyko oddelegowania części zespołu wykonawcy do innego (np. lepiej płatnego) projektu, co prowadzi do opóźnień i komplikacji związanych z przekazywaniem frontu robót nowym osobom.
Dodatkowo często zdarza się, że niektóre role w zespołach zlecającego i wykonawcy muszą być „lustrzane”. Mówimy tu o kierownikach projektu, analitykach, testerach, czy prawnikach. Te same prace są wykonywane podwójnie, aby zapewnić że żadna ze stron nie zachowuje się nieuczciwie.
2. Wydłużenie i zakłócenia w komunikacji
Z uwagi na wspomniane w poprzednim punkcie duplikowanie ról mamy często „burzę komunikacyjną”.
Przykładowo – na projekcie pracują dwaj kierownicy – jeden z naszej firmy, a drugi z firmy zewnętrznej. Wydłużają i zakłócają oni tor komunikacyjny między „skrajnymi” odbiorcami projektu. Czyli przykładowo użytkownikami wdrażanego systemu a jego realnym wykonawcą – zespołem wytwórczym.
Często wygląda to (w dużym uproszczeniu) tak:
A mogłoby wyglądać tak:
Nawet specjalne narzędzia, procedury i plany komunikacyjne nie zawsze gwarantują sukces. Są to zresztą dokumenty, które trzeba opracować, zatwierdzić i honorować – a to zajmuje więcej czasu przy udziale obcej firmy.
Podobnie (albo gorzej) może być w sytuacjach kiedy zespoły wdrożeniowe zamawiającego i wykonawcy próbują uzgodnić coś między sobą. Zwykłe porównanie środowiska czy opracowanie planu wdrożenia może być koszmarem, jeśli każdy mail musi przejść przez „bramkę” w postaci kierownika projektu a każda praca (proste „podajcie nam wersję serwera na waszej maszynie testowej”) musi być zlecona za jego pośrednictwem.
3. Przeciwne cele
W trakcie prac nad realizacją umowy często zdarza się, że obie strony dążą do minimalizacji kosztów, co niestety może prowadzić do konfliktu interesów.
Zamawiający chce mieć wysoką jakość w ramach uzgodnionej ceny a wykonawca chce zrealizować uzgodniony zakres – najmniejszym możliwym kosztem. Wykonawca rzadko (chociaż są chlubne wyjątki) chce zrobić solidny, dopracowany, wydajny i ergonomiczny system. Raczej będzie reagował alergicznie na wszelkie prośby o dopracowanie interfejsu użytkownika czy nawet poprawę wydajności.
Bardzo prostym przykładem jest zespół testujący. Wykonawca może pójść po najmniejszej linii oporu i przyjąć podejście znane jako „klient i tak przetestuje”. Polega ono na tym, że testerzy dostają bardzo niewiele czasu na sprawdzenie pojedynczej wersji. Zamawiający otrzymuje więc kod przetestowany pobieżnie i musi i tak wykonać swoje testy.
Czyli jak w memie „When they ask me to ship to production as soon as possible and without testing„:
Inny przykład – celowe braki w dokumentacji analitycznej i projektowej. Podejście znane jako „klient nie zauważy, podpisze a potem jak się zorientuje będzie za późno”. Czyli dostajemy po roku aplikację, w której brakuje jakiejś ważnej funkcji, ale wykonawca zasłania się podpisanym przez nas projektem.
Taki konflikt interesów może być trudny do rozwiązania jeśli w umowie nie są wprost zapisane mierzalne kryteria pozwalające rozstrzygnąć kto ma rację. Takich niestety często brakuje, z różnych względów. Warto je jednak z umowy na umowę uzupełniać i „zaciskać pętlę” na szyi wykonawcy, tak aby nie uszły mu na sucho ewidentne błędy w sztuce.
Minusy „zaciskania pętli”? Widzę co najmniej dwa. Spadnie na nas zadanie utrzymania i aktualizacji całej masy prezycyjnie zdefiniowanych kryteriów umownych. Wykonawcy zaś – widząc w co będą musieli się wpasować aby wystawić nam fakturę – podniosą ceny lub odstąpią od złożenia oferty. Mają przecież instynkt samozachowawczy.
4. Narzut formalności i biurokracji
Wdrażanie dużych projektów przy pomocy firm zewnętrznych często wymaga przeprowadzenia wielu formalności i przejścia przez gąszcz biurokracji. Projekt umowy, dokumenty przetargowe, negocjacje, opinie prawne. W dużych firmach zakup prostej licencji na pudełkowe oprogramowanie potrafi zniechęcić, a co dopiero tak skomplikowanej usługi jaką jest wytworzenie systemu czy wdrożenie rozwiązania.
Takie procedury mogą prowadzić do opóźnień i utrudnień w procesie realizacji projektu. Wszystko to związane jest z koniecznością uzyskania różnego rodzaju akceptacji, zgód czy też spełnienia innych wymogów, które są niezbędne do przeprowadzenia projektu zgodnie z obowiązującymi przepisami i wewnętrznymi regulacjami.
Możemy bagatelizować wpływ tego typu biurokracji na zespół ale zapewniam was, że jest bardzo demotywujący. Daj informatykowi tonę papieru do zaopiniowania albo jakieś projektowe (a nie daj boże księgowe) mumbo-jumbo do wypełnienia i masz gotowy przepis na kwaśną minę, L4 albo „na żądanie”.
5. Brak zrozumienia dziedziny i lokalnej specyfiki
Zewnętrzna firma może nie mieć pełnego zrozumienia naszej dziedziny i lokalnego kontekstu, regulacji, procesów. Taki brak wiedzy i doświadczenia może prowadzić do błędów i niedopasowania rozwiązań do naszych potrzeb. Często należy zapewnić im dodatkowe szkolenia oraz przekazać informacje na temat naszej firmy, procesu i branży. W ten sposób będziemy mieli większą pewność, że otrzymamy rozwiązania, które będą odpowiadać naszym potrzebom. Niestety, zawsze w jakiejś formie zapłacimy za czas jaki firma poświęci na proces „wgryzania się” w naszą organizację.
6. Zarządzanie zmianą
Wdrożenie dużego projektu to proces, który wymaga nie tylko odpowiedniego planowania, ale również skutecznego zarządzania zmianą.
Bywa, że zapisy umowne to jedno a praktyka codzienna drugie. Póki mieścimy się w czasie, kosztach i zakresie to wszystko jest pięknie. Często jednak – szczególnie gdy terminy się zbliżają – dochodzi do konfliktów i przepychanek na tym tle. Zaczyna się udowadnianie: kto, kiedy, komu i czego nie przekazał albo nie potwierdził zgodnie z zapisami umownymi. W skrajnych przypadkach może dojść do tego, że zamiast ratować projekt będziemy zbierać materiały dowodowe do ewentualnego postępowania w sądzie albo przynajmniej dla prawników.
Drugi aspekt tego punktu to zrozumiała niechęć wykonawcy do jakichkolwiek zmian w zakresie projektu, jeśli był on ściśle uzgodniony. Wykonawca często „okopuje się” na swoim stanowisku i „na siłę” dostarcza nam funkcje, które w trakcie trwania projektu stały się niepotrzebne (bo zmieniło się prawo czy nasz proces biznesowy). Jeśli nie uwzględnimy takich sytuacji w projekcie umowy to możemy po 3 latach pracy dostać system, który nijak ma się do naszych aktualnych potrzeb.
Zmiany w zespole złożonym z pracowników są zazwyczaj dużo prostsze i „zwinniejsze”. Nie wymagają renegocjacji, aneksowania umów itd.
7. Problemy z budżetami i harmonogramami
W wypadku opóźnień środki przeznaczone na projekty nie są „z automatu” przekazywane na kolejny rok. Wykonawcy też mają jakieś założenia przychodów, które planują osiągnąć w danym okresie. Co gorsza, w kolejnym roku wcale nie ma gwarancji, że dostaniemy kasę na dokończenie projektu.
Zaczyna nas wtedy kusić wizja podpisania protokołu cząstkowego lub warunkowego, mimo że umowa takich nie przewiduje. Niestety zapłacenie (chociaż części) w uzgodnionym terminie, mimo nieukończenia prac to proszenie się o wszelkiej maści kłopoty. Mimo tego czasem ryzykujemy – tylko po to, aby nie narażać się na procedury przenoszenia środków inwestycyjnych, wyjaśniania zmian budżetowych i walki o przyznanie środków (budżety to zresztą temat na całkiem osobny wpis).
Te sytuacje wzmagają napięcia, zwiastują konflikt a ich obsługa wymaga dodatkowego czasu, doświadczenia a zazwyczaj też uzyskiwania opinii działów prawnych i księgowych.
8. I tak nie unikamy pracy naszych developerów
Korzystając z usług firmy zewnętrznej do wdrożenia aplikacji, nie możemy zapominać o potrzebie posiadania własnego (lub niezależnego, wynajętego na zewnątrz) zespołu deweloperów i wdrożeniowców.
To oni powinni być odpowiedzialni za ocenę, testy bezpieczeństwa, odbiór kodu, zarządzanie nim w przyszłości. Nierzadko również zajmą się wdrożeniami, konfiguracją CI/CD, czy dalszym rozwojem aplikacji – własnymi siłami czy też zlecając to do kolejnej firmy podwykonawczej.
9. Koszty
Porównanie kosztów wdrożeń, które są realizowane przez własny zespół i tych, które są zlecane na zewnątrz, często pokazuje, że korzystanie z własnych sił może być tańsze i bardziej efektywne. Nie mogę niestety podzielić się realnymi przykładami z uwagi na oświadczenia o poufności. Mając za sobą już ponad 20 lat pracy w dużej spółce skarbu państwa miałem możliwość porównania całościowych nakładów poniesionych przez zamawiającego w kilkudziesięciu dużych i małych wdrożeniach. Nie mogę podać twardych liczb, ale pewien, że licząc TOC (całkowity koszt posiadania) dla dużych rozwiązań budowa ich własnymi siłami wyjdzie taniej.
Podsumowanie
Duże i skomplikowane wdrożenia realizowane przez firmy zewnętrzne często niosą ze sobą wiele problemów i wyzwań, które mogą negatywnie wpłynąć na cały proces.
Mogą to być problemy związane z komunikacją między firmami, niejasno określonymi wymaganiami, brakiem zaangażowania ze strony zewnętrznych wykonawców czy też trudnościami w dostosowaniu się do specyficznych potrzeb naszej organizacji.
Dlatego moim zdaniem wiele organizacji, które twierdzą, że nie stać ich na wdrożenie własnymi siłami (bo etaty kosztują) tak naprawdę „pchają się w gips” i jeszcze większe koszty.
Jedno ważne zastrzeżenie. Mówię o dużych, ważnych, krytycznych projektach. O systemach, które są unikalne, nie do kupienia na rynku, dają nam przewagę konkurencyjną. Procesach, których usprawnienie wymaga szycia na miarę a nie dostosowania się do istniejących gotowych produktów.
Coś jest możliwe do zakupu „z półki” i nagniemy się trochę do sposobu działania gotowego systemu? Jest mniej ważne, tańsze, prostsze? Da się napisać w miesiąc czy kwartał? Jak najbardziej warto rozważyć zakup gotowego produktu lub zlecenie jego budowy do firmy zewnętrznej.
Dziękuję, jeśli nadal czytasz ten wpis. Pora na Ciebie. Jakie Ty masz doświadczenia w opisanym temacie? Chętnie poznam inny punkt widzenia. Zapraszam do komentowania!