출처: http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=28&no=126&page=1

제목이 좀 도발적이죠?

이글의 실제 내용 "Quick-Kill Project Management"와 제목을 연관시키려다 보니 이렇게 되었네요.

얼마전 여기 Devpia에 링크되어있는 "노땅엔지니어의 노트"에서 본 것 같은데, 우리 나라의 낮은 개발자 처우, 너무 과도한 프로젝트와 빡빡한 일정 이런 것 어떻게 바꿔야 하지 않겠는가 하는 글을 읽은 적이 있었습니다.

물론 처우개선할 것은 해야 하지만 현실이 쉽게 바뀌지 않는다면 우리 자신이 이런 상황을 타개해 나가야 하지 않을까요?

"Quick-Kill Project Management"이라는 기사를 인터넷에서 읽고 과중한 프로젝트 압박은 비단 우리 나라에만 있는 것은 아닐성 싶었습니다.

필요는 발명의 어머니라고 하지 않았던가. 이 지구상의 수많은 사람들중 어떤 한 사람이라도 같은 고민을 하고 있을 겁니다. 그리고 운 좋으면 해결책까지 이미 가지고 있고요. 요즘 뭐 개발 하라고 하면 인터넷에 비슷한 소스 있나 먼저 찾아보는 이유도 다 이런 범주에 속하겠죠.

이 글은 말그대로 성공적인 프로젝트 수행을 위한 빠른 프로젝트 관리 기법을 소개한 글입니다. 개발 5년차가 넘어가서 이제 프로젝트 관리까지 담당을 해야하는 개발자 겸 책임자에게 도움이 될 것 같아 이렇게 올립니다.

꼭 기법을 배우지 않더라고 글 중간중간에 닥치는 상황과 고민이 어쩜 나하고 같지 하는 공감을 불러 일으키리라 봅니다.

영문 원문을 바로 읽으시려는 분은 http://www.ddj.com/architect/189401902 로 가시면 됩니다.

이곳에 있는 것을 좀 서투른 영어지만 성심껏 번역했습니다.

번역본 word 파일이 필요하시면 제 블로그에서 가시면 있습니다.

자!! 이 부분부터 번역한 글입니다.

__________________________________________________________________________________________

빠른 처리(Quick-Kill) 프로젝트 관리

 극히 불가능한 일정에 직면했을 때 조차 현명하게 소프트웨어를 개발 하기

 저자:  Andrew Stellman and Jennifer Greene

작성일: 30, 2006년 6월 30

출처: Dr. Dobb's Journal(http://www.ddj.com/dept/architect/189401902)

 앤드류와 제니퍼는 “Applied Software Project Management (O'Reilly & Associates)” 책의 저자이다.

 당신이 다섯 명으로 이루어진 개발 팀 리더라고 하자. 한 프로젝트에 몇 주 동안 매달린 결과, 팀이 막 결과물을 내놓기 시작했다. 팀은 경력상으로 고참 설계자로부터 학교를 갓 졸업한 초보 프로그래머에 이르기까지 다양하게 구성되었다. 그때 당신의 상관이 당신을 불러 부사장이 전화로 자기를 씹어대며 어제까지 그 프로젝트가 끝났기를 바랬다고 말한다. 알려진 바와 같이 이 프로젝트는 확연히 드러나고 오랫동안 약속된 것이다. 고객은 이 소프트웨어로 처리할 일이 있고 이 소프트웨어는 매우 중요하다. 만약 이게 잘 안 돌면 당신은 옷 벗을 생각을 해야 한다.

 일전에 이런 종류의 높은 압박 속의 팀에 있었다면 그 프로젝트는 악몽이었을 것이다. 팀원들이 몇 날을 헤매고 있고 당신은 영웅 역할을 해야 해서 심각한 설계 오류를 고치기 위해 뛰어 들어가 주말 40시간 일을 한다. 고참 관리자와의 끝없는 회의와 결코 없어지지 않는 끈질긴 버그들과 야밤의 너무 많은 커피와 피자가 있다. 그리고 마침내 팀이 어떤걸 내놓자, 고객은 그것을 싫어한다. 그들이 버튼을 누를 때 마다 버그가 있고 그들이 기대했던 어떤 것도 그 소프트웨어 전체 기능 안에는 전혀 구현이 안된 것처럼 보인다.

빠른 처리(Quick-Kill)

요즈음 많은 팀들은 이런 상황에 놓여있고 개발 책임자는 심각한 도전에 직면해있다. 그는 직접적으로 그의 팀을 관리할 필요는 없지만 그 소프트웨어가 출시될 수 있게 하는데 책임이 있다. 팀은 그를 존중하고 그가 결정 하면 사람들은 보통 그를 따른다. 그렇지만 개발 책임자의 일은 관리가 아니라 개발에 있다. 그는 솔루션과 소프트웨어 설계와 코드를 작성하는데 대부분의 시간을 보낸다.

 이상적인 프로젝트 관리는 전담 프로젝트 관리자가 있거나 아주 많은 프로젝트 준비 시간을 필요로 한다. 하지만 당신이 팀을 이끌고 있고 올바른 프로젝트 관리를 위한 시간도 예산도 없다면 어떻게 하겠는가? 이런 자리에 있는 사람이 어떻게 시작해야 하는지 조차도 어려운 일이다. 이것이 “빠른 처리(Quick Kill)”의 탄생 배경이다 – 프로젝트에서 가장 큰 문제들만을 처리하기 위한 아주 범위를 좁힌 시스템. 다르게 말하면 프로젝트 책임자들에게 가장 적은 비용으로 큰 이익을 얻게 하는 행동 강령이다.

 빠른 처리(Quick-kill) 프로젝트 관리는 상관이 기대하고 고객이 필요로 하는 제품이 산출될 수 있게 돕는 세가지 기술로 구성된다.

• 비전과 범위 문서(Vision and scope document)

• 작업 세분화(Work breakdown structure)

• 코드 검토(Code review)

위의 각 기술을 실행하는 데는 시간이 얼마 걸리지 않고 팀이 대부분의 일반적이고 큰 비용을 치러야 하는 프로젝트의 큰 위험을 회피할 수 있게 한다. 이것들을 사용하여 책임자는 만족스러운 소프트웨어를 만들 수 있는 확률을 여러모로 높일 수 있다.

비전과 범위 문서: 최대 6시간

만약 팀이 어떤 소프트웨어를 만들고 있는지를 실제 이해하지 못하면 프로젝트 전 과정에 걸쳐 잘못된 결정들을 내릴 소지가 더 농후하다. 팀은 이러한 잘못된 결정들을 고치기 위해 귀중한 시간을 허비해야 하거나 만약 고치지 않고 남겨 프로젝트가 고객의 필요를 충족하지 못했을 때 고객에게 사정해야 할 상황에 놓이게 된다. 프로젝트 실제 범위에 대한 올바른 이해 없이 팀은 촉박하다는 것만을 보게 되고 그들이 채워야 하는 요구 사항에 대한 궤도를 잃게 된다. 프로그래머들은 큰 그림을 보지 못하고 그들이 해결 하고자 하는 일의 개별적인 문제만을 볼 수 있다. 그리고 이것은 프로젝트 실패와 지연을 야기시키는 가장 큰 단일 원인이다.

다행히도 팀이 이러한 문제를 회피하게 만드는 간단하고 실행에 옮기기 쉬운 것이 있다. 비전과 범위 문서를 작성하는 데는 하루가 안 걸리고 이는 팀이 몇 주의 재 작업과 잘못된 시작을 하지 않도록 하는데 도움이 된다.

비전과 범위 문서 작성의 첫 번째 단계는 프로젝트 관계자와 이야기 하는 것이다. 불행히도 누가 관계자인지 항상 분명한 것은 아니다. 프로젝트 책임자는 어떤 사람이 그 프로젝트에 의해 가장 영향을 받을 지를, 그것을 그가 사용하는 것을 계획했기 때문인지 또는 개발 되는 것에 대한 다소 책임이 있기 때문인지를 파악해야 한다. 바꾸어 말하면 책임자는 그 소프트웨어가 개발이 안되었다면 누가 가장 어려워질 건지를 찾아야 한다. 개발 책임자가 또는 가능하면 다른 팀 구성원들까지도 관계자들과 꼭 해야 할 일이다. 이러한 요구 사항을 수집하는 것은 관계자 한 사람당 한 시간이 안 걸릴 것이다.

비전과 범위 문서(표1)는 몇 페이지가 넘지 않게 간단해야 한다. 관계자들과 대화를 통해 팀이 수집한 모든 정보는 문제 서술 장(Problem Statement section)에 추가되어야 한다.

표 1: 비전과 범위 문서 윤곽

 프로젝트 배경 장은 그 프로젝트가 해결해야 할 문제를 요약한다. 문제의 간단한 이력과 어떻게 그 조직이 그 문제를 다루기 위한 소프트웨어 개발을 결정했는지에 대한 설명을 제공해야 한다.

 프로젝트 관계자 장에는 관계자들을 기술한다. 개개의 관계자는 이름, 직책 또는 역할(지원 부서 관리자, SCTO, 선임 관리자)에 의해 언급될 수 있다. 각 관계자의 요구 사항은 몇 문장으로서 기술된다. 사용자 장은 사용자들 목록을 포함하여 비슷하게 작성된다. 관계자들에 대해 했던 것 같이 각 사용자도 이름 또는 역할(고객지원 상담자, 통화 품질 감사, 가정에서 사용하는 웹 사용자)에 의해 언급될 수 있지만 만약 많은 사용자가 있다면 각 사용자를 지칭하는 것은 보통 비효율적이다. 각 사용자의 요구사항은 기술된다.

 사용자와 관계자의 요구 사항은 이 문서에서 가장 중요한 부분이다. 팀이 그 프로젝트를 이끄는 요구 사항을 이해하지 못하면 관계자들에게는 사소한 문제를 처리하기 위해 팀의 시간을 소모시키는 원인이 되는 지협적인 초점에 매달릴 수 있다. 잘못된 문제를 해결하는 거대한 소프트웨어를 만들기는 쉽다. 적절한 소프트웨어를 만들기 위한 단 한가지 방법은 일이 시작되기 전 왜 어떻게 소프트웨어가 만들어져야 하는지에 대해 프로젝트 참여자의 모든 사람의 이해와 동의를 구하는 것이다. 이것이 프로젝트 계획의 목적이다.

 비전과 범위 문서의 비전 부분은 소프트웨어의 최종 목적에 대한 설명을 일컫는다. 모든 소프트웨어는 특정 사용자와 관계자의 요구를 충족하기 위해 만들어진다. 팀은 그러한 요구 사항을 식별하고 비전 기술서(어떻게 그런 요구 사항이 충족될 것인지를 설명하는 비전 기술서)를 작성해야 한다. 비전 기술서 장의 최종 목표는 성취하기 위해 무엇이 프로젝트에 기대되는가를 기술하는 것이다. 프로젝트의 목적이 설명되어야 한다. 이 목적은 프로젝트에 소비되는 시간, 돈, 자원에 대한 필수 불가결한 이유와 합당한 타당성이 있어야 한다.

 "기능 목록"과 "개발에서 제외된 기능" 장들은 무엇이 구현되고 구현되지 않을 것인지에 대한 정확한 목록을 담아야 한다. 이 장들을 쓰기 전에 팀은 문서 나머지 부분을 작성해야 하고 충족시키고자 하는 요구사항에 대해 열린 회의를 해야 한다. 팀은 종종 확실해 보여서 어떤 기능을 도출하지만 실제 필요하지 않는 것으로 판명이 되는 것이 있다. 이와 같은 기능들은 "개발에서 제외된 기능"에 기술해야 된다.

작업 세분화 구성(Work breakdown structure):  2 시간

 만들 기능들에 대해 작업 들어가기 전에 책임자는 팀과 함께 각 기능을 구현하는데 얼마가 소요될 것인가 하는 추정 목록을 마쳐야 한다. 많은 개발자들은 추정을 크게 어려워한다. 다행히도 추정 단계를 보다 직관적이고 신뢰성 있게 만드는 다소의 지침들이 있다.

 추정 단계는 팀 구성원이 프로젝트의 모든 관점을 생각하게끔 하는 것으로 중요하다. 대부분 프로그래머들은 그들이 예측 했던 작업량보다 나중에 더 일이 많음을 알게 될 때 위축되게 된다. 만약 다른 팀 구성원이 그 일에 의존하고 있다면 전체 프로젝트에 혼선이 일 것이다. 올바르게 추정하는 것은 팀이 모든 현격하고 일반적인 실패를 회피할 수 있도록 한다. 프로젝트 추정은 끝마치기 위해 필요한 절차와 각 절차가 요구하는 처리가 몇 일(주, 달, 시간 등등) 걸릴 것인지를 팀이 미리 도출하게끔 만든다. 이러한 단계와 소요 시간을 구하기 위한 유일한 방법은 하지 않으면 프로젝트 후반에까지 남겨질지 모르는 많은 상세한 사항들을 한 팀으로써 모여 앉아서 생각하는 것이다.

 추정하기 위한 첫 번째 단계는 그 프로젝트를 최종 제품에 포함될 작업 목록으로 쪼개는 것이다. 이 목록을 “작업 세분화 구성(work breakdown structure: WBS)”라고 부른다. 프로젝트를 “작업 세부화 구성”으로 나누는 여러 방법이 있다. 책임 개발자는 팀원들과 이 작업 목록을 토의할 회의를 가져야 한다.

 가장 유용한 법칙은 어떤 프로젝트라도 10에서 20개의 작업으로 쪼갤 수 있다는 것이다. 예를 들어 우주선 프로젝트와 같이 큰 프로젝트의 작업들은 “항해 시스템 시험”과 같이 아주 클 것이고 간단한 계산기 작성 같은 작은 프로젝트는 “덧셈, 곱셈, 두수의 곱셈을 위한 산술 객체의 제작”과 같이 작업들이 작을 것이다. 팀원들과 작업 목록에 대해 회의는 한 시간이 안 걸려야 한다.

 일단 팀 구성원들이 “작업 세분화 구성”에 동의하면 각각에 대해 추정할 수 있도록 각 작업에 대한 토의를 시작할 수 있다. 프로그램 초기 단계에는 팀 구성원들이 추정에 필요한 모든 정보를 갖지 못했지만 어쨌든 수치를 뽑아내야 한다. 부족한 정보를 메우기 위해 할 일에 대한 가정 해야만 한다. 가정 했으므로 팀 구성원은 보다 정확한 추정을 나중에 추가하기 위한 정보에 대해서는 표시를 남길 수 있다.

가정은 추정에 있어 매우 중요한 요소이다. 만약 두 사람이 얼마나 걸릴 것인가에 대해 동의하지 않는다면 그 원인은 일의 세부적인 내역 또는 그것을 도출하기 위한 전략에 대해 서로 다른 가정을 했다고 할 수 있다. 달리 표현하면 이 의견 차이는 보통 그것을 끝내기 위해 들인 노력에 관한 것이 아니라 그 일 자체를 하기 위해 무엇이 필요한 것인가에 관계된다. 예를 들어 컴퓨터 시간을 설정하는 툴에 대한 비전(vision)과 범위(scope) 문서를 주면 두 개발자는 아주 다르게 추정할 수 있다. 한 개발자는 간단한 명령 입력 방식이라고 생각하는 반면 다른 개발자는 운영 체제의 제어판과 완벽하게 통합되는 사용자 인터페이스를 가져야 한다고 가정할 수 있다.

 책임자는 다른 프로그래머들이 이러한 가정들을 의논하게 하고 그들의 다른 견해에 관해 임시적인 결정을 하게 함으로써 그 작업에 대한 하나의 추정에 동의하도록 도울 수 있다. 책임자는 차례로 각 작업을 꺼내고 각 작업에 대해 팀이 얼마나 걸릴 것 인가를 결정하게 해야 한다. 의견 차이가 발생할 때 마다 가정하는데 있어 무언가를 놓치고 있는 것을 의미한다. 책임자는 그 가정들이 무엇인지를 정확히 밝히기 위해 나머지 팀 구성원과 같이 처리해야 한다. 이것들이 밝혀지면 기록해야 한다. 회의가 진행 될수록 더 많은 가정들이 쓰여지면 팀 구성원들은 그 프로젝트에 관해 더 많이 알게 된다. 그리고 어떤 소프트웨어를 만들어야 할지를 토의 할 것이다. 이것은 그 팀이 각 작업에 대한 추정들을 취합하게 돕는다.

 최종 “작업 세분화 구성”은 작업 목록과 각 작업에 대한 추정, 작업에 대한 가정한 목록으로 구성 되야 한다. “작업 세분화 구성”의 10에서 20개의 작업에 대한 가정과 추정을 도출하는데 대략 한 시간이 소요 되야 한다. “작업 세분화 구성”을 만들고 예측을 하는 총 시간은 보통 두 시간 정도이다. 보통의 다섯 사람이 하는 프로젝트의 기본 추정 시간으로서는 충분하다. 그렇지만 큰 프로젝트이면 팀을 나눌 필요가 있고 각 나뉜 팀은 두 시간씩의 추정 시간을 가질 수 있다.

코드 검토: 한 검토 건수당 2.5 시간

 코드 검토란 팀이 샘플 코드를 검사하고 거기에 오류가 있으면 고치는 것이다. 오류라고 하는 것은 프로그래머가 의도하는 대로 동작하지 않거나 잘못되지는 않았지만 개선될 수 있는 여지가 있는 것을 일컫는다. 예를 들자면 보다 가독성 있게 만들거나 성능이 향상될 수 있는 것이라 할 수 있다.

 코드 검토의 첫 번째 작업은 검토할 샘플 코드를 선택하는 것이다. 코드 전체 줄을 검토하는 것은 불가능 함으로 프로그래머는 검토할 코드 부분을 선택할 필요가 있다. 검토에 적당한 코드를 선택하면 보다 효율적인 검토작업이 된다. 대부분의 프로젝트에서 밝혀진 바로는 대부분의 오류는 비교적 작은 코드 조각에 집중되는 경향이 있다. 코드가 잘 선택되면 이 검토는 만약 남겨진다면 나중에 그것을 찾아 고치는 비용보다는 훨씬 적게 들게 된다.

 책임 개발자에게 검토를 위한 적당한 코드를 선택하는 일을 어렵지 않다. 좋은 검토 후보 코드는 이상한 알고리즘을 구현하거나 어려운 API 또는 객체 인터페이스를 사용한 것, 유지보수하기 위해 전문 기술이 요구되는 것, 새로운 기술을 수용한 것이 될 수 있다. 오류가 있으면 큰 재앙을 불러일으킬 위험이 큰 부분의 코드를 선택하는 것은 특히 유용하다. 보다 더 많은 오류가 있을 성 싶어서가 아니라 보다 많은 사람들이 전적으로 그것에 의존할 수 있기 때문이다. 소프트웨어 많은 부분에 큰 변경을 요구하는 큰 수정이 있으면 오류를 불러일으킬 위험이 높다. 이런 코드 또한 좋은 후보이다.

 검토를 준비하기 위해 책임자는 줄 번호가 있이 인쇄한 선택한 코드를 각 팀 구성원에게 배포한다. 팀 구성원 각자는 개별적으로 샘플 코드를 한 시간 반에 걸쳐 가능하면 실행도 해보면서 읽는다. 그들은 작성자가 하고자 한 의도대로 코드가 진짜 동작하는지 밝히기 위해 최선을 다해야 한다. 그들은 정확성, 유지보수, 신뢰성, 견고함, 보안, 확장성, 재 사용성, 효율성에 문제가 있는지 찾아야 한다. 이것 중 어떤 것이라도 오류로 간주된다. 각 팀은 최대한 많은 오류를 찍어내어 복사본에 표시한다.

 각자의 준비가 끝나면 팀 책임자는 검토회의를 위해 모두 모은다. 코드 검토는 책임 개발자가 큰소리로 최초의 코드 조각을 읽는 것으로 시작된다.  그는 말 그대로 코드에 쓰여진 명령을 읽는 것이 아니라 코드 조각의 목적에 대해 간단한 설명을 한다. 만약 책임자를 포함해서 누구라도 코드가 뭐 하기 위한 건지 이해하지 못하거나 그 해석에 동의하지 않으면 코드 작성자가 그 코드가 어떤 것을 이루기 위함이었는지 설명한다. 종종 팀 구성원이 동일한 것을 구현하기 위해 보다 좋은 제안을 할 수 있지만. 문제 제기한 사람에게 단순히 코드의 목적을 설명하는 정도이다.

 팀 구성원은 그 다음에 코드 조각에서 발견된 모든 오류에 대해 의논한다. 바로 이 지점에서 책임자가 회의 사회자로 나서야 한다. 만약 누구라도 오류를 발견하면 책임자는 그 시점에서 고칠 건지 여부를 결정한다. 책임자가 구성원들이 고칠 수 있다 판단되면 그렇게 한다. 그렇지 않으면 책임자는 코드 작성자가 나중에 고쳐야 할 문제점으로 기록한다. 어떤 경우든 책임자는 검토이력을 담는 스프레드 시트 한 행을 추가해 기록한다. 스프레드 시트에 한 오류당 한 행을 작성하며 각 행은 오류를 가지고 있는 줄 번호, 누가 발견했는지 어떻게 해결했는지 또는 아직 해결이 안된 문제라는 표시를 담는다.  사회자는 이 이력의 위 부분에 언제 회의가 있었고 어떤 조각의 코드를 검토했는지 적어야 한다.

 이 회의는 두 시간을 초과해서는 안 된다. 만약 이것보다 더 걸리면 다음 코드 검토에서는 더 간단한 샘플 코드를 선택해야 한다. 만약 회의가 끝나면 책임자는 나머지 팀원에게 검토 이력을 이메일로 보내고 해당 코드에 책임이 있는 사람에게 수정을 지시한다. 오류가 수정된 후 그는 수정된 코드를 검토하고 잘 고쳐졌는지 확인해야 한다.

상습적으로 고민거리를 말하고 다닌다.

주어진 일을 하다보면 크고 작은 고난에 부딪치게 마련, 누구나 고민은 한다.
하지만 고민하더라도 입 밖으로 내색하지 말라.
고민이 되든 안되든 어차피 당신이 풀어야 할 일이다.
특히 당신이 상습적으로 고민을 풀어놓는 대상이 당신에게 실질적인 도움을 주지 못한다면 더욱 입을 다물어야 한다.
당신의 잦은 푸념은 결국, 내 능력은 이것밖에 안돼!! 라고 광고를 하고 다니는 격이되고 만다.


모르는 것은 일단 묻고 본다.

모르는 것은 죄가 아니다.
또한 원활한 업무 진행을 위해서라도 모르는 것이 있으면 분명히 짚고 넘어가야 한다.
잘 모르는데 설명을 듣고도 이해하지 못했는데도 무시당할까봐 쑥스러워서 등의 이유로 넘어가는 것은 위험한 일이며 더 큰 실수를 부를수 있다.
모르는 것이 있다면 마음 속에 진정 의문이 있다면 씩씩하게 물어봐야 한다.
그러나 질문의 내용이 사실 확인이 아닌 방법이나 방안에 관한 것이라면 생각도 해 보기전에 일단 묻고보자는 태도가 문제가 있다.
무엇인가를 누군가에게 묻기 전에 적어도 당신 스스로 해결할 수 있는 방법을 두 가지 이상 찾아보라. 질문은 그 뒤에 해도 늦지 않다.
질문의 절제 역시 당신의 능력을 인정받는 하나의 전략이 될 수 있다.


이유를 밝히지 않고 맞장구를 친다.

왜 좋은지에 대한 구체적인 이유가 서지 않는다면 남의 의견에 함부로 동조하거나 맞장구치지마라.  일이 잘되면 상으로 주어지는 몫은 의견을 낸 자에게만 돌아가지만 반대로 일이 안 풀리면 (당사자 혹은 함께한 팀원으로부터) 변명이나 원망의 대상에 당신마저 포함될 수 있다.


네!! 라는 답을 듣고도 설득하려 든다.

동조와 허락을 받아낸 것에 대해서는 더 이상 설득하려 들지 마라.
정말 그래도 되는지 그로인해 당신에게 돌아올 불이익은 없는지 등을 두고 애써 당신의 처지를 설명하고 재차 동조를 구하는 것은 적극적이지 못하고 소심하다는 인상만을 남길 뿐이다.  공감을 얻어야만 안심하는 습관을 버려야 한다.


죄송해요. 라는 말을 남용한다.

죄송합니다. 몰랐네요..라는 말을 자주 쓰는가?
죄송하다는 말은 자신의 잘못이나 실수를 인정하는 말이다.
일처리 과정에서 만약 정말 당신의 잘못이 있다면 죄송하다는 애매한 말 대신 왜 그런실수가 일어났는지 그래서 어떻게 해야하는지 상황부터 설명하고 그렇지 않은 경우에서는 죄송하다고 말하지말라.
습관적인 죄송은 배려로 받아들여지지 않고 오히려 상대방에게 내가 무관심하다는 것을 보여주는 것임을 명심해야 한다.


스스로 함정에 빠지게 하는말. 그럼..제가 해볼게요.~

조직 내에서 가장 끔찍한 상황은 공식화되지 않은 책임을 수행해야 될 때이다.
당신은 모든일을 처리하기 위해 조직에 있는 것이 아니며 조직역시 당신에게 그런 기대를 하지 않는다.
그러나 당신이 당신 업무 외적인 일에 자주 나선다면 조직은 그걸 당연시하게 된다. 그만큼 당신이 가치를 발할 기회가 줄어드는 것은 당연하다. 무언가 당신이 그일을 함으로써 당신에게 내적이든 외적이든 도움이 된다고 판단될 때만 나서라.
우선 당신에게 주어진 업무를 분류해보자.
당신이 반드시 끝내야 하는 일 당신이 하면 좋지만 반드시 하지 않아도 되는 일, 당신이 하지 않아도 상관 없는일이 있을 것이다.
이중 세번째 업무는 머리속에서 지워라.
제일 우선시해야 할것은 당연하게 첫번째 일이다.
바로 이일에 모든 역량을 집중하고 쓸데없는 일에는 시간을 낭비하지 말라는 말이다.
두번째 업무는 첫번째에 가까우면서 당신에게 이로운 것을 가려서 취사선택하라.


부정적 의견을 되묻는다.

조직은 각양각색의 사람이 모인 곳이다.
당연히 업무상 의견차가 있을 수 있고, 당신의 생각이나 행동이 상대의 마음에 들지 않을수도 있다.
당신이 당신 스스로에 대해 혹은 업무에 대해 확신이 선 상태에서 일을 추진할 경우 태클 세력들에 대해 왜요? 뭐가 잘못됐죠? 하고 되묻지말라.
쓸데없는 감정 노출로 경계심을 살 필요없이 결과로만 말하면 될일이다
 

출처: http://blog.daum.net/hdjy1024/9477008