Żeby zrozumieć horror pracy z praktykantami, stażystami i innymi istotami czasowo pojawiającymi się w projekcie, trzeba najpierw porzucić klasyczne wyobrażenie o pracy jako procesie, w którym ktoś zaczyna zadanie, rozumie je, wykonuje, testuje, poprawia, a następnie kończy.
To założenie jest piękne. Niestety należy do tej samej kategorii zjawisk co punktualne zebrania, kompletna dokumentacja techniczna oraz klient, który wie, czego chce przed wdrożeniem, a nie trzy tygodnie po nim.
W praktyce wygląda to inaczej. Ludzie przychodzą i odchodzą w dowolnych momentach. Wchodzą do projektu, otwierają jakiś fragment kodu, dokumentacji albo konfiguracji, wykonują kilka ruchów o niejasnym przeznaczeniu, po czym znikają. Czasem dlatego, że są zajęcia. Czasem dlatego, że jest urlop. Czasem dlatego, że jest urlop, który okazuje się zajęciami. Czasem dlatego, że są zajęcia będące mentalnym urlopem. A czasem dlatego, że rybka tonie, pies ucieka, pianino samo się nie zagra, a mandolina najwyraźniej wymaga natychmiastowej interwencji. Projekt w tym czasie czeka. Klient również czeka. System oczywiście nie czeka, tylko konsekwentnie nje działa.
Problem pierwszy: nikt nie potrafi złożyć niczego, co sklada się z części
Największy błąd organizacyjny polega na założeniu, że takiej osobie można przypisać grupę projektów. Nie można. Grupa projektów zakłada bowiem pewien minimalny poziom ciągłości, pamięci roboczej oraz zdolności do policzenia, że dwa projekty to więcej niż jeden, ale jeszcze nie nieskończoność. Całkiem poważni ludzie są sami zaskoczeni, że dostali dwie lite metalowe kulki, z czego jedną zgubili, a drugą popsuli.
Jeżeli praktykant dostaje dwóch klientów, to zwykle nie potrafi się ich doliczyć. Jeżeli dostaje jednego klienta i dwa projekty, to również zaczyna się robić mgliście wiele. Jeżeli dostaje jeden projekt i dwa zadania, to również trudno się doliczyć i jedno z nich zostaje porzucone, drugie zostaje rozpoczęte, a trzecie, którego nikt nie zlecił, pojawia się samoistnie jako efekt uboczny całego nieporozumienia.
W efekcie praca nie przypomina realizacji planu. Przypomina raczej archeologiczne odkopywanie warstw przypadkowych prób, rozpoczętych zmian, niedokończonych analiz i notatek zapisanych językiem, który mógłby próbować coś powiedzieć, gdyby autor nie zniknął w połowie zdania.
Problem drugi: zmiany bez celu, testów i świadomości skutków
Najwięcej katastrof zaczyna się od prostego zdania: „Coś tam robiłem”. To zdanie powinno być traktowane jak alarm przeciwpożarowy. Najczęściej oznacza ono, że ktoś wykonał zmianę, której nie rozumie, w module, którego przeznaczenia nie zna, w celu, którego nie potrafi wyjaśnić, bez testu, którego nie byłby w stanie zaprojektować, ponieważ nie wie, jaki wynik miałby oznaczać sukces.
Aby przetestować zmianę, trzeba wiedzieć, czemu ona służy. Żeby wiedzieć, czemu służy, trzeba rozumieć problem. Żeby rozumieć problem, trzeba pamiętać zgłoszenie klienta. Żeby pamiętać zgłoszenie klienta, trzeba było być obecnym wtedy, kiedy klient jeszcze wiedział, czego potrzebuje lub miałby przynajmniej okazję sprzetestować, czy zmiana odpowiada jego potrzebom.
Tymczasem po trzech dniach przerw, zajęć, wyjść, powrotów i nagłych zdarzeń życiowych nikt już nie pamięta, co było źródłem problemu. Praktykant nie pamięta, co robił. Opiekun nie pamięta, co praktykant miał zrobić. Klient nie pamięta, dlaczego Sam musiał rozwiązać problem w jakiś inny sposób. System natomiast pamięta wszystko i wyraża to w postaci błędów produkcyjnych.
Problem trzeci: dłuższe zadania są skazane na porażkę
Każde zadanie wymagające pracy przez kilka dni jest w tym modelu organizacyjnym przedsięwzięciem wysokiego ryzyka. Nie dlatego, że jest technicznie trudne. Dlatego, że kilka dni to w świecie praktykanta epoka geologiczna. W pierwszym dniu zadanie zostaje otwarte. Pięć minut później pojawia się pierwsza blokada która trwa najczęściej cały kolejny dzień. W trzecim dniu okazuje się, że trzeba być gdzie indziej niż w pracy. W czwartym dniu trzeba nadrobić coś innego. W piątym dniu nikt już nie pamięta, co było robione w pierwszym dniu, ale wszyscy czują, że „coś już jest zaczęte”.
To „coś” jest najgorszym możliwym stanem projektu. Nie jest to zadanie niewykonane, które można po prostu zaplanować od nowa. Nie jest to zadanie wykonane, które można wdrożyć. Jest to stan pośredni: techniczny półprodukt, emocjonalny kompromis i organizacyjny wyrzut sumienia. Niby coś istnieje, ale nie wiadomo, czy można tego użyć, czy trzeba to wyrzucić, czy może najpierw powołać komisję śledczą.
Problem czwarty: produkt działający w 90% nie działa wcale
W projektach informatycznych istnieje wyjątkowo niebezpieczny mit, że rzecz „prawie działa” albo jeszcze częściej działa ale nie zostało jeszcze przetestowane do końca. Nieprawda. Rzecz działająca w 90% nie działa wcale.
Ludziom bez doświadczenia w ogóle nie mieści się w głowie że jeżeli system księgowy działa w 90%, to znaczy, że co dziesiąta faktura może być błędna, a cały system jest do wyrzucenia ponieważ jest niewiarygodny. Jeżeli import danych działa w 90%, to znaczy, że dane są niewiarygodne. Jeżeli proces klienta działa w 90%, to znaczy, że klient i tak musi zadzwonić, napisać, wyjaśnić, poprawić albo porzucić system.
Produkt, któremu brakuje jednej ćwiartki, nie jest produktem prawie gotowym. Jest produktem, który w najważniejszym momencie nie spełnia swojej funkcji. Najbardziej zdradliwe są właśnie te efekty pracy, które wyglądają na prawie ukończone. Mają ekran. Mają przycisk. Mają formularz. Mają nawet komunikat sukcesu. Tylko po kliknięciu okazuje się, że sukces jest głównie deklaratywny, a dane zapisały się nigdzie, częściowo albo w miejscu, którego nikt potem nie potrafi znaleźć.
Najczęściej problem w ogóle nie polega na tym, że coś zostało źle zaimplementowane. Co ciekawe, problem polega na tym, że całość czasu, jaki był przeznaczony na zadanie, została przeznaczona na jego implementację i wykonanie kodu, dokumentu albo analizy. Tylko najczęściej tam gdzie praca powinna wypełnić 10% czasu a testowanie i weryfikacja powinny zająć 90% czasu tam najczęściej proporcje są albo odwrócone albo wręcz testowanie i weryfikacja nie miały w ogóle miejsca bo nie starczyło czasu...
Problem piąty: brak etyki domykania
Najtrudniejszy nie jest brak wiedzy technicznej. Brak wiedzy można uzupełnić. Brak doświadczenia można z czasem naprawić. Brak znajomości technologii można rozwiązać szkoleniem, dokumentacją i sensownym przeglądem kodu. W dzisiejszych czasach brak wiedzy w ogóle nie jest problem dla nikogo ponieważ wszelka wiedza dostępna jest dla każdego.
Najtrudniejszy jest brak etyki domykania. Chodzi o wewnętrzny nawyk doprowadzania rzeczy do końca. Nie do momentu, w którym „coś zostało ruszone” albo postawiono ostatniąkropke lub uruchomiono kompilację bez błędów. Nie do momentu, w którym „prawie działa”. Nie do momentu, w którym „trzeba tylko jeszcze sprawdzić”. Tylko do momentu, w którym zadanie jest skończone, sprawdzone, opisane, przekazane i możliwe do użycia przez klienta.
Tego nie da się zastąpić samą obecnością przez kilka godzin tygodniowo. Nie ma takiej ilości kodu która jest w stanie obronić się przed brakiem testów ani nie ma takiej ilości treści która jest w stanie wytrzymać brak przeglądu tego co zostało napisane. Jeżeli ktoś pracuje wyłącznie w sztywnych, krótkich okienkach czasowych, które prawie zawsze kończą się szybciej niż zadanie, to w praktyce nie realizuje pracy projektowej.
Realizuje serię epizodów. Te epizody, choć mogą wyglądać aktywnie, nie tworzą produktu. Tworzą ślady aktywności. Te ślady aktywności to jeszcze nie wartość dla klienta.
Problem szósty: pamięć zanika po wyjściu na chwilę
Dochodzi do sytuacji absurdalnych, w których człowiek przed południem pracuje nad zadaniem, w południe wychodzi „tylko na chwilę”, a po powrocie nie pamięta nie tylko tego, co robił, ale czasem nawet tego, nad jakim projektem pracował. Pomijam już nawet przypadki w których w ogóle zapomniał, że powinien jeszcze do czegoś wrócić z danego dnia tylko dlatego że obiecał.
Wtedy zaczyna się rytuał odtwarzania kontekstu. Otwieramy repozytorium. Patrzymy na ostatnie zmiany. Próbujemy zrozumieć intencję. Szukamy zadania. Szukamy komentarza. Szukamy wiadomości. Szukamy sensu. Sens zwykle wychodzi jako ostatni, a czasem nie wychodzi wcale, bo klient nie dostał tego co miał obiecany na czas i w związku z tym kompletnie zmienił zdanie co do tego co w ogóle chce.
W profesjonalnym zespole kontekst jest zarządzany: przez opisy zadań, kryteria akceptacji, notatki techniczne, testy, przeglądy i procedury przekazania. W modelu praktykanckim kontekst bywa przechowywany w głowie osoby, która właśnie poszła grać na pianinie, bo według jej uznania postawiła ostatnią kropkę a kod kompiluje się przecież bez błędów więc można całkowicie zapomnieć o nim jak o zdanym egzaminie.
To architektura wysokiej dostępności, tylko bez dostępności. Co zatem zostaje? Zostaje brutalne skracanie zadań to jakiś absolutnie trywialnych aktywności które można całkowicie powierzyć najprostsze modelowi językowemu, który dokładnie tak samo jak pracownik z krótkim stażem zapomina wszystko w momencie zakończenia rozmowy i najczęściej absolutnie nie potrafi zweryfikować tego co właśnie stworzył.
Ludzie pozbawieni etyki domykania stawiają się na jednej linii z modelami językowymi które również nie ponoszą żadnej odpowiedzialności nie mają żadnego kontekstu, ani nie potrafią dokonać oceny swojej własnej pracy w warunkach realnego zastosowania. Nie dlatego, że to idealny model pracy. Dlatego, że każdy dłuższy odcinek zaczyna przypominać zakład z losem. Taki los w przypadku białkowego czata zwykle ma psa, rybkę, zajęcia i urlop.
Zadania muszą być małe. Bardzo małe. Tak małe, żeby dało się je zrozumieć, wykonać, sprawdzić i zamknąć zanim nastąpi kolejne rozproszenie. Jeden klient. Jeden projekt. Jedno zadanie. Jeden rezultat. Jedno kryterium akceptacji. Jedna odpowiedzialność. Najlepiej jeszcze jedno zdanie opisu, bo dwa zdania mogą już stworzyć równoległą rzeczywistość interpretacyjną.
Nie jest to może romantyczna wizja edukacji, mentoringu i rozwoju talentów. Jest to raczej procedura przeciwpożarowa dla organizacji, która próbuje dostarczyć klientowi działający produkt, a nie kolekcję dobrze rozpoczętych katastrof. Praktykant nie jest problemem. Problemem jest złudzenie, że praktykant zastąpi proces.
Najuczciwiej trzeba powiedzieć: sam praktykant nie jest największym problemem. Problemem jest wiara, że osoba niedoświadczona, dostępna fragmentarycznie, rozproszona innymi obowiązkami i pozbawiona pełnego kontekstu będzie samodzielnie dowozić złożone zadania projektowe. Nie będzie.
Może pomagać. Może wykonywać małe, dobrze opisane fragmenty. Może uczyć się na konkretnych przykładach. Może odciążać zespół, jeśli praca jest przygotowana, zawężona i kontrolowana. Ale nie może być wrzucona w sam środek projektu klienta z cichym założeniem, że „jakoś sobie poradzi”.
Bo „jakoś” to nie jest metoda zarządzania. „Prawie” to nie jest status wdrożenia. A „później” to najczęściej elegancka forma pochówku zadania.
Dlatego praca z praktykantami wymaga nie więcej luzu, ale więcej dyscypliny. Nie większej swobody, ale mniejszych zakresów. Nie ambitniejszych zadań, ale lepszych granic. Nie wiary w cudowne samodzielne dowiezienie, ale systemu, który zakłada, że bez domknięcia, testu i przekazania każda zmiana jest tylko kolejnym niedokończonym śladem na drodze do produktu, który działa w 90%. Czyli nie działa wcale.
Domyślnym rozwiązaniem jest podział zadania na tyle fragmentów, ilu ma się praktykantów dostępnych przez następną godzinę, zanim zgubią kontekst i zapomną w ogóle, dlaczego to zadanie realizowali. To jednak wymaga pogodzenia się z tym, że zamiast realnego zadania dostaniemy jakieś pojedyncze czynności, a zamiast realnego wynagrodzenia dostaniemy pieniądze na waciki, karmę dla rybki albo bilet na trawaj realizując prace w kilkunasto osobowym zespole, które mogła by zrealizować jedna osoba.
To z kolei prowadzi do nieuzasadnionych pretensji w drugą stronę: skierowanych do pracodawcy który miał dać jakiś pracę za które miało być jakieś wynagrodzenie. To właśnie w tym nieporozumieniu językowym tkwi chyba źródło problemu, że jedna strona myśli, iż dostaje wynagrodzenie za pracę, a zatem wykonywanie pracy jest źródłem wynagrodzenia. Tymczasem tak naprawdę źródłem wynagrodzenia każdej firmy jest domknięte zadanie, skutkujące zadowoleniem klienta, który chce tylko zapłacić za rzeczy, które zamówił.
Jest bardzo trudno wyjaśnić w tej sytuacji, że wynagrodzenie jest efektem umiejętności utrzymywania długiego kontekstu oraz szerokiego rozumienia środowiska, w jakim realizuje się zadanie. Umiejętności poświęcenia większości czasu na weryfikację swojej własnej pracy, przypadków testowych oraz warunków brzegowych w symulowanych okolicznościach, w jakich będzie uruchamiany w jakich dokument będzie odczytywany, czy strona internetowa przeglądana.
Przede wszystkim każde dobre zadanie, z którego bierze się dobre wynagrodzenie, wymaga dobrej ilości czasu i ciężkiej pracy, która jest doprowadzona do końca. Ludzie nie mają żadnej szansy na otrzymywanie wynagrodzenia za pracę, którą może wykonać za nich dowolny automat, jeśli ustawiają się w tym samym szeregu z automatem pod względem braku rozumienia sposobów weryfikacji tej pracy, a także braku brania odpowiedzialności za powierzone zadanie.
W przyszłości ludzie całe wynagrodzenie, jakie będą w ogóle kiedykolwiek otrzymywali, będą otrzymywali tylko z tego powodu, że będą potrafili ocenić, w jaki sposób inni ludzie będą oceniać daną pracę, a także z tego powodu, że będą brali ludzką inicjatywę oraz odpowiedzialność za doprowadzenie spraw, do końca, w taki sposób, w jaki ludzie rozumieją ich zakończenie, a nie w jaki rozumie je treść z zadania czy treść prompta skierowanego w notatce.
Ostatecznie człowiek różni się od automatu właśnie etyką pracy i odpowiedzialnością. Jeżeli ktoś nie ma tej etyki pracy oraz odpowiedzialności to może się ścigać z automatem na szybkość wprowadzania treści oraz kosztem pracy.