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

27

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.

Ozz
źródło
2
Czy mówisz, że „odejdź” nie jest odpowiedzią? Czy mówisz o sytuacjach, w których musisz podjąć decyzję? A może mówisz o sytuacjach, w których nie ma praktycznej reakcji poza odejściem?
S.Lott,
1
Tak, to właśnie powinno oznaczać moje ostatnie zdanie: „Po prostu wybierzmy już coś i przejdźmy do rozwiązania problemu biznesowego”.
ozz
Takie rzeczy mogą się zdarzyć na wielu polach, więc nie sądzę, żeby były tutaj na temat.
David Thornley,
Czy jesteś liderem?
3
Połóż piłę łańcuchową na stole. Przyniosłeś piłę łańcuchową, prawda? :)
Vitor Py

Odpowiedzi:

25

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.

S.Lott
źródło
2
Dobra odpowiedź - dwa problemy zarysowują na początku wiele tego, co prowadzi do tego rodzaju rzeczy.
Jon Hopkins
9

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.

Jon Hopkins
źródło
2
Nie jestem wielkim fanem oparcia oceny pracownika na decyzji technicznej podjętej w przeszłości. Może się zdarzyć, że nikt nie chce wziąć na siebie odpowiedzialności, a chociaż może to uniemożliwić prowadzenie długich i niepotrzebnych dyskusji, może także przerwać wszelką pomocną i sensowną dyskusję. Dodatkowo dajesz wrażenie, że błąd jest uważany za zły. Z mojego doświadczenia w branży oprogramowania ludzie cały czas się mylą, ale to nie znaczy, że nie wiedzą o czym mówią. Chodzi o to, że coś, o czym byłeś przekonany, nie zmieniło się tak, jak myślałeś.
Anne Schuessler
2
@Anne, myślę, że istnieje różnica między proszeniem o opinie a dwiema / kilkoma osobami, które walczą o coś, co powstrzymuje zespół. Jon podkreśla, że ​​jeśli zależy ci na tym, aby tracić czas / pieniądze na utrzymywanie drużyny jako argumentu, powinieneś zostać pociągnięty do odpowiedzialności.
Steve Jackson
2
+1 za zmuszanie ludzi do kwantyfikacji swoich argumentów. To zwykle śpieszy wiele osób.
John Bode
1
@Anne - To byłaby część oceny, a nie automatycznie negatywna rzecz. Z pewnością nie chciałbym zniechęcać ludzi do podejmowania decyzji, ale musisz także uświadomić ludziom, że decyzje mają konsekwencje i że nie mogą po prostu strzelać z biodra.
Jon Hopkins
@Jon i @ Steve Tak, myślę, że rozumiem. Zgadzam się z częścią dotyczącą odpowiedzialności, po prostu bałbym się, że ludzie mogą wydawać się upomnieni za wzięcie odpowiedzialności, gdy okazało się, że ich pierwotna decyzja okazała się nieskuteczna. Jeśli sprawisz, że ktoś weźmie odpowiedzialność za coś, co mocno go odczuwa, musisz upewnić się, że jeśli tak naprawdę nie spieprzyło go to, to i tak zostaniesz nagrodzony za podjęcie działań. Jeśli tak jest, to jestem na pokładzie.
Anne Schuessler
6

Minutnik

  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.
George Stocker
źródło
5

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.

sharptooth
źródło
Podjęliśmy tę decyzję w sprawie komputera kieszonkowego. Jedna z marek była tak trudna do zdobycia (musieliśmy być autoryzowanym sprzedawcą, który wymagał wypełniania formularzy po formularzach), że poszliśmy z jego konkurentem.
Pierre-Alain Vigeant
5

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.

back2dos
źródło
3

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.

Gary Rowe
źródło
Standaryzacja środowiska - zwłaszcza sprzętu i systemów operacyjnych - ma jedną wadę, którą warto zauważyć: niektóre problemy wynikające z interakcji aplikacji i środowiska zostaną zauważone tylko przez użytkowników / klientów - klasyczny „działał na moim komputerze!”. W zależności od rodzaju tworzonych aplikacji może być lepiej zachować heterogeniczne środowisko programistyczne, aby wykryć takie błędy przed wysyłką produktu (lub, jeśli masz oddzielne środowisko testowe, zachować przynajmniej heterogeniczność).
Joonas Pulakka 27.01.11
@Joonas Całkiem tak. Chciałbym przyjrzeć się znormalizowanemu procesowi kompilacji (np. Maven), który pozwala każdemu używać dowolnego IDE / vim / emacs itp., Ale z formalnym procesem ciągłej integracji w celu zapewnienia, że ​​zawsze masz działającą kompilację pod kontrolą źródła (lub jesteś w najmniej świadom, że obecnie tego nie robisz).
Gary Rowe
3

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.

Jacek Prucia
źródło
3

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ć.

użytkownik1249
źródło
3

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.

Aaron McIver
źródło
1

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.

DevSolo
źródło
Robię to, gdy rozmawiają tylko ludzie. Zaktualizowano pytanie, aby było bardziej szczegółowe
ozz
1

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ć. : - /

Paul Nathan
źródło
1

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ść.

Robert Rossney
źródło
1

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

Crosenblum
źródło
1

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ć.

quant_dev
źródło
1

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.

scunliffe
źródło
1

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.

pdr
źródło
1

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.

Karl Bielefeldt
źródło
0

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

Marcie
źródło