Czy możesz z tym żyć i robić swoje? Strong opinions – wyzwanie czy problem?
Praca programisty z reguły opiera się na pracy w zespole. Zespoły mogą być małe i duże, zależnie od firmy i podejścia do rozwoju oprogramowania, które zostało przyjęte. W momencie podejmowania decyzji dotyczących wykorzystania danej technologii zaczyna się często przepychanka między racjami poszczególnych osób które mają różne na temat danej technologii.
Bardzo często spotykam się wtedy ze stwierdzeniem, że ktoś ma strong opinions (własne, niepodważalne opinie) na dany temat i nie zamierza ustępować w danej kwestii. Może to wynikać z wielu rzeczy, m.in. z doświadczenia wyniesionego z pracy w innych projektach czy zespołach.
Proces decyzyjny dotyczący stacku technologicznego
W idealnym świecie proces podejmowania decyzji dotyczącej wyboru technologii w której dana aplikacja/funkcjonalność zostaną wykonane jest poprzedzony analizą wymagań oraz analizą istniejących technologii/rozwiązań. Dopiero na tej podstawie zespół lub inna osoba decyzyjna decyduje, w którą stronę zespół programistów powinien podążyć.
W przypadku, gdy istnieją jakieś uwagi lub sugestie dotyczące wybranych wstępnie technologii, to powinna wystąpić merytoryczna dyskusja bazująca na faktach. Wówczas powinno nastąpić podjęcie decyzji i rozpoczęcie prac nad danym projektem.
Jak strong opinions wpływają na pracę zespołu?
Wyzwaniem dla każdego zespołu może być moment, gdy pojawiają się tzw. strong opinions między członkami zespołu. Najczęściej wynikają one z faktu, że dana osoba popracowała z daną technologią przez jakiś czas, a z innymi spędziła o wiele mniej czasu lub wcale.
Problem jaki się wówczas rodzi, to brak możliwości podjęcia decyzji ze względu na swoistą wojnę na argumenty. Argumenty, które tak naprawdę potrafią się pokrywać, ale ze względu na fakt iż są one wyartykułowane w taki sposób a nie inny, powoduje to brak zrozumienia problemu jaki mają rozwiązać. Rodzą się wtedy argumenty w stylu: Zróbmy to tak, bo ja tak chcę; Bo ja tak kiedyś robiłem lub Jestem tu dłużej, więc moje zdanie jest ważniejsze.
Tutaj nie ważne jest czy blokada wychodzi ze strony członka zespołu czy architekta. Powoduje ona negatywne emocje i sprawia, że zespół mniej chętnie przystępuje do pracy, albo przystępuje do pracy w atmosferze narzekania na wszystko. To sprawia, że produktywność zespołu spada zauważalnie.
Wyzwanie czy problem?
W sytuacji, gdy któryś z członków zespołu ma kompletnie inną wizję dotyczącą danej technologii, to w takiej sytuacji warto się przysłuchać argumentom tej osoby. Jeśli wynikają one z doświadczenia bazującego na pracy nad innym projektem, w technologii mniej znanej innym członkom zespołu, to jest to świetna okazja aby nauczyć się czegoś innego. Na przykład poprzez próbę zrozumienia punktu widzenia danej osoby. Nie zawsze zaproponowane rozwiązanie będzie właściwym, ale próba zrozumienia rozwiązania zaproponowanego przez daną osobę, może się przyczynić do własnego rozwoju oraz do zdobycia nowego doświadczenia, które będzie można wykorzystać w przyszłości w innym miejscu, projekcie.
Dodatkowo, fakt że dana osoba została wysłuchana może sprawić, że morale takiego członka zespołu nie ulegnie pogorszeniu, ponieważ ktoś podjął wysiłek i próbował zrozumieć punkt widzenia danej osoby. To jest bardzo ważna cecha w zarządzaniu zespołem.
Konsensus jako droga do zarządzania zespołem
Drogę wyjścia z tak niekorzystnej sytuacji widzę jedną. Jest nią konsensus, czyli dojście do porozumienia poprzez zadanie pytania: Czy możesz żyć z danym wyborem i pracować efektywnie? To co jest jednak ważne, to żeby takie pytanie zadać osobom, które znajdują się w mniejszości. Czyli osobom, które niezbyt chętnie zgadzają się z danym wyborem technologicznym.
Jeśli podejmie się decyzję wbrew woli większości, to wtedy należy wziąć odpowiedzialność za nią na siebie w całości. Piszę tu o punkcie widzenia lidera zespołu lub architekta. Nie może być tak, że osoba wyższego stopnia podejmie decyzję, która może doprowadzić do niepowodzenia i zrzucić winę na osoby niższego szczebla. Trzeba pamiętać o tym, że z zespołem programistów jest jak z drużyną piłkarską. Można mieć świetnych specjalistów z różnych dziedzin, ale jeśli decyzje będą podejmowane wbrew woli większości osób oraz na przekór ich specjalizacjom, to może to doprowadzić do złej atmosfery i niskiej wydajności pracy, co końcowo doprowadzi do braku sukcesu lub odejścia programistów z zespołu, co generuje dodatkowe utrudnienia zarówno dla zespołu jak i firmy.
Bardzo ważne jest to, aby działać demokratycznie tam gdzie się da, a w momencie, gdy głosy rozkładają się po równo - podjąć decyzję samodzielnie i być za nią odpowiedzialnym.
Żyj z tym i rób swoją robotę
Jeśli jednak jesteś jedną z tych osób, które często wyrażają swoją opinię i uważają że pozostali są w błędzie, to proponuję następujące rozwiązanie. Poświęć swój czas (w pracy lub czas wolny) zaprezentuj prototyp, który jest oparty o twoje założenia i na podstawie faktów przekonaj zespół do swoich racji. Nic tak nie przekonuje dobrze jak klarownie przedstawione fakty bazujące na konkretnym przykładzie. Takim podejściem zdobywa się zaufanie i szacunek. Bo już nie mówimy tutaj o narzucaniu swojej woli, lecz o konkretach, które mogą prowadzić do sukcesu.
W innym przypadku: Żyj z tym i wykonuj profesjonalnie swoją pracę!
Podsumowanie
W tym wpisie chciałem nakreślić problematykę która dość często się pojawia w zespołach programistycznych, gdzie mamy grupę ludzi o dużych umiejętnościach technicznych, a nie zawsze umiejących spojrzeć na pracę zespołu spoza perspektywy własnej osoby.
Bardzo ważne jest to, aby swoje racje zawsze udokumentować jakimś dowodem. Doświadczenie wyniesione z innych projektów jest przydatne w argumentacji swoich racji, ale należy pamiętać też o tym, że to co działało wcześniej w innym projekcie (być może w innym zespole/innej firmie) nie musi działać w obecnej sytuacji. Trzeba być elastycznym i dbać o dobre samopoczucie swoje jak i innych członków zespołu.
Jakiś czas temu zamieściłem też podobne pytanie na Twitterze i kilka osób podzieliło się swoimi przemyśleniami na ten temat. Wystarczy kliknąć w Tweeta i będzie można zobaczyć cały wątek wraz z odpowiedziami.
#devlife strong opinions. Are they good or evil in the team of software developers? #javascript #webdev #Frontend
— Piotr Nalepa (@sunpietro) 15 lipca 2019