Większość z nas czuje, że przełączanie się między różnymi wątkami to wytracanie energii – rozpędziliśmy się w jednym temacie, musimy przerwać, a powrót do niego będzie trwał. Z jakiegoś powodu jednak ciężko nam z tym walczyć. W tym poście dowiesz się jakie są koszty przełączania między zadaniami, między projektami i jakie są potencjalne źródła takich problemów.
Ten post to czwarty post z serii, w której poruszam problem manortrawstwa. Jeśli chcesz się dowiedzieć, czym ono jest lub przeczytać poprzednie artykuły przejdź do tej strony.
Przełączanie między zadaniami
Jak myślisz, który sposób będzie szybszy?
1) zrobić jedno zadanie do końca, a potem chwycić za drugie i zrobić je do końca
2) czy rozgrzebać trochę pierwszego, przejść do drugiego, rozgrzebać, zmienić, rozgrzebać, zmienić?
Wiele razy widziałem sytuacje, gdy programista musiał przełączać się między różnymi zadaniami, nie kończąc poprzednich – był to skutek m.in. ciągłych zmian w priorytetach, “wszystko jest pilne” itp. 😤
Najczęściej kończyło się to obniżaniem jakości, ze względu na pośpiech (robienie na kolanie) i opóźnieniami w całym projekcie. Opóźnienia wynikały z tego, że powrót do poprzedniego tematu zajmuje z reguły sporo czasu. I z tego, że niższa jakość generowała bugi – bo nie było możliwości zrobienia dobrego code review, nie było testów itd. Potem zatem poświęcano dużo czasu na poprawki. Ponadto, raz odłożony kod zaczynał się starzeć i każdy kolejny dzień zwiększał ryzyko wystąpienia konfliktów podczas łączenia kodu “starego” i “nowego”. Dodajmy te wszystkie wątki do siebie, niech wystąpią wiele razy w ciągu jednego projektu i straty zaczynają być naprawdę duże.
To zwykłe marnotrawstwo.
“How long does it take people to get back on task?
We found about 82 percent of all interrupted work is resumed on the same day. But here’s the bad news — it takes an average of 23 minutes and 15 seconds to get back to the task.”
Tu przeczytasz całkiem dobry artykuł, z którego powyższy cytat pochodzi.
Przełączanie między projektami i Prawo Brooks’a
Często, zmorą organizacji, szczególnie tych dużych, jest przerzucanie ludzi między projektami – “musimy Was pilnie przerzucić do projektu XYZ, bo tam jest sztywny deadline i zespół nie daje rady” 😱
Koszty?
- osłabenie zespołu, z którego odchodzi dany deweloper,
- inni programiści zamiast w pełnym tempie pracować nad swoimi rzeczami, pomagają nowemu koledze,
- czas na nauczenie się projektu
- czas potrzebny na zgranie się osobowościowe, dopasowanie do standardów itd. oraz wynikające z początkowego niedopasowania, różnego rodzaju problemy (komunikacyjne itd.).
To wszystko generuje opóźnienia. Często dużo większe niż zyski, wynikające z większej liczby “palców do stukania w klawiaturę”. Frederick Brooks już w 1975 o tym pisał i jest nawet na to “nazwa”. Czemu nadal popełniamy takie same błędy? 💩
Jak żyć?
Rozwiązania, na te bolączki, są proste. Z założenia 🙃
Konieczność przełączania między zadaniami może mieć bazylion powodów. Jest jednak kilka obszarów, które warto sprawdzić czy można coś w nich zmienić, aby sobie ulżyć:
- stan wiedzy, o tym co jest do zrobienia w projekcie; stan Backlogu Produktu, poszczególnych historyjek czy zadań i planu na ich realizację, – większa wiedza = mniej niespodzianek
- jakość komunikacji z interesariuszami / klientami – niska skutkuje chaosem komunikacyjnym, zmianami priorytetów, nieporozumieniami
- autonomia i asertywność zespołu – deweloperzy nie mają wpływu na kolejność działań, dostają precyzyjne (złudnie!) zakresy bez możliwości negocjacji i nie mogą odmawiać wrzutkom. W tym samym czasie Product Owner, Scrum Master czy Kierownik Projektu nie pomagają, interesariusze rozdają wszystkie karty,
- przyspieszenie procesu dewelopmentu przez: automatyzację powtarzalnych czynności i eliminowanie zbędnych – im mniej czasu musimy poświęcić na “odrabianie pańszczyzny” tym szybsza nasza praca “właściwa”, a to może oznaczać że szybciej będziemy mogli ukończyć rozgrzebane, więc jest zawsze argument, żeby jednak to dopiąć do końca
- twarde stosowanie dobrych standardów jakościowych (testy automatyczne, lintery itd.), nie obniżanie ich pod presją czasu – im mniej bugów i pomyłek tym więcej czasu na robienie nowych, kolejnych zadań w przyszłości, mniej rozpraszaczy które sobie sami wygenerujemy
- rozmiar projektów i zadań – łatwiej zarządzić małymi rzeczami, ewentualne straty w przypadku konieczności zmiany zadania są mniejsze i jak wyżej, łatwiej przekonać, że nie zostało nam wiele do skończenia
Przerzucanie ludzi między projektami to bardziej złożony problem. Z moich doświadczeń wynika, że najczęściej można tego uniknąć przez:
- realistyczne szacowanie rozmiaru projektów i regularne, od wczesnego etapu, sprawdzanie jego postępów (+ częste, możliwie małymi partiami, wdrażanie kodu na środowisko produkcyjne),
- zarządzanie ryzykami i komunikacją problemów w trakcie trwania projektów – zespoły, menadżerowie potrzebują odwagi, aby mówić głośno o tym, że jest jakieś zagrożenie. Często zdają się czekać na cud, który sprawi, że problemy same się rozwiążą albo ktoś inny to powie i “nie będzie na mnie”
- stawianie na zespoły produktowe (lub obszarowe), zamiast na projektowe – bardzo duży projekt może być realizowany przez wiele zespołów, które znają swoje obszary i synchronizują się między sobą. Często jednak widzę zawiązywanie zespołów na potrzeby kolejnych projektów – “bo są duże i obejmują kilka obszarów”, a potem kolejnych i kolejnych – zanim się rozkręcą mija całkiem sporo czasu… :)
Listy nie wyczerpuję. To tylko praktyki, których doświadczyłem, w takich czy innych okolicznościach i praca nad nimi pomogła zespołom, z którymi pracowałem. Sądzę jednak, że coś może Cię zainspirować :)
Podsumowanie
Eliminowanie marnotrawstwa nie jest łatwe. Pewnie dlatego, że dotyczy ludzi i ich przyzwyczajeń – proponowanie zmian bardzo często wiąże się z oporem. Co nie znaczy, że nie warto próbować :) Jestem pewien, że zaczynając od małych kroków, w tym edukacji naszych kolegów, a potem coraz szerszego grona, jesteśmy w stanie dojść do punktu, w którym przełączania między zadaniami i przerzucania ludzi między projektami będzie minimalna ilość. Świat będzie lepszy ;-)
Inne posty, które mogą Cię zainteresować:
- “Scrum to chaos i brak prawdziwego planowania”. Serio? 🙃
- “Przejdźmy na Kanban, bo mamy dużo wrzutek w sprintach” – przypadek z życia pewnego zespołu
- Krótka gra, która pokazuje, że multitasking to zło
W poście wykorzystałem grafiki / zdjęcia z rawpixel.com