혼자서 포석부터 끝내기까지 할 수 있는 작업이 아니라면, 누구든지 '누구로 부터' 작업의 형식 또는 내용을 전달 받게 된다. 우리는 이것을 업자용어로 요구사항, 요건이라고 한다. 웹프로젝트관리방법론을 강의 했을 때, 가장 많은 질문을 받은 섹션도 요구사항정의, 요건정의, 분석 부분이다. Requirement Define 은 3 단계로 진행하는 것이 프로세스다. 1단계 : 명세화, 2단계 : 상세화, 3단계 : 플로우화(도식화) 이다. 소프트웨어 설계 시 데이터베이스나 비즈니스로직을 설계 하는 과정과 크게 다르지 않다. 여기서 문제인식,
첫 번째 문제 인식 : How requirements could be full listed? and then how listed requirements should be break-down?, finally, how many requirements have to convert to form of flow?
첫 번째 문제 인식은 Skill 의 문제로, 탬플릿을 토대로 몸에 익숙해질 때까지 해보는 수밖에 없다. 길(프로세스와 탬플릿)을 가르쳐 주면 해내는 것(Out-put)은 오롯한 것이다. 프로세스와 탬플릿은 형식이다. 형식에는 전문성이 깃든다. 그렇다면 내용은?
더 큰 첫 번째 문제 인식 : Who has charge of this requirement or section?
관리자의 Overview 는 어떤 업무의 90% 이상을 How 로 보지 않고 Who 로 연결하는데 있다. 업무(Work-package)=담당자(Staff)의 일대일 Matching 만을 의미하는 것은 아니다. 관리자에게 지식의 강도는 전문성에 있는 것이 아니라 개념성에 있다. 따라서 관리자는 넓은 지식을 개념화 시킬 수 있고, 개념화된 지식에 동기 부여(Motivation)를 시킴으로써 실제 업무 진행자(Player) 에게 전달하게 된다.
개념화 시킬 수 있는 지식을 가진 관리자는 카테고리를 구성할 수 있고 개별 카테고리에 대한 work-package 를 알고 있다.(알고 있어야 하거나, 공부를 하거나) 먼저 해야 할 일은 각 카테고리와 담당자의 연결이다. 대부분 의뢰인(Client)의 조직은 대리인(Consultant)의 것보다 방대해서 이 연결고리를 찾는 것조차 쉽지가 않다. 일단 연결고리가 되면 관리자의 경험과 기술이 혼합된 커뮤니케이션이 발생하여 업무가 개념화 되기 시작한다. 이것이 요건의 내용이다.
요건의 내용은 앞서 말한 형식에 주입되어 비로서 요건의 셋트가 되고 요건의 셋트는 '요건 정의(Requirement Define)' 가 된다.
한 좌담회에서 '너무 복잡한 프로세스와 형식을 따지는 것 아닌가?' 라는 물음에 이미 오래전에 칸트 선생이 친절히 답을 했다. 통찰(사상)이 아닌 직관을 가지기 위한 요건정의 활동에서 개념이 없으면 맹목이 되고, 개념은 형식(대상이 표상되기 위한 시선, 그리고 문서에서는 항목)의 토대로 부터 비롯된다. Cutting edge 의 현대사회에서 아름다움은 형식으로 부터 깃든다. 하물며, 시각의 자극(아름다움)에 신념을 던지는 사람끼리의 소통에서 형식이 없으면 마음이 아무리 착해도 꼴보기 싫은 법이다. 언제 열길 사람속을 다 들여다 보며 프로젝트를 하나?
첫 번째 문제 인식 : How requirements could be full listed? and then how listed requirements should be break-down?, finally, how many requirements have to convert to form of flow?
첫 번째 문제 인식은 Skill 의 문제로, 탬플릿을 토대로 몸에 익숙해질 때까지 해보는 수밖에 없다. 길(프로세스와 탬플릿)을 가르쳐 주면 해내는 것(Out-put)은 오롯한 것이다. 프로세스와 탬플릿은 형식이다. 형식에는 전문성이 깃든다. 그렇다면 내용은?
더 큰 첫 번째 문제 인식 : Who has charge of this requirement or section?
관리자의 Overview 는 어떤 업무의 90% 이상을 How 로 보지 않고 Who 로 연결하는데 있다. 업무(Work-package)=담당자(Staff)의 일대일 Matching 만을 의미하는 것은 아니다. 관리자에게 지식의 강도는 전문성에 있는 것이 아니라 개념성에 있다. 따라서 관리자는 넓은 지식을 개념화 시킬 수 있고, 개념화된 지식에 동기 부여(Motivation)를 시킴으로써 실제 업무 진행자(Player) 에게 전달하게 된다.
개념화 시킬 수 있는 지식을 가진 관리자는 카테고리를 구성할 수 있고 개별 카테고리에 대한 work-package 를 알고 있다.(알고 있어야 하거나, 공부를 하거나) 먼저 해야 할 일은 각 카테고리와 담당자의 연결이다. 대부분 의뢰인(Client)의 조직은 대리인(Consultant)의 것보다 방대해서 이 연결고리를 찾는 것조차 쉽지가 않다. 일단 연결고리가 되면 관리자의 경험과 기술이 혼합된 커뮤니케이션이 발생하여 업무가 개념화 되기 시작한다. 이것이 요건의 내용이다.
요건의 내용은 앞서 말한 형식에 주입되어 비로서 요건의 셋트가 되고 요건의 셋트는 '요건 정의(Requirement Define)' 가 된다.
한 좌담회에서 '너무 복잡한 프로세스와 형식을 따지는 것 아닌가?' 라는 물음에 이미 오래전에 칸트 선생이 친절히 답을 했다. 통찰(사상)이 아닌 직관을 가지기 위한 요건정의 활동에서 개념이 없으면 맹목이 되고, 개념은 형식(대상이 표상되기 위한 시선, 그리고 문서에서는 항목)의 토대로 부터 비롯된다. Cutting edge 의 현대사회에서 아름다움은 형식으로 부터 깃든다. 하물며, 시각의 자극(아름다움)에 신념을 던지는 사람끼리의 소통에서 형식이 없으면 마음이 아무리 착해도 꼴보기 싫은 법이다. 언제 열길 사람속을 다 들여다 보며 프로젝트를 하나?
Trackback URL : http://drunkenstar.x-y.net/tt/trackback/277
Trackback RSS : http://drunkenstar.x-y.net/tt/rss/trackback/277
Trackback ATOM : http://drunkenstar.x-y.net/tt/atom/trackback/277
당신의 의견을 작성해 주세요.