Dzisiaj bardziej na poważnie, bo o pokorze. To jedna z tych cech, której brak niemal natychmiast zauważamy u innych, znacznie ciężej jest nam zauważyć to u samych siebie. Wg Słownika języka Polskiego pokora to brak pychy – pomijając kwestie życia na codzień, skupimy się tutaj na tym, czym jest pokora w zakresie własnych umiejętności i jak wypływa na nas i nasze otoczenie w miejscu pracy. Na rozwój Twój i zespołu, a także realizowanie projektu.
Pokora w branży IT.
Ciężko mi wyobrazić sobie branże, w której wiedza jest bardziej dynamiczna niż w branży IT – każdego dnia miliony osób pracuje nad systemami, z których część stanie się dostępna publicznie, będzie zawierała technologie i rozwiązania niestosowane nigdzie indziej i rozwiązywała problemy, z których istnienia nie zdajesz sobie sprawy. Proste zapytanie do google o framework do aplikacji web zwróci nam co najmniej kilkaset możliwości. A to tylko jeden z elementów układanki.
Pierwszy i najważniejszy krok, z którym trzeba się zmierzyć planując swoją przyszłość w branży IT to przyznanie przed samym sobą, że nigdy nie będzie się wiedziało wszystkiego. Mnie zajęło to około 5 lat. Problemem jest nie tylko nasza duma (‘jak to, ja się nie nauczę?’ / ‘ja nie wiem?!’), ale także edukacja (która w zdecydowanej i przykrej większości nastawiona jest na jedno rozwiązanie, które akurat wykładowca raczył poznać, bez refleksji nad aktualnością czy nawet poprawnością (!!) od wielu lat), a przede wszystkim – nastawienie innych.
Nie wiem
To głównie przez ten ostatni czynnik tak trudno przychodzi nam powiedzieć ‘nie wiem’ czy poprosić o pomoc. Obawiamy się, że ktoś o nas pomyśli źle, utrudni nam to szanse na awans w pracy czy podważy nasze kompetencje.
W rzeczywistości jest zupełnie odwrotnie – tylko będąc świadomi obszarów, których nie znamy lub w których mamy braki w wiedzy, jesteśmy w stanie je uzupełnić. ‘Nie wiem’ to to samo, co ‘wiem, że w tym obszarze nie mam kompetencji, ale chce je uzupełnić’, tylko efektywniej przekazane. Nie ma w tym nic złego i jest to najlepszy wstęp do wymiany wiedzy – bo w końcu o to chodzi w zespole, żeby mieć uzupełniające się kompetencje, i mieć możliwość dzielenia się swoją wiedzą, a nie być wszechwiedzącym omnibusem.
Pułapka niekompetencji
Najgorsza sytuacja to osoba nieświadoma swoich braków na stanowisku decyzyjnym. Skutkiem działania takiej osoby jest najczęściej jest najczęściej błedny wybór technologii (bo ‘ta’ jest najlepsza/najnowsza/najfajniejsza), złe decyzje biznesowe (bo przecież klient na pewno nie chce ‘tego’, a ‘to’ będzie dla niego lepsze), problemy z dostarczaniem, rozwojem i utrzymaniem (zróbmy tak, bo przecież to zalożenie na pewno jest prawdziwe), przesuwanie się deadline’ów (osoba taka najcześniej nie potrafi przyznać się do tego, że nie radzi sobie z zadaniem i poprosić o pomoc – sama zmarnuje mnóstwo czasu żeby znaleźć odpowiedź, której ktoś udzieliłby jej w kilka minut) czy po prostu frustracja – praca z technologią, która generuje więcej problemów niż ich rozwiązuje nie jest czymś przyjemnym i najczęściej jest też ona w błedny sposób implementowana (‘bo przecież przeczytałem tutorial to wiem, jak to zzastosować w projekcie‘).
Ciekawostką może być fakt, że socjologowie badali wpływ poziomu wiedzy w danym temacie na ‘przekonanie o swojej słuszności’. Zainteresowanych odsyłamy do np. tego artykułu (albo niezawodnej Wikipedii), a my możemy szybko streścić, że najbardziej pewni swego, są Ci zaraz na początku nauki i prawdziwi eksperci. Świadomość niewiedzy, to coś, co zazwyczaj naturalnie przychodzi z doświadczeniem i poszerzaniem swojej wiedzy.
W cyklu #PierwszaPraca był przykład z portalu Linkedin osoby przekonanej o swoich wysokich kompetencjach. Niestety miałem okazję zweryfikować, że jest zupełnie przeciwnie i w rzeczywistości nie chciałbym mieć tej osoby w projekcie. Należy jednak zdecydowanie odróżnić ‘pychę’ od świadomości swoich kompetencji – nie jest to łatwe i nie ma prostego sposobu, podejrzewając taką skłonność u kogoś, warto zapytać o decyzje w projekcie i ich uzasadnienie – to już powinno dać nam pełny obraz.
Sygnały ostrzegawcze
Jest kilka sygnałów ostrzegawczych, na które warto zwrócić uwagę. Szczególnie należy unikać / uważać na osoby, które nigdy nie proszą o pomoc, a regularnie mijają się z planowanym czasem realizacji. Także na te, które uzasadniając decyzję na pierwszym miejscu wymieniają rzeczy takie jak ‘bo XYZ to robi’, ‘bo to najlepsza technologia’, ‘bo tak trzeba’, ‘bo inaczej się nie da’, ‘bo w XYZ nie da się tego zrobić’. Publiczne chwalenie się osiągnięciami, przymiotniki w stylu ‘najlepszy’, ‘jedyny’. Ignorancja i niezrozumienie pracy innych, ‘ja bym to zrobił lepiej’, ‘to dało się zrobić szybciej’ itp. (oczywiście, o ile krytyka jest konstruktywna i sugeruje realne rozwiązania, to absolutnie nie kwalifikuje się do tego punktu).
Technologicznie także należy uważać na osoby, które pozornie ‘są perfekcjonistami’, i które przykładowo próbują optymalizować zapytania wykonywane przez JPA do bazy danych w aplikacji typu CRUD, tworzonej dla małej firmy. Optymalizacja oczywiście jest ważna, ale żeby ją poprawnie wykonać, trzeba mieć bardzo głęboką wiedzę na temat działania technologii, którą chcemy optymalizować. I przede wszystkim realny powód, żeby to robić (wspomniana optymalizacja, nawet gdyby była owocna, przyspieszy wyświetlanie strony o kilkadziesiąt milisekund; przy takiej liczbie użytkowników pozwoli zaoszczędzić kilkanaście sekund rocznie; to wszystko nakładem pracy min. kilku roboczodni).
Jak sobie radzić
Praca z takimi osobami jest trudna, szczególnie, że nikomu nie zależy na tym, żeby coś ze sobą zrobiły. Osoby takie nie widzą problemu i są przekonane o swojej świetności – ich przełożeniu/pracodawcy nawet albo nie są w stanie dostrzec problemu (np. nie mają kompetencji pozwalających ocenić kompetencje innych) albo im nie zależy – niestety często logika jest taka, że ‘klepacze’ kodu też na siebie zarabiają w projekcie, i pomimo że osoba taka nie awansuje i nie rozwinie się, ‘liczby się zgadzają’. To jednak bardzo krótkowzroczne podejście – morale w zespole naprawde spadają, pojawia się brak zaufania, i w komunikacji. Projekt też często jest opóźniony, bo trzeba poprawiać coś, co ktoś ‘wiedział lepiej’.
W idealnym świecie możesz zwrócić uwagę takiej osobie, starać się jej pomóc niewprost – nie tylko pytając czy potrzebuje pomocy w danym zadaniu, ale też dawać strzępki wiedzy niepytanym – np. Po odmowie pomocy, możesz powiedzieć ‘bo wiesz, w ostatnim zadaniu mialam problem z tym i tym, długo szukała odpowiedzi, a wystarczyło zrobić to i to’ – szanse są, że akurat trafisz. Możesz też porozmawiać z przełożonym o sytuacji i być może wspólnie znajdziecie wyjście –być może nie jest on po prostu świadomy problemu. Pamiętaj jednak aby opierać się na faktach i konkretnych przykładach, inaczej może to być bardzo źle widziane.
Niestety, niektórzy są po prostu niereformowalni i przekonani, że są ‘serem do pizzy’. Wtedy jedyne, co możesz zrobić to ignorować albo zmienić zespół / pracę. Upewnij się też, że jasno widać, co jest czyim obowiązkiem i kto się z nich wywiązuje – np. poprzez system do śledzenia zadań i czasu nad nimi spędzonego, dzięki temu unikniesz ‘uśredniania’ wyników w zespole i przypisywania sobie Twoich zasług. Denerwowanie się tylko przysporzy Tobie problemów i nie przyniesie nic dobrego.
Rozmowy rekrutacyjne
To zagadnienie ma dwie strony – z jednej strony Ty jako kandydat – nie bój się powiedzieć, że czegoś nie wiesz. Niestety zdajemy sobie sprawę z tego, że część rekruterów inaczej podchodzi do ‘nie wiem’ powiedzianego przez osobę z dużym doświadczeniem i takiego usłuszanego od osoby, która dopiero zaczyna karierę. Mimo wszystko nie ma co ‘szarżować’ – na 90% czegoś nie będziesz wiedziała, nie bój się do tego przyznać. Od razu możesz powiedzieć, gdzie poszukała byś tej informacji, albo jak Ci się wydaje (jak już wspominaliśmy, IT jest bardzo logiczną branżą i jeśli nie wiesz jak coś działa, to załóż, że działa tak, jak byłoby najbardzije uniwersalnie i logicznie) – dobry rekruter z pewnoscią doceni taką postawę.
Z drugiej strony rozmowa rekrutacyjna to też moment, kiedy możesz (i powinnaś) wyrobić sobie opinie o danej firmie. Zapytaj o technologie, jakich używają. Zapytaj, dlaczego to robią i jakie alternatywy rozważali. Zapytaj też co robią, aby ich wiedza była aktualna i jak wspierają rozwój wewnątrz firmy. Odpowiedź ‘bo tak się robi’ lub ‘żadnych, bo to najlepsza technologia’ to ogromne, neonowe napisy w jaskrawych kolorach ‘tutaj się nie rozwiniesz’. Oczywiście pytania te zadaj osobie technicznej, rekruter raczej nie będzie w stanie Ci odpowiedzieć. Zwróć też uwagę na pytania, jakie są zadawane – jeśli ktoś na stanowisko juniorskie pyta Cię o servlet i oczekuje, że wyrecytujesz definicje, to znaczy że spisał te pytania z banku pytań 5 lat temu i nie zadał sobie trudu żeby je zweryfikować. To wazna wiedza, czasem niezbędna. Zdecydowanie jednak nie jest to coś, z czym jako junior się zetkniesz i powinnaś wiedzieć.
Podsumowanie
Pokora to nie tylko jakaś ‘cecha charakteru’, to coś, co ma znaczący wpływ na to, jak będzie przebiegała Twoja kariera. Oczywiście ważna jest świadomość własnych mocnych stron, ale jeszcze wazniejsze jest znać te słabe i nad nimi pracować.
Dlatego, poszukiwania pokory w zespole zacznij od siebie, bo najwięcej możesz tu zmienić. Zastanów się więc nad tym, jak Ty się zachowujesz w stosunku do innych i czy czasem ktoś czytając ten tekst nie pomyśli o Tobie. Następnie odpowiedz sobie samej, czy nadal jesteś przekonana, że jeszcze chwila i będziesz wiedzieć wszystko o Y albo, że to właśnie Twoje rozwiązanie jest tym jedynym dobrym, bo przeciez stosujesz je od X projektów? I pamiętaj, że nikt za Ciebie nie otworzy się na rozwój i wyszukiwanie (a nie powielanie) rozwiązań, to Ty jesteś odpowiedzialna za swoją postawę.
Warto też doceniać innych za takie podejście. Czasem możesz myśleć, że nie są pewni swoich rozwiązań, ale właśnie takie podejście stymuluje projekt w wyszukiwaniu nie ‘jedynego słusznego’, a tego najbardziej pasującego rozwiązania. Czasem wydawać Ci się może, że bez sensu opowiadają, o swoich doświadczeniach z poprzedniego projektu, ale jak się w to wsłuchasz, to być może dostrzeżesz zagrożenie, lub inne rozwiązanie. I za warto takim osobom podziękować.
