Jeżeli prowadzicie zespół IT, w którym pracują młodzi, zdolni programiści, to często zaskakuje Was fakt, jak wiele nowych technologii znają, jak wiele ich próbowali i aż palą się, aby wykorzystać je w pracy w jakimś projekcie. Jest to często bardzo pozytywne zjawisko - słuchając takich osób, inni programiści mogą podłapać jakieś techniki warte doczytania, frameworki, a nawet języki programowania. Do tego, entuzjazm można spożytkować podczas prac nad aplikacjami i zarazić nim resztę zespołu. Jednak, z dużym prawdopodobieństwem osoby zarządzające takimi drużynami znają również jeden negatywny skutek - niezadowolenie specjalisty z powodu "zastania się" w jednej technologii lub podejściu. Jeśli taka osoba jest przy tym dość energiczna i aż nosi ją, aby postawić na swoim, to można ją określić mianem "pistoletu" (termin zapożyczony z jednego artykułu).
Na wstępie chciałem zaznaczyć, że nie jest to tekst krytykujący jakąkolwiek ze stron. Na co dzień pracuję w Wilda Software z programistami dużo młodszymi ode mnie (jeśli to czytają, serdecznie ich pozdrawiam) i stanowimy zgraną oraz sprawnie działającą ekipę, która dużo uczy się razem i wzajemnie rozumie swoje poglądy na pracę oraz dowcipy. Bycie młodym niejako pokrywa się z byciem niedoświadczonym na polu tego, czym różni się tworzenie oprogramowania na swoje potrzeby od takiego na potrzeby klienta. Jest zatem oczywiste, że młodsi programiści będą popełniał błędy, podobnie zresztą jak i starsi programiści czy kadra kierownicza, którzy podchodzą do projektów z zupełnie innym spojrzeniem i bagażem doświadczeń. Obie strony mają swoje racje i kluczem jest zbilansowanie podejścia.
Problem wynika głównie z tego, że młodzi pracownicy, przychodząc do pracy, dysponują głównie wiedzą teoretyczną lub praktyczną, ale zdobytą na własny rachunek i własnych warunkach. Co za tym idzie - gdy już wpasują się w tryby pracy drużynowej, zaczynają widzieć, iż mogą realizować swoje marzenia oraz plany i mogą dotyczy one np. technologii. Mało tego - widząc, że zbliża się np. projekt aplikacji mobilnej dla klienta, mogą zaproponować użycie Fluttera jako rozwiązania polecanego przez guru programowania. I świetnie, że to robią, naprawdę - już taka jedna wzmianka może uruchomić pewną zębatkę w mózgu innych osób i chociaż zachęcić ich do poczytania lub potrenowania w domu. Natomiast taki młody programista, spotykając się z odmową osoby opiekującej się techniczną warstwą projektu, może czuć się rozczarowany lub wręcz zły. "Stary piernik nie chce zmian i obstaje przy Ionicu - jeszcze tego pożałuje", zapewne niejeden pomyślał o starszym programiście lub kierowniku. A jak wygląda spojrzenie tego ostatniego?
Należy zdać sobie sprawę, że za projektem stoi pewna obietnica złożona klientowi, zabezpieczana wyceną, jaka została przygotowana dla danego zadania. Ta wycena jest zwykle podawana na podstawie rozmów z bardziej doświadczonymi programistami, którzy niejedno w życiu widzieli i niejedną porażkę przeżyli. Przez to jest często przygotowywana na podstawie ich doświadczeń, umiejętności i spojrzenia na projekt. Jest to bowiem oszacowanie, które ma sprawić, iż wykonanie oprogramowania będzie dla firmy nie tylko satysfakcjonujące (tworzenie projektów IT naprawdę potrafi takie być!), ale też opłacalne. W końcu firma musi się utrzymać, aby mogła dalej funkcjonować. A to oznacza, że często trzeba iść w kierunku znanych i stabilnych technologii, pracę w których możemy nie tylko prawidłowo ocenić, ale też być pewnym, że to zadziała. Brzmi to brutalnie, ale taka jest prawda.
Zresztą, opisywana sytuacja nie dotyczy tylko technik programistycznych, ale też innych aspektów. Pamiętam sytuacje, w których takie stanowcze podejście do technologii prezentował administrator mający opiekować się serwerem. Był to człowiek doświadczony w swoim fachu, znający zalety i wady różnych rozwiązań i umiejący zawczasu ocenić potencjalne problemy. Z drugiej strony, programiści mieli tworzyć projekt dość innowacyjny, w którym pragnęli zastosować ciekawy i nowy framework oraz inny niż zazwyczaj system zarządzania bazą danych. Na papierze wszystko miało sens, natomiast nadal niewiadomą była stabilność nowego rozwiązania, w związku z czym administrator podał w wątpliwość decyzje techników, nazywając je "chwilową modą".
Nie muszę pisać, jak rozsierdziło to programistów, którzy zaproponowali kupno serwera VPS bezpośrednio, a oni go skonfigurują, wgrają oprogramowanie i wszystko będzie działało. Najlepsze było to, że do tego punktu prawdopodobnie mieli rację - nie mam wątpliwości, że ci młodzi, zdolni ludzie byliby w stanie wdrożyć aplikację na taki samodzielnie przygotowany serwer. Jednak to moment, w którym kończy się optymizm, a zaczyna się pesymizm wynikający z doświadczenia i fakt, gdzie leżała mądrość administratora. Po pierwsze, skonfigurowanie środowiska mogłoby zakończyć się pełnym sukcesem, owszem, ale w przypadku rozwijania systemu, prawdopodobnie rekonfiguracja byłaby nie tylko utrudniona, ale też wymagałaby zapoznawania się z dokumentacją, co oznacza czas potrzebny na dokształcanie się (aby poznać bardziej elastyczne metody konfiguracji), zmianę nawyków itd. Po drugie i ważniejsze, "pistolety" założyły, że po wdrożeniu system działałby wiecznie bez problemu, a jak dobrze wiemy - nie do końca jest to prawda i przyczyny są różnorakie. A to oznacza, że w pewien późny niedzielny wieczór mógłby się zdarzyć telefon od spanikowanego klienta błagającego o natychmiastowe sprawdzenie sytuacji na serwerze, bo dzieją się złe rzeczy. Czy taki młody "domorosły administrator" byłby tak pozytywnie nastawiony do życia, gdyby szef zadzwoniłby z poleceniem wykonania zadania o tej nieludzkiej porze? Śmiem wątpić.
Jednak, po stronie zarządzających również zdarzają się sytuacje, w których można by było pozwolić programistom na nieco "luzu" i spróbowanie czegoś nowego, ale tego się nie robi ze zbytniej obawy o kwestie biznesowe. Z jednej strony można to zrozumieć, gdyż trudno przewidzieć, jakie skutki może mieć postawienie na nieznane rozwiązanie, ale z drugiej strony - dobry CTO powinien takie sytuacje identyfikować i rozważać odmianę, jeżeli jest uzasadniona. W ten sposób można zapoznać się z frameworkami, które pokazując swoją moc w jednym projekcie, mogą stać się cennym atutem przy rozmowach z klientami, wprowadzić różnorodność w stosie technologicznym i dać poczucie programistom, że się rozwijają. A nawet, jeżeli nie okażą się sukcesem, to przynajmniej dokładają się do zbioru doświadczeń, z których można wyciągnąć istotne wnioski.
Najlepszą okazją do tego typu poczynań są projekty, które nie są pilne (zdarzają się takie, serio!) lub autorskie. Należy przy tym zachować umiar i jedną ważną zasadę - wprowadzamy JEDEN (no, może ewentualnie dwa) nowy element i patrzymy, jak się zachowuje. Zwykle błędne są decyzje o wymianie całego stosu technologicznego na potrzeby projektu, gdyż daje to n-krotne prawdopodobieństwo, że wszystko skończy się fiaskiem i trudno będzie z takiego stanu wyciągnąć wnioski. Dlatego warto to mieszać - zastosować znany framework, ale wprowadzić nowy rodzaj bazy danych lub odwrotnie. A może frontend napisać w znanym sobie Angularze, ale poszaleć z backendem?
Podsumowując - młodzi pracownicy, niezależnie od tego, jak świetni są w kodzeniu, muszą zrozumieć biznesową postawę osób trzymających pieczę nad nimi. Zarządzający muszą z kolei zrozumieć, że zbyt długi przystanek przy danej technologii może skończyć się źle i warto nauczyć się identyfikować sytuacje, w których można pozwolić dać spróbować czegoś nowego. Na pewno takie eksperymenty przeprowadzane w kontrolowanych warunkach mogą przynieść dużo pozytywów całej organizacji, zarówno pod kątem oferowanych narzędzi, ale też poczucia zespołu, że mogą cały czas się rozwijać.