Czasami muszę wyłączyć monitor i się przejść. Muszę, bo inaczej powiem/napiszę coś czego nie powinienem. Muszę się przejść by zrozumieć drugi punkt widzenia. By zastanowić się jak do tego tematu podejść. Bo mam taki problem, że nie potrafię zrozumieć ludzi, którzy na przykład próbują podjąć decyzję wiążącą nas programistów na kolejne kilka lat, z całkowitym brakiem wiedzy na temat danego rozwiązania. To jest tak jakby ktoś powiedział wam, że macie teraz pisać w Java bo miałem ochotę na kawę. Jedna zachcianka, nie przemyślana, prowadzi do konieczności wykorzystywania czegoś kompletnie niezgodnie z jego przeznaczeniem.

Podejmowanie decyzji na temat produktów z których mamy korzystać na co dzień w pracy, jest dość istotną decyzją i wymaga ona analizy kilkunastu rzeczy. Jednak, zanim się decyzje podejmie, trzeba spisać rzeczy które ZMIANA powinna ROZWIĄZAĆ. Chcemy móc pisać aplikacje mobilne nie powinno spowodować kupna xbox i próby zastosowania go w tworzeniu aplikacji mobilnej. Bo to się mija z celem. Zarówno xbox nie pomoże, jak i nasz problem nie zostanie rozwiązany.

Mając spisane rzeczy, będzie nam łatwiej dobrać narzędzie spełniające nasze oczekiwania. Nigdy nie powinniśmy znajdować narzędzia i próbować dopasować go do naszych oczekiwań. To tak nie działa. Jeżeli nawet się uda, to powstanie kreatura, której nikt ale to naprawdę nikt nie będzie chciał supportować.

Gdy jednak decyzja już zapadła, i jesteśmy postawieni przed czynem dokonanym to mamy dwie opcje: powiedzenie, sorki, cofamy to narzędzie lub próbujemy się zmienić tak by z tego narzędzia jak najlepiej skorzystać.

Dla przykładu, jeżeli zmieniamy GIT na TFS (tak wiem…), to wraz z tym powinniśmy zmienić w jaki sposób pracujemy z kodem. Nie próbować nagiąć TFS to naszej pracy, ale zrozumieć jak działa TFS i wykorzystać jego wszystkie dobre strony (jeżeli jakieś są). Jednak to nie zadziała kiedy zespół mimo wiedzy, że będzie musiał korzystać z TFS nie uczy się go, nie wie co to jest, nie wie jak on działa, nie wie czym się różni od GIT. Nie wie nic. Jak wtedy można się zastanawiać nad tym jak najlepiej pracować, jakie rozwiązania wprowadzić? Skoro jest to rozmowa czysto abstrakcyjna i większość osób będzie miało zdanie (bo jak inaczej) na temat jak to powinno być rozwiązane, przy czym będzie ono w pełni bazowało na wiedzy na temat pracy z GIT.

Czyli, mamy podjętą decyzję na temat przejścia na TFS. Zostało to narzucone. Każdy z tego będzie musiał korzystać. Do tego, musimy wymyślić sposób jak najlepiej pracować z TFS. Tylko, że każdy ma zdanie na ten temat, mimo iż nikt jeszcze z TFS nie pracował. Nikt nawet nie wie jak i z czym się go je. To sami odpowiedzcie sobie na pytanie: czy z tego da się podjąć logiczną rozsądną i DOBRĄ decyzję?

Moim zdaniem nie. I nie tędy droga. Jak mamy coś narzucone, to nauczymy się tego narzędzia. Wykorzystajmy w pełni to co ono nam oferuje, a nie próbujmy naginać rzeczywistość bo przy git pracowaliśmy na wielu repo i wielu branchach, to też tak będzie w TFS.

Najgorsze jest to, że niezależnie czasami jak coś będziemy chcieli zmienić, lub wspomóc w decyzji zmiany, możemy zostać zrozumieni opacznie. Miałem nie raz takie sytuacje i u mnie zawsze działały dwie rzeczy:

  • Próba zrozumienia punktu widzenia przeciwnej strony i spisanie sobie argumentów z ich strony
  • Próba obalenia argumentów z naszego punktu widzenia

Będąc tak przygotowani możemy albo zrobić krótkie spotkanie i przekazać tą wiedzę, albo napisać krótki dokument i podesłać to wszystkim. Najlepiej tak szczerze to zrobić dwie rzecz, przy czym spotkanie poprowadzić tak, by oni dali dosłownie te argumenty które my sobie sami spisaliśmy. Czyli trzeba być podstępnym, bo kiedy to wyjdzie od nich, to łatwiej będzie ich przekonać niż jakbyśmy my sami powiedzieli co oni myślą. Dziwny jest człowiek.

A ty miałeś taką sytuację? Jak sobie z nią poradziłeś? Albo czy się udało w ogóle coś z tym zrobić?

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

5 KOMENTARZE

  2. Niestety często spotykam się z dopasowywaniem decyzji “na siłę”, pod oczekiwania. Zauważyłem, że takie sytuacje dotyczą nie tylko wyboru samych rozwiązań/technologii, ale także dopasowywania rozwiązań pod budżet projektu. Dorzućmy do tego brak chęci zrozumienia racjonalnych argumentów “sprzeciwu” i mamy mieszankę wybuchową, która wywołuje tylko nerwy i irytację. Najbardziej denerwujące są dla mnie decyzje projektowe narzucone przez osoby “nie techniczne” (biznes/management). Każda sytuacja to inny przypadek i niestety ciężko znaleźć uniwersalne rozwiązanie…

  3. Znam taki przypadek, gdzie pracę nad nowo rozpoczętym projektem były prowadzone z wykorzystaniem mocno archaicznego narzędzia. Dlaczego? Bo zespół po prostu znał to środowisko i to był w zasadzie jedyny argument za jego wyborem.

  4. Najgorzej że merytoryczne argumenty i technologiczny sens czegoś nie zawsze już mają znaczenie. Czasem ktoś podjął decyzję i ogłosił ją wszem i wobec i wtedy gra toczy się tylko o to by nie dać nikomu podważyć swoich kompetencji i autorytetu ;)

    @Łukasz: wybór rozwiązań pod budżet też od razu przyszedł mi do głowy ;) Choćby wciskanie zespołowi tragicznego Skype for Business bo jest gratis w subskrypcji Microsoftu.

Comments are closed.