* 서로 잘 모르는 관계에서 어떤 토의를 하거나, 요구사항 등을 받아들일 때, - 예를 들면, 해외 지사에서, 업무에 불편한 점이 없는지, 도와줄 일은 없는 지 등을 조사할 경우 - 는 반드시 아래의 사항들을 먼저 언급하고 시작해야, 서로간 잘못된 의사소통에 따른 비용을 최소화 할 수 있다.

- 이번 토의/회의 의 명확한 목적

ex: 제안을 받아 들여 달라, xxx를 해 달라 등등

- (제안/요구 를 듣는 입장의 경우) 나의 R&R, 할 수 있는 일과 한계 등.


* Software 업계에서 자주 나오는 이야기 중 "Software중에 '보안'을 이야기할 정도로 정말 가치있는 부분은 얼마 되지 않는다"라는 말이 있다. 수많은 좋은 Opensource software가 넘쳐나는데, 회사의 software중 보안이라는 이름으로 권한을 정밀하게 할 가치가 있는 부분은 얼마나 있을까? 너무 넓은 범위, 정밀한 permission체계는 실무자들에게 쓸데없는 Overhead 및 불편함을 만들 가능성이 굉장히 높다.


* 내가 그 사람의 일(작업)을 control할 수 있는 위치가 아니라면, 가능하면, feedback은 긍정적으로 하자.

ex)

Proposal : '이런 이런' 아이디어가 있고, 이렇게 하면 '이런 이런'게 좋아집니다. 어떤가요?

+ 내가 그 사람의 상관(관리자)라면 : 좋으면 -> OK, 나쁘면 -> NO. 만약 idea가 받아 들이기 힘들다면 NO.. etc.

왜냐하면, 그 사람이 하는 일 및 시간을 관리해야 하는 위치이기 때문에, 필요없는 일을 하는 것들 두고 보는 것은 업무에 도움이 되지 않는다.

+ 만약 내가 3자의 입장이라면 : '이런 이런' 점들이 걱정되지만(뭔가 feedback을 원하는 경우이므로, 내가 관심이 있다는 것을 알려 주기위해 feedback은 해 주어야 한다.), 그렇게만 되면 정말 좋겠군요. 꼭 성공하세요.(마지막 feedback은 항상 긍정적이여야 한다. 나는 불가능하다고 생각하지만, 그 사람은 그것을 정말로 해 낼 수 있을지도 모르기 때문이다.)

나랑 관계없는 사람/일 에 굳이 부정적인 feedback을 주어서, 미움을 살 필요는 없다.


* Project에 대한 발표(Presentation)시, Risk에 대한 언급을 포함하고 있지 않다면 그 발표는 문제가 있는 것이다!

무엇이 문제인지도 모르는(고려해 보지 않은) Project description이 제대로 된 것일리 만무하다.


* Project Schedule이 "꼭 해야만 하는 일"로 꽉 차 있다면, Risk에 대해 전혀 고려되어 있지 않다는 것이다!

Project Schedule에 "꼭 해야하지는 않으나, Risk 완화를 위해 필요한 일"을 위한 시간이 포함되어 있어야 한다.


* Project 완료 시간이 너무 촉박하다면, 그 Project는 너무 늦게 시작된 것이다.(해당 사업계획을 잘못 세웠다는 말이다.)

기획/계획 쪽에서도 책임을 져야한다.







+ Recent posts