Rozpoczynając nowy rok wiele z nas czyni przeróżne postanowienia. Nie będziemy przy tym pochylać się nad ich skutecznością sensu stricte. Tak w życiu prywatnym, jak i w pracy dobrą praktyką jest, by nasz cel pozostał jasno zdefiniowany oraz by był osiągalny. Rzecz trywialna, ale czy zawsze?
Praca nad wytwarzaniem produktu rozpoczyna się już w chwili, gdy zespół planuje pracę nad funkcjonalnością, na przykład podczas PI Planningu lub jakiegokolwiek innego wydarzenia, gdzie ma miejsce kolektywne planowanie. Nie położenie rąk na klawiaturze w południe po planowaniu, nawet nie przeciągnięcie zdania w Jirze w kolumnę „In Progress” – to właśnie definicja celu przechyla szalę odpowiedzialności w kierunku zespołu, który do wykonania danego zadania się zobowiązał, jednocześnie inicjując rzeczywistą nad nim pracę.
Czy istnieje jeden właściwy sposób na jasne i konkretne nazwanie celu naszych wysiłków? Zdecydowanie nie, gdyż wiele zależeć będzie od dziedziny naszej pracy, stopnia zrozumienia problemu czy też naszej wewnętrznej mobilizacji i dyscypliny. W miarę uniwersalnym, a przy tym bardzo użytecznym sposobem na określanie celów jest choćby reguła SMART będąca akronimem cech, jakie definicja celu powinna w sobie zawierać. Praca nad zadaniami formułowana w ten sposób wymaga nazwania naszych działań w jednoznaczny, zrozumiały dla laika sposób. Wyniki naszej pracy powinny być również mierzalne, co mogłoby być wyrażone poprzez wartości liczbowe, czy choćby dzięki punktom kontrolnym rozmieszczonym na różnych etapach realizacji pracy. Także jego osiągalność nie może przekraczać faktycznych możliwości zespołu, który będzie go realizował, równocześnie pozostając istotnym i wartościowym z punktu widzenia beneficjenta celu. Zwieńczeniem użycia owej reguły pozostaje określenie punktu w czasie, kiedy to realizacja celu dobiegnie końca, lub chociaż jego część będzie mogła zostać uznana za zadowalającą.
Ale czy naprawdę potrzebujemy celów, gdy już pracujemy nad funkcjonalnościami, które same w sobie prawdopodobnie składają się z serii mniej lub bardziej konkretnych wymagań? Do osiągnięcia wysokiej wydajności w realizacji planu trzeba patrzeć trochę poza horyzont. Wspomniane wcześniej przesunięcie odpowiedzialności za wykonanie zadania na zespoły niesie za sobą konsekwencję na przykład w postaci innej interpretacji założeń poczynionych przez menadżerów produktu. Zespół pracujący nad realizacją zadań widzi więcej, z czasem wie więcej i jest krytycznym ciałem sprawczym w łańcuchu dostaw, bowiem odpowiada za przetłumaczenie wymagań biznesowych na rzeczywistą wartość, którą musi, dajmy na to, zakodować czy zrefaktorować. Ta wartość biznesowa to oczywiście kres i cel naszych wysiłków, jednak kroczy ona ramię w ramię z pracą nad równoczesnym rozwojem architektury, dbaniem o dobrą jakość platformy i szybkie rozwiązywanie defektów, potrzebę ciągłego doskonalenia swojego rzemiosła czy też uczenie się poprzez robienie nieintencjonalnych błędów. W takim kontekście bezpiecznym będzie stwierdzenie, że nie tylko sam finisz jest celem, a jest nim cała droga, jaką zespół musi przebyć, by do finiszu dobiec.
Wszystkie wielkie osiągnięcia zaczynały się od postawienia małego kroku. Choć nie każdy z nich będzie do końca przemyślany, niektóre z pewnością pozostaną przypadkowymi, to wszystkie z nich winny kierować nas poza horyzont. Ciągłe równoważenie ambicji i możliwości zabierze nas o wiele dalej, niż chaotyczne porywy serca, które, owszem, mogą być spektakularne, lecz dla całego zespołu (oraz zespołu zespołów) mogą również skończyć się zawałem.