Theory/Project Management

9장 의사소통과 관계

오늘날의 의사소통에서 그것의 품질과 효과, 함께 일하는 사람들과의 관계를 중요하게 생각합니다.

의사소통은 전송, 수신, 이해, 동의, 조치라는 기본 상태를 가집니다. 원하는 일이 제대로 일어나지 않는다면 이것을 사용하여 어떤 단계에 문제가 생겼는지 파악합니다.

일반적으로 발생하는 의사소통의 문제는, 1) 확인되지 않은 가정, 2) 내용을 명확히 절달하지 못함, 3) 상대의 말을 주의깊에 듣지 않음, 4) 지시, 명령, 5) 감정이 다른 형태로 표출됨, 6) 인신 공격, 7) 비웃음, 조소, 비난 등이 있습니다.

이것을 해결하기 위해서는, 1) 핵심 사항에 대한 가정을 논의 중에 습관적으로 밝힘 2) 다른 사람이 쉽게 이해할 수 있는 방법을 찾음, 3) 내가 모르는 것을 상대방이 알고 있다는 가능성을 인정, 4) 좋은 질문을 던지고, 관리자의 논리에 도전할 수 있는 환경을 만듬, 5) 사안을 분리, 예를들면, "문제가 기능을 구현할 방법인가요 아니면 바라던 승진을 못한 이유인가요?", 6) 좀 더 성숙한 사람이 되기, 7) 아이디어를 내놓은 사람이 상대적으로 약한 면을 드러낸다는 것을 인정함 등이 있습니다.

누군가와 좋은 대화를 나누려면 긍정적인 관계를 맺어야 합니다.

PM은 함께 일할 핵심 인물들 모두에게 자신의 역활을 명시합니다. 역활의 설명은 1) 자신이 책임지는 항목, 2) 두 사람이 공유하는 항목, 3) 삼자가 전적으로 책임지는 항목입니다.

PM은 팀이 최고의 엄무를 수행할 수 있도록 돕습니다. 윽박지르거나 비난해서는 안됩니다. 상대가 문제를 이해하고 해결하도록 도와야 합니다.

최고의 업무를 끌어내기 위해서는, 충고를 경청, 동기를 유발, 팀원의 업무를 방해하는 것들을 막아줌, 개별 역활과 프로젝트의 목표를 상기, 교육, 그리고 최선을 다해달라고 요청하기 등이 있습니다.

'Theory > Project Management' 카테고리의 다른 글

11장 어려움을 극복하기  (0) 2007.03.08
10장 프로세스, 전자편지, 회의  (0) 2007.03.07
9장 의사소통과 관계  (0) 2007.03.06
8장 올바른 결정 내리기  (0) 2007.03.02
7장 명세서  (0) 2007.02.27
6장 아이디어 관리하기  (0) 2007.02.23
Life/Communication

들을 준비가 되어 있습니까?

요즘에 개콘에서 "대화가 필요해."라는 코너가 있습니다. 대화가 없는 현대 가족을 풍자한 개그입니다. 코메디보다는 덜하지만 우리 가족 역시 그리 대화가 많지 않습니다.

저번주에 가족끼리 가볍게 술한잔 하면서 그와 비슷한 얘기가 나왔습니다. 이 얘기는 이번 자리 뿐만이 아닙니다. 가족간의 모임에서 종종 아버지가 이런 얘기를 꺼내십니다. 아버지가 처음에 말을 꺼내기는 하지만 가족 모두 대화가 부족하다는 것을 모두 느끼고 있습니다. 매번 비슷한 얘기가 나온다는 것은 대화의 방법에 근본적인 문제가 있다는 것으로 생각합니다.

저의 의견은 어느 누구도 들을 준비가 되어 있지 않다는 것입니다. "우리 대화하자!"라는 말은 "내가 너에게 할말이 있어"라는 의미이고, "니 문제를 얘기해 봐"는 "니가 문제를 얘기하면 내가 해결책을 내어줄께"라는 것입니다. 이런 상태에서는 상대방의 말을 주의깊게 듣지 않고, 그 사람에게 해줄 자신의 말에만 집중하게 됩니다. 이것은 대화가 아니라 연설입니다. 가족간에는 흔히 잔소리라고 표현하기도 합니다.

문제점을 파악했으니 실천이 남았습니다. 누군가와 대화하려고 할때마다, 항상 자신에게 물어보겠습니다.

"들을 준비가 되어있습니까?"


Theory/Project Management

8장 올바른 결정 내리기

의사결정을 성공하기 위해서는 어느 결정에 시간과 에너지를 쏟아부을지 결정해야 합니다. 이것을 메타-의사결정이라고 합니다.

의사결정의 첫번째는 중요성을 판단하는 겁니다. 문제의 핵심을 파악하고, 결정으로 생기는 영향을 고려합니다. 시간이 결정에 미치는 효과를 판단합니다. 필요하다면 전문가와 같이, 또는 전문가에게 위임할 수도 있습니다.

여러가지 선택방안을 찾아서 평가하고 판단합니다. 여러 선택방안에 차이가 별로 없으면, 가장 먼저 떠오르는 합리적인 방안을 선택합니다. 결정에 따르는 위험부담이 크거나 선택 방안의 본질에 익숙하지 못하면, 여러 대안을 비교 평가하여 판단을 합니다.
(tip: 여러가지 선택방안을 선정할 때, "아무 조치도 취하지 않음"이라는 선택안을 항상 포함합니다.)

선택의 영역을 밝혀준 자료들로 상황을 파악했다면, 정보가 많아져도 구도의 본질은 변하지 않습니다. 즉, 자료가 아무리 많아도 그것이 결정을 해주지 않습니다.

자료의 조작과 오역을 방지합니다. 자료의 근거를 조사하고, 지지하는 증거와 반박하는 증거를 모두 찾습니다. 당사자 또는 해당 전문가와 직접 대화를 나눕니다.

좋은 결정도 나쁜 결과를 불러올 수 있습니다. 따라서 결과만 가지고 결정을 판단할 수 없습니다. (주: 그렇다면 결정의 좋고/나쁨을 어떤 근거로 판단합니까?)

의사결정을 개선하는 두가지 방법: (1) 어려운 결정을 내려봅니다. (2) 결정의 결과에 주의를 기우려 결과 품질을 평가하고 개선점을 파악합니다.

'Theory > Project Management' 카테고리의 다른 글

10장 프로세스, 전자편지, 회의  (0) 2007.03.07
9장 의사소통과 관계  (0) 2007.03.06
8장 올바른 결정 내리기  (0) 2007.03.02
7장 명세서  (0) 2007.02.27
6장 아이디어 관리하기  (0) 2007.02.23
5장 아이디어 내기  (0) 2007.02.21
Theory/Project Management

7장 명세서

명세서는 문서를 만들고 읽는 사람과 현재의 프로젝트에 따라서 여러가지 방식이 있습니다.

명세서는 올바른 제품을 만들게 하고, 계획 수립 단계의 마침표를 찍으며, 관련자들이 검토와 피드백을 내놓도록 도와줍니다.

명세서에 담기는 정보의 다섯 가지 유형은, 요구사항, 기능, 기술 명세서, 작업 항목 록록, 테스트 기준과 중간 목표 종료 기준이 있습니다.

명세서 작성은 한 명이 설계 도중에 시작하며 설계에 대한 이해가 쌓이면서 이를 따라가도록 합니다.

검토와 피드백은 반복적으로 확인하고 개선하는 과정입니다. 이는 명세서의 품질을 정의하고 제어하는 가장 간단한 방법입니다.

팀이 미해결 문제들을 잘 해결할 수 있다고 예측할 수 있다면 명세서를 검토하고 완료할 수 있습니다.

명세서를 완료하면 다음으로 진행하기전에 팀을 재충전하고 전환시키는 것은 좋은 방법입니다.

'Theory > Project Management' 카테고리의 다른 글

9장 의사소통과 관계  (0) 2007.03.06
8장 올바른 결정 내리기  (0) 2007.03.02
7장 명세서  (0) 2007.02.27
6장 아이디어 관리하기  (0) 2007.02.23
5장 아이디어 내기  (0) 2007.02.21
4장 비전  (0) 2007.02.13
Theory/Project Management

6장 아이디어 관리하기

이전에 설명했던 작업은 문제 영역을 키우는 과정이고, 이 글은 가장 나은 설계안으로 문제 영역을 좁히는 과정입니다. 최종적으로 모든 설계 결정을 내리고 명세서로 문서화를 합니다. 이 과정은 점진적으로 이루어져야합니다.

설계의 과정은 반복입니다. 이는 시간이 지나면서 세부 사항을 구체화해 간다는 뜻입니다.

설계 과정에서 발생할 문제를 미리 파악하기는 어렵습니다. 대부분 일단 결정을 내리고 앞으로 나가는 과정에서 문제를 발견하게 됩니다. 따라서 잘못된 결정으로 밝혀지더라도 일단 앞으로 나가야 합니다.

아이디어를 관리하기 위해서 몇개의 점검 지점을 둡니다. 비전과 개념 증명, 아이디어 그룹화/목록, 세가지 설계안, 두가지 설계안, 한가지 설계안, 명세서로 점검 지점을 두는 것을 추천합니다.

아이디어를 관리하는 방법 중에 친화도의 방법이 있습니다. 포스트잇 같은 것을 사용해서 아이디어를 정리하고 팀원들이 그룹별로 그것을 옮깁니다.

아이디어의 우선 순위는 비공식적으로 개략적인 분위기만 파악하는 것이 좋습니다.

프로토타입핑의 각각의 그룹에서 유망한 아이디어를 선택해서 통합하고, 어떤 결과가 나오는지 살펴보는 과정입니다. 프로토타입의 반복할때, 초반에는 큰 아이디어나 폭넓은 변경 탐색에 촛점을 맞추고, 후반에는 설계 영역을 줄이고 결정에 도움이 되는 방향을 나갑니다.

미해결 문제는 엔지니어에게 확인하여 명세서 전에 해결해야 하는지 미뤄도 되는지 판단합니다.

'Theory > Project Management' 카테고리의 다른 글

8장 올바른 결정 내리기  (0) 2007.03.02
7장 명세서  (0) 2007.02.27
6장 아이디어 관리하기  (0) 2007.02.23
5장 아이디어 내기  (0) 2007.02.21
4장 비전  (0) 2007.02.13
3장 할 일을 파악하기  (0) 2007.02.12

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

Today : 38
Yesterday : 75
Total : 199,816