일을 처리하는 한 자세에 관한 일종의 Framework

       

 

 

 

※ 일종의 Idea 하나 :

  

 

ISO 9001 규격 원문을 놓고 씨름하던 시절이 있었지...

그 원문 중에서 "요구사항"과 관련하여서는 대략 다음과 같은 문구들이 적혀 있다.

"규정된 요구사항" (specified requirement)과 "고객의 요구사항" (customer's requirement) 그리고

굳이 9004 규격까지를 더하자면, "의도된 요구사항" (desired requirement) 등이 있겠다.

 

이는 마치 어떤 일을 함에 있어서도 거의 동일한 룰로 적용될만한데, 예를 들자면 그중에서 첫째로 꼽힐만한 것은

역시 "규정된 요구사항", 즉 "스펙"이다. 따라서 모든 일을 시작함에 있어서도 제일 중요한 건 그 일에 대한

"스펙" (혹은 이를 일컬어 scope이라고도 한다.)을 결정짓는 일이다. 사실상 이 시작이 반이다.

그 다음이 "고객의 요구사항", 그 일에 대한 최종고객의 needs를 파악하고 이를 meet하기 위한 노력이다.

마지막으로, 일을 착수하기 전의, 혹은 하는 과정중에 여러 가지 아이디어 (idea)들이 창출 (create)되는데,

이를 일에 add value하려는 노력, 즉 따로 요구되진 않았어도 자발적으로 목표를 삼는 "의도된 요구사항"이

존재할 수 있게 된다. 배보다 배꼽이 더 클 수는 없듯이, 물론 이는 앞의 두가지에 후속하는 성질이긴 하나,

 

대략 위의 세가지 중 앞의 두가지 정도로까지 일들을 처리하게 되면, 예를 들어 이를 KPI score 기준으로 치자면,

약 60~80%의 일은 대개가 성사된 것과 다름없다. (실제로 baseline을 결정하는 logic의 standard는 그렇다.)

부가적으로, value-added된 수준, 즉 "desired requirement"가 나머지 100%를 채우게 된다. 이것까지를

모두 통틀어 "제대로 해냈다"는 평가를 받기 위해 고안된 형태라면, 그게 바로 "well-designed job"인 셈이다.

- 그리고 그 첫 작업의 산출물이, 바로 "Storyline"이다. ("logic"을 고안/검토하기 위한 형태로서의 그것 말이다.)

 

비록 ISO 규격 원문을 감히 원용해가면서까지 일종의 패러다임을 스스로 창출해보고자 하려는 시도(?)쯤이겠지만,

일을 처리함에 있어서는 매사에 이와 같은 뚜렷한 기준 내지 원칙 같은 게 좀 존재했으면 좋겠다는 생각에 몇줄.

- 이게 내가 잠시 생각해본, 일을 처리하기 위한 한 방편 내지는 그것에 관한 일종의 "프레임워크" (framework)다.

   ☞ Framework = 결론적으로, "Scope을 결정짓는 행위" / Storyline = "logic" (according to the "McKinsey")

        ......

 

 

 

---