끝없는 기술 토론을 멈추고 결정하기

나는 항상 가장 작은 "기술적 인 것"을 넘어서 오랫동안 뛰기를 좋아하는 사람들을 만납니다.

내가 잘못하지 마라, 나는 내가하는 일을 좋아하는 괴짜 프로그래머이지만 대화의 유형을 알고있다.

• Mac은 Windows보다 훨씬 낫다
• For Each 루프를 사용하지 말고 While 루프를 사용하십시오
• Intel 기반 PC를 구입하지 말고 AMD 기반 PC를 구입하십시오.
• 한 IoC 컨테이너를 다른 IoC 컨테이너보다 사용해야합니다.

이 모든 "사물들"은 양쪽에 유효한 장단점이 있으며, "올바른"답변을 얻지 못할 것이며 그 사람은 그 요점을 인정하지 않을 것입니다. (물론 답이있는 곳이있을 것입니다.)

내 질문은 (나는 거기에 간다!) : 소프트웨어 팀에서 어떻게 혁신을 방해하지 않고 이러한 긴 토론을 어떻게 끝내고 결정을 내리고 실제 비즈니스 문제를 해결할 수 있을까요?

문제 1. 어떤 사람들은지는 것을 좋아하지 않습니다. 그들이 샷을 호출하지 않으면, 그들은 감소를 통해 샷을 호출 할 때까지 토론을 할 것입니다.

문제 2. 실제로 위험에 처한 것은 없으므로 토론은 허용됩니다.

문제가 있습니까? 예. 대부분의 결정은 거의 제로 달러 영향을 미칩니다. 그것이 "나이를위한 뱅 (bang on for ages)"이라는 사실은 두 선택이 사실상 동일하다는 것을 의미합니다.

무엇을해야합니까?

1. 아무것도 위험에 처하지 않음을 인식하십시오.

2. 2 ~ 3 년 후에는 조직 외부의 무언가가 변경되어 전체 주제가 다시 열립니다.

3. 동전을 던지세요. 진심으로. 무언가를 골라 넘어가십시오. 어떤 사람들은 토론에서 침묵을 보게 될 것입니다. 그런 다음 일부 사람들은 던져지는 동전의 본질에 대해 토론합니다. 사람들이 동전 던지기에 만족하지 못하면 자아 문제가 있으며 (a) 위험에 처한 것이 없으며 (b) 몇 년 안에 결정이 변경 될 것임을 알아야합니다.

그들이 위험에 처한 것을 알 수 없다면, 논쟁의 양쪽에 대한 달러 가치를 써야합니다. 어떤 시점에서 누군가는 실제 결정보다 가치있는 시간이 분석에 더 많이 소비되고 있음을 알 수 있습니다. 동전 던지기는 저렴한 비용으로 동일한 가치를 창출합니다.

고려해야 할 몇 가지 사항 :

1. 수량화 할 수있는 인수 만 허용하십시오. 누군가 시간이 절약된다고 말하면 수량을 정하고 답변을 잡아달라고 요청하십시오. 이런 식으로 그들이 쓰레기를 말하고 있다면, 모두가 파열 된 것을 알기 전에 한 번만 가야합니다.

2. 사람들이 권장 사항에 대해 책임을지게하십시오. 연말에 그들이 평가의 일부가 될 나쁜 전화를 걸 었음을 분명히하십시오. 나는 논쟁을 신경 쓰지 않지만 확신을 가진 용기를 가진 사람들을 원합니다. 무언가를 맹세하고 우리가 그것을 채택 할 것을 기대한다면, 그 결과로 더 잘 살 수있을 것입니다.

이것들은 S.Lott의 두 가지 문제에서 벗어날 수있는 실제적인 것입니다. 어떤 사람들은 잃고 싶지 않으며 아무것도 위험에 빠지지 않습니다. 나의 반응은 위험에 처해 있으므로 토론을위한 토론은 없습니다.

1. 타임 박스 토론. -각 측에서 사례를 설명하는 데 5 분 이상 소요되면 너무 복잡합니다. 우리는 실제로 이것을 위해 주방 타이머를 사용합니다 . 그들은 훌륭하게 작동하며 약 5 달러가 들었습니다.
2. 참가자들이 데이터와 경험에 대해 논쟁하도록 요구하십시오.
3. 우리는 테이블에 옵션을 유지합니다. 양측이 각자의 시간을 보낸 후, 우리는 5 분을 더 투자하여 각 접근법의 의미에 대해 논의합니다. 20 분 후, 우리는 나가서 해냈다 (구현). 작동하지 않으면 다른 접근법을 사용하십시오.

규칙은 간단합니다. 무엇을 선택해야할지 모른다면 회사에 무엇이 더 좋은지 생각해보십시오.

예, 인텔 v AMD의 선택은 쉽지 않습니다. 그러나 어느 것이 회사에 더 좋습니까? 예를 들어, 물건을 주문하는 사람이 있고 AMD 프로세서 기반 PC를 주문하는 데 나이가 걸릴 수 있지만 인텔 기반 주문은 1 분 안에 주문할 수 있으며 실제로 무엇이 될지는 신경 쓰지 않습니다. 회사에 더 좋기 때문에 인텔 기반 제품을 주문하십시오.

일반적으로 이러한 논의는 실제로 자전거 타기 입니다. 어떤 전송 형식이나 어떤 데이터 저장소를 사용해야하는지, 그리고 다른 모든 세부 사항에는 투명해야하지만 다른 세부 정보는 구현해야하는 다른 세부 사항을 주장하는 사람들. 구성 요소가 설계 계약을 이행하고 계약 담당자가 합리적인 시간 내에 계약 변경에 응답 할 수있는 한 누구도 망설이지 않습니다.

소프트웨어 개발에서 발생하는 모든 기술 문제의 대부분은 자전거 흘림 문제입니다. 그들은 이미 솔루션을 가지고 있기 때문에 유일한 질문은 어떤 솔루션을 선택 하느냐입니다.
그러한 결정에 자신을 고정해서는 안됩니다. 이러한 결정을 응용 프로그램을 세부 정보와 분리 하는 추상화 계층에 고정시켜야합니다 .
소프트웨어 개발에서 실제로 중요한 문제는 기능 및 시스템 수준의 디자인 문제입니다. 다른 모든 것은 부차적입니다.

따라서 그러한 토론을 시작하지 마십시오. 프로젝트를 독립적 인 부분으로 나누는 데 에너지를 집중하십시오. 이를 통해 소프트웨어가 더욱 강력하고 유연 해집니다. 그리고 명백한 단점이있는 기술적 결정을 정확히 찾아 낼 수 있다면 (실행중인 소프트웨어가있는 경우에만 할 수있는 일) 나머지 시스템에 영향을주지 않고 다른 결정을 내릴 수 있습니다.

표준화는 하나의 접근법입니다

팀은 개발 표준으로 채택 할 대상에 대해 의견을 모은 다음 합리적인 기간 (팀이 결정)에 따라야합니다. 표준이 실패하면 가능한 새로운 솔루션 프레임 워크에서 새로운 표준이 채택 될 것입니다.

"이봐 요, 그 PC는 결국 쓸모가 없었습니다. Mac을 사용해 봅시다!"

또는

"저는 그렇게 말했습니다. Spring은 EJB보다 훨씬 낫습니다."

등등.

표준을 가짐으로써 팀 전체에서 코드 작업이 쉬워지고 생산성이 향상됩니다.

저는 현재 "Papal conclave"라는 코드와 그 유망한 접근 방식을 테스트하고 있습니다. 교황 선거 중 하나에 교착 상태가 있었고 추기경이 단순히 선택을 할 수 없다는 이야기를 기반으로합니다. 선거 (주로 일부 도시 전공)를 주최하는 주체는 먼저 건물에 추기경을 가두었다가 급식을 급격히 줄인 다음 건물의 지붕을 제거하여 토론을 더욱 편안하게 만들었습니다. 지붕이 제거 된 후 3 년 교착 상태가 끝나고 예상대로 추기경들이 선택했다.

그래서 제 접근 방식은 사람들이 어떤 것에 동의하지 않을 때, 선택을 할 때까지 논의해야한다는 것입니다. 나는 다른 불편 함을 제공하지 않으며 시간 제약조차 없으며 물론 지붕으로 아무것도하지 않습니다. :). 내가하는 일은 항상 문제를 매일 제기하는 것입니다. 누군가 "우리는 결정을 내릴 수 없습니다"라고 가면 "음 ... 당신은해야합니다"라고 대답합니다. 지금까지 나는 사소한 기술적 인 세부 사항에 너무나 중독 된 사람을 만나지 못했습니다. 여러 번의 회의 후에 그들은 추기경처럼 타협을 찾는 경향이 있습니다.

나는 이것이 끊임없는 논의가 아니라 지속적인 토론이라는 데 동의합니다. 그러나 토론은 끝이 아니며 플러스로, 그러한 "클레이브"이후의 일부 사람들은 사소한 기술적 논쟁을 피하는 경향이있어 팀 전체가보다 편안하게 일할 수 있습니다.

당신이 합의에 도달하지 않기 때문에 당신이 갈 곳과해야 할 일에 동의해야한다면, 6 번 이상 함께 여행해서는 안되는 곳을 읽었습니다.

결정적인 힘을 가진 사람이 필요한 이유의 주요 예입니다. 이 특정한 예에서, 상기 사람은 결정을 내려야하며 "이것과 같아야한다"고 말해야하며, 다른 사람들은 그 결정을 존중하여 실제 작업을 수행 할 수 있어야합니다.

결정이 나중에 나쁘다고 판명되면, 적어도 확실하게 알고 결정을 통해 배울 수 있습니다.

한 가지 방법은 투표에 의한 것이며 소규모 팀에서 잘 작동합니다.

두 사람이 대화를하는 동안; 공개 포럼으로 옮기십시오 .N 시간 동안 토론 한 다음 손을 들어서 투표하십시오.

단순하면서도 민주적이며 앞으로 나아갈 수 있습니다.

비슷한 질문이 될 수 있습니다.

포럼에서 종교 / 불꽃 전쟁을 멈추는 방법?

@ S.Lott이 그의 의견에 맞다고 생각합니다. 유일한 논점이 "토론", "도보"또는 그렇지 않으면 그것을 무시하는 것이 유일한 답일 수 있습니다. 나는 과거에 그 기술을 사용했습니다.

요점은 솔루션에 관한 것이라면, 해당 도메인의 장단점을 측정하고 시간 제한을 설정하고 (Nike에게 끄덕임) 그렇게하십시오.

이상적 - IMO - 테크 리드 또는 권한 그림은 "좋아, ... 우리가있어, 당신의 점에 감사드립니다"라고 주사위 롤의 소리를 . "아무개의 아이디어 것 ..." 모두가 가서 앉습니다.

사소한 포인트 이상의 괴짜가 회의 시간을 엄청나게 낭비했으며 더 이상 듣고 싶지 않습니다. :-/

나는 당신이 어떤 대안이 옳은지에 대한 것이 아니라 잘못된 것을 고르는 결과에 대해 대화에 집중할 때 너무 혼란에 빠지지 않는 것을 발견했습니다. 우리가 A가 옳더라도 B가 우리를 죽이지 않을 것이라고 합의에 도달 할 수 있다면, 우리가 B와 함께 갈 경우 아무도 너무 엉망이되지 않을 것입니다. 우리는 해결해야합니다.

가장 중요한 것은 우리는 성숙해야하고, 우리가 항상 서로 동의 할 수 없다는 것을 이해하고, 크고 성숙한 것은 서로에게서 배우는 것, 왜 우리의 입장이 있고, 아마도 내 자신과 관련이 있는지를 이해하는 것입니다 질문, 어떤 경험과 이유를 배우십시오. 그러면 우리는 우리 자신의 정보에 근거한 의견을 구성하고 저주받을 수 있습니다.

나는 개인적으로 다른 사람들이 저에게 동의 할 필요가 없거나 기대하지 않습니다. 그것은 좋지만 중요하지는 않습니다. 그리고 지금까지 볼테르를 인용합니다.

"나는 당신이하는 말에 동의하지 않을 수도 있지만, 죽음에 대해 말할 권리가 있습니다." -볼테르, 5 세기 철학자

모든 회의에는 의제와 질서를 담당하는 의장이 있어야합니다. 회의가 너무 커서 모든 것을 처리 할 수없는 경우 다른 사람에게이 작업을 위임 할 수는 있지만 몇 분이 걸립니다. 의장의 임무는 누군가에게 말다툼을 중단하라고 지시하는 것입니다 ( "사람들은 회사 발언에서 오프라인으로 가져 가십시오").

회의를 의장으로 임명 할 가치가 없다면 회의를 가질 가치가있는 회의가 아닙니다. 워터 쿨러에서 채팅 할 수도 있습니다.

"종료보다 더 쉬운 말, quant_dev"라고 말할 수 있습니다. 자연 회장은 팀장, 프로젝트 매니저, 팀 매니저입니다. 필요한 권한이 있어야합니다. 누가 실제로 회의를 이끌고 있는지 아무도 모르는 회의는 조직의 혼란의 징후이며 해결해야 할 더 깊은 문제입니다.

웹 서버, 앱 서버, DB 등이 필요합니다.

사용할 DB 또는 서버에 대한 토론을 위해 다른 미팅에 해당 항목을 보관하십시오.

후속 회의에서 MySQl, MS SQL Server, Postgres 등과 같은 잠재적 인 오퍼링을 "짧은 목록"으로 토론 할 수 있습니다.

팀원이 의견을 제시 할 수 있지만 사실을 뒷받침하도록 요청하십시오. 제품 X는 짜증 난다! 절단하지 않음, 제품 Y는 확장되지 않습니다! 너무 모호합니다. 기타.

모든 세부 사항이 발표되고 표에 나오면 투표에 넣거나 팀장이 임원 결정을 내릴 필요가 있습니다.

명확한 승자를 플러시하거나 기능 / 개념에 대한 지원 / 부족을 확인해야하는 경우 POC (Proof Of Concept)를 수행하는 데 어느 정도 시간이 걸리지 만 시간이 걸리고 개발자가 경향이 있음을 알고 있어야합니다. POC를 시작하기 전에 모든로드 블록 / 기술 문제를 확인하십시오.

팀 리더로서, 나는 결정은 경우에 따라 다르다 느낌이 있어야 지금 여기에서 할.

그렇다면 나는 가장 저렴한 반전 비용을 가진 것을 찾습니다. 개발 팀으로서 결정이 잘못되었다는 것을 아는 것이 항상 중요합니다. 당신은 골리를 고르고 마음을 바꿔야 할 수도 있습니다. 그렇게하는 비용은 항상 최소화되어야합니다.

기다릴 수 있다면 동의하지 않는 당사자가 모든 사실을 소유하고 있지 않다는 사실을 고려하십시오. 멀리 가서 더 연구하고 직접 연구하도록 부탁하십시오.

우리는 항상 전투의 열기에서 이것을합니까? 아니, 특히 내가 열렬한 의견을 가진 사람들 중 하나 일 때 (나는 완벽하다고 주장하지는 않는다). 그러나 나는 이것이 그러한 상황에 접근하는 방법이라고 생각합니다. 타임 복싱은 모든 사람이 동의하는 것으로 결코 보이지 않으며, 결론을 내릴 수 없습니다.

어려운 팀원이 아닌 한, 두 가지 접근 방식에 분명한 이점이 없다면 일반적으로 끝없는 토론은 없습니다. 다음은 동점을 끊는 좋은 방법입니다.

• 실제로 구현해야하는 사람이 결정하게하십시오.
• UI 문제의 경우 고객 요구 사항을 가장 잘 알고있는 사람이 결정하도록합니다.
• 주제 나 코드베이스의 일부에 대해 가장 경험이 많은 사람이 결정하도록하십시오.
• 가장 엄격한 일정 제약이나 인력 및 자원 제한을 가진 사람이 결정하도록하십시오.
• 이론적 이의가 아닌보다 구체적인 사람을 결정하게하십시오.
• 접근 방식간에 타협점을 찾으십시오.
• 다음 회의에서 더 많은 정보를 수집하고 결정하여 마지막 회의 이후 연구에 시간을 보낸 사람들에게 더 많은 비중을 두십시오.

지금까지와 같은 방법 결정을 발표, 당신은 그냥 "좋아, 우리가가는거야,라고 이 때문에 이 ." 사람들이 당신이 그들에게 공정한 청문을 한 것처럼 느끼고 리더로서 소망스럽지 않다면, 그들은 당신의 결정을 따라갈 것입니다. 특히 완고한 사람에게는 일정량의 구현이 완료된 후에 재평가하겠다고 약속 할 수 있지만 대부분의 사람들은 그 시점에이를 철회 할 것입니다.

훌륭한 회의 진행자는 이러한 종류의 토론을 방해하지 않고 진행할 수 있습니다.