Zatrzymywanie niekończących się dyskusji technicznych i podejmowanie decyzji

Zawsze spotykam ludzi, którzy od wieków lubią walczyć o najdrobniejsze „rzeczy techniczne”.

Nie zrozum mnie źle, jestem programistą-maniakiem, który uwielbia to, co robię, ale znasz typ rozmowy.

• Mac jest o wiele lepszy niż Windows
• Nie używaj pętli For Each, użyj pętli While
• Nie kupuj komputera z procesorem Intel, kup komputer z procesorem AMD.
• Powinniśmy używać jednego kontenera IoC nad drugim.

Wszystkie te „rzeczy” mają ważne argumenty za i przeciw obu stronom i nigdy nie dostaniesz „poprawnej” odpowiedzi, a osoba nigdy nie zgodzi się z tym. (oczywiście będzie tam, gdzie jest odpowiedź, może :).

Moje pytanie (dostaję się tam !!) brzmi: w zespole oprogramowania, jak przejść przez te długie dyskusje bez hamowania innowacji, aby można było podjąć decyzję i zająć się rozwiązywaniem rzeczywistych problemów biznesowych.

Problem 1. Niektórzy ludzie nie lubią przegrywać. Jeśli nie sprawdzą strzałów, będą debatować, dopóki nie wywołają strzałów przez ścieranie.

Problem 2. Nic nie jest naprawdę zagrożone, więc debata jest tolerowana.

Nic nie jest zagrożone? Tak. Większość decyzji ma prawie zerowy wpływ. Fakt, że sprowadza się do „starcia na wieki” oznacza, że ​​oba wybory są w rzeczywistości identyczne.

Co robić?

1. Uświadom sobie, że nic nie jest zagrożone.

2. Uświadom sobie, że za 2 lub 3 lata cały temat zostanie ponownie otwarty, ponieważ zmieniło się coś spoza organizacji.

3. Rzuć monetą. Poważnie. Po prostu wybierz coś i idź dalej. Niektórzy ludzie zobaczą głupotę w debacie. Niektórzy ludzie będą wtedy dyskutować na temat natury rzucanej monety. Jeśli ludzie nie mogą być zadowoleni z rzutu monetą, mają problemy z ego i muszą nauczyć się, że (a) nic nie jest zagrożone i (b) decyzja zostanie zmieniona za kilka lat.

Jeśli nie mogą zrozumieć, że nic nie jest zagrożone, muszą podać wartość obu stron argumentu w dolarach. W pewnym momencie ktoś może zauważyć, że na analizy poświęcane są więcej roboczogodzin niż jest to warte faktycznej decyzji. Rzut monetą daje taką samą wartość przy niższym koszcie.

Kilka rzeczy do rozważenia:

1. Przyjmuj tylko argumenty, które są kwantyfikowalne. Jeśli ktoś powie, że pozwoli to zaoszczędzić czas, poproś go, aby go ilościowo oszacował i zatrzymał na odpowiedzi. W ten sposób, jeśli rozmawiają o śmieciach, dostają tylko jedno, zanim wszyscy dowiedzą się, że są pokrytym rumieńcem.

2. Niech ludzie wezmą odpowiedzialność za swoje rekomendacje. Wyjaśnij, że pod koniec roku, jeśli wykonują złe połączenia, będzie to częścią ich oceny. Nie mam nic przeciwko debatom, ale chcę, aby ludzie mieli odwagę swoich przekonań - jeśli masz zamiar przysiąc, że coś jest wspaniałe i oczekujesz od nas przyjęcia, lepiej przeżyj konsekwencje.

To są prawdziwe rzeczy, aby uciec od dwóch problemów S.Lott - że niektórzy ludzie nie lubią przegrywać i że nic nie jest zagrożone. Moja odpowiedź jest zagrożona, więc nie ma debaty dla samej debaty.

1. Timebox dyskusji. - Jeśli każda ze stron zajmuje więcej niż 5 minut, aby przedstawić swoją sprawę, jest to zbyt skomplikowane. W tym celu korzystamy z timerów kuchennych . Działają wspaniale i kosztują około 5 dolarów.
2. Wymagaj, aby uczestnicy sprzeczali się z danymi i doświadczeniem.
3. Trzymamy opcje na stole. Po tym, jak każda ze stron poświęci swój czas, spędzamy kolejne 5 minut na omawianiu konsekwencji każdego podejścia. Po 20 minutach wychodzimy i robimy to (wdrażamy). Jeśli to nie zadziała, wówczas zastosujemy inne podejście.

Zasada jest prosta. Gdy nie wiesz, co wybrać, zastanów się, co jest lepsze dla firmy.

Tak, wybór Intel v AMD nie jest taki łatwy. Ale co jest lepsze dla Twojej firmy? Na przykład, jeśli jest osoba, która jest odpowiedzialna za zamawianie rzeczy, a zamówienie komputera PC z procesorem AMD zajmie wieki, ale procesor Intel można zamówić w ciągu minuty i naprawdę nie obchodzi Cię, co to będzie - po prostu zamów ten oparty na Intelu, ponieważ jest to lepsze dla firmy.

Zwykle te dyskusje są po prostu rowerowe . Ludzie spierają się o to, który format transferu lub który magazyn danych użyć, i mnóstwo innych szczegółów, które powinny być naprawdę przejrzyste dla wszystkich komponentów, z wyjątkiem tego, który implementuje ten sam szczegół. Nikt nie dba o to, dopóki element spełnia kontrakt projektowy, a osoby odpowiedzialne za niego będą w stanie zareagować na zmiany umowy w rozsądnym czasie.

Zdecydowana większość wszystkich problemów technicznych, które napotykasz podczas tworzenia oprogramowania, to problemy z rowerami. Po prostu dlatego, że mają już rozwiązania, a jedynym pytaniem jest, które rozwiązanie chcesz wybrać.
Nie powinieneś blokować się przed takimi decyzjami. Powinieneś zablokować takie decyzje w warstwie abstrakcji, która oddzieli Twoją aplikację od takich szczegółów .
Naprawdę ważne problemy w rozwoju oprogramowania to problemy projektowe na poziomie funkcji i systemu. Wszystko inne jest drugorzędne.

Więc nie zaczynaj nawet takich debat. Skoncentruj swoją energię na podziale projektu na niezależne części. Daje to oprogramowanie, które jest bardziej niezawodne i elastyczne. A jeśli potrafisz wskazać decyzje techniczne, które mają wyraźne wady (coś, co możesz zrobić tylko wtedy, gdy masz uruchomione oprogramowanie), możesz podjąć inną decyzję bez wpływu na resztę systemu.

Standaryzacja to jedno podejście

Twój zespół musi dojść do konsensusu co do tego, co przyjmie jako standard rozwoju, a następnie trzymać się go przez rozsądny okres czasu (decyzja zespołu). Jeśli standard zawiedzie, wówczas prawdopodobnie zostanie przyjęty nowy z nowej serii możliwych ram rozwiązań.

„Hej, te komputery były w końcu bezużyteczne, spróbujmy komputerów Mac!”

lub

„Mówiłem ci tak! Wiosna jest znacznie lepsza niż EJB”.

I tak dalej.

Posiadanie standardu oznacza, że ​​kod staje się łatwiejszy do pracy w zespole, co z kolei prowadzi do bardziej produktywnego środowiska.

Obecnie testuję podejście, kod o nazwie „Papieskie konklawe” i jest dość obiecujące. Opiera się na historii, że podczas jednego z wyborów papieskich nastąpił „impas”, a kardynałowie po prostu nie mogli dokonać wyboru. Podmiot organizujący wybory (najprawdopodobniej niektóre z głównych miast) najpierw zamknął kardynałów w budynku, a następnie drastycznie zmniejszył zapasy żywności, a następnie usunął dach budynku, aby debata była jeszcze mniej komfortowa. Zgodnie z oczekiwaniami kardynałowie dokonali wyboru po usunięciu dachu, kończąc trzyletni impas.

Więc moje podejście jest takie, że kiedy ludzie nie zgadzają się co do niektórych rzeczy, są zmuszeni dyskutować o tym, dopóki nie znajdą wyboru. Nie zapewniam żadnego innego dyskomfortu, nawet ograniczenia czasowego i oczywiście nie robię nic z dachem :). Wszystko, co robię, to ciągle poruszam ten problem każdego dnia. Jeśli ktoś powie „Nie możemy podjąć decyzji”, odpowiadam „Cóż ... musisz”. Jak dotąd nie spotkałem osoby tak beznadziejnie uzależnionej od drobnych szczegółów technologicznych. Po wielu spotkaniach szukają kompromisu, podobnie jak kardynałowie.

Zgadzam się, że jest to bardziej długotrwała dyskusja, niż jej przerywanie. Jednak dyskusje nie są niekończące się i na plus, niektórzy ludzie po takim „konklawe” unikają drobnych debat technologicznych, co sprawia, że ​​wszystko jest wygodniejsze dla całego zespołu.

Przeczytałem gdzieś, że nie powinieneś podróżować razem więcej niż 6, jeśli musisz uzgodnić, dokąd się udać i co robić, ponieważ nie osiągniesz konsensusu.

Jest to doskonały przykład tego, dlaczego musi istnieć osoba o decydujących mocach. W tym konkretnym przykładzie wspomniana osoba musi podjąć decyzję i powiedzieć „tak musi być”, a inni muszą uszanować tę decyzję, aby można było wykonać prawdziwą pracę.

Jeśli później decyzja okaże się zła, przynajmniej wiesz na pewno i możesz się z niej uczyć.

Jedno podejście polega na głosowaniu i działa dobrze w mniejszych zespołach.

Podczas gdy dwie osoby mogą prowadzić rozmowę; przenieś go na otwarte forum ... debata przez N, a następnie głosuj, podnosząc ręce.

Prosty, ale demokratyczny i pozwala iść do przodu.

Podobne pytanie może brzmieć:

Jak zatrzymać wojny religijne / płomienne na forach?

Myślę, że @ S.Lott ma rację w swoim komentarzu, jeśli jedynym punktem jest „dyskusja”, „odejście” lub w inny sposób zignorowanie tego może być jedyną odpowiedzią. Użyłem tej techniki w przeszłości.

Jeśli chodzi o rozwiązanie, rozważ zalety / wady dla danej domeny, ustaw limit czasu i (skinął głową Nike) po prostu to zrób.

Idealnie - IMO - lider technologiczny lub autorytet mówi: „okej, dziękuję za twoje punkty, jesteśmy…„ dźwiękiem rzutu kostką ”… idąc z pomysłem„ tak i tak ”. i wszyscy idą i siadają.

Geekery ponad maleńkie punkty zmarnowały ogromną ilość mojego czasu na spotkanie i nie chcę tego więcej słyszeć. : - /

Uważam, że kiedy skupiasz się na rozmowie nie na tym, która alternatywa jest właściwa, ale na konsekwencjach wyboru niewłaściwej, nie popadasz zbytnio w kłopoty. Jeśli uda nam się dojść do konsensusu, że nawet jeśli A ma rację, B nas nie zabije, nikt nie dostanie zbyt wiele, jeśli skończymy z B. Jeśli nie możemy dojść do tego konsensusu, to na ogół dlatego, że istnieje prawdziwy problem do których musimy się odnieść.

Najważniejsze jest to, że musimy być dojrzali i rozumieć, że nie zawsze możemy się ze sobą zgodzić, dużą i dojrzałą rzeczą jest uczyć się od siebie, dlaczego mamy pozycje, które zajmujemy i być może związane z moimi zadaj pytanie, dowiedz się, jakie doświadczenia i dlaczego. Następnie możemy stworzyć własną, świadomą opinię i być przeklętym lub nie.

Ja osobiście nie potrzebuję ani nie oczekuję, że inni się ze mną zgodzą, byłoby miło, ale nie ważne. I do tego momentu cytuję Voltaire.

„Mogę się nie zgodzić z tym, co mówisz, ale będę bronił się na śmierć, masz prawo to powiedzieć”. -Voltaire, filozof z 5 wieku

Każde spotkanie powinno mieć przewodniczącego odpowiedzialnego za porządek obrad i utrzymanie porządku (i zabieranie minut, chociaż mogą przekazać to zadanie komuś innemu, jeśli spotkanie jest zbyt duże, aby mogli obsłużyć wszystko). Zadaniem przewodniczącego jest powiedzenie komuś, by przestał się kłócić („chłopaki, wyłączcie to” w mowie korporacyjnej).

Jeśli spotkanie nie jest warte wyznaczenia przewodniczącego, nie warto go mieć. Równie dobrze możesz porozmawiać na watercooler.

Można powiedzieć „łatwiej powiedzieć niż zrobić, quant_dev”. Cóż ... naturalny przewodniczący jest kierownikiem zespołu, kierownikiem projektu, kierownikiem zespołu. Powinny mieć niezbędny autorytet. Spotkania, w których nikt nie wie, kto tak naprawdę prowadzi spotkania, są oznaką chaosu w organizacji, głębszego problemu, który należy rozwiązać.

Najpierw rozwiąż ogólne problemy: potrzebujemy serwera WWW, serwera aplikacji, DB itp.

W przypadku debat o tym, której bazy danych lub serwera użyć, zaparkuj te elementy na inne spotkanie.

Podczas kolejnych spotkań pozwól na dyskusję w celu „krótkiej listy” potencjalnych ofert, np. MySQl, MS SQL Server, Postgres itp.

Pozwól członkom zespołu wyrazić swoją opinię, ale poproś, aby poparli ich faktami. Produkt X jest do bani! Nie tnie, produkt Y nie skaluje się! Jest zbyt niejasne Itp.

Gdy wszystkie szczegóły zostaną podane do stołu, musisz albo poddać je pod głosowanie, albo jako lider zespołu podjąć decyzję wykonawczą.

Jeśli musisz spłacić wyraźnego zwycięzcę lub potwierdzić wsparcie / brak funkcji / koncepcji, poświęć trochę czasu na wykonanie POC (Proof Of Concept), ale zdaj sobie sprawę, że zajmie to trochę czasu, a programiści mają tendencję do chcesz biegać z tym, od czego zaczęli ... Pamiętaj, aby zweryfikować wszelkie przeszkody na drodze / problemy techniczne przed skorzystaniem z POC.

Jako lider zespołu czuję, że to zależy, czy decyzja musi zostać podjęta tu i teraz.

Jeśli to konieczne, szukam tego o najniższym koszcie odwrócenia. Jako zespół programistów zawsze ważne jest, aby wiedzieć, że Twoja decyzja może być błędna, być może będziesz musiał dokonać podejrzanego wyboru i zmienić zdanie. Koszt takiego działania należy zawsze zminimalizować.

Jeśli może poczekać, należy rozważyć fakt, że żadna ze stron nie zgadza się z wszystkimi faktami. Poproś ich, aby odeszli i zbadali dalej i przeprowadzili własne badania.

Czy zawsze robimy to w ogniu bitwy? Nie, szczególnie gdy jestem jednym z tych, którzy mają gorącą opinię (nie twierdzę, że jestem doskonały). Myślę jednak, że jest to sposób na podejście do takich sytuacji. Boks czasowy nigdy nie wydaje się prowadzić do tego, że wszyscy się zgadzają, po prostu prowadzi do niejednoznacznego argumentu.

O ile nie masz trudnego członka zespołu, zwykle nie trwa niekończąca się debata, chyba że nie ma wyraźnej przewagi nad żadnym z tych podejść. Oto kilka dobrych sposobów na zerwanie remisu:

• Niech osoba, która faktycznie musi to wdrożyć, zdecyduje.
• W przypadku problemów z interfejsem użytkownika decyduje osoba najbardziej świadoma wymagań klienta.
• Niech zdecyduje osoba z największym doświadczeniem w temacie lub części bazy kodu.
• Pozwól osobie o najściślejszych ograniczeniach czasowych lub ograniczeniu siły roboczej i zasobów.
• Niech osoba decyduje, kto ma bardziej konkretne, niż teoretyczne zastrzeżenia.
• Znajdź kompromis między podejściami.
• Zbierz więcej informacji i zdecyduj na następnym spotkaniu, przykładając większą wagę do osób, które najwyraźniej poświęciły trochę czasu na badanie od ostatniego spotkania.

W miarę jak ogłosić decyzję, po prostu powiedzieć: „Dobra, jedziemy z tym z bo to ”. Jeśli ludzie czują się tak, jakbyś ich wysłuchał i nie jesteś żałosnym przywódcą, podejmą decyzję. W przypadku szczególnie upartych możesz obiecać, że dokonasz ponownej oceny po dokonaniu pewnej ilości implementacji, ale większość ludzi dorzuci ją do tego momentu.

Dobry organizator spotkań może ułatwiać tego rodzaju dyskusje bez wypuszczania ich z rąk.