Kiedy i czy w ogóle zatrudnić konsultanta zewnętrznego w firmie?

Jeśli zastanawiałeś się, czy w Twoim projekcie potrzebny jest konsultant zewnętrzny lub wiesz, że jest potrzebny, ale nie wiesz jak się przygotować na jego przybycie, to myślę, że ten krótki tekst jest dla Ciebie.

Napisałem go na podstawie moich doświadczeń. Tych całkiem dobrych i całkiem nieudanych, gdyż być może nie dla każdego to jest oczywiste, ale przybycie konsultanta nie zawsze kończy się spektakularnym sukcesem. W tekście odpowiem na cztery ważne pytania:

1. Dlaczego warto zatrudnić konsultanta z zewnątrz?
2. Kiedy to robić, a kiedy zdecydowanie nie?
3. Na co się przygotować, kiedy on się już pojawi?
4. Co daje konsultant zewnętrzny?

Dlaczego warto (jeśli warto) zatrudnić konsultanta?

Osoba z zewnątrz to świeże spojrzenie na problem rozwiązywany przez zespół. Jest to wartość tak duża, że czasami zatrudnienie kogoś na jeden lub dwa dni, kto wysłucha zespołu, porozmawia z nim i podzieli się swoimi luźnymi spostrzeżeniami na temat problemu, wybranego rozwiązania czy nawet doboru frameworków/bibliotek, ma ogromny sens. Osoba taka pełni rolę „gumowej kaczuszki”, ale w wersji interaktywnej. Jeśli problem jest poważniejszy niż tylko chwilowy spadek formy zespołu, to jeden lub dwa dni raczej nie wystarczą.

źródło: wikipedia

Jednak nie tylko świeże spojrzenie jest ważne. Bardzo cenna okazuje się „polityczna” niezależność od rozmaitych „układów” w samym zespole czy nawet szerzej - w całej organizacji. Taka niezależność pozwala zwrócić uwagę na różne nietypowe lub po prostu dziwaczne rozwiązania w projekcie, czyli na coś, czego nikt z wnętrza nie zrobi z obawy przed konsekwencjami. Oczywiście, jeśli taka sytuacja występuje, to jest to już objaw pewnej poważnej patologii, ale tym nie będę się dziś zajmował.

Jeszcze jednym - być może najważniejszym - efektem rozmowy z konsultantem (chociaż to mocno zależy od jego charyzmy i charakteru) może być wzrost morale zespołu. Dobry profesjonalista potrafi w zespół tchnąć ducha i zupełnie nowe siły oraz motywację do nauki, rozwoju, eksperymentowania itd.

Kiedy to robić, a kiedy zdecydowanie nie?

Zacznijmy od początku - kiedy w zespole pojawia się potrzeba zatrudnienia konsultanta z zewnątrz?

Najczęściej pojawia się, gdy projekt jest rozwijany przez grupę mało doświadczonych programistów. Jednak niekoniecznie. Bardziej doświadczony zespół, w szczególnych okolicznościach także może doprowadzić do sytuacji „prawie bez wyjścia”. Zwykle przyczyną jest chaotyczny rozwój systemu, a tenże może wynikać z ciągle zmieniających się potrzeb biznesowych czy niekończącej się lawiny „ficzerów do zaimplementowania na wczoraj”.

Zarówno niedoświadczone, jak i doświadczone zespoły (lub po prostu pojedynczy programiści) mają tendencję do chodzenia na skróty. Wynika to albo z niewiedzy (czyli przypadek pierwszy), albo z chaosu wokół (przypadek drugi).

Przypadek pierwszy

Czyli niedoświadczony zespół w idealnych warunkach. Znają świetnie kod, nie znają wzorców projektowych, nie znają frameworków innych niż te, które w projekcie były od początku. Dobre praktyki są im zupełnie obce, „czysty kod” kojarzy im się wyłącznie z myciem monitora. Nadrabiają dobrą miną oraz heroicznym wręcz zaangażowaniem na każdą pojawiającą się potrzebę od „biznesu”. Odpalają swoje IDE i kodują jak szaleni. Przelewają hektolitry kawy, redbulla, zjadają kolejne pizze i po godzinach walki z pełnym poświęceniem, mogą z dumą objaśnić światu, że skończyli. Zwykle mają rację. „Nowy ficzer” działa, ale czasami inne (te już istniejące) zaczynają działać inaczej. Przypadkowo albo wcale, ale nie ma to znaczenia - bo herosi tego nie zauważają. Przecież nie ma testów (to nie gimnazjum, prawda?) a bohaterowie nie klikają dwa razy w to samo.

Przypadek drugi

Czyli doświadczony zespół w warunkach iście bojowych. Na początku jest cudownie. System rozwija się harmonijnie, „biznes” nie oczekuje zbyt wiele, a „ficzery” wymyślane są, by jakoś zapełnić czas. Nadchodzi jednak chwila, gdy “biznes” dostrzega wartość aplikacji, a jednocześnie widzi, że brakuje „kilku ficzerów, wszystkie na wczoraj”. Zespół oczywiście zabiera się do jeszcze cięższej pracy. Heroicznej. Oczywiście. W związku z tym, że heroizm wymaga poświęcenia, najczęściej, co już wspomniałem, poświęca się w takich sytuacjach dobre praktyki programistyczne, projektowe a co najważniejsze, pierwszą ofiarą stają się testy. Wszystkie. Bez wyjątku. Nikt w ferworze heroicznej walki o lepsze jutro nie myśli o takich drobiazgach jak jakiekolwiek testy automatyczne. Nikt także nie testuje ręcznie. Szkoda czasu, przecież wczoraj działało, prawda? Paradoksalnie, w trakcie tej walki o lepsze jutro, programiści zaczynają zachowywać się, jakby jutro miało nie nadejść.

Efekt

Efekt będzie ten sam w obu przypadkach. W końcu nadchodzi moment, gdy żadna ilość kofeiny i pizzy nie jest w stanie posunąć projektu do przodu. Powstają „ficzery”, ale ewidentnie coś się złego dzieje. Zespół to wyczuwa podskórnie, niemalże na granicy świadomości, ale nie wie, o co chodzi. Przecież jeszcze miesiąc wcześniej było dobrze... W okolicy pojawia się tajemnicze, nienamacalne zło, niczym przybyłe wprost z mrocznych opowieści Stephena Kinga czy Grahama Mastertona.

Czas na działanie

Zespół zbiera się na naradzie (niekoniecznie tajnej) i wspólnie decyduje się zatrudnić konsultanta z zewnątrz. Zwykle jednak jako cel, zespół wskazuje zachowanie tempa „dostarczania ficzerów”. Czasami, gdy ktoś z zespołu otrze się chociaż o „czysty kod”, celem staje się także poprawienie projektu. Jeśli przypadkiem zderzy się także z “czystą architekturą”, to także poprawienie architektury. Jednak absolutnie zawsze chodzi o poprawienie tempa “dostarczania ficzerów”.

Brawo! Dobra decyzja! Jednak czy to takie proste? Oczywiście, że nie. Do przyjścia konsultanta, który poprowadzi drużynę herosów, trzeba się przygotować. Przygotowanie musi być na kilku poziomach.

Jak się przygotować na przybycie konsultanta?

Tak naprawdę to poniższa lista powinna być przeglądana zawsze, gdy ma dołączyć chociażby nowy programista do zespołu. Jednak temat onboardingu jest tak ważny, że zasługuje na osobny tekst.

Po pierwsze infrastruktura

Bardzo frustrujące jest, gdy konsultant pojawia się pierwszego dnia pełen chęci niesienia pomocy i słyszy: jest problem z dostępem do repozytorium, ale nie przejmuj się, Michał/Jasiek/Witek opowie Ci o systemie. No świetnie, ale konsultant nie przychodzi tylko słuchać. Przychodzi pomóc. Chce obejrzeć kod, obejrzeć system itd. I znowu słuchać, patrzeć w kod i słuchać. Jeśli instalacja systemu jest bardziej skomplikowana niż mvn clean jetty:run, przygotujcie zawczasu choćby dokumentację najprostszą: co należy zrobić, krok po kroku, żeby system zainstalować. Idealnie byłoby, gdyby do tego był jakiś skrypt, konfiguracja dla dockera, chefa, vagranta, cokolwiek... jest 2018 rok. Zrzut ekranu z konfiguracją, która działa u któregoś z developerów oraz porada - zrób u siebie tak jak u mnie, to będzie działać - jest mało zachęcająca. Nie wspomnę nawet, że nie jest profesjonalna. Irytujące dla konsultanta jest usłyszenie czegoś w stylu “hej, myślę, że taki skrypt i dokumentacja to byłoby dla Ciebie dobre pierwsze zadanie”. WTF?

Po drugie, komunikacja

Jeśli zatrudniasz konsultanta, to zapewnij mu wsparcie kogoś z zespołu, kto dysponuje wiedzą na temat całego systemu, nad którym ma pracować. Człowiek, który przychodzi z zewnątrz, nic nie wie. Potrzebuje dużo informacji, ale nic nie jest w stanie zapewnić przewodnika. Zwykle, gdy pojawia się potrzeba zatrudnienia pomocy z zewnątrz, system wygląda jak zapleśniałe spaghetti. „Po prostu spaghetti” to jest jeszcze ten moment, kiedy kawa i pizza dodają wystarczająco dużo siły i otuchy, by dzielnie dorabiać „ficzery”. To jest coś, co konsultant już widział wiele razy, ale za każdym razem makaron splątany jest w nieco odmienny sposób i pleśń także narasta inaczej. Jeśli pracujecie zdalnie, to koniecznie cały zespół powinien być dostępny na jakimś komunikatorze, który będzie dostępny dla konsultanta. Nie, rozwiązania korporacyjne nie są dobre. Wiem, że Lync jest w systemie, ale nie będzie dostępny dla konsultanta. Chyba że zostanie wyposażony w firmowy komputer z dostępem do Waszej sieci korporacyjnej. Postarajcie się o Slacka/Mattermosta lub Skype. Cały zespół. Nie nicki, tylko imię i nazwisko. Ze zdjęciem. Człowiek Was nie zna i nie skojarzy po nicku.

Po trzecie, gotowość na krytykę
 

To pewnie najtrudniejszy punkt przygotowań. Tak, tak… pewnie przyjdzie człowiek z zewnątrz i jak rasowy hydraulik powie coś w stylu: oooo Panie, ale tu panu ktoś s… I pewnie byłoby nawet zabawnie, ale ten ktoś, to Wy. Może konsultant będzie taktowny, a może nie. Pamiętajcie, nie zatrudniacie go dlatego, że jest taktowny, tylko dlatego, że Wy jesteście/byliście do bani. A zadaniem konsultanta jest pokazać gdzie, jak i dlaczego. Krytykę należy przyjąć z uśmiechem i pokorą, wyciągnąć wnioski i zrobić plan naprawczy.

Po czwarte, wsparcie

Większość „upadłych” systemów upada dlatego, że nie ma testów. Klasyk napisał, że testy nie zapewniają dobrej architektury, ale chronią przed złą. Jeśli ich nie ma, to wiadomo… prędzej czy później musi pojawić się konsultant. Jeśli konsultant zaproponuje doprowadzenie systemu do chociaż takiej formy automatyzacji, żeby dało się napisać jakiekolwiek smoketesty. Pomóżcie mu. To jest dla jego zdrowia psychicznego i Waszego dobra na przyszłość. Kilka kluczowych „smoków” pozwala łatwiej zapanować nad zmianami. Konsultant może zrobić zmiany w kodzie, ale jeśli nie wie jak je przetestować, to jest spore ryzyko błędu. Zaufajcie, jeśli mówi, że coś trzeba zrobić. Zawsze pamiętajcie, że zatrudniacie takiego gościa nie dlatego, że jest miły, ładnie się uśmiecha, tylko dlatego, że wie coś, czego nie wiecie Wy albo przynajmniej jest w stanie to dostrzec. U klienta kiedyś usłyszałem: widzisz, nie mamy żadnego testu, a wszystko działa. Te testy są jednak przereklamowane.

Po piąte, cierpliwość

Cierpliwość potrzebna jest na dwóch różnych poziomach. Po pierwsze, będziecie słyszeć mnóstwo pytań. Czasami kłopotliwych, czasami po prostu wynikających z ciekawości. Dlaczego coś zostało zaimplementowane tak, a nie inaczej, dlaczego coś wygląda dziwnie? Może tak musi być, bo jakaś zewnętrzna część systemu nie działa, gdy jest inaczej itd. Drugi poziom to czas. Konsultant zwykle potrzebuje kilku tygodni, żeby zrozumieć, jak ma działać system (to jak działa i dlaczego, pozostanie tajemnicą znacznie dłużej). Pewnie chętnie zrobi z kimś z zespołu jakiś „ficzer”. Pewnie zaproponuje pair programming. Należy się zdecydowanie zgodzić. Kluczowa w takiej chwili jest pomoc w zrozumieniu systemu oraz Waszego modelu tego systemu. Najpierw musi zrozumieć, w jaki sposób Wy widzicie system i nad nim pracujecie, a dopiero później może zaproponować zmiany.

Po szóste, zrozumienie

Mieliście zrobić konia. Wyszedł jeż. Biznes oczekuje, że będzie odrzutowiec. No i teraz oczekiwania Wasze mają być osiągalne. Konsultanci lubią wyzwania i chętnie je podejmują. W końcu to ich praca. Zapewne powiecie tak: zrób tak, żeby to ciągle był jeż, bo my umiemy do jeża dodawać ficzery, ale też tak, żeby pewnego dnia w jednej chwili ten jeż zamienił się w odrzutowiec i żeby te wszystkie ficzery nie były kolcami na jeżu, ale silnikami w nowoczesnym odrzutowcu. No... i zacznij od skryptu do stawiania systemu, bo wiesz... przyda się. To nie jest łatwe. Zwykle konsultant najpierw zaproponuje zmianę jeża tak, żeby miał silniki na grzbiecie i potem powoli zacznie przerabiać go na odrzutowiec. To się da zrobić, ale z czasem. Przy otwartości na propozycje i zmiany.

Co daje konsultant zewnętrzny?

Świeże spojrzenie

Przede wszystkim, świeże spojrzenie na problem i jego rozwiązanie. Na pewno łatwiej mu wskazać problemy w rozwiązaniu niż osobie z zespołu. Dla niego wszystkie nietypowe rozwiązania są podejrzane. Oczywiście, nie każde nietypowe rozwiązanie jest złe, ale każde powinno być podejrzane. Zewnętrzny konsultant najczęściej dobrze zapoznany jest z katalogami wzorców obiektowych czy funkcyjnych. I dobry konsultant jest na bieżąco ze zmianami i opracowaniami świata IT.

Brak ograniczeń politycznych

Zespół zwykle jest „uleżany” w jakiś sposób. Jego członkowie czują do siebie sympatię i na przykład wdzięczność za to zatrudnienie czy coś podobnego (rzadko są to emocje negatywne). Często jest to także jakaś służbowa hierarchia, w której podwładny czuje respekt przed przełożonym, co staje się podświadomą blokadą jakiejkolwiek krytyki poza pozytywną. Nawet widząc, że przełożony robi fuszerkę, developer uzależniony od szefa raczej nie odezwie się. Człowiek z zewnątrz nie ma tych ograniczeń. Przychodzi, widzi jakiś programistyczny dziwoląg, więc bez zażenowania zadaje pytania. A są to trudne pytania.

Ignorancja dziedzinowa

W większości wypadków zewnętrzny konsultant nie ma wiedzy dziedzinowej dotyczącej systemu. Trzeba mu tę wiedzę przekazać. Sam moment przekazywania wiedzy, opis dziedziny i sposoby jej zmapowania na system, mogą wytworzyć pretekst do zmian. Konsultant działa wtedy jak „gumowa kaczuszka”, o której wszyscy zapominamy chociaż nie powinniśmy.

Reasumując

Jeśli czujecie, że w projekcie nastąpiło zwolnienie pracy, jeśli okazuje się, że pojawiają się wąskie gardła w wydajności, których nie możecie namierzyć i wydzielić, żeby nad nimi pracować, jeśli okazuje się, że klasy mają wzajemne referencje, że konfiguracja budowania jest trudna itd., to warto zatrudnić konsultanta. Jeszcze raz podkreślam: bądźcie gotowi na krytykę, zmiany, naukę. Jestem fanem starych westernów, więc nawiążę do jednego z nich. W klasyku „Siedmiu wspaniałych” - konsultanci z zewnątrz łatwiej obronili wioskę, gdy pomagali im wieśniacy, którzy przeszli trening z bronią. Chociaż była to dla nich kompletna nowość. Wcześniej jednak było kilka trudnych rozmów pomiędzy konsultantami i klientem (rewolwerowcy i wieśniacy).

W kolejnym tekście napiszę kilka słów o wzorcach i antywzorcach, z którymi się spotkałem w systemach klientów. Pokażę kilka naprawdę dziwnych konstrukcji i oczywiste sposoby ich poprawienia. Wszystkie dotyczą projektów rozwijanych w Javie. Niektóre z nich to prawdziwe perełki.

Można się ze mną skontaktować pod adresem [email protected], również w celu wynajęcia mnie do konsultacji :)