Szybko, bo to ważne

Stary dowcip mówi, że bardzo łatwo możemy zrobić coś szybko i dobrze – wystarczy zrobić to dwa razy. Skąd więc bierze się pomysł, żeby w ważnych dla nas tematach działać jak najszybciej? Przecież nie od dziś wiadomo, że szybko to nie zawsze znaczy dobrze…

 

“Jak powstają Twoje teksty…”

Ten tekst był pisany na szybko. Nie na kolanie, bo niezależnie od tego, co się dzieje, “kryteria jakościowe nie są obniżane”. Stąd też powód, dla którego świąteczny okres ciszy na naszym blogu przerywamy dopiero teraz. Spragnionym treści polecamy także nasz kanał na YouTube (w tym zmontowane do 29 minut wystąpienie pod tytułem “Najważniejsze zwinne pytanie, którego nikt nie zadaje“).

Tekst na blogu nie jest żadnym krytycznym projektem. To BAU, czyli “business as usual”. Możemy sobie wyobrazić jego powstawanie w trakcie podróży, grubo po północy albo nawet na komórce. Ponieważ nasze kryteria Definition of Done obejmują także korektę wykonywaną przez drugą osobę, efekt końcowy nie będzie się różnił w żadnym z tych przypadków. I to jest dla nas cecha rzeczy zwyczajnych, robionych regularnie albo wręcz rutynowo.

Tę samą charakterystykę ma dla nas każdy Sprint, niezależnie od tego czy jest on pierwszy, czy też sto pierwszy. Jak zresztą zostało napisane w dobrze nam znanych 12 Zasadach Zwinnego Tworzenia Oprogramowania, nie interesują nas w tym temacie zrywy i rzuty na taśmę.

“Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy w nieskończoność” – Agile Manifesto

Skoro mamy mieć zrównoważony rozwój, to nie powinniśmy mieć też sytuacji, w których dociskamy śrubę, wyrzucamy kryteria jakościowe przez okno i zaczynamy dewelopować na kolanie, nieprawdaż?

 

Ważne czy pilne?

Najwięcej nieporozumień w temacie robienia rzeczy na szybko, bierze się z pomieszania dwóch pojęć. Rzeczy pilne musimy zrobić szybko, rzeczy ważne zaś – dokładnie. W obu przypadkach odpowiednia kategoria wynika z potencjalnych konsekwencji.

Dla rzeczy pilnych najbardziej istotne jest przekroczenie terminu, po którym dotkną nas nieprzyjemne konsekwencje (np. niedostosowanie się do zmieniającego się prawa). Zdarza się też tak, że po prostu odnotowujemy straty tak długo, jak nie zadziałamy (np. awaria naszych systemów).

Rzeczy ważne są istotne dla nas lub dla naszej organizacji. W ich przypadku zrobienie ich źle bądź pomylenie się przy realizacji spowoduje więcej szkód niż jakiekolwiek opóźnienia. Jeżeli startujemy “najważniejszy dla naszej firmy projekt”, to poświęćmy odpowiednio dużo czasu na jego organizację. Gdy zaś mamy do czynienia z “krytyczną funkcjonalnością, która przynosi nam 80% dochodu”, to zapewnijmy wszystkim odpowiedni komfort pracy.

No dobrze, a jeśli coś jest zarówno ważne, jak i pilne? Typowym przykładem jest tutaj błąd krytyczny, który powoduje przerwę w działaniu naszego systemu centralnego. Z jednej strony chcemy go poprawić szybko, z drugiej zaś – nie chcemy przy okazji wygenerować kolejnych błędów.

Schemat postępowania wydaje się być oczywisty: spróbujmy określić, która cecha jest tą najbardziej istotną. Jeżeli jest to pilność – poprawmy go tak szybko jak się da, aby nie spowodować dalszych szkód. W przypadku błędów ważnych (krytycznych z punktu widzenia naszej organizacji) poświęćmy im tyle czasu, ile potrzeba.

A gdy nie potrafimy się zdecydować, musimy zadziałać zgodnie z przywołanym na wstępie dowcipem. Najpierw poprawmy byle jak, “aby działało”, a następnie od razu zacznijmy opracowywać rozwiązanie docelowe. A że narobimy się więcej? Skoro chcemy szybko i dobrze…

 

Krytyczny brak czasu

Brak czasu na rzeczy krytyczne z punktu widzenia naszej organizacji zawsze prędzej czy później wyjdzie nam bokiem. Nie można robić rzeczy ważnych będąc w ciągłym niedoczasie. Nie ma ludzi, którzy pracując pod presją nie popełnią w końcu błędów. Tak samo w każdej sytuacji, w której zaczniemy pracować na akord, skończy się to rosnącym długiem technologicznym.

Kontrolerzy lotów pracują co najwyżej dwie godziny jednym ciągiem, potem mają przerwę. Nie pracują też więcej niż pięć i pół godziny w trakcie jednego dnia. Wykonują oni krytyczne i ważne zadania zapewnienia bezpieczeństwa w ruchu lotniczym. Nikt nie zmusza ich do nadgodzin, nikt nie dokręca im śruby.

Nie mówię, że praca każdego z nas może mieć podobne konsekwencje. Na szali zwykle nie ma ludzkiego życia, a “co najwyżej” pieniądze. Ale zastanówmy się, czy w przypadku naprawdę krytycznych spraw nie powinniśmy brać przykładu z okolic kontroli lotów.

Jeżeli coś jest dla nas naprawdę ważne, poświęćmy temu odpowiednio dużo uwagi, środków i… czasu. Jeżeli realizujemy to “coś” zwinnie, to pamiętajmy o zrównoważonym tempie, które pomoże nam w zapewnieniu wysokiego jakościowo rozwiązania. Odstępstwa od tej zasady mogą mięć zgubne skutki.

Praca pod presją czasową, dowożenie wymagań na ostatnią chwilę i wdrożenia realizowane rzutem na taśmę mogą mieć naprawdę nieprzyjemne konsekwencje. Szczególnie te długoterminowe.

 

Zgubne skutki…

Dziesiątki razy ostrzegaliśmy co się dzieje, gdy tylko pozwolimy sobie na luz w temacie trzymania się zwinnych zasad. Broken Window Theory jest naszym ulubionym tekstem na ten temat, bo dobitnie pokazuje, że nie ma czegoś takiego jak “jedno odstępstwo”. Ono zawsze ma konsekwencje w postaci następnych i następnych.

Jeżeli zaś chodzi o agile mindset, to nie możemy być “trochę zwinni”. Musimy zadbać o zrozumienie całego podejścia i wszystkich jego aspektów w każdym zakamarku organizacji, w której się znajdujemy. Bo zwykle w teorii wszyscy wszystko rozumieją i się zgadzają, a w praktyce prędzej czy później pada pytanie pod tytułem “No dobrze, to jak ja mam kontrolować czy Zespół Deweloperski nie bierze za mało pracy na Sprint?” I ręce opadają.

Podobną reakcję mam zawsze w przypadku popędzania ludzi w tematach skrajnie ważnych. Mam alergię na zdania typu “Nie mamy czasu się nad tym dłużej zastanawiać, bo to ważny problem i trzeba go rozwiązać szybko” czy “To jest dla nas kluczowy produkt i musimy go wdrożyć we wcześniej zakładanym terminie.” Takie stwierdzenia są ok tylko i wyłącznie wtedy, gdy zgodnie z zasadą transparentności jawnie pokażemy wszystkie ryzyka, które wiążą się z takim działaniem.

Rozumiem, że jak się pali, to trzeba gasić. Ale warto przedtem zastanowić się chociażby jakiego typu gaśnicę wybierzemy. Inaczej możemy narobić więcej szkody niż pożytku. A na to zwykle naprawdę nie możemy sobie pozwolić.

Tomasz Dzierżek

16 lat doświadczenia w IT, 8 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: