Niejasne zasady? Pewne problemy! – czyli o liczbie kas w sklepie i nie tylko…
Zaktualizowano: 23 cze 2021
Poprzedni wpis był o tym, że w czasach trwającej pandemii COVID-19 organizacja pracy wielu sklepów zaczęła jawnie przypominać systemy pull, a więc coś, co stoi u podłoża Metody Kanban. Dziś będzie o tym co jeszcze dzieje się wokół nas gdy zasady gry, lub jak mówimy w Kanbanie – polityki nie są jasne.
W dosłownie kilka godzin po publikacji pierwszego wpisu z tej miniserii pojawiła się kolejna zmiana. Zarządzono, że liczba osób przebywających jednocześnie w sklepie nie powinna przekraczać 3-krotności liczby kas.
I bum! Stało się. W zamiarze zapewne dobrze, w wykonaniu … nie, nie zamierzam jednak napisać, że źle. Stało się niedoskonale, ponieważ polityki były niejasne 😊
Po pierwsze, co mnie zdziwiło, to regulacja odnośnie liczby klientów dotyczyła liczby kas, a nie kas obecnie otwartych, a przynajmniej tak to zrozumiałem z całego medialnego zamieszania. To pewnie jeden przykład niewystarczająco jasnej i jawnej zasady, która prowadzi do niepożądanych zachowań.
Co nam po zamkniętej kasie? Jeśli na jej podstawie pozwalamy klientom wchodzić do sklepu, to możemy oczywiście liczyć na zmienną naturę czasu robienia zakupów itp., ale raczej bardziej lub mniej prawdopodobnie doprowadzi to do wzrostu gęstości ludzi w sklepie i długości kolejek, których chcielibyśmy uniknąć.
Przypomina mi to sytuację wielu zespołów, które „planują” pracę w oparciu o deklaratywną, często na dodatek tylko częściową dostępność członków zespołu. Ludzie Ci pracują w nim jedynie „na org charcie”. Ich dostępność, skupienie, czas są mocno ograniczone. To nie spowoduje zwiększenia dostarczanej wartości.
Taka nieprecyzyjna lub źle sformułowana polityka prowadzi, a może raczej zachęca do nadużyć. Przykład? Cała kreatywność w postaci traktowania czegokolwiek przypominającego rzeczoną „kasę” jako coś, co pozwala zwiększyć liczbę klientów.
A gdybyśmy tak spróbowali ograć system? 😊 I tak się właśnie stało. Szukając analogii do pracy zespołów, nie tylko z branży IT, przypomina mi to oszukiwanie wizualizacji i limitów pracy w toku.
Ach wiecie, takie małe zadanko na boku, nie widać go, bo szkoda czasu zakładać ticket.
Jeszcze mocniej brak jasności i spójności w interpretacji zasad dotknął osoby ukarane mandatami za zachowania, które były mówiąc wprost.. lokalnie i jednostkowo interpretowana na ich niekorzyść przez policję czy straże miejskie.
Wolno biegać czy nie? A co z rowerem? A jak rowerem po zakupy, a jeśli na trening? A czym się różni trening biegowy od kolarskiego? A co z samochodem i kierowcą, którzy przecież mogą przemieścić się szybciej i dalej niż rower? Sami pewnie widzieliście click baity na różnych portalach oraz udostępniane nagrania nieposłuszności obywatelskiej.
Nie piszę tego pod żadnym pozorem by rozpętać tu burzę. Ktoś powie – kontekst jest królem i będzie miał rację. Jasne polityki to jedna z podstawowych praktyk Kanbanu, która powoduje, że w wielu przypadkach w tę kontekstowość nawet byśmy nie wchodzili i nie musimy zajmować sobie niepotrzebnie czasu i głowy.
Mówicie, że coś jest zrobione? Ale czy sądzicie tak Wy, Ty, wasz Product Owner czy sam użytkownik?
To nie to samo i scrumowa Definicja Ukończenia, użytkowniko-historyjkowe Kryteria Akceptacji, czy cała rodzina kanbanowych pull criteria są właśnie po to.
Zanim więc przejdziemy do polityki. Nie, tego nie zrobimy. 🙂 Zanim przejdziemy do krytyki zasad, osób którym możemy zarzucać nawet bez świadomości złą wolę, brak umiejętności zastanówmy się, z pokorą, na ile znane, aktualne i wspólnie rozumiane są nasze zasady gry. Ile jest w nich “to zależy” nawet tam, gdzie nie powinna być to domyślna odpowiedź.
Kiedy się tym zajmować? Dobrymi okazjami do przeglądu i aktualizacji obowiązujących polityk na pewno są wszelkie zmiany:
nowo tworzony zespół,
każda zmiana osobowa, pojedynczego członka zespołu lub większej ich liczby,
łączenie zespołów,
zmiana klienta, Product Ownera,
ale również powinno odbywać się do regularnie nawet, gdy środowisko zespołu i jego otoczenia pozostaje niezmienne. Dlaczego? Nawet jeśli mamy ten sam zespół, PO to zwykle zmienia się sama natura, faza projektu. Zmieniają się nasze praktyki, zarówno te developerskie, nowe czynności, środowiska, czy narzędzia. Zmienia się też rynek, produkt, forma i częstotliwość feedbacku dotyczącego produktu, jaki dostajemy. To również są powody, dla których powinniśmy regularnie przeglądać i aktualizować obowiązuję polityki i czynić je jawnymi.
Na koniec inspiracja jedną z zasad dostarczania usług Metody Kanban: