Być docenianym programistą

0
1925
Być docenianym programistą

To umiejętności miękkie, nie twarde, decydują o pozycji developera w teamie.

O zatrudnieniu w firmie IT decydują głównie umiejętności twarde. Wystarczy dobra znajomość tematu oraz doświadczenie komercyjne, by móc przebierać w ofertach pracy. Deficyt specjalistów IT na rynku pracy, z którymi boryka się niejedna firma IT z Krakowa,  nie eliminuje osób, które mają problem z umiejętnościami miękkimi. Jeśli w zespole znajdą się osoby, które mają problem z komunikacją, realizacja projektu może być utrudniona. Dlatego ważne jest, aby programista mógł się pochwalić nie tylko stroną techniczną, ale również pozytywnym podejściem do pracy zespołowej.

Dobry developer jest identyfikowany po odpowiedzialnym podejściu do swojej pracy. Działa proaktywnie, udziela się w środowisku developerskim –  dla swoich kolegów jest wzorem do naśladowania. Pamięta również o rozwoju własnym, nieustanie podnosząc swoje kwalifikację. Co ważne, bardzo dobrze się komunikuje i nawet jeśli musi nadrobić umiejętności twarde, robi to szybko poprzez nawiązanie dobrych relacji z zespołem.

Doświadczeni programiści, wspominając swoją pracę z developerami o zróżnicowanym doświadczeniu zawodowym, dostrzegają, że finalnie przeszłość nie ma większego wpływu na ich pracę.  Ważniejszy jest ich obecny stosunek do pracy oraz relacje z otoczeniem.

Złote rady, które warto zastosować w praktyce, to komunikacja oparta o konkret. Często klienci mają problem z precyzyjnym wyrażaniem się, szczególnie jeśli nie znają terminologii. Zamiast snuć domysły lub co gorsza, źle zinterpretować wskazówki klienta, należy zastosować taktykę: w pytaniu użyć kierunkujących zwrotów, parafrazując pytanie klienta, jednocześnie odwołać się do konkretu, który być może jest przedmiotem pytania. Przykład źle zadanego pytania: Co Pan ma na myśli? Dobrze zadane pytanie: Rozumiem, że chce Pan wprowadzić zmianę w strukturze menu. Czy chodzi Panu o panel admina? Nawet jeśli pytanie klienta ostatecznie zostało źle zrozumiane, istnieje szansa, że klient doprecyzuje swoje wytyczne.

Można również pójść dalej i porozmawiać o problemie z zespołem – być może programista nie jest jedyną osobą, który zetknął się z tym tematem. Zgromadzenie w międzyczasie danych zwiększa prawdopodobieństwo znalezienia odpowiedzi. W przypadku dojścia do ściany należy szczerze porozmawiać na ten temat – przyznanie się do swoich ograniczeń działa na korzyść rozwoju projektu.

Doświadczony deweloper nie bierze wszystkiego na siebie. Bycie odpowiedzialnym to również umiejętność powiedzenia „nie” w przypadku nadmiaru tasków, które mogą negatywnie się odbić na efektywności pracy. Sam fakt przypisania do zadania nie oznacza, że programista musi brać go na siebie – można poprosić o pomoc kogoś innego. W przypadku wpadki, odpowiedzialny developer natychmiast informuje o problemie, nie czekając, aż sytuacja wymknie się spod kontroli.

Im szybciej developer rozwiąże problem, który finalnie jest przecież problemem zespołu, tym szybciej zakończy swoje zadanie. Bo czas to pieniądz. Aktywne poszukiwanie rozwiązań wypada dobrze w czach pracodawcy – programista jest zaangażowany w swoją pracę i działa na korzyść projektu. A za korzyścią kryje się również poważanie w zespole.

[Głosów:1    Średnia:5/5]

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here