Merytoryka vs polityka w zespołach

Cześć. Gdybyście mieli określić, gdzie mniej więcej plasuje się praca w Waszych zespołach:

1. Decyzje techniczne podejmowane merytorycznie vs kto głośniej krzyczy / kto jest dłużej w zespole / kto ma ważniejszy tytuł;
2. Decyzje podejmuje cały zespół lub jakieś grono vs pojedyncza osoba;
3. Decyzje podejmowane sprawnie vs odkładane aż będzie za późno;
4. Zespół angażuje się w techniczne tematy vs siedzi cicho i się nie wychyla;
5. Developer / inżynier może koncentrować się na technicznej robocie vs musi uprawiać politykowanie i dyplomację;
6. Developer / inżynier ma stosunkowo dużą swobodę co do sposobu, w jaki realizuje zadania vs nie może kiwnąć palcem w bucie bez pozwolenia;

Gdzie byście je umieścili?

Zacznę od siebie:

1. Raczej to drugie, często trudno jest stwierdzić kto, kiedy i dlaczego podjął daną decyzję, tak po prostu jest i nie należy tego tykać.
2. Wygląda na to, że na ogół pojedyncza osoba, choć nie zawsze.
3. Często odkładamy decyzję, by choćby przedyskutować jakiś temat, na "lepszy moment", w praktyce tzw. wieczne nigdy.
4. Dominuje siedzenie cicho. Wychyliłem się z jakimiś technicznymi tematami, to za to pokutuję.
5. 80% politykowania i dyplomacji, 20% roboty, żeby coś zostało zrobione.
6. Lepiej nie zaczynać niczego na własną rękę bez wyraźnego polecenia, że tak ma być, przyklepanego przez jedną spośród kilku konkretnych osób.

1. Merytorycznie
2. Ostateczna decyzja należy do architekta/leada, ale dyskutowana jest przez cały zespół. Lead/architekt może zdecydować inaczej niż chce zespół lub w przypadku braku jednomyślności, to na nim spoczywa odpowiedzialność za wybór i podjęcie ostatecznej decyzji. Na szczęście u mnie wszyscy architekci to osoby techniczne z doświadczeniem w programowaniu/infrze czy devopsowaniu, którzy nie jedno g**no widzieli, więc błędne decyzje się zdarzają ale stosunkowo rzadko.
3. Sprawnie
4. Patrz p.2
5. Zwykle programiści robią swoje. Czasem się zdarza, że gadają z biznesem na temat dokładniejszych wymagań czy funkcjonalności, żeby architekt mógł skupić się na polityce i dyplomacji.
6. Zwykle na początku projektu określamy jakich narzędzi, wzorców, konwencji będziemy używać i tego się trzymamy. Jak ktoś chce coś zrobić inaczej, to musi mieć powód i się skonsultować z resztą zespołu. Jak tego nie zrobi, to nie przejdzie PR i albo będzie to dyskutowane, albo będzie musiał przepisać co zrobił i się z tego potem tłumaczyć, czemu nie dowiózł.

1. Merytorycznie
2. Cały zespół, ale ostateczna decyzja należy do lead'a. Wszystko zależy, jak istotna ma być podjęta decyzja, ale zazwyczaj mamy pewną dowolność w wyborze.
3. W zespole zazwyczaj sprawnie. Jak trzeba podjąć decyzję, to potrafimy się umówić na spotkanie i to przegadać, lub eskalować to wyżej drabinki w korpo. Dopiero tam zaczynają się problemy. Często trzeba długo czekać na odpowiedź, czasem nikt niczego nie wie i trzeba się prosić, czasem potrafią nas zbywać.
4. Zespół się bardzo angażuje w tematy techniczno-biznesowe i potrafi sam coś załatwić z innym zespołem, kiedy jest to potrzebne. Nie czekamy, aż PO/manager zrobi coś za nas. Jedynie jak jest jakaś rzecz wymagająca akceptacji kogoś u góry, wtedy ingeruje manager, lub jakaś czysto biznesowa (coś do potwierdzenia z klientem albo designerami) rzecz do załatwienia, to wtedy PO przeważnie to ogarnia.
5. Większość czasu mamy na taski i kodowanie.
6. Kiedyś mieliśmy dużą swobodę w wyborze technologi używanych w projektach. Ostatnio to się zmienia i góra coraz więcej rzeczy nam narzuca.

1. Merytorycznie, senior zwykle wnosi więcej niż regular i junior.
2. Zespół/grono zainteresowanych, sytuacyjnie zależne. Po prostu gdy decyzja ma duży wpływ, to robimy calla. Inicjatywę i bycie skrybą przejmuje osoba, która tej decyzji szuka. Do calla wrzucamy osoby pracujące z danym tematem i jako optional resztę ludzi. Gdy jest konflikt i nie ma kompromisu, to rozwiązuje to osoba wyżej w hierarchii managerskiej.
3. Sprawnie i szybko
4. Zawsze, jeśli mają coś do powiedzenia
5. Często b. dużo rozmów, ale bez politykowania, w dobrej intencji by znaleźć dobre rozwiązania.
6. Jeśli nie dotyka to innych zespołów i wspólnej infry to całkowita swoboda jeśli jesteś pewny, że zrobisz coś dobrze. Jak ma wpływ na coś poza teamem, to zadecyduje ktoś z odpowiedniego szczebla. Jeśli zadanie ma jakąś specyfikacje czy narzucone wymagania przez osobę typu PO czy jakiegoś stakeholdera, to wszystko zależy, czy umiesz into rozmowa i argumentacja.

Nie pracuję w miejscu gdzie jest rola 'architekta' i bardzo dobrze, decyzje są podejmowane demokratycznie i bezpośrednio przez team.

A można dopytać o przykłady co to dokładnie jest decyzja techniczna? Bo jeśli wybór postgres vs Oracle to to chyba nigdy ani senior ani nawet team lead nie ma nic do gadania, tylko na o wiele wyższym (CTO) levelu. Tak samo Rabbit vs Kafka to często są infrastruktury rekomendowane przez całą organizację i raczej jako szeregowy dev nie ma się na to wpływu.

Pinek napisał(a):

A można dopytać o przykłady co to dokładnie jest decyzja techniczna?

Decyzja, na którą w danej organizacji zespół ma wpływ. Nie chcę narzucać konkretnego przykładu, ale nie miałem na myśli decyzji podejmowanych na poziomie 10 leveli wyżej.

No ale powiedzmy, że z pewnymi wyjątkami, gdzie szef produktu dyktował nam nazwy klas i zmiennych, to jednak jakiś-tam choćby symboliczny poziom autonomii zespołowi przypada. Można sobie, nie wiem, wziąć taką albo inną bibliotekę do asercji, albo nie wiem co jeszcze. Formatter kodu skonfigurować, linter dodać. Można trafić na jakiś problem techniczny, na który nie przyszła recepta z góry i rozwiązać go jako zespół, albo czekać aż przyjdzie architekt albo manager i podyktuje rozwiązanie. Można zdecydować, że nam się nie podoba stan np. dokumentacji albo czegoś, i coś tam poprawić.

W kontekście podejmowania decyzji, ciekawym i efektywnym konceptem jest Informed Captaincy od Netfliksa https://kowalskipiotr.pl/informed-captain-decision-making-in-team/

ehh durszlak durszlak

jak nie będziesz szukał firm z tą całą engineering culture to z przypadku może być ciężko na taką trafić

No ale powiedzmy, że z pewnymi wyjątkami, gdzie szef produktu dyktował nam nazwy klas i zmiennych

???????????????????????????????

superdurszlak napisał(a):

Cześć. Gdybyście mieli określić, gdzie mniej więcej plasuje się praca w Waszych zespołach:

1. Decyzje techniczne podejmowane merytorycznie vs kto głośniej krzyczy / kto jest dłużej w zespole / kto ma ważniejszy tytuł;
2. Decyzje podejmuje cały zespół lub jakieś grono vs pojedyncza osoba;
3. Decyzje podejmowane sprawnie vs odkładane aż będzie za późno;
4. Zespół angażuje się w techniczne tematy vs siedzi cicho i się nie wychyla;
5. Developer / inżynier może koncentrować się na technicznej robocie vs musi uprawiać politykowanie i dyplomację;
6. Developer / inżynier ma stosunkowo dużą swobodę co do sposobu, w jaki realizuje zadania vs nie może kiwnąć palcem w bucie bez pozwolenia;

1. to pierwsze
2. implementacje pojedyncza osoba, decyzje biznesowe i plany architektury zespół + architekt ostateczny boss
3. raczej sprawnie, nikt nie odkłada za długo
4. zalezy od tego jak kto wstanie w danym dniu, czasami sie zdarzy ze wszyscy sie angażują i potem tydzien siedzimy cicho zeby odreagowac
5. bez przerwy obie opcje na raz, czasami sprawa kulturowa, czasami sprawa kultury firmy
6. to pierwsze, zdecydowanie

superdurszlak napisał(a):

1. Decyzje podejmowane sprawnie vs odkładane aż będzie za późno;

Nie jestem pewien czy to zawsze jest dobre Czasami właśnie warto nie podjąć decyzji w temacie wcześniej, tylko podjąć meta-decyzję żeby zostawić sobie otwarte drzwi by móc podjąć decyzję w temacie później w świetle nowych informacji i wiedzy; zamiast od razu.

superdurszlak napisał(a):

Cześć. Gdybyście mieli określić, gdzie mniej więcej plasuje się praca w Waszych zespołach:

1. Decyzje techniczne podejmowane merytorycznie vs kto głośniej krzyczy / kto jest dłużej w zespole / kto ma ważniejszy tytuł;
2. Decyzje podejmuje cały zespół lub jakieś grono vs pojedyncza osoba;
3. Decyzje podejmowane sprawnie vs odkładane aż będzie za późno;
4. Zespół angażuje się w techniczne tematy vs siedzi cicho i się nie wychyla;
5. Developer / inżynier może koncentrować się na technicznej robocie vs musi uprawiać politykowanie i dyplomację;
6. Developer / inżynier ma stosunkowo dużą swobodę co do sposobu, w jaki realizuje zadania vs nie może kiwnąć palcem w bucie bez pozwolenia;

@superdurszlak Fajna rozpiska. Od razu mi się skojarzyło z Westrum’s Organisational Culture: Pathological/Bureaucratic/Generative.

Celem wyjaśnienia:

• Oriented: Co głównie kieruje "ludźmi u góry": power/rules/performance
• Cooperation: to jest podobna rzecz co punkt 2. w liście @superdurszlak
• Messengers: co się robi z ludźmi którzy przynoszą złe wieści: shoot/neglect/train to bring bad news.
• Responsibilities: tutaj chodzi o to jak ludzie pracują: każdy ma swój kawałek/ludzie współpracują/wszyscy pracują nad wieloma elementami
• Bridging: tutaj chodzi o to jak jest z komunikacją między zespołami
• Failure: tutaj chodzi o to co się dzieje z chłopem który właśnie popełnił błąd? Albo się go obwinia, albo każe mu się dawać wyjaśnienia, ale cały zespół się zastanawia "czemu to się stało? jak możemy to poprawić w przyszłości". Tutaj jest kluczem że wszyscy w firmie powinni powiedzieć "On popełnił błąd, ale jak ja byłbym na jego miejscu to pewnie też mógłbym go popełnić".
• Novlety: tutaj chodzi o to czy innowacje są zabijane w zarodku, kojarzą się z problemami, czy może są sprawdzane.

Riddle napisał(a):

superdurszlak napisał(a):

1. Decyzje podejmowane sprawnie vs odkładane aż będzie za późno;

Nie jestem pewien czy to zawsze jest dobre Czasami właśnie warto nie podjąć decyzji w temacie wcześniej, tylko podjąć meta-decyzję żeby zostawić sobie otwarte drzwi by móc podjąć decyzję w temacie później w świetle nowych informacji i wiedzy; zamiast od razu.

Jak się nie mylę, jest taka metodyka podejmowania decyzji / zarządzania podejmowania decyzji, że decyzje o małym impakcie i które łatwo odkręcić podejmuje się jak najwcześniej, by w razie potrzeby móc je zmienić jeśli okażą się nietrafione, natomiast decyzje trudne do odkręcenia i które mają potencjalnie największe skutki odkłada się na jak najpóźniej, by zebrać jak najwięcej danych up-front.

Czasem nawet udawało się to wdrażać, ale często jest odwrotnie - np. architekci lub zespół z góry narzucają sobie jakieś decyzje techniczne, a potem wdrażają je bez względu na to, czy rzeczywistość weryfikuje decyzję pozytywnie, czy negatywnie. Z drugiej strony, czasami pod zupełnie nieistotnymi decyzjami (z punktu widzenia organizacji) niezbędne jest 10 pieczątek.

Miałem raz tak, że architekci wymyślili sobie protokół komunikacyjny, zespoły 3 lata go implementowały, jak przyszedłem do firmy to architekci właśnie wpadli na pomysł, by go zaorać (miesiąc przed dowiezieniem pierwszych MVP - po 3 latach!!!) i zacząć wymyślać nowy. Okazało się, że wymyślają Protocol Buffers od zera, ale nie umieją nawet zaimplementować PoC. Decyzje high-impact podejmowane najpierw, te low-impact ale kluczowe by zbudować choćby to PoC odkładane na wieczne nigdy. Parę miesięcy się z nimi o to ścinałem aż w końcu rzuciłem papierami, paru kolegów zostało (i potem też zaczęli rzucać papierami), do dziś ten wymysł nawet nie jest na etapie "projekt można skompilować"

A co do kultury organizacyjnej, to w zeszłym roku zetknąłem się z Culture Map od Erin Meyer. No i wyszło na to, że moje żarty o byciu krypto-Niemcem są nieaktualne, bo naprawdę trochę nim jestem. Za ~10 dolarów można sobie zrobić kwestionariusz: https://erinmeyer.com/tools/the-personal-profile-tool/

Mam, znalazłem:

Decyzje techniczne podejmowane merytorycznie vs kto głośniej krzyczy / kto jest dłużej w zespole / kto ma ważniejszy tytuł;

Merytoryka, często popierana konkretnymi argumentami jeśli np uważam, że podejście A będzie lepsze od B. Czasami trafi się jakiś PoC.

Decyzje podejmuje cały zespół lub jakieś grono vs pojedyncza osoba;

Różnie. Mamy refinementy, tech talki itp. Natomiast najwięcej do powiedzenia mają osoby, które będą na tym siedzieć.

Decyzje podejmowane sprawnie vs odkładane aż będzie za późno;

Różnie. Pod kątem tech-debtu późno i obecnie mamy go całkiem sporo. Nowe projekty są za to sprawne.

Zespół angażuje się w techniczne tematy vs siedzi cicho i się nie wychyla;

Różnie. Jak ktoś nie jest zaangażowany bezpośrednio w projekt to się raczej nie wychyla.

Developer / inżynier może koncentrować się na technicznej robocie vs musi uprawiać politykowanie i dyplomację;

Może koncentrować się w 100% na kodzie. To jest jedna z najlepszych rzeczy w moim projekcie, że od spotkań są BA, SM i TL. Potem tylko przekazują "mięso" co jest znacznie bardziej efektywne niż gnicie 2h na callach.

Developer / inżynier ma stosunkowo dużą swobodę co do sposobu, w jaki realizuje zadania vs nie może kiwnąć palcem w bucie bez pozwolenia;

Pełna swoboda. Nie ma żadnych sztywnych ram, godzin pracy, czy dziwnych ustaleń. Projekt ma być dowieziony, godziny na jirce zalogowane (Nikt ich nie sprawdza) i tyle. Pod kątem technicznym to samo - Nikt nie stoi za plecami i dyktuje jak masz nazwać zmienną. Technologie mamy raczej sztywne (big data) i tutaj nikt nie wprowadza wodotrysków. Ew inne podejścia, jak np inkrementacyjne procesowania dużej tabeli (70 tb) zamiast wszystko na raz.

superdurszlak napisał(a):

Cześć. Gdybyście mieli określić, gdzie mniej więcej plasuje się praca w Waszych zespołach:

1. Decyzje techniczne podejmowane merytorycznie vs kto głośniej krzyczy / kto jest dłużej w zespole / kto ma ważniejszy tytuł;
2. Decyzje podejmuje cały zespół lub jakieś grono vs pojedyncza osoba;
3. Decyzje podejmowane sprawnie vs odkładane aż będzie za późno;
4. Zespół angażuje się w techniczne tematy vs siedzi cicho i się nie wychyla;
5. Developer / inżynier może koncentrować się na technicznej robocie vs musi uprawiać politykowanie i dyplomację;
6. Developer / inżynier ma stosunkowo dużą swobodę co do sposobu, w jaki realizuje zadania vs nie może kiwnąć palcem w bucie bez pozwolenia;

Gdzie byście je umieścili?

U mnie to w zasadzie będzie retrospektywa, bo nie pracuję już w tej chwili w IT (i na razie mi się wcale tam nie spieszy, jeśli mam być szczery), natomiast w ostatniej firmie wyglądało to tak:

1. Decyzje podejmowane merytorycznie, po czym przychodził zarząd niezaznajomiony z projektem (złożony z osoby nieznającej się w ogóle na IT i uważającej, że firma informatyczna nie potrzebuje działu IT, a także z toksycznego narcystycznego programisty, który zawsze wie wszystko najlepiej) i cały plan był w momencie rozwalany.
2. Decyzje formalnie podejmował cały zespół, przy czym zwykle i tak wszyscy spuszczali się na mnie, aby w sytuacji (a) dobrej zdaniem zarządu decyzji sprzedać to jako sukces managera (osoby nietechnicznej, nieznającej się ani na programowaniu, ani na zarządzaniu ludźmi, natomiast trzymanej w firmie ze względu na to, że nikt inny nie zgodziłby się na takie traktowanie przez zarząd, jakie było mu fundowane), (b) błędnej zdaniem zarządu decyzji (sytuacja najczęstsza) powiedzieć, że to ja tak wymyśliłem i to ja się mam z tego teraz wytłumaczyć.
3. Trudno powiedzieć, jeśli trzymałem rękę na pulsie i przypominałem managerowi o tym czy o tamtym, to raczej szło to sprawnie - z zastrzeżeniem punktu 1., że na koniec dnia i tak zarząd zwykle sabotował cały proces decyzyjny. Natomiast gdy odpuszczałem temat, to nikt go nie podejmował do momentu krytycznego. Zdarzało się to rzadko, zwykle w sytuacjach, gdy byłem chory albo na urlopie, ale wystarczyło, by zarzucić mi brak proaktywności.
4. Różnie, czasem się zdarzało zaangażowanie (ok. 5% przypadków), choć w zdecydowanej większości przypadków było tak, że koledzy nawet nie słuchali tego, co było podejmowane na spotkaniach, nie uczestniczyli aktywnie w daily/weekly/retro ani nie czytali też notatek po spotkaniach, które starałem się w imieniu zespołu przygotowywać, tylko bezrozumnie przytakiwali, a po kilku dniach lub tygodniach wzywali (tak, to jest właściwe słowo) mnie na calla z pretensjami, że o niczym nie wiedzą i że oni to widzą zupełnie inaczej.
5. Developer musiał uprawiać politykowanie i dyplomację, a także cotygodniowo tłumaczyć się i rozliczać przed zarządem w bardzo upokarzającej formule, w której niezależnie co się zrobiło i powiedziało, dosłownie zawsze było to kwestionowane, aby pokazać wyższość zarządu nad załogą. Może to brzmi jak przesada, natomiast dochodziło już do takich sytuacji, że pod nieobecność jednego z członków zarządu drugi najeżdżał na programistę za wykonanie zeszłotygodniowego polecenia drugiego członka zarządu. Po czym następnego tygodnia dochodziło do odwrócenia sytuacji. Natomiast niezmiennie zawsze winny był developer.
6. Developer miał swobodę realizacji zadań do momentu, w którym zarząd nie postanowił włączyć ręcznego sterowania. Wtedy wymuszano różne kuriozalne rzeczy, które się nie sprawdzały w praktyce. Efekt był taki, że w ciągu pół roku zespół deweloperski został zdemontowany niemal do podłogi, został tylko manager i stażysta - syn kolegi prezesa. I chyba właśnie o to chodziło.

1. Merytorycznie. Chociaz wiadomo, ze przy wiekszej liczbie osob, zawsze sie trafi ktos kto uzna ze mozna bylo zrobic inaczej.
2. Zalezy od tematu i wplywu decyzji. Generalnie sa na odpowiednim poziomie.
3. Sprawnie, chociaz czasem trzeba kogos przycisnac.
4. Zalezy od tematu. Jak sa bzdury albo karmienie procesu to sie robi zeby miec z glowy i zajac sie tym co wazne.
5. Jak najbardziej, polityki jest bardzo malo.
6. Tak, mam z grubsza powiedziane co mam zrobic przez najblizsze 3 miesiace i ciagne temat + sami tworzymy taski i ogarniamy tematy ktore wychodza po drodze. Albo ustalamy co dobrze byloby zrobic.

superdurszlak napisał(a):

Cześć. Gdybyście mieli określić, gdzie mniej więcej plasuje się praca w Waszych zespołach:

1. Nie ma znaczenia, i tak to ogarnę a lepiej pozwolić innym też zarobić na swoje utrzymanie
2. Nie ma znaczenia, i tak całe g**no poleci na lida a ja co najwyżej zmienię firmę
3. Nie ma znaczenia, przy private equity następny właściciel wymieni wszystko poza jakimś murzynem
4. Nie ma znaczenia, czy są dyskusje czy nie, jedyne co się liczy to czy dowozimy
5. Nie ma znaczenia, bycie poetą implikuje umiejętność pisania dobrych paszkwili
6. Nie ma znaczenia, każdą cenzurę i ograniczenia można wykpić nią samą

W obecnej pracy to wygląda tak:

1. HiPPO na wszystkich poziomach firmy. Niby merytoryka, ale HiPPO wynika z tego, że zespoły są mało zaangażowane.
2. Konkretna osoba. Przy czym raczej szukamy najpierw konsensusu.
3. Aż będzie za późno, chociaż widzę, jak się poprawia.
4. Zespół siedzi cicho.
5. Developer może kodować. Musimy zwracać uwagę na to, aby JIRA dobrze się prezentowała przed ludźmi którzy nie rozumieją, co jest napisane w ticketach.
6. Swoboda lokalnych decyzji.

Ciekawe, co powiedziałaby Linda?

@superdurszlak Podczas refaktowania testów w jednym serwisie raz dostałem opierdziel bo... użyłem testów z parametrami (JUnit 5 i ParameterizedTest). Jego argumenty? W innych mikroserwisach nie ma takich testów- co z tego że to miało olbrzymi sens - (nie wchodząc w szczegóły chodziło o normalizację tekstu). Taka uwage dała osoba która była niby senior developerem i miała pieczę nad wszystkim w projekcie, ogolnie czasami bywało tak że blokował bo tak i musiało być po jego myśli :/
Z koei w innym zespole mieliśmy praktykę demokatrycznego głosowania