Na rozwój można spojrzeć z wielu perspektyw. Każda płaszczyzna wygląda trochę inaczej. Wspominałem wielokrotnie w swoich materiałach jak istotny jest aspekt rozwoju w branży IT. Czasami rozwój rozumiemy jako dokształcanie się, zdobywanie wiedzy na temat nowych technologii, a czasami jak po prostu dużo poszerzanie horyzontów.

Przez ostatnich 11 lat brałem udział w tworzeniu około 30 projektów, pracując w strukturach różnych firm i około 50, działając jako freelancer. Czasami mój udział był bardzo wymagający, a czasami był to krótki kilkudniowy romans. Mogę otwarcie powiedzieć, że nic nie rozwija tak bardzo, jak praca projektowa. W projekcie spotkamy wiele przypadków, których nie mielibyśmy szansy spotkać w trakcie szkolenia, warsztatów czy też ucząc się samodzielnie. Zawsze powtarzam, że poziom zwiększyć możemy tylko poprzez pisanie kodu. Jak w dobrej grze RPG - żeby „wylevelować” swoją postać trzeba wykonać szereg questów i wybić setki potworów błąkających się po okolicy.

Staż w projekcie

Dość często zmieniałem projekty. Wynikało to z kilku kwestii. Czasami dochodziłem do ściany technologicznej, gdzie czułem, że już więcej nie osiągnę, czasami projekt się kończył, a czasami oferta była zbyt dobra, żeby ją odrzucić. Wydawać by się mogło, że jestem raczej zwolennikiem częstego zmieniania projektów. I rzeczywiście dostrzegam dużą wartość w szeroko rozumianej zmianie, ale nie sposób nie docenić projektów, które mają wiele lat wytwarzania za sobą.

Problemy młodych

W młodych projektach nigdy nie poznamy problemów, z którymi walczy się na dalszych etapach ich życia. Bardzo często okazuje się, że to, co dzieje się potem, walidują decyzje, które zostały podjęte na początku. Trzeba powiedzieć sobie otwarcie - to nie widzimisię programisty powinno decydować o technologii wybranej w projekcie. Zespół, który nie ma doświadczenia wybierze technologie według tego, co jest modne, fajne i co zna.

Podczas jednego ze szkoleń, które prowadziłem w zeszłym roku, rozmawiałem z zespołem, który utrzymuje projekt od 20 lat. Dłużej niż całe moje doświadczenie zawodowe. 20 lat temu, gdy oni zaczynali budować swój projekt, ja miałem 14 lat i nie miałem zielonego pojęcia co będę chciał robić w swoim dorosłym życiu. Co ciekawe, wiele z osób, które szkoliłem pracuje w tym projekcie od samego początku jego istnienia. Mocna ekipa, ale też mocno poobijana.

Ćwierć wieku temu technologie były zupełnie inne. Nikt nie słyszał o NodeJS, React, NPMie, Typescript’cie. Współczesny frontend w zasadzie jeszcze nie istniał. Wymagania aplikacji były spore - była to aplikacja bankowa, która była odpowiedzialna za zarządzania kontami klientów. Wydawało się, że będzie to prosty, wewnętrzny projekt bez zbędnych fajerwerków. Tak też został wydany w pierwszej wersji.

Przez lata rynek usług bankowych się zmienił. Rozwinęły się technologie komunikacyjne. Pojawiły się smartfony. Ludzie, zaczęli korzystać z bankowości internetowej. To wszystko wymagało zmian. Biznesowo uznano, że dotychczasowa aplikacja będzie najlepszym miejscem do obsługi większości nowych funkcjonalności. Dokładano coraz to nowe warstwy, produkując kod, którego utrzymanie za kilka lat stanie się niemożliwe.

Na powyższym przykładzie bardzo ładnie widać, że nie da się przewidzieć wszystkiego. Produkty mają kilka faz życia: od wprowadzenia na rynek, poprzez fazę wzrostu, następnie dojrzałości rynkowej aż do fazy spadku. W moim odczucie projekty IT należy traktować jak produkty. Ostatnia faza, czyli faza gdy nasz produkt po prostu trzeba utrzymać przy życiu, jest bardzo pouczająca. W fazie spadku, najczęściej mamy do czynienia z legacy code, czyli kodem na tyle przestarzałym (obarczony ogromnym niespłacalnym długiem technologicznym), którego w prosty sposób nie da się zastąpić niczym nowszym, ponieważ koszty byłyby zbyt wysokie.

Życzę każdemu, aby chociaż raz w życiu trafił do takiego projektu chociaż na chwilę. Daje to bardzo szeroką perspektywę i pokazuje dlaczego zrozumienie przeszłości jest tak ważne.

Długi staż w projekcie to jednak nie zawsze powód do dumy. Dużo zależy od wyzwań, które projekt nam daje - jeśli jest wola jego rozwijania lub chociażby optymalizacji to super. Projekty, które tylko trwają, bez fazy aktywnego programowania czy refaktoryzacji są chyba najgorszym miejscem do rozwijania siebie.

Dawid i Goliath

Zdarzyło mi się pracować w firmach, gdzie wszystkich było nas 5 osób i w korporacjach liczących załogę w tysiącach osób. Oczywiście nadal duży aspekt stanowi projekt, który w ramach danej organizacji się realizuje. Warto jednak podkreślić, że duże projekty w dużych korporacjach mają swój "czas". Nie mam na myśli deadline’ów, ich przekraczania czy dowożenia. To jest czas, który jest niezbędny, aby cokolwiek mogło być zrealizowane. Jest on zdecydowanie dłuższy w korporacji aniżeli w małej organizacji.

Podam przykład z mojego życia zawodowego. Swojego czasu pracowałem dla jednej z największych firm na świecie - z powodu swojej wielkości na każdą aktywność była opracowana procedura. Najczęściej związana z bezpieczeństwem lub kontrolą. Uważam, że to bardzo istotne aspekty, w szczególności w firmach, które mają kontakt z finansami czy danymi osobowymi. Niestety procedury, które powinny usprawniać pracę, często są ograniczeniami - w szczególności w procesach twórczych. Na otrzymanie dostępu do projektu czekałem ponad 2 tygodnie (i nie był to rekord firmy), postawienie projektu wymagało doinstalowania pakietów, które były na liście niedozwolonego oprogramowania, pierwsze zadanie otrzymałem po około miesiącu - i raczej nie było to nic wymagającego specjalistycznej wiedzy.

Co to pokazuje? Rozwój w ogromnych firmach ograniczają bardzo często procedury. Idąc do pracy w korporacjach - bardzo często trzeba liczyć się z niemocą, która będzie nas czasem dotykała. Decyzyjność jest rozmyta i przez to - wszystko trwa długo, bardzo długo.

Na osłodę dodam, że im większa firma tym większe budżety. Im większe budżety tym większy nacisk na takie aspekty jak testowalność, wydajność i jakość. Według mnie te 3 warstwy dają najszersze możliwości zrozumienia i rozwoju.

W takim razie, wydaje sie,  że małe firmy powinny być lepsze. Osobiście nie lubię małych firm - ze względu na brak czasu na wszystko, najczęściej portfolio małych klientów, a co za tym idzie - niewielkie budżety. Zespoły są często niewielkie lub jednoosobowe. Jeśli chodzi o rozwój w takich firmach to ostatni wymieniony przeze mnie punkt, czyli wielkość zespołu, jest największą wadą takich organizacji.

Nie da się rozwijać siebie bez konfrontowania naszej wiedzy, spostrzeżeń i pracy z innymi. One-Man-Army to frazes, który prowadzi do wypalenia zawodowego i żadnym wypadku nie oznacza efektywnego rozwoju. Podejmowanie decyzji samodzielnie może być fajne - mam to w projekcie swojej strony internetowej - ale moja strona to mój poligon doświadczalny. Z aplikacji klienta, za którą otrzymujemy pieniądze, nie można zrobić takiego laboratorium. Pomijam fakt, że budowanie aplikacji, którą za kilka miesięcy będzie robił ktoś inny, ponownie w pojedynkę, wzbudza w programiście więcej frustracji niż go faktycznie rozwija. Takie aplikacje to worek z błędami, które zostały sprytnie ukryte przez poprzednie jednoosobowe zespoły.

W małych firmach nie zawsze jest się od kogo uczyć. Niestety.

Dinozaury

Słyszeliście o słynnych ofertach pracy dla programistach COBOLa? Już kilka lat temu oferowano średnio około 30 tysięcy złotych miesięcznie dla znawców tego języka. COBOL to dziadek wśród języków programowania, a pomimo to nadal jest dość popularny, znajdziemy go między innymi w bankomatach czy systemach ubezpieczeniowych i bankowych. Jest też dość prosty - jego składnia miała za zadanie przypominać składnię języka angielskiego. Pomimo to, to dinozaur, który nie zmienia się od lat. Praca w takim języku daje nam szanse na fajne pieniądze, ale szufladkuje nas na lata i blokuje rozwój.

Nie myślę tylko o języku COBOL, ale o wszystkich technologiach, które firmy zbudowały tylko na swoje potrzeby. Tworzenie takiej technologii może być rozwijające, ale praca z nią już mniej. Przykłady: język Gosu od firmy Guidewire czy język ABAP firmy SAP. Można się niechcący zamknąć na lata w dość ciasnej klatce. Z takiego pudełka później trudno wyjść. Na szczęście, najczęściej wychodzi się z pełną kabzą.

Przywództwo

Najtrudniejsze w projektach jest zapewnienie odpowiedniego składu osobowego. Wspomniałem jak istotne jest to, aby nie pracować w pojedynkę. Równie istotny jest jednak fakt, kto i jak zarządza organizacją, w której realizujemy dany projekt. Szef, który jest trudny lub, wręcz przeciwnie, zbyt miękki - może storpedować każdy, nawet najlepszy projekt. Nie jesteśmy w stanie tego łatwo wychwycić niestety. Tutaj warto zdać się na intuicję i uciekać od toksycznych ludzi. Praca to praca. Nie dom, nie rodzina, ale też nie kołchoz czy więzienie.

Pisząc szef nie mam na myśli tylko właściciela / prezesa - raczej traktuję to pojęcie dość szeroko - manager / lider / prezes - to zależy od tego, kto zarządza projektem. Podkreślę, że według mnie zarządzanie to najtrudniejszy aspekt. Manager może wprowadzać bardzo nerwową atmosferę lub ja rozładowywać, może być wsparciem dla zespołu lub go dodatkowo obciążać, może być dla zespołu albo przeciwko niemu. Według mnie ma ogromny wpływ na to jak zespół i poszczególni jego członkowie się rozwijają.

Podsumowanie

Wbrew pozorom ciekawe i rozwijające projekty znaleźć możemy wszędzie - zarówno w małych, jak i dużych przedsiębiorstwach, pracując wiele lat w jednym projekcie, jak i po kilka miesięcy.

Osobiście nie wybieram nigdy projektów, gdzie technologia jest mało znana, manager jest despotą a zespół techniczny ma być dynamiczny i jednoosobowy. Znalezienie takiej perełki jest trudne, ale kilka razy mi się udało. Nie chciałbym powiedzieć nic złego o Software House’ach czy Agencjach Interaktywnych, ponieważ nawet tam zdarzają się wartościowe projekty, ale osobiście preferuję firmy produktowe, gdzie jest większa kontrola nad tym, co się wytwarza i jakość zależy tylko od wewnętrznych ustaleń części biznesowej z częścią techniczną. Niestety nie do końca jest to naturalny proces, gdy jest się pośrednikiem - pomiędzy aplikacją a klientem.

Wracając do analogii gier RPG. Pojawi się taki moment, gdy gra nie pozwoli nam na wbicie kolejnego poziomu lub gdy wbijanie kolejnych nie będzie zbyt opłacalne. Wówczas warto przedefiniować zestaw zdobytych umiejętności, zastanowić się nad możliwościami, które nam dają, bo być może odkryjemy nowe ścieżki, które wcześniej wydawały się nam nieosiągalne.