기본 콘텐츠로 건너뛰기

3월, 2018의 게시물 표시

성과 있는 기술 회의를 위해 의견을 제시할 때 유의할 점

기술 회의를 하는 건 일반적인 회의와 약간 다른 특성이 있는데 그건 아마도 상당 부분 물리적으로 혹은 논리적으로 검증 가능하기 때문일 것이다. 주장을 확인할 방법이 항상 있다고 생각할 수 있다.
회의에서 발언하는 사람들은 발언의 범주를 잘 구분할 필요가 있는데 흔히 자기 질문의 성격을 구분하지 않고 얘기하는 경우가 있다.
발언의 유형을 단순하게 나눠보자면 1. ‘질문(몰라서 묻는)’2. ‘즉흥적 가설(문맥의 상황을 설명하거나 해결하기 위한)’3. ‘제안(의사결정이나 부분 기술에 대한 의견 제시)’4. ‘의사결정(잠정적 결론에 대한 기술)’그외 회의 진행을 돕기 위한 보완 설명 등으로 나눌 수 있겠다.
단순 질문은 명쾌해야 하며 진행을 돕는 보조 설명은 너무 늘어지면 안된다. 흔히 발생하는 문제는 질문과 가설, 제안을 혼돈하는 것과 가설, 제안과 의사결정을 혼돈하는 것이다.
몰라서 질문을 하면서 마치 의견 제안을 하는 듯이 토론을 요구하는 듯한 경우도 있고, 의견을 내면서 무조건 자기 의견을 결정하기 위한 의사결정의 안인 듯이 윽박지르기도 한다. 심지어 회의에 참석하는 것은 자기 의견을 관철하기 위한 수단으로 생각하는 경우도 있다.
토론할 때 잘못된 방식의 의견들로 다음 현상들을 볼 수 있다.

반복된 변명식 주장단답형 답변말 끊기추임새식 내용없는 랩업 반복타인의 권위를 근거로 한 주장
모두 깊이있는 개념적, 다면적 이해와 아이디어 공유를 방해하는 행위들이다.

많은 오류는 마음 속에 의견이 아니라 의사결정을 들고 있기 때문이다. 시작부터 Open-ended 원칙을 추구하지 않는 셈이다.
의견과 의사결정은 큰 차이가 있다.
권한의 문제이기도 하겠지만 그보다는 의견의 수준에 있다. 의견의 수준이 충분히 의사 결정할 만큼 풍부하고 해결책을 포함해야 의사결정의 단계에 이를 수 있다.
조급함이나 압박감은 더욱 문제를 악화시킨다.
좋은 의사결정 수준에 이른 의견 혹은 안은 몇 가지 특징을 요구한다.
하나는 풍부함이다. 회의를 하는 이유는 다른 생각을 얻기 위함이다.두번째, 개…