Większość z nas za każdym razem, kiedy zespół zaczyna realizację nowego projektu ma przed oczami taką samą wizję. Sprawna realizacja zadań, stabilny i systematyczny progres ukończonych zadań i efektywna praca wszystkich członków zespołu. Co ciekawe, nawet w sytuacjach zbliżonych do ideału, kiedy mamy dużą elastyczność na etapie tworzenia zespołu, jest to bardzo rzadki widok. Najczęściej postępy trudno nazwać zadowalającymi i to mimo intensywnego wysiłku członków zespołu starających się jak najlepiej realizować swoje zadania. To jeden z tych momentów kiedy, zamiast wywierać presję na zespół, warto się zatrzymać i zadać sobie pytanie: „dlaczego?”
Dlaczego zespół specjalistów sprawdzonych w innych projektach, mających dość dobrze zdefiniowany zakres zadań, ma takie problemy w ukończeniu czegokolwiek?
100% utylizacji
Odpowiedź kryje się w bardzo powszechnym, niestety, podejściu do organizacji pracy w zespołach. Zacznijmy jednak od symptomów. Jednym ze standardowych sygnałów, że coś jest nie tak, są rosnące kolejki zadań czekających na realizację kolejnego etapu procesu.
Typowym przykładem w projektach informatycznych są zadania, dla których etap developmentu jest zakończony i czekają na testy. Czy takie zadanie można traktować jako zakończone? Nie, w końcu najprawdopodobniej będą potrzebne poprawki do znalezionych błędów.
Jeśli przyjrzymy się temu, jak wygląda realizacja zadań w dowolnym momencie procesu, takich kolejek zadań znajdziemy wiele. Dlaczego?
Odpowiedzią jest jeden z bardzo powszechnych paradygmatów zarządzania – dążenie do 100% utylizacji ludzi. Przecież jeżeli mówimy o tzw. knowledge work, zwykle jedyny istotny koszt to koszt pracy. To nie linia produkcyjna z kosztownymi maszynami gdzie człowiek jest tylko dodatkiem. Tutaj linią produkcyjną jest człowiek.
Jeżeli zatem koszt ludzi jest główną składową ogólnych kosztów projektu, powinniśmy chcieć tak zorganizować pracę, aby ludzie byli maksymalnie wykorzystywani. W ten sposób osiągniemy maksymalną efektywność. Brzmi sensownie, prawda?
I to właśnie cały problem – brzmi sensownie, mimo że absolutnie nie znajduje potwierdzenia w rzeczywistości.
Aby zbliżyć się do 100% utylizacji ludzi, każdy z członków zespołu musi mieć kolejkę zadań czekających na niego. Kiedy skończy bieżące zadanie, zawsze będzie czekało na niego kolejne, dzięki temu będziemy minimalizować przestoje.
Problem w tym, że to również oznacza bardzo dużą liczbę zadań, które są rozpoczęte a nie zakończone – tak zwanych prac w toku. Oczywiście zakładam tutaj, że prace w toku definiujemy patrząc przez pryzmat całego procesu, a nie konkretnego jego etapu. Innymi słowy zadanie zaczyna być w toku kiedy rozpoczyna się pierwszy z etapów prac – analiza, projektowanie, czy cokolwiek to jest w danym kontekście – a kończy się kiedy zespół nie planuje robić z nim już niczego więcej.
Jaki jest efekt dużej ilości prac w toku? Prostą konsekwencją jest częste przełączanie kontekstu, co ma tragiczne skutki dla efektywności pracy.
Koszt przełączania kontekstu
Gerald Weinberg wskazuje1, że koszt przełączania kontekstu to 20% czasu dla każdego kolejnego zadania, nad którym pracujemy równolegle. Okazuje się, że nie tak trudno doprowadzić do sytuacji, w której marnujemy blisko połowę dostępnego czasu pracy (zobacz Rysunek 1).
Argument, który często słyszę, kiedy przywołuję opracowanie Geralda Weinberga w kontekście dużej ilości prac w toku jest taki, że przecież każdy z członków zespołu w danym momencie skupia się nad jednym zadaniem. Pozostałe zadania niejako oczekują na swój czas. Przełączanie kontekstu odbywa się zatem w znacznie mniejszej skali niż sugerowałoby to proste porównanie ilości zadań w toku i liczby członków zespołu.
Prawdopodobnie byłoby tak, gdybyśmy byli maszynami. Niestety nasz mózg ma tendencję aby sam sobie przerywać bieżącą pracę myślami o zadaniach, które pozostawiliśmy niezakończone. Przypomnijcie sobie sytuacje, w których, robiąc coś zupełnie niezwiązanego nagle pomyśleliście o rachunku, którego zapomnieliście zapłacić, emailu, na który mieliście odpisać, albo jakimś nierozwiązanym problemie. To efekt Zegarnik (bo taką nazwę nosi to zachowanie naszego mózgu) w akcji.
Dokładnie to samo dzieje się w kontekście naszej codziennej pracy. Wracamy myślami do zadań, nad którymi obecnie nie pracujemy jednocześnie obciążając nas samych kosztem przełączania kontekstu.
Jest to zresztą bardzo spójne z wynikami badań na temat multitaskingu2 prowadzonych przez Eyala Ophira na uniwersytecie Stanford. Wskazuje on, że główne źródło kosztu przełączania kontekstu to fakt, że nasz mózg zajmuje się myśleniem o zadaniach, których w danym momencie aktywnie nie wykonujemy.
Przełączanie kontekstu to nie tylko niższa efektywność pracy. To również niższa jakość. Wspomniane badania Eyala Ophira wskazały również, że osoby zajmujące się paroma rzeczami jednocześnie częściej się mylą.
Dołóżmy do tego kluczowy dla biznesu parametr time to market, określający ile czasu potrzeba aby dostarczyć wynik prac na rynek. Jeżeli przeanalizujemy go pod kątem jego związku z przełączaniem kontekstu bardzo jasno zobaczymy jak możliwość skupienia się na jednym zadaniu przekłada się na efektywność całego procesu. (Zobacz Rysunek 2).
W pierwszym z zaprezentowanych powyżej scenariuszy systematycznie przełączamy się między kolejnymi zadaniami. W drugim, rozpoczynamy kolejne zadanie dopiero po zakończeniu wcześniejszego. Nie tylko całkowity czas pracy jest krótszy w drugim przypadku, ale także moment dostarczenia poszczególnych zadań drastycznie się różni.
Co więcej, w drugim scenariuszu – tym z ograniczoną liczbą zadań w toku – możemy wykorzystać informacje zwrotne z realizacji pierwszego zadania przy realizacji kolejnych. Dajemy sobie szanse na usprawnienia. W pierwszym scenariuszu takiej możliwości nie dostajemy.
Ograniczanie prac w toku
Od szczytnego celu, czyli efektywnej pracy, przeszliśmy przed 100% utylizację i jej smutne konsekwencje, czyli intensywne przełączanie kontekstu wraz ze wszystkimi związanymi kosztami. Spróbujmy zatem odwrócić cały tok myślowy – jaki będzie efekt jeśli ograniczymy ilość prac w toku?
Najbardziej typowym obecnie podejściem do ograniczania prac w toku jest określenie limitów dla każdego kolejnego etapu naszego procesu. Jednocześnie unikamy sytuacji wprowadzenia nielimitowanych kolejek zadań w przypadku gdy są one przekazywane do kolejnego etapu. Limit tak będzie zatem dotyczył np. wszystkich zadań w developmencie, niezależnie od tego czy development jeszcze trwa czy już został zakończony a zadanie oczekuje na testy. (Zobacz Rysunek 3).
Rysunek 3.Nie potrzeba nadmiernej kreatywności aby wyobrazić sobie sytuację, w której wprowadzone limity uniemożliwią rozpoczęcie pracy nad kolejnym zadaniem. Wyobraźmy sobie, że programista reprezentowany przez zielony awatar na powyższej tablicy zakończył właśnie prace nad zadaniem F. W normalnej sytuacji zacząłby prace nad kolejnym zadaniem, G lub F, jednak w tym przypadku wprowadzony limit uniemożliwia to.
Sytuację taką, a dokładniej czas, w którym członek zespołu jest „zablokowany” przez limit prac w toku, nazywamy slack time. Slack time zgodnie z typowym postrzeganiem zarządzania zespołem oznacza czas zmarnowany. Obniża on utylizację pracowników i spowalnia tempo rozpoczynanianowych zadań.
Interesujące jest to, że obie te rzeczy – ograniczenie utylizacji i niższe tempo rozpoczynania zadań – są do pewnego stopnia pożądane jeśli chcemy optymalizować efektywność prac całego zespołu. Innymi słowy, slack time pomaga nam podnieść efektywność zespołu. Dzieje się tak w dużej mierze dzięki uniknięciu kosztów związanych z przełączaniem kontekstu.
W końcu miarą tego jak efektywny jest nasz proces nie jest to jak szybko zaczynamy kolejne zadania, ale jak sprawnie je kończymy. Jeśli użyjemy takiej właśnie miary okaże się, że sytuacja, w której część członków zespołu od czasu do czasu nie zajmuje się w ogóle pracą projektową powoduje, że produktywność zespołu wzrosła!
Jak właściwie ustalić limity? Przyjrzymy się teorii ograniczeń3. Proces jako całość będzie jedynie tak wydajny jak jego najwolniejszy etap. Jeżeli zatem wąskie gardło w naszym procesie jest gdziekolwiek indziej niż na jego najwcześniejszym etapie, to limity prac w toku są nam potrzebne po to aby nie zasypać wcześniejszych etapów procesu nadmiarem zadań.
Jednocześnie, sensowne limity prac w toku będą dopasowane do wydajności naszegowąskiego gardła. Biorąc pod uwagę jak zmienne są zadania w projektach informatycznych wskazanie właściwych limitów wyłącznie na bazie analizy samego procesu jest niemożliwe. Dochodzimy do tego eksperymentalnie. Innymi słowy, powinniśmy tak długo zmieniać limity aż przepływ zadań będzie najsprawniejszy.
Podejście to ma również taką zaletę, że przygotowuje nas do dalszych zmian limitów w sytuacji kiedy nasz proces ewoluuje. W kontekście knowledge work proces jest znacznie bardziej elastyczny niż ma to miejsce w przemyśle. Często drobne zmiany wprowadzane przez poszczególnych członków zespołu mocno zmieniają dynamikę pracy i powodują, że wąskie gardło znajdzie się w innymi miejscu. Czasem podobny efekt wywoła po prostu zmiana specyfiki wykonywanych zadań.
W każdym z takich przypadków limity prac w toku powinny być dostosowane do nowej sytuacji. Dzięki temu, że znamy już mechanizm ewolucyjnego dopasowywania ich, nie powinno to nastręczyć specjalnych trudności.
Efektywny czy zajęty?
Jak zmierzyć efektywność pracy? Najłatwiej zliczyć kończone zadania w czasie. Jeżeli na etapie definiowania zadań przyjmujemy jakieś wagi lub rozmiar możemy to również uwzględnić. Oba te podejścia są mocno uproszczone, bo nie mówią o wartości, którą dostarczamy klientowi lub użytkownikowi – najlepiej byłoby zatem przyjąć jakąś miarę dostarczonej wartości. O to jest jednak zwykle bardzo trudno.
Niezależnie jednak, której z tych miar użyjemy będziemy w stanie bardziej lub mniej dokładnie powiedzieć jaka jest i jak zmienia się produktywność zespołu.
Mając taką metrykę możemy dość bezpiecznie przeprowadzić eksperyment z ograniczaniem prac w toku. Okaże się, że wbrew intuicji większości menadżerów optymalizacja zajętości ludzi wcale nie pomaga w byciu efektywnym. Wręcz przeciwnie, skupienie się na efektywności i optymalizowanie tego parametru z pomocą ograniczeń prac w toku doprowadzi do tego, że utylizacja ludzi spadnie.
Nie dość, że efekty pracy zespołu będą lepsze to jeszcze jego członkowie dostaną czas, który mogą wykorzystać na przykład na rozwój własnych umiejętności.
Efektywny wcale nie oznacza ciągle zajęty i vice versa.
- Gerald Weinberg, Quality Software Management: Vol. 1 Systems Thinking
- Eyal Ophir, Cliord Nass, Anthony D. Wagner, Cognitive control in mediamultitaskers
- Eliyahu M. Goldratt, The Goal: The Process of Ongoing Improvement
Paweł jest doświadczonym liderem prowadzącym zespoły tworzące oprogramowanie. Obecnie pełni rolę CEO w Lunar Logic, gdzie metody zarządzania i organizacji pracy daleko wykraczają poza tradycyjne standardy. Paweł jest aktywnym członkiem światowej społeczności Lean Kanban i częstym prelegentem na konferencjach branżowych. Na stronie brodzinski.com prowadzi bloga poświęconego szeroko pojętemu zarządzaniu projektami informatycznymi. Paweł jest również coachem i trenerem wspierającym zespoły chcące usprawnić swoją pracę. Jest jednym Polakiem będącym Kanban Coaching Professional (KCP). Wierzy, że zaufanie jest konieczne w każdym udanym przedsięwzięciu oraz że szklanka jest zawsze w połowie pełna.