Feedback w projekcie

Dawanie lub otrzymywanie konstruktywnego feedbacku to bardzo trudna sprawa (challenge). Najczęśniej trzeba powiedzieć, co nie działa u danej osobo i powiedzieć to twarzą w twarz. Nie każdy dobrze znosi krytykę. W naszym zawodzie, gdzie miękkich umiejętności raczej deficyt, jest to jeszcze trudniejsze.

feedback-heads

Mieliśmy w zespole rozmowę o ogólnie pojętym feedbacku. Wyszło podczas ankiety, że jest z tym problem więc trzeba to obgadać. Było wiele pomysłów jak można to usprawnić, każdy przeszedł jakąś inną drogę do Making Waves i miał inne doświadczenia. Fajnie było posłuchać jak to kiedyś w firmie było oraz jak to w innych firmach wygląda.

Oczywistość tytułem wstępu: Mówimy raczej bezosobowo o faktach, niż o konkretnych ludziach i ich przywarach.

Mi osobiście nie podobają się pomysły typu „wprowadźmy nowy proces, który będzie polegał na obowiązkowym dawaniu feedbacku po zakończonym projekcie”. Jest wiele kombinacji jak może to wyglądać: w którą stronę, czy zawsze, czy każdy, czy anonimowo, czy widoczne dla niektórych, czy punkty, czy opisowy tekst. Jakoś nie jestem fanem wprowadzania procesów.

Moje kilka myśli

Nie odkrywające Ameryki, ale wiem, że mogę prosto sam stosować:

  • dawać feedback pozytywny. Zawsze znajdzie się w projekcie coś co wychodzi (bardzo) dobrze. Wiadomo, że bardziej fiksujemy się na problemach. Można jednak spróbować budować wokół pozytywów. Nie jest to tak proste jak brzmi, ale przynajmniej każdy sam może to robić.
  • poprosić o feedback (czy np. o Code Review). Trzeba jednak być lub przynajmniej sprawiać wrażenie otwartego na krytykę.
  • niezależnie czy się daje czy słucha feedbacku zawsze lepiej jest mieć jakąś historię z daną osobą. Już wcześniej współpracowaliśmy, a i będziemy to robić w przyszłych projektach. Przydadzą się też jakieś wypite wspólnie browary. Może nie będziemy tak spięci i nieufni, bo po prostu kogoś wreszcie poznaliśmy.

Pewnych rzeczy się nie przeskoczy

Jeśli coś działa źle, czujemy, że próba zwrócenia na to uwagi nie przyniesie zamierzonego efektu, a dodatkowo zbliża się koniec projektu to nikt raczej nie będzie się wychylał. Zwłaszcza z „konstruktywnym” feedbackiem. Raczej każdy w takiej sytuacji zaciśnie zęby (byle do końca projektu) i będzie liczył, że podobne problemy nie przydarzą się w następnym projekcie. Ostatecznie może się okazać, że wcale nie było tak źle jak nam się wydawało 😉

Reklamy
Ten wpis został opublikowany w kategorii Uncategorized i oznaczony tagami . Dodaj zakładkę do bezpośredniego odnośnika.

4 odpowiedzi na „Feedback w projekcie

  1. robotb pisze:

    Mój były TL nauczył mnie, że przy feedbacku należy zastosować zasadę kanapki z szynką.
    Najpierw należy powiedzieć pozytyw, później negatyw a na końcu znowu pozytyw. Wtedy osoba nie wyjdzie zniesmaczona i nie poczuje się oskarżona. Co do Code Review to podsunąłeś mi pomysł na kolejnego posta 🙂
    Najsmutniejsze jest to, że część TL’ów zupełnie ignoruje drobne pochwały. Wystarczy powiedzieć dobra robota, fajnie zrobiłeś tą klasę, dobry pomysł itp. Od razu się lepiej pracuje, gdy szefostwo docenia pracownika.
    Co do retrospekcji, w poprzedniej pracy po każdym sprincie, przed demo każdy z nas miał odpowiedzieć krótko na dwa pytania. Co się nam podobało a co nie. Bardzo dobrze się to sprawdzało.

  2. Pingback: dotnetomaniak.pl

  3. chrisseroka pisze:

    Moich kilka myśli na temat feedbacku:
    Myślę, że sztuka dawania feedbacku bardzo zależy od zespołu, jeżeli zespół jest bardzo (ale na prawdę bardzo) zżyty, to powinno się mówić otwarcie o tym co robi się źlę, np w stylu: „kolejny raz widzę, że nie robisz Unit Testów do ścieżek krytycznych”, albo „naucz się wreszcie, że zostawianie zakomentowanych lini kodu jest straaasznie słabe”. Ja ze swej strony dodam, że ponad rok pracowalem bardzo blisko z kolegą-developerem, któremu nie potrafiłbym tak podać „feedbacku”.
    Drugą sprawą jest to, że feedback możemy dawać jako para: „pluses & delta pluses” (zastępujemy tutaj minusy lżejszymi konstrukcjami w stylu „na twoim miejscu starałbym się pamiętać o robieniu testów do ścieżek krytycznych”). W ten sposób zawsze podajemy co było dobre w tym co ktoś zrobił, żeby wiedział co kontynuować ale także podkreślamy miejsca do poprawy bądź dajemy rady na przyszłość.

  4. Pingback: Code Review | robotb

Możliwość komentowania jest wyłączona.