Ratowanie projektu IT: 5 pułapek przy zatrudnianiu konsultantów

Twój projekt technologiczny płonie. Przekroczony budżet, opóźnienia, zarząd zadaje trudne pytania. Ktoś proponuje: “Może zatrudnimy konsultantów? Accenture, Deloitte, McKinsey Digital, albo jakąś mniejszą firmę.” Brzmi rozsądnie. Prestiżowa marka uspokoi inwestorów. Konsultanci mają sprawdzone metody. Może nawet wezmą odpowiedzialność, jeśli coś pójdzie nie tak.

Zanim podpiszesz umowę, musisz wiedzieć jedno. Współpraca z konsultantami, szczególnie w modelu godzinowym i z zewnętrznymi zespołami, niesie ryzyka, które warto znać z góry. Nie wynikają one ze złej woli, tylko z samej konstrukcji tego modelu. Jeśli je poznasz, łatwiej ocenisz, czy taka współpraca pasuje do Twojej sytuacji, a jeśli tak, jak ją ułożyć, żeby zadziałała.

W modelu godzinowym cele konsultanta i Twoje mogą się rozjechać

Standardowe umowy T&M (Time & Materials) tworzą przepaść między tym, co dobre dla konsultanta, a tym, co dobre dla Ciebie. Konsultant zarabia na przepracowanych godzinach. Ty potrzebujesz rezultatów. Ryzyko rozkłada się nierówno: jeśli projekt utknął, to Ty ponosisz konsekwencje biznesowe, a rachunki nadal przychodzą. To natura tego modelu współpracy, nie wina konsultantów.

Projekty ratunkowe wymagają szybkich decyzji i błyskawicznych iteracji. T&M nie karze za powolne postępy tak, jak robią to umowy za stałą cenę lub płatności za kamienie milowe. Bez świadomych ustaleń nikt nie pilnuje tempa – można szlifować detale, aż skończą się pieniądze.

Ale powiedzmy sobie uczciwie: to działa w obie strony. Klienci, którzy zwlekają z decyzjami, co tydzień zmieniają zakres prac albo ukrywają kluczowe informacje, też skazują operację ratunkową na porażkę. Konsultant, który działa po omacku, bo klient unika decyzji, ma równie ciężko. Żeby współpraca zadziałała, obie strony muszą naprawdę grać do jednej bramki.

Jak lepiej skonstruować umowę

Wynegocjuj, żeby przynajmniej część rozliczenia była powiązana z kamieniami milowymi i konkretnymi rezultatami, a nie wyłącznie z przepracowanymi godzinami. Pod presją trudniej negocjować, ale jeśli dostawca z góry wyklucza takie rozliczenie, to powinno dać Ci do myślenia. Płatności za kamienie milowe łatwiej wynegocjujesz z mniejszą firmą niż z dużą korporacją konsultingową, która trzyma się sztywnych procedur.

Model T&M ma swoje uzasadnienie. Klienci często wybierają go, bo nie potrafią jasno zdefiniować zakresu prac, chcą elastyczności bez renegocjacji umowy albo ich procedury zakupowe tego wymagają. Twoim Celem nie powinno być wyeliminowanie T&M, ale dodanie mechanizmów rozliczania za wyniki.

Sprawdzą się tutaj się modele hybrydowe: T&M na etapie analizy, gdzie zakres jest jeszcze niepewny, a stała cena na realizację jasno zdefiniowanych celów.

Wpisz do umowy premie uzależnione od wyników, np. powiązane z datą uruchomienia czy poziomem dostępności systemu. Kar raczej nie wynegocjujesz, bo konsultanci słusznie odmówią warunków, w których klient może storpedować rezultat powolnymi decyzjami czy zmianami zakresu. Ale konsultant, który odmawia jakiejkolwiek premii za sukces, daje Ci jasny sygnał, że nie ma zamiaru brać odpowiedzialności.

Jeśli żadne z powyższych rozwiązań nie przejdzie, wynegocjuj przynajmniej cykliczne spotkania decyzyjne, na których możesz skorygować zakres albo wycofać się bez kar. To uczciwy kompromis: masz kontrolę nad projektem, a konsultant nie ponosi nieuzasadnionego ryzyka.

Wiedza odchodzi razem z konsultantami

W kryzysie wszyscy myślą tylko o jednym: “po prostu to naprawcie”. Nikt nie zastanawia się, co będzie, gdy konsultanci skończą swoją pracę. Jeśli nikt nie zaplanuje przekazania wiedzy, konsultanci odejdą, a Twój zespół zostanie z rozwiązaniami, których może do końca nie rozumieć.

Nie wszystko da się przekazać przez dokumentację. Dlaczego wybrano daną architekturę, jakie zastosowano obejścia, jakie edge case’y ktoś rozwiązywał. Tę wiedzę konsultanci zabierają ze sobą, gdy odchodzą. A że konsultanci są zwykle rozliczani z widocznych rezultatów, przekazywanie wiedzy schodzi na dalszy plan, chyba że wprost wpiszesz je do umowy.

Efekt? Wszystko będzie działać, dopóki konsultanci będą na miejscu. Po ich odejściu system zacznie się sypać. Twój zespół będzie miał dokumentację, ale może mu brakować wiedzy, żeby skutecznie diagnozować problemy i dalej go rozwijać.

Jak zaprojektować transfer wiedzy

Wpisz przekazanie wiedzy do umowy jako osobny wymóg z kryteriami odbioru, np. “Twój inżynier potrafi samodzielnie wdrożyć zmianę” albo “Twój zespół potrafi zdiagnozować i naprawić problem produkcyjny bez wsparcia konsultanta”.

Wymagaj, żeby konsultanci pracowali wspólnie z Twoim zespołem, ale dostosuj model do swojej sytuacji:

• Jeśli masz własny zespół: Niech konsultanci pracują bezpośrednio z Twoimi programistami. To najlepszy sposób na przekazywanie wiedzy.
• Jeśli pracujesz z zewnętrznym zespołem vendora: Dopilnuj, żeby konsultanci włączyli się w pracę tego zespołu, a nie działali obok niego. Programiści vendora też potrzebują tej wiedzy.
• Jeśli nie masz zespołu: Od pierwszego dnia zaplanuj, kto przejmie utrzymanie po konsultantach. Wyznacz lub zatrudnij taką osobę jak najwcześniej, żeby pracowała z konsultantami od początku.

Jeśli projekt jest duży, rozłóż odejście konsultantów w czasie, żeby Twój zespół przejmował odpowiedzialność stopniowo, a nie z dnia na dzień. Dodaj do umowy okres wsparcia, w którym konsultanci będą odpowiadać na pytania, nie pracując już bezpośrednio z zespołem.

Konsultanci mogą niepotrzebnie skomplikować Twój stack technologiczny

Konsultantów ciągnie do technologii, które dobrze wyglądają w CV albo które po prostu dobrze znają. Jeśli tego nie przypilnujesz, łatwo o wybory, które będą lepiej pasować do branżowych trendów niż do faktycznych możliwości Twojego zespołu. Nowoczesne technologie kuszą. To, co w branży uchodzi za standard, to często po prostu to, czego używają liderzy na rynku. Co nie znaczy, że to samo sprawdzi się u Ciebie.

To, co działa w skali Google’a, może być nie do udźwignięcia dla firmy ze 100-500 pracownikami i małym zespołem programistów. Jeśli masz niewielki zespół, możesz nie dać rady utrzymać przekombinowanego systemu. Jeśli polegasz na zewnętrznych dostawcach, zbyt złożona architektura uzależni Cię od nich i trudno będzie Ci się z tego wyrwać. W obu przypadkach efekt będzie ten sam: Twoje koszty będą rosły i uzależnisz produkt od małej grupy specjalistów, którzy mogą odejść w każdej chwili.

Ale czasem “prostsze rozwiązanie” jest dokładnie tym, co wpędziło Cię w kłopoty. Tutaj nie chodzi o wybór “proste vs złożone”. Chodzi o to, czy złożoność wynika z Twoich realnych potrzeb, czy tylko z branżowych trendów. Dobry konsultant powinien wyjaśnić, dlaczego konkretny wybór pasuje do Twoich możliwości i skali, a nie zbyć temat słowami “taka jest dobra praktyka”.

Jak zxabezpieczyc się przed złymi wyborami technologicznymi

Określ ograniczenia technologiczne w umowie: zatwierdzone języki, frameworki i infrastrukturę. Wymagaj pisemnego uzasadnienia dla każdej nowej technologii, ze wskazaniem, jak wpłynie to na koszty i trudność utrzymania.

Wpisz “możliwość utrzymania przez Twój obecny zespół” jako wymóg. W razie wątpliwości, zapytaj wprost: “Czy moi programiści będą w stanie utrzymać system po Waszym odejściu?” Jeśli odpowiedź brzmi “będziecie musieli zatrudnić nowych specjalistów”, to sygnał, że proponowane rozwiązanie jest niedostosowane do Twojego kontekstu.

Wymagaj spotkania kontrolnego, zanim zapadną kluczowe decyzje architektoniczne. Dzięki temu będziesz mógł zareagować, zanim będzie za późno na zmianę.

Zespół nie przyjmie konsultantów z otwartymi ramionami

Każda organizacja ma coś, co sami konsultanci nazywają “układem odpornościowym”. W skrócie: chodzi o instynktowne występowanie pracowników w obronie istniejących procesów i relacji. To zjawisko jest tak znane, że firmy konsultingowe często z góry ostrzegają przed nim potencjalnych klientów.

Jeśli nie zadbasz o to, żeby konsultanci i Twój zespół naprawdę ze sobą współpracowali, rekomendacje zostaną po cichu zignorowane. Twoi ludzie mają własne procesy (dobre lub złe), nawyki i kulturę, które wynikają z tego, jak działa cała Twoja firma. Konsultanci nie znają tych realiów. Możesz być pewny, że ludzie będą bronić swojego dotychczasowego sposobu pracy, nawet gdy zmiany miałyby im pomóc.

Nie zawsze to źle. Jeśli konsultant proponuje coś, co nie pasuje do Twojej sytuacji, opór zespołu może Cię uchronić przed błędną decyzją. Problem w tym, że ten mechanizm nie rozróżnia dobrych zmian od złych. Odrzuca jedne i drugie.

Typowe wzorce oporu

Izolacja: zespół pozwala konsultantom pracować, ale nadal “robi swoje”. Praca konsultantów toczy się równoległym torem i nie wpływa na codzienne działanie zespołu.

Asymilacja: zespół przejmuje nową terminologię, ale sposób pracy zostaje ten sam. Forma niby jest, treści brak.

Bierny opór: zespół po prostu bierze konsultantów na przeczekanie. Odpowiedzi się ciągną, spotkania są przekładane, zaangażowanie jest minimalne. Wszyscy przeciez wiedzą, że konsultanci w końcu odejdą.

Jak zadbać o skuteczną integrację

Zacznij od doboru konsultantów. Duże firmy konsultingowe często wysyłają świetnie przygotowany zespół sprzedażowy w trakcie wyboru, a potem inny zespół realizacyjny. Poproś o spotkanie z ludźmi, którzy faktycznie będą pracować nad Twoim projektem i wpisz ich nazwiska do umowy. Sprawdź referencje konkretnie dla projektów ratunkowych, nie dla samych nowych wdrożeń.

Gdy współpraca się zacznie:

• Dopilnuj, żeby konsultanci pracowali razem z Twoim zespołem, nie obok niego.
• Zadbaj o to, żeby konsultanci rozmawiali bezpośrednio z programistami, nie tylko z zarządem. Jeśli komunikacja będzie przechodzić wyłącznie przez dyrektorów, zespół potraktuje konsultantów jako narzędzie kontroli, nie jako wsparcie.
• Powiedz zespołowi wprost, dlaczego szukasz pomocy i co chcesz osiągnąć. Niespodzianki rodzą niechęć.

Niejasne wymagania projektowe spokonają każdego konsultanta

Metodologie, frameworki i narzędzia rozwiązują problemy techniczne. Strategicznego chaosu raczej nie uporządkują. Sprzeczne wymagania, brak zgody co do priorytetów, niejasna potrzeba rynkowa – żaden konsultant nie naprawi tego lepszymi procesami.

Fred Brooks w eseju “No Silver Bullet” (1986) rozróżnił złożoność “przypadkową” i “istotną”. Przypadkową da się naprawić: złe narzędzia, bałagan w kodzie, wolne procesy CI/CD. Konsultanci zwykle są w tym świetni (jeśli zespół współpracuje). Istotna jest trudniejsza: zagmatwana logika biznesowa, niezdefiniowane rynki, źle zrozumiane potrzeby użytkowników. Tu trzeba najpierw dogadać się wewnętrznie i zbadać rynek, nie szukać rozwiązań technicznych.

Według Brooksa to właśnie ta “istotna” złożoność odpowiada za większość trudności w tworzeniu oprogramowania. Konsultanci mogą usprawnić Twoje narzędzia i procesy, ale nie dogadają za Ciebie interesariuszy. Mogą pomóc ustalić, co Twój produkt ma naprawdę robić. Pytanie tylko, ile to będzie kosztować.

Bohater nie wystarczy

Gdy projekt się pali, kusi, żeby szukać “bohatera”, który zdziała cuda. Ale jeśli przetrwanie wymaga heroizmu, to znak, że problem leży głębiej. Konsultant może wylewać wodę z łódki, ale nie załata dziury, jeśli nikt nie będzie chciał przyznać, że ona w ogóle istnieje.

Konsultant rozwiąże problem tak, jak go rozumie tu i teraz. Jeśli podstawowe wymagania będą ciągle się zmieniały albo okaże się, że nigdy na dobrą sprawę nie istniały, akcja ratunkowa się nie uda.

Zdiagnozuj problem, zanim zatrudnisz konsultanta

Zanim podpiszesz umowę na ratowanie projektu, zdiagnozuj, czy Twój problem jest głównie techniczny czy organizacyjny. Jeśli interesariusze nie mogą się zgodzić, co produkt ma robić, żaden konsultant go nie naprawi. Najpierw musicie się dogadać.

Przeprowadź krótki etap rozpoznania, żeby ustalić wymagania, priorytety i warunki powodzenia, zanim zobowiążesz się do realizacji. A gdy już zatrudnisz konsultantów, dopilnuj, żeby mogli szybko uzyskiwać jasne odpowiedzi. Każdy dzień czekania na decyzje to dodatkowe koszty.

Co dalej

Twój następny krok zależy od Twojej obecnej sytuacji.

Jeśli martwi Cię rozliczenie godzinowe, dowiedz się, kiedy stała cena lepiej się sprawdzi. Jeśli obawiasz się, że wybory technologiczne uzależnią Cię od dostawcy, przeczytaj, jak rozpoznać i uniknąć vendor lock-in.

Jeśli zastanawiasz się, jak powinno wyglądać przejęcie projektu, opublikowaliśmy listę kontrolną przejęcia projektu IT. Jeśli nie wiesz, co właściwie jest zepsute, nasza diagnoza zdrowia produktu pomoże Ci ustalić, czy problem leży w strategii, analizie, realizacji czy zarządzaniu.

Zanim zdecydujesz się na konkretną ścieżkę ratowania projektu, rozważ niezależny audyt, żeby zrozumieć, co faktycznie jest zepsute i jakie masz opcje.

Podsumowanie

Współpraca z konsultantami w modelu godzinowym wiąże się z konkretnymi ryzykami: sprzeczne interesy, utrata wiedzy po zakończeniu współpracy, przekombinowane technologie, opór zespołu i błędna diagnoza problemu. Jeśli świadomie się nimi nie zajmiesz, mogą storpedować całe ratowanie projektu.

Zatrudnienie konsultantów może się sprawdzić, jeśli problem jest dobrze zdiagnozowany. Wielu z nich, szczególnie mniejsze firmy nastawione na wyniki, z własnej inicjatywy dba o to, żeby współpraca faktycznie działała. Nie chodzi o zakładanie złych intencji. Chodzi o to, żeby ułożyć współpracę tak, żeby jej sukces nie zależał od szczęścia.

Zanim podpiszesz umowę, zadaj sobie trzy pytania. Czy obie strony odpowiadają za wyniki? Czy mój zespół będzie silniejszy po tym wszystkim, a nie tylko mój kod? Czy ustalilismy, co właściwie jest zepsute?

Jeśli odpowiedź na wszystkie trzy brzmi “tak”, masz dobry punkt wyjścia. Jeśli nie, najpierw rozwiąż te kwestie.