Team leadership w IT — jak podejmować decyzje techniczne razem z zespołem
Architektura narzucona przez jedną osobę rzadko działa w praktyce. Nawet jeśli decyzja jest słuszna, zespół, który nie rozumie jej uzasadnienia, znajdzie sposób, żeby ją obejść.
Problem: decyzje techniczne jako czarna skrzynka
W wielu zespołach wygląda to tak: architekt lub tech lead podejmuje decyzję, spisuje dokument, a reszta zespołu dostaje gotowe wytyczne. Problem w tym, że:
- zespół nie rozumie kontekstu decyzji
- nie czuje się za nią odpowiedzialny
- przy pierwszym problemie szuka obejścia
- architektura ewoluuje w sposób, którego nikt nie planował
Rozwiązanie: decyzje zespołowe
Zamiast narzucać rozwiązania, warto zaangażować zespół w proces decyzyjny:
1. Wspólne zrozumienie problemu
Zanim padnie propozycja rozwiązania, upewnij się, że wszyscy rozumieją problem. Sesja Event Storming lub Domain Storytelling to dobry start.
2. Ograniczone opcje
Nie ma sensu rozważać dziesięciu rozwiązań. Zaproponuj 2-3 opcje, każdą z krótkim uzasadnieniem. Daj zespołowi przestrzeń do zadawania pytań i proponowania modyfikacji.
3. Decyzja i dokumentacja
Zdecydujcie wspólnie i zapiszcie nie tylko samą decyzję, ale też kontekst i odrzucone alternatywy. To kluczowe — za pół roku nikt nie będzie pamiętał, dlaczego wybraliście to rozwiązanie.
4. Regularny przegląd
Decyzje techniczne nie są wieczne. Ustalcie punkty kontrolne, w których weryfikujecie, czy wybrane rozwiązanie dalej ma sens.
Code review jako narzędzie rozwoju
Code review to nie polowanie na błędy — to narzędzie do budowania wspólnego standardu i dzielenia się wiedzą. W dobrym zespole:
- review to rozmowa, nie egzekucja
- uwagi są uzasadnione, a nie na zasadzie “zrób inaczej”
- każdy może się czegoś nauczyć — zarówno autor, jak i reviewer
Mentoring — inwestycja w utrzymywalność
Najlepszym sposobem na utrzymywalność systemu jest zespół, który rozumie, dlaczego kod wygląda tak, a nie inaczej. Inwestycja w mentoring:
- skraca czas wdrażania nowych osób
- buduje świadomość architektoniczną
- zmniejsza ryzyko przypadkowych decyzji
Nie bądź single point of failure
Jeśli tylko ty rozumiesz architekturę systemu, to nie jest powód do dumy — to ryzyko dla całego projektu. Celem tech leada nie jest być niezbędnym, ale sprawić, żeby zespół mógł działać bez niego.
Decyzje techniczne podejmowane zespołowo są lepsze, trwalsze i łatwiejsze w utrzymaniu niż te narzucone z góry. Nie dlatego, że zespół zawsze ma rację — ale dlatego, że wspólnie wypracowane rozwiązanie ma większe szanse być zrozumiane, zaakceptowane i utrzymane w dłuższej perspektywie.