Pętla informacji zwrotnej to kluczowy element wszystkich systemów kontroli, z wyjątkiem tych trywialnych. A jeżeli zależy Ci na innych celach, takich jak:

• uczenie się,
• zbudowanie działającej aplikacji,
• zarabianie pieniędzy,

to masz do czynienia z systemem kontroli, który trywialny nie jest. Spójrzmy wobec tego na najważniejsze cechy skutecznej pętli informacji zwrotnej i zastanówmy się, jak mógłbyś ją wykorzystać w swojej karierze programistycznej.

Im szybciej, tym lepiej

Im szybciej dowiesz się, czy wszystko idzie zgodnie z planem, tym lepiej. Posuwanie się do przodu po omacku nic Ci nie da. Jeśli jesteś na dobrej drodze, informacja zwrotna zmotywuje Cię do dalszego działania. Jeśli natomiast robisz coś źle, uzyskany feedback pozwoli Ci to zmienić. Wyobraź sobie, jak skomplikowana byłaby jazda na rowerze, gdyby sygnał z Twoich oczu dochodził do mózgu z choćby milisekundowym opóźnieniem: prowadziłbyś rower, jakbyś był pijany.

W zależności od złożoności systemu podejmowanie działań na podstawie uzyskanej wiedzy wymaga czasu. Jeśli dowiesz się, że Twoja aktualna ścieżka zawodowa nie jest dla Ciebie, nadal będziesz musiał przeznaczyć kilka lat na nauczenie się nowego fachu. Ale zdecydowanie wolałbyś zdobyć tę informację na pierwszym semestrze studiów, a nie po ich ukończeniu.

Codzienne pętle informacji zwrotnej

Spróbujmy zebrać w jednym miejscu wszystkie pętle informacji zwrotnej, z którymi stykasz się codziennie jako programista.

Zmiany w kodzie

Praca nad kodem wymaga sprawdzania wpływu wprowadzanych zmian na jego zachowanie. Testy automatyczne są szybkim i dobrym sposobem na pozyskiwanie informacji zwrotnej. Pisanie ich wymaga na początku nakładu czasu, ale jednocześnie zwiększa Twoją produktywność, nie mówiąc już o ich długofalowym wpływie na jakość, jeśli stosowane są regularnie.

Gdy mam przed sobą logikę, która jest skomplikowana, lubię zaczynać pracę od napisania testów. Zrozumienie wszystkich szczegółów projektu jest trudne i wolę zrobić to podczas tworzenia testów, a nie za każdym razem, kiedy wprowadzam w kodzie zmiany.

Codzienna praca nad ticketem

Jeśli działasz w dobrze zorganizowanym zespole, ktoś będzie weryfikować Twoją pracę. Jest to świetny sposób na to, żeby się dowiedzieć, w jaki sposób zespół wykonuje swoje zadania, a także dokształcić się z programowania. Praca nad ticketem przez dzień czy dwa tylko po to, aby dostać ponad 40 propozycji zmian naraz, może być frustrująca.

Aby temu zapobiec, możesz podzielić swoją pracę na kilka mniejszych etapów i prosić o informacje zwrotne po zakończeniu każdego z nich:

1. Po przeczytaniu ticketu przekaż jego treść swoimi słowami osobie, która rozumie, czego on dotyczy. Jeśli czegoś nie zrozumiałeś, będzie ona mogła skorygować Twój sposób myślenia.
2. Napisz plan rozwiązania problemu – i daj go innemu programiście do weryfikacji, zanim przeznaczysz czas na jego wdrożenie. Możliwe, że zwróci Ci uwagę na coś, co Ci umknęło.
3. Najważniejsza jest jednak informacja zwrotna dotycząca logiki programu. Poproś o weryfikację kodu, kiedy jeszcze aktualizujesz testy.

Wersja aplikacji

W miarę jak sprint posuwa się do przodu, rośnie zbiór zmian czekających na dostarczenie. Czekanie w takiej sytuacji miałoby sens tylko wtedy, gdybyś w tym czasie robił coś konstruktywnego, na przykład realizował złożony protokół testowania aplikacji. Jeśli jednak nie są wykonywane żadne sensowne testy, to tylko opóźniasz moment, w którym zaczniesz dostawać feedback od użytkowników. Zamiast tego proces wdrażania staraj się przeprowadzać jak najczęściej. Dzięki temu unikniesz wydania jednego dużego release’u zawierającego wszystkie zmiany (i bugi) wprowadzone przez Twój zespół przez całe kilka tygodni sprintu – zamiast tego będziesz wydawał zmiany po trochu, co kilka dni.

Dopasowanie produktu do rynku

Aspekt ten znajduje zastosowanie nawet na szerszą skalę. Metody takie jak Agile czy Lean Startup wskazują, że najlepiej jest wydać produkt jak najszybciej, co pozwoli na zebranie feedbacku od klientów.

Co z jakością informacji zwrotnej?

Nie każda informacja zwrotna ma taką samą wartość. Wszystko dzieje się na pewnym kontinuum – od dokładnych wyników testów do subiektywnej opinii osoby udzielającej informacji zwrotnej. W przypadku informacji obiektywnych, takich jak:

• negatywny wynik testu lub nieprawidłowe działanie funkcji,
• zbyt wolne działanie aplikacji,
• przyjmowanie nieoczekiwanych wartości przez inne wskaźniki wydajności,

dobrze jest natychmiast rozpocząć proces naprawy.

Natomiast w przypadku opinii subiektywnych, które mogą dotyczyć:

• podejścia do kodowania,
• nazewnictwa zmiennych lub metod,
• innych spraw, które różni programiści zrealizowaliby na różne sposoby,

sytuacja wymaga wyważonego podejścia. Możliwe, że pracujesz wbrew konwencji przyjętej w projekcie albo Twoje nazewnictwo wprowadza zamęt – takimi problemami najlepiej zająć się od razu. Zdarza się jednak, że niektóre osoby dzielą się sposobem, w jaki poradziliby sobie z konkretnym problemem, tak po prostu, wiedzione chęcią omówienia metodologii pracy nad projektem.

A co z Tobą?

Czy kiedykolwiek dostałeś informację zwrotną, która zmieniła bieg Twojej kariery? Daj mi znać w komentarzach – przeczytam na pewno!