• Mission / Job / Work / Task

전형적인 상하위 hierachy구조, 피라미드 구조다. 이 구분법은 “그 일은 너무 중요하지 않아.” 혹은 “그 일은 너무 높은 곳에 있어”와 같이 현실적으로 오늘 당장 집중해야 하는 일과 그렇지 않은 일을 구분할 때에 자주 쓰인다. 또는 미래 계획을 세울 때에 너무 구체적인 실행단계로 빠져들지 않기 위해 사용되기도 한다. 실행에 집중해야 할 때에 근원적인 철학적 질문을 던지는 것을 막아야 할 때에도 도움된다. 하지만 일의 계층을 구분하고 레벨을 구분하는 것은 추상적으로 도움될 뿐, 실무에 바로 적용하기 어렵다.

• 일의 단위화

일을 Chunk로 만들어낸다는 것은, 그 일의 시작부터 끝까지가 모두 파악된 상태라는 것이다. 일에 대한 파악은 [현황파악 > 문제정의 > 해법제시 > 실행방안] 네 단계로 진행한다. 지금 비드폴리오의 구성원들과의 협업관계에서는 일을 Chunk단위로 만드는 단계가 생략되어 있다. 현 구성원들은 일을 Chunk로 만들어내지 못한다.

Chunk를 만들어내지 못한다면 [현황파악 > 문제정의]을 제시해야 한다. 현황파악은 누구나 할 수 있다. 불평에 불과하기 때문이다. 이렇더라, 저렇더라. 보이는 대로 씨부리면 그것이 현황파악이다. 현황과 문제를 구분하는 이유다. 우리가 풀 수 있는 문제, 풀어야 하는 문제를 구분해야 한다. 문제를 구분해내지 못하는 단계에서 현황만 지껄여대는 것은 도움 되기는커녕 정보의 공해를 만들어 훼방을 놓는다.

때문에 정의되지 않은 현황, 정의된 문제, 완성된 Chunk의 과업은 모두 구분되어야 한다. 현황은 쏟아 내고 끄집어 내야 한다. 문제의 정의는 파고들어야 한다. 각각의 행위가 다른 것임을 인지할 수 있어야 하며 구성원들의 role playing도 정의되어야 한다. 업무 논의, 기록 공간 또한 각 행위에 최적화되어 마련되어야 한다.

완성된 Chunk의 과업은 따질 게 많다. 완성된 일의 성과가 얼마나 큰지, 소요 자원은 얼만큼 들어가는지 input과 output을 비교해 가치를 판단한다. 해법이 얼마나 적합한지도 따져야 한다. 실현가능성이 얼마나 높은지도 따져야 한다. 해당 일을 담당하는 사람의 역량도 따져져야 한다.

• 로드맵을 짭니다.

실행하는 사람의 로드맵은 실행자 각자 짜여져 있어야 합니다. 실행자의 로드맵이 없는 상황에서 상관, 상부 관리자는 어떤 판단과 지시를 내리기 어렵습니다. 로드맵의 부재는 부하의 문제입니다.

• Priority Management

상관은 종합적으로 판단합니다. 부하는 판단기준과 판단방법을 배웁니다. 상관의 판단과 부하가 판단이 일치해지는 시기를 앞당기기 위해 상호 노력합니다.

• 중요하지 않은 문제로 빠지지 않습니다.

[문서냐 이메일이냐 노션이냐 GDSS냐 카톡이냐 대면맞짱이냐 커피타임이냐 이면지낙서냐 단체회의냐 좌장주도지시냐 상명하복하달이냐 실무자의바텀업이냐 브레인스토밍이냐 연구조사냐 R&D냐 정보취합이냐 데이터기반통계냐 머신러닝이냐 MECE냐 귀납이냐 연역이냐 린스타트업이냐 해커톤이냐 역할게임이냐 OO학원이냐 스프린트냐]에 상관없습니다. 그건 그저 매개체일 뿐입니다. 실행방안의 극히 일부일 뿐입니다. 방법일 뿐입니다. 도구일 뿐입니다. 뭐든 어떤방식으로 하든 문제가 문제해결의 틀에 맞춰져야 합니다.