Wydaje się, że transparentność, czyli przejrzystość, to jeden z tych tematów, które wracają do nas regularnie co dwa lata. Dlaczego by więc nie zacząć kolejnego roku od przypomnienia tego zagadnienia? A przy okazji postaramy się udzielić kilku porad o tym, jak to może wyglądać w praktyce.
Czym jest transparentność?
Nasz główny tekst o przejrzystości nazywa się po prostu „Transparentność” i został napisany przez Łukasza jeszcze w 2018 roku. Dotyczy głównie scrumowego ujęcia tego zagadnienia, gdzie najbardziej liczy się dla nas informacja procesie, pracy i o wszystkich artefaktach:
„Kształtujący się proces oraz praca muszą być widoczne dla osób ją wykonujących, jak również dla osób,
na rzecz których praca ta jest wykonywana. (…) Niedostateczna przejrzystość artefaktów może prowadzić do decyzji, których wynikiem jest zmniejszona wartość bądź zwiększone ryzyko.” – Scrum Guide 2020
W skrócie – musimy podejmować decyzje na podstawie tego, jak jest, a nie jak „wydaje nam się, że jest”. To drugie prowadzi do problemów, a przecież jak pisał Łukasz „nie ma negatywnych konsekwencji dzielenia się stanem faktycznym naszej pracy”.
Temat dalej został rozwinięty w tekście „Szacunek kontra transparentność„, gdzie poruszone zostały sytuacje, w których bardzo drażliwe informacje (np. osobiste bądź strategiczne) nie powinny wychodzić poza jakieś określone grono. Tam odwołałem się do zdrowego rozsądku, który zawsze powinien podpowiedzieć nam właściwe rozwiązanie. To sugeruje, że być może tytułowa „pełna transparentność” nie jest tym najlepszym rozwiązaniem.
A jak jest naprawdę?
Definicja pełnej transparentności
Poniższa definicja pełnej transparentności jest moim prywatnym konstruktem i nie znajdziecie jej w żadnych materiałach. No chyba, że ktoś gdzieś ma podobne przekonania. Co, biorąc pod uwagę agile mindset, jest to wysoce prawdopodobne.
Warto też dodać, że kwestię te rozpatruję w kontekście zawodowym, gdzie wszyscy pracujemy w jednej firmie bądź jednym zespole. W profesjonalnym środowisku nie zajmujemy się rzeczami prywatnymi, w związku z czym mają tutaj znaczenia przekonania osobiste i tak rozumiana prywatność.
„Domyślnym stanem informacji jest ich pełna dostępność dla wszystkich. W ramach organizacji/zespołu wszystkie informacje, które potencjalnie mogą być potrzebne do pracy powinny być jawne i bez problemu dostępne dla każdego.”
Kluczowe słowa to „wszystkie”, „mogą być potrzebne”, „każdego”. Jeśli pracujemy razem w jednej firmie, ale na różnych projektach, które mają ze sobą mało punktów styku, to jak najbardziej powinniśmy mieć dostęp do wszystkich. Bo przecież punkty styku są, więc może się zdarzyć, że coś będzie potrzebne. Łatwiej będzie sięgnąć do źródeł niż najpierw „załatwiać sobie dostępy”. Podobnie jeśli np. jako wspólnicy wykonujemy działania promocyjne naszego produktu bądź marki w różnych mediach, to prawdopodobnie nie wchodzimy sobie w drogę. Możemy nawet nie chcieć wiedzieć co robią inni, ale szaleństwem byłby brak dostępu do tych informacji.
Powyższa definicja jest oczywiście niekompletna. Brakuje wszystkich tych kwestii, które powinny zostać „ukryte”. Natomiast pamiętajmy, że ukrywanie czegokolwiek prowadzi do naruszenia zaufania. Pół biedy, jeśli wiemy, że coś jest ukryte i z jakich powodów („Projekt: zwolnienia grupowe” ;)), dużo gorzej jeśli nie wiemy dlaczego nie wiemy. Ale już zupełną tragedią jest, gdy coś jest tak ukryte, że nawet nie wiemy, że istnieje. Bo jak się dowiemy (a prędzej czy później się dowiemy), to burzymy miesiące albo i lata budowania zaufania.
W związku z tym powinniśmy dodać do tej definicji jakiś wentyl bezpieczeństwa, który pozwoli nam na zachowanie odpowiedniego poziomu dostępu (żeby nie powiedzieć „ukrycia”):
„Informacje niejawne powinny być 'jawnie ukryte’, tzn. powinna być jasna informacja, dlaczego dostęp do danej rzeczy jest ograniczony i kto go posiada.”
Tym ostatnim sformułowaniem („kto posiada [dostęp]”) załatwiamy kluczowe słowo „każdy”. Co do zasady wszyscy wiedzą wszystko, ale jeśli czegoś mamy nie wiedzieć, to wszyscy wiedzą „kto wie”.
Praktyka pełnej transparentności
Jak pisał Łukasz „nie ma negatywnych konsekwencji dzielenia się stanem faktycznym naszej pracy”. Moja definicja idzie dalej – nie ma żadnych negatywnych konsekwencji dzielenia się wszystkimi informacjami, których używamy w ramach naszej pracy. Bo jeśli mi coś się przydaje albo jest potrzebne, to drugiej osobie również może się to okazać użyteczne. A jeśli nie – nic się przecież nie stanie.
W dzisiejszym zinformatyzowanym świecie sam fakt, że ktoś ma do czegoś dostęp, nie znaczy, że mu on przeszkodzi. Pliki projektu X przecież leżą w innym miejscu niż pliki projektu Y. Nie wyświetlają się na jednej liście. Wyszukiwarki mają filtry. Nie ma tu żadnego problemu.
W praktyce – niech wszystkie Zespoły Deweloperskie mają dostęp do wszystkich „projektów” np. w Jira. Dlaczego nie? I tak nikt nie będzie tam nic czytał, a „w razie potrzeby” dostęp jest. Tak samo z repozytoriami kodu, z dokumentami analitycznymi, z aplikacjami. Słabo mi się robi, gdy „tylko testerzy mają konta w systemie do obsługi testów”. Dlaczego? A jak ktoś inny będzie potrzebował przetestować (patrz nasz ostatni film o Deweloperach) albo sprawdzić wynik jakiegoś testu, albo zweryfikować czy na pewno wszyscy dobrze się zrozumieliśmy?
Jeżeli chodzi o kwestie organizacji, to tu wiadomo, że inne są poziomy odpowiedzialności np. właścicieli czy zarządu, a inne pracowników. Kwestia „potencjalnej przydatności do pracy” elegancko nam to załatwia. Zespołom Scrumowym do pracy (nawet potencjalnie) nie są potrzebne umowy z dostawcami czy klientami, ani NDA podpisane z konsultantami. Te rzeczy „potencjalnie potrzebne do pracy” są dla managementu, dyrektorów, zarządu, etc.
Wprowadzając politykę pełnej transparentności musimy zadbać więc o dwie rzeczy. Po pierwsze, aby domyślny tryb uprawnień był ustawiony na „dostępne dla wszystkich”. Po drugie – i o wiele trudniejsze – aby wszyscy faktycznie korzystali z naszych repozytoriów wiedzy, dokumentów i informacji. Bo taka polityka na nic się nie zda, jeżeli mamy do czynienia z jednostkami, które „potencjalnie potrzebne do pracy” informacje trzymają na swoim prywatnym komputerze i się z nimi nie dzielą. To jednak temat na osobny tekst, który już w czwartek zostanie rozesłany na naszej liście mailingowej, do której subskrypcji gorąco zachęcamy.
Tomek, użyłeś cytatu współtwórcy bialko.eu „(…) nie ma negatywnych konsekwencji dzielenia się stanem faktycznym naszej pracy”. W mojej ocenie, oczywiście tak być powinno, a jak jest to już zupełnie inna historia. Pierwszy przykład z brzegu to niewłaściwa interpretacja wykresu spalania zespołu i związane z tym komunikaty kierowane do zespołu. Często zdarza się, że wykres ten trafia do osób, które nie mają pojęcia czemu ma on służyć a widząc linie, słupki czy inne zobrazowanie sytuacji gdzie zespół się znajduje w sprincie wyciągają błędne wnioski wywołując nimi naruszenie zaufania, a także bezpośrednio wpływając na atmosferę w zespole.
Przykładów tego typu można by pewnie mnożyć, szczególnie poruszając się w obszarze mierzenia skuteczności zespołów. Zdaję sobie sprawę, że jest to patologia i ogromny obszar do pracy z organizacją, niemniej poddaję w wątpliwość w/w cytat o braku negatywnych konsekwencji. W profesjonalnie działającym agile'u tak być powinno, ale gdyby tak wszędzie i zawsze było to nie mielibyśmy pracy 🙂