Jak poprawić wydajnośc programisty?

Udostępnij

Często mówi się o tym, że dany programista jest “niewydajny”. Pojęcie to jest nieostre – można je różnie zinterpretować, ktoś w organizacji A może być uważany za niewydajnego, natomiast w organizacji B może być najbardziej produktywnym programistą z całego zespołu. Często chodzi jedynie o relatywizm i percepcje. Tak jak wspominałem w poprzednich wpisach – uważam, że ludzie z natury nie są “źli”. Nikt nie przychodzi do pracy z myślą, co by tu dziś opóźnić/zepsuć – starają się pracować najlepiej jak potrafią. Zdarza się jednak, że środowisko projektowe temu nie sprzyja – dzisiaj właśnie będzie o tym.


Higiena projektowa

Właściwie to wymyśliłem to pojęcie parę wpisów temu. Chyba nigdy nie zdarzyło mi się wyjaśnić co dokładniej przez nie rozumiem. Przez higienę projektową rozumiem to, że projekt jest zadbany. Każde zadanie rozwiązuje jeden problem – nie ma zadań “worków”, programiści wiedzą doskonale co mają robić – treść zadań jest zrozumiała jednoznaczna. Nie ma niepotrzebnej presji oraz niezdrowej rywalizacji w zespole. Obowiązki są podzielone i każdy wie, co ma robić. Mógłbym tak wymienić jeszcze setkę rzeczy, ale na tym poprzestanę, mam nadzieję, że wiesz co mam na myśli pisząc o higienie projektowej.

 

Higiena projektowa

jeśli nie wiesz co robić, to co robisz?

…jeśli nie wiesz co robić, to prawdopodobnie nie robisz tego co powinieneś. Ten akapit będzie głównie w kontekście programistów. Na początek mała dygresja. Jakiś czas temu czytałem tekst Rafała Agnieszczaka, w którym było m.in. o tym, żeby zdać sobie sprawę z tego, że zatrudnieni pracownicy, nigdy nie będą “dbać” o biznes tak jak właściciel. Można to przełożyć na relację kierownik projektu – programiści, gdzie to właśnie PM jest tą osobą, która jest odpowiedzialna za projekt (analogia do szefa), oraz programiści, którzy wykonują polecenia kierownika projektu (analogia do pracowników). Często polecenia/zadania pisane przez kierowników projektów są lakoniczne “bo przecież wiadomo co trzeba zrobić”. Jeśli więc występuje sytuacja dla programisty, że zadanie nie jest jednoznacznie określone to raczej ciężko wymagać od niego by wczuł się w rolę kierownika projektu i doprecyzował sobie zadania. Czasami oczywiście możemy być miło zaskoczeni jeśli programista jest proaktywny.
Zmierzam do tego, że jeśli nie wiesz co masz robić (bo to nie wynika z zadania) to musisz się domyślić. Często zdarza się tak, że niektóre fakty wynikają z implikacji zadań. Dla mnie domyślanie się jest najbardziej męczącą czynnością. Nie ważne czy chodzi o IT czy o komunikacje z kobietami – domyślanie się, męczy (hehehe) 😉 Kiedy nie wiesz jak coś powinno być zrobione bo nie jest dokładnie opisane, to brakujące rzeczy musisz wymyślić. Poruszałem ten temat w kontekście tworzenia wymagań projektowych. Jeśli chodzi o programowanie – mnie zawsze męczą najbardziej zadania, w których nie do końca wiem jaki powinien być finalny efekt lub jak go uzyskać. Po drodze trzeba wiele rzeczy wywnioskować z kontekstu innych zadań (wcześniej wspomniana implikacja) lub po prostu je “wymyślić”. Zamiast skupić się na tworzeniu funkcjonalności trzeba się skupiać na tworzeniu wymagań. Proces analityczny i kreatywny (domyślanie się) jest wymagający – dodatkowo utrudnia zadania, ale przede wszystkim zniechęca programistów do ich wykonywania. To się dokładniej nazywa brakiem motywacji. Jeśli ktoś ma do wyboru zadanie, w którym wiadomo co trzeba zrobić i ma pełną wiedzę na temat jego wykonania, a takie, w którym jest rzucony lakoniczny opis i część rzeczy trzeba wnioskować i się domyślać – to wiadomo, które z nich wykonamy chętniej. Motywacja i chęć wykonania jest ściśle powiązania z wydajnością.

 


zboczenie zawodowe

Być może to zboczenie zawodowe – być może normalna rzecz, ciężko mi określić, ale uczestniczenie w projektach, w których jest wysoka higiena projektowa jest dla mnie przyjemnością 🙂 Wtedy czuje, że realizuje swoją pasję. Jeśli zadania są dobrze rozpisane, cały zespół wie co ma robić – każde zamykane zadanie przybliża nas do końca projektu i widać progres to mam ogromną motywację do realizacji takiego projektu. Całkiem inaczej wstaje się do “pracy”.
Jeśli natomiast w projekcie jest dużo domyślania się to jest zupełnie odwrotnie – bo wiem, że to będzie wymagające, żeby realizować taki projekt. Często zauważam taką sytuację, w której czas mija, a właściwie nic konkretnego się nie zrobiło. W moim przypadku w większości przypadków zawsze to był brak odpowiednio zaplanowanej pracy – czyli domyślanie się w kwestii zadań. Jeśli nie wiemy co mamy robić to jedynie zgadujemy co musimy zrobić by domknąć to zadanie – krążymy w okół najbardziej optymalnych czynności. Przez co spada nasza wydajność. Nie jest to “lenistwo” – tak po prostu działa nasz mózg. Jesteśmy nastawieni na osiąganie celów zadaniowych, natomiast jeśli nie są jasne – to nie dążymy do nich “pełną parą” i najkrótszą drogą. Nie ważne jest czy jesteś kierownikiem projektu, programistą czy pracownikiem fabryki. Jeśli twoja praca będzie dobrze zaplanowana – będziesz dużo wydajniejszy i zmotywowany.

Warto sobie odpowiedzieć na poniższe pytania:

  1. jeśli przełożonemu “nie chciało się” dokładnie wykonać swojej pracy w planowaniu zadań dla programistów – to dlaczego programistom ma się chcieć to robić za nich?
  2. Jeśli chodzi o domyślanie się, to zdarza się tak, że jest kilka alternatywnych rozwiązań. Jaka jest szansa, że programista wybierze to rozwiązanie, które jest najbardziej odpowiednie?
  3. Jaka jest szansa, że programista wybierze to rozwiązanie, którego oczekuje kierownik projektu, ale nie opisał go “bo przecież to wiadomo”?
  4. Ile czasu więcej potrzeba programiście na realizację zadań jeśli część rzeczy musi sam wywnioskować na podstawie innych faktów? Ile szybciej by było, gdyby te rzeczy były opisane?

Takie pytania można mnożyć – mam nadzieję, że zauważyłeś bezpośredni związek pomiędzy higieną projektową a wydajnością.


Podsumowanie

To, że ktoś jest wydajny to pojęcie względne. Często zdarza się, że nie wykorzystujemy pełnych możliwości programistów przez złe warunki środowiska projektowego. W braku motywacji/wydajności warto rozejrzeć się za przyczyną i ją poprawić. W moim przypadku i ludzi, z którymi współpracuje niejednoznaczność zadań wpływa na brak motywacji co przekłada się bezpośrednio na wydajność. Jeśli zadania są precyzyjnie opisane, a w projekcie jest higiena projektowa – pracuje się “szybciej” i przyjemniej. Oczywiście nie mam badań na ten temat, podobnie jak na większość moich przemyśleń, które publikuje. To są jedynie wnioski, które sprawdzają się w środowiskach projektowych, w których się obracam. Podejrzewam, że powodów do złej wydajności/braku motywacji jest tyle ile zespołów – niezliczenie wiele 😉 Daj znać jak jest w twoim przypadku 🙂


Jeśli wpis ci się spodobał, udostępnij go lub śledź mnie na facebooku, twitterze, LinkedIn lub subskrybuj mój kanał na YouTube – twoja interakcja motywuje do dalszego pisania! Jeśli interesują cię podobne treści, dopisz się do newslettera (na górze strony) :).


Udostępnij

10 thoughts on “Jak poprawić wydajnośc programisty?

  • 13 listopada 2017 at 11:34
    Permalink

    Zgadzam się w 100%. Jako programista strasznie irytujące jest gdy muszę się domyślać o co chodzi w zadaniu co w rezultacie kończy się pytaniem o szczegóły osobę zlecającą. Zwykle po uprzednio wymyślonych możliwościach interpretacji zadania. A jako że jestem jeszcze juniorem to dodatkowo wkurza gdy jestem z tego powodu mało produktywny. Jak do tego dorzuci się brak znajomości systemu w którym się pracuje lub jego części to momentami jest blokada.

    Reply
    • 13 listopada 2017 at 12:49
      Permalink

      dzięki za komentarz 🙂 Podeślij wpis swoim PM – może jeszcze “nie jest za późno” hehe 🙂

      Reply
  • 13 listopada 2017 at 15:09
    Permalink

    Wydajny programista to moim zdaniem taki z TYLKO JEDNYM przełożonym.
    Nic tak nie rozwala wydajności jak zła hierarchia gdzie zadania/polecenia mogą pochodzić z różnych źródeł wyższego szczebla.

    Reply
    • 13 listopada 2017 at 15:13
      Permalink

      Myślę, że tu nie chodzi o ilość przełożonych (przełożony twojego przełożonego jest twoim przełożonym), a o to, że w teorii zadanie dane wyższemu rangą ma wyższy priorytet i trzeba skakać z zadania do zadania przez co pracuje się w trybie multitasking.

      Reply
      • 14 listopada 2017 at 09:15
        Permalink

        Multitasking na pewno przeszkadza. W każdy razie mi 🙂
        Ale mnie bardziej chodziło o fakt, że dwie osoby w hierarchii wyżej mają różne wyobrażenie wyniku tego samego zadania. Wtedy się dzieją dopiero cuda bo “każdy wie lepiej”. Nie wiem jak jest za granicą. W polskich realiach się spotkałem z czymś takim.

        Reply
        • 14 listopada 2017 at 09:18
          Permalink

          To faktycznie masakra. Totalne nieporozumienie na linii managerskiej i pewnie brak analizy (skoro są różne wersje interpretacji zadania).

          Reply
  • 13 listopada 2017 at 23:25
    Permalink

    Najpierw zaczyna się od backendu lub frontendu. Następnie dostaje się backend lub frontend w zależności od tego co było pierwsze.
    Kolejno doskakuje baza danych, usługi, serwis i naprawę bugów …
    W pewnym momencie programista backend/frontend staje się fullstack developerem.
    Ale to chyba za mało… niech porobi jeszcze analizy systemu, zaprojektuje i zaimplementuje. Sam przetestuje i wypuści nową wersję aplikacji.
    Na końcu dorzuca się jeszcze telefon służbowy i klientów.
    Dziękuję.

    Reply
    • 16 listopada 2017 at 08:25
      Permalink

      #Makumba Jakbyś moje życie opisywał… 😉

      Reply
  • 16 listopada 2017 at 23:38
    Permalink

    Fakt. Strasznie mnie irytuje fakt, w sytuacji, że to ja muszę przeanalizować wszystkie możliwe rozwiązania problemu choć są od tego analitycy.

    Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *