Czołowi gracze na rynku rozumieją wartość no blame culture. Wywiad z Piotrem Kubowiczem

Czy w IT panuje kultura wymiany wiedzy w pełnym wymiarze? Nie tylko na temat działających rozwiązań, ale też tych, które nie do końca spełniają oczekiwania, mają wysoki próg wejścia? O to zapytaliśmy Piotra Kubowicza, Senior Backend Engineer w Superside, odpowiedzialnego za Developer Experience.

Przed czym chciałbyś przestrzec całą branżę IT?

Gdy zaczynamy szukać informacji o pewnej technologii, bibliotece czy frameworku, zazwyczaj zalewa nas wyliczenie zalet. Znajdujemy dużo o takich i innych możliwościach. Podobnie wyglądają nie tylko strony producenta, ale też artykuły w serwisach IT, wystąpienia na konferencjach.

Nie jest łatwo znaleźć bardziej zniuansowane opinie. Na przykład, że framework X ma duże możliwości, ale też duży próg wejścia i wymaga zespołu z dużym doświadczeniem. Lub że system Y dużo obiecuje, ale w praktyce wyniki są średnie. Relacje o tym, że coś się nie sprawdziło.

Jesteśmy w branży IT dumni, że potrafimy dzielić się wiedzą. Robimy to często za darmo, przekraczamy bariery firm, języków programowania. Jest z czego się cieszyć, ale też musimy zastanawiać się nad jakością tej wiedzy.

Jeśli ludzie dzielą się tylko historiami, gdy coś wyszło, przestajemy mieć pełny obraz rzeczywistości. Środowisko naukowe zna podobny problem, czasem nazywany “publication bias” lub “file-drawer effect”. Jeśli łatwiej opublikować badania, w których ktoś uznał lek za skuteczny, niż badania, w których skuteczność nie osiągnęła oczekiwanego poziomu, dzieją się złe rzeczy. Są znane przypadki dopuszczenia do sprzedaży środków, które nie działały – ponieważ ocenę podjęto patrząc na jedynie fragment badań, czyli te, które ostatecznie opublikowano.

Dlaczego Twoim zdaniem powinniśmy zmienić kulturę mówienia o wartych uwagi rozwiązaniach?

Nie działamy w branży medycznej, więc nie ryzykujemy zdrowiem ludzi. Jednak wciąż będziemy ponosić poważne koszty, jeśli w dyskusjach o rozwiązaniach będzie panowało pozytywne skrzywienie.

Nie obejmuje to tylko pieniędzy wydanych na subskrypcje i licencje na oprogramowanie. Darmowe biblioteki wciąż wiążą się z kosztami. Wdrażając rozwiązanie, które w działaniu rozmija się daleko z naszymi oczekiwaniami, możemy stworzyć w zespole frustrację i konflikty. Być może ciągle trzeba będzie tam coś poprawiać, uwikłamy się w dodatkowe wysiłki na utrzymywanie, zamiast pracować nad potrzebnymi rzeczami.

Nie mamy problemu z brakiem miejsc do czerpania wiedzy. Przeznaczyliśmy i wciąż przeznaczamy dużo energii na tworzenie konferencji, newsletterów, blogów, vlogów, podcastów i tak dalej. Niech jednak cała ta wielka energia służy polepszaniu tego, jak pracujemy, a nie powtarzaniu jednego i tego samego przesłania.

Jeśli mowa o kulturze dyskusji, dobrze by było, żebyśmy za wzór brali to, jak opinie wymieniają naukowcy. Czyli skupiać się na wniesieniu czegoś nowego do dyskusji oraz poparciu tego argumentami.

Na Instagramie i TikToku mamy influencerów, którzy bawią się nowymi gadżetami, ale nic odkrywczego o nim nie mówią. Od czasu do czasu wybucha nowa afera, że jakiś celebryta poleca produkt, którego nawet nie użył. Uważajmy, żeby nie pójść w tym kierunku.

Co konkretnie możemy zrobić? Dzielenie się wiedzą działa na wielu poziomach. Dlatego działanie potrzebne jest nie w jednym miejscu, ale kilku. Zaczynając od konferencji, newsletterów, osób kierujących blogami firmowymi – bo tam decyduje się, jakie tematy są brane na warsztat i jakie ostatecznie pokazywane publiczności. Niech organizatorzy dbają o to, by prezentacje czy artykuły prezentowały zdrową mieszankę. Nie samo “sprzedawanie” nowych technologii, ale mówienie o szerszej historii. Czyli w jakim kontekście rozwiązanie się sprawdza, pod jakie problemy jest zaprojektowane, a w jakich kontekstach nie przyniesie korzyści. Dobre konferencje dostrzegły, że historia i kontekst są tym, co interesuje ludzi i sprawia, że wyciągają więcej dla siebie. Takie materiały wymagają więcej pracy przy przygotowaniu, ale dają więcej wartości twórcy, konferencji, oraz odbiorcom. Zyskują wszyscy.

Z perspektywy twórcy, warto dostrzec, że mamy szansę wyróżnić się z tłumu. Gdy inni podchodzą do tematu powierzchownie, powtarzają te same informacje. Łatwiej zostaniemy dostrzeżeni, zwracając uwagę na aspekty pomijane przez tych, którzy skupiają się na “happy path”.

Ludzie czasem narzekają, że nie mają o czym powiedzieć na konferencji, napisać na blogu. Myślenie, że mówić warto tylko o fajnych nowościach i sukcesach, zamyka przed nami możliwości. Nieudane wdrożenie, napotkanie problemów, o których milczą typowe poradniki – spotykamy je w codziennej pracy częściej niż nowinki technologiczne, a też mogą być dobrymi tematami. Jeśli opowiemy historię porażki tak, że uchroni innych przed popełnieniem tych samych błędów, stworzymy materiał o dużej wartości.

Takie tendencje są już teraz do pewnego stopnia obecne. Jedna z moich dawnych firm robiła comiesięczne wewnętrzne spotkanie, gdzie można było na luzie opowiedzieć o ciekawych wpadkach i napotkanych błędach. Czołowi gracze na rynku rozumieją wartość no blame culture. Teraz musi jeszcze ten trend dotrzeć szerzej.

W jaki sposób dzisiaj weryfikujesz, czy rozwiązanie polecane w social mediach czy na konferencjach, jest warte uwagi?

Zaczynam od szybkiego przejrzenia oficjalnej strony i dobrych omówień. Unikam artykułów i prezentacji, gdzie ktoś nie wychodzi poza “hello world”, bo dają mało przydatnych informacji. Celem jest uniknięcie nieporozumień – szkoda inwestować czas w weryfikowanie rozwiązania stworzonego dla innego problemu, niż mam.

Jeśli coś po wstępnej selekcji wygląda na przydatne, konieczna jest próba zastosowania w praktyce. Nie ufam, gdy ktoś chce wprowadzić nowość bez choćby minimalnej praktycznej demonstracji, że ma szansę zadziałać i jakie ma skutki uboczne. Doświadczenie nauczyło mnie, że koszty utrzymania nietrafionego rozwiązania czy też usunięcia go są często bardzo wysokie. Pracujemy ze skomplikowanymi systemami, zawsze mogą wystąpić niespodziewane komplikacje z powodu tego, jak wygląda dane środowisko.

Dużo taniej jest poświęcić jeden czy dwa dni pracy wybranej osoby na praktyczną weryfikację, by uniknąć dużo większych kłopotów w przyszłości.

Staram się podchodzić do tego jak do eksperymentu naukowego. Na przykład mieć wcześniej chociaż z grubsza przygotowane ramy czasowe oraz kryteria sukcesu. Chcę w ten sposób uniknąć sytuacji, gdy naciągam warunki, by dać narzędziu jeszcze jedną szansę wykazania się. Dodatkowo, wolę decydować szybko nawet w oparciu o niepełną wiedzę, niż bez końca przepalać czas i pieniądze na sprawdzanie kolejnych scenariuszy. Jeśli dostaję zadanie zbadania pewnej technologii, to utrzymanie zadania w przewidywalnych granicach buduje zaufanie do mnie.

Co na to firmy, w których pracowałeś? To o czym mówisz wymaga czasu, czyli po prostu kosztuje.

Miałem szczęście pracować w firmach, które potrafiły być cierpliwe. Nie byłem dzięki temu nigdy w sytuacji, gdy poświęciłem czas na badania, a następnie była presja, żeby pojawiły się wyniki, bo przecież przeznaczono na coś pieniądze. Ważne, żeby nie wpaść w takie błędne myślenie typu “sunk cost”. Trzeba rozważać nowość jak inwestycję: zdefiniować, co możemy zyskać, jakie są koszty, czy mamy jakieś alternatywy. Gdy zyski są wątpliwe, a koszty spore, rezygnacja z wdrożenia jest mądrą decyzją. Co z tego, że coś zmienimy, będziemy mieć to, co poleca jeden czy drugi influencer, jeśli z tego powodu projekt wpadnie w kłopoty. Influencer nie zostanie za nas po godzinach w pracy.

Nie jest łatwo ocenić sprawiedliwie. Każdy ma swoje preferencje, urazy, ulubione sposoby pracy. Wydaje mi się, że z pomocą paru dobrych książek zmądrzałem o tyle, że nie próbuję udawać, że jestem wyjątkowy, bardziej obiektywny niż inni. Dla dobrych decyzji dobrze jest próbować znaleźć błędy w swoim rozumowaniu, rozważyć przeciwne opcje, wejść w rolę “adwokata diabła”. Jestem teraz bardziej świadomy swoich skrzywień w ocenach, typów rozwiązań, które mam tendencję “punktować” wyżej. To pokazuje mi, gdzie szukać tych przeciwnych opcji.

Mój proces decyzyjny i drogę do konkluzji wolę zapisać w formie pisemnej, jak najbardziej otwarcie i zrozumiale. Takie pisanie pozwala na łatwiejsze wejście w temat innym osobom. Wolę zaangażować w rozważania kogoś dodatkowego, nawet jeśli będę samodzielnie podejmować ostateczną decyzję. Jest to pewne spowolnienie, ale druga osoba jest często w stanie podsunąć obserwacje, których nigdy sam bym nie zrobił, nieważne jak bym był dobry w graniu “adwokata diabła”. Forma pisemna jest też przydatna, jeśli chciałbym do decyzji wrócić po pewnym czasie, na przykład, żeby przypomnieć sobie, czemu jakieś rozwiązanie było wybrane, albo zostało odrzucone.

Czym mógłbyś podzielić się w kontekście rozwiązań, z których nie byłeś zadowolony?

Utkwił mi szczególnie w pamięci przypadek, gdy parę lat temu badałem temat biblioteki do programowania funkcyjnego w języku Kotlin. Byłem wtedy pod dużym wrażeniem tego, co robił Martin Fowler i jego Thoughtworks. Czytałem każde wydanie raportu Technology Radar, gdzie oceniali aktualne technologie i podejścia. Gdy w jednym z wydań biblioteka Arrow dostała najwyższą rekomendację “adopt” (czyli “wdrażaj”), z komentarzem, że uważają ją za “sensible default”, postarałem się o wygospodarowanie czasu na zbadanie, jak możemy z niej skorzystać. Uważałem, że nie możemy zostać za aktualnymi trendami, że gdy pojawiają się lepsze sposoby pracy, szybkie z nich skorzystanie oznacza oszczędności i zyskanie przewagi.

Oferty pracy z

Rozdźwięk między oczekiwaniami a rzeczywistością był na poziomie, na jaki w ogóle nie byłem przygotowany. Dokumentacja była luźnym zbiorem artykułów z blogów, problemem było dowiedzenie się, jak wpiąć bibliotekę do działania, jakie typy są dostępne, a co dopiero, jak ich użyć. Wcześniejsze doświadczenie z programowaniem funkcyjnym pozwoliło mi opracować kod, który dało się uruchomić i zaprezentować innym, więc z pewnego punktu widzenia osiągnąłem cel.

Otrzeźwiło mnie pomyślenie o tym, jak będzie wyglądała realna praca w przyszłości. Czy zespół, w którym spotykają się osoby o bardzo różnym doświadczeniu, będzie w stanie sprawnie poruszać się w kodzie opartym w dużym mierze o taką bibliotekę. Rzeczy, które były wygodne dla mnie, wcale nie musiały być wygodne dla zespołu jako całości.

Przygoda z Arrow skończyła się na wewnętrznej prezentacji. Starałem się być uczciwy i nie narzucać innym swojej opinii, ale też przejrzyście wyjaśnić, jak widzę stosunek zysków do kosztów i że nie warto wdrażać biblioteki.

Sam wyniosłem też stamtąd naukę, podobnie chyba wszyscy obecni na prezentacji – by zachowywać zdrowy sceptycyzm wobec rzeczy, które głoszą ludzie popularni w świecie IT. To tylko ludzie, mogą się mylić. Liczy się siła argumentów i zgodność z faktami, a nie taka czy inna osoba.

Były też biblioteki, które zbadaliśmy, wdrożyliśmy, ale wychodziły z nimi coraz to nowe problemy. Przydatne były wtedy dokumenty opisujące proces decyzyjny. Można było wrócić do powodów, dla których dana biblioteka została wybrana. Przypominaliśmy sobie wtedy, że alternatywy były jeszcze gorsze. Oszczędzało to niepotrzebnego ponownego badania tematu, które skończyło by się jedynie dojściem do tych samych wniosków. Polecam wszystkim przechowywanie ADR (Architecture Decision Record) dla każdego istotnego elementu infrastruktury, każdej ważnej biblioteki.

Architecture Decision Record – mógłbyś opowiedzieć o nim więcej? Z czego składa się Twój ADR?

Pomysł polega na tym, żeby decyzje istotne dla danego projekcie zapisywać w formie pisemnej. Kilka z korzyści takiego podejścia wymieniłem wcześniej – chronimy się przed własną krótką pamięcią, unikamy powtarzanego badania tego samego tematu.

Wspominałem też o wciąganiu innych w decyzje. ADR-y mogą pomóc naszemu zespołowi a nawet całej firmie przyzwyczaić się do pracy w przejrzysty, otwarty sposób. Jeśli proces decyzyjny polega tylko na ogłoszeniu ostatecznego wyniku, nie są widoczne powody, jakimi kierowała się osoba decyzyjna. Za to dobrze zrobiony ADR zawiera kontekst problemu, czyli jakie okoliczności spowodowały, że w ogóle chcemy coś zmienić, oraz opisuje, jakim aspektom rozwiązania się przyjrzeliśmy, co przypadło, albo nie przypadło nam do gustu. Samo to jest małym krokiem do poprawy kultury organizacyjnej – bo buduje większe zrozumienie, dlaczego wszyscy idziemy tam, gdzie idziemy.

Dalszym etapem może być zaangażowanie dodatkowych osób w proces. Argumenty przestają być zamknięte tylko w głowie osoby decyzyjnej, czy też zamknięte na spotkaniu wąskiej grupy. Można się z nimi zapoznać, zgłosić uwagi i odrębne zdanie. Organizacja, która otwiera się na wymianę różnych opinii, robi duży krok naprzód.

Najważniejszym elementem ADR-a jest więc według mnie opis kontekstu problemu. Dobrze jest zawrzeć co najmniej dwa różne rozważane rozwiązania, opisać ich plusy i minusy. Jeszcze lepiej, żeby były porównane według tych samych kryteriów. Jeśli mamy w dokumencie tylko jedną opcję, albo opcja ma wymienione same korzyści, jest to sygnał ostrzegawczy, że być może nie przemyśleliśmy dobrze tematu. Wiadomo, że pisanie pozwala uporządkować myśli, więc ADR może pomóc nam być lepszym w podejmowaniu decyzji. Dodatkowo, nawet jeśli sami coś przegapimy, to jest szansa, że inni zwrócą nam uwagę na braki.

Słowo “architecture” w nazwie może być nieco przytłaczające. Nie chodzi o to, żebyśmy pisali tylko teoretyczne traktaty o skali tak dużej jak czy wybieramy architekturę mikroserwisową. Możemy zrobić ADR o tym, który framework do pisania testów wykorzystamy, które narzędzie będzie nam automatycznie aktualizowało zależności. Warto zapisywać decyzje, które trudno podjąć i których zmiana nie jest tania.

Zupełnie zachwyciło mnie w mojej obecnej firmie, że kulturę tworzenia ADR-ów wdrożył management. Gdy “biznes” rozmawia ze sobą o zmianie strategii cenowej, ma przed sobą dokument omawiający, jakie cele chcemy osiągnąć na poziomie finansowym i w innych obszarach, jak dana propozycja chce wpłynąć na osiągnięcie tych celów. Po spotkaniu zostaje dokumentacja, czemu zmieniliśmy ceny. Gdy przyjdzie pora oceny skuteczności zmian, będzie łatwiej stwierdzić, czy iść dalej w tym kierunku. Nie wygląda to jak ADR-y, które tworzymy w dziale programistycznym, ale filozofia i sposób myślenia są podobne, podobne też korzyści.

---

Piotr Kubowicz. Senior Backend Engineer w Superside. Aktualnie odpowiedzialny za Developer Experience. Pasjonat dzielenia się wiedzą, pisze artykuły, występuje na konferencjach, działa w społeczności open source. Uczy, jak wykorzystywać wiedzę naukową do lepszego podejmowania decyzji i efektywnej pracy kreatywnej.