#2_1 업무분장에 대해서
분업이란, 단어 앞에서 고리타분이란 생각을 하지 않을 사람은 거의 없을 것이다. 국부론(國富論)의 서두에서 그 본질이 제기되고 18세기 산업혁명을 이끈 장본인이었지만, 고도의 현대화를 이룬 지금, 분업을 전근대적인 경제형태 또는 전문화를 저해하는 요소로 기억하는 것은 당연하다. 하지만, 웹 프로젝트의 실패와 전문성을 떨어뜨리는 요소로 관리와 기획의 통합이 왜? 기술적으로 분리되고 분업화되어야 하는지 고려해보고자 한다.
프로젝트의 분업화에 대한 얘기를 하기 전에 먼저 웹 프로젝트의 회의실로 들어가 업무분장에 대한 생각을 해보도록 하자.
PM : 지난번에 나왔던 이슈사항은 모였지요?
개발팀장 : 멀티 풀다운 메뉴에 대한 카테고리 적용부분입니다.
PM : (회의록을 뒤적이며) 그렇지, 결정이 안났었지요?
개발팀장, 기획팀장 :(동시에) 네...
기획팀장 : 현재 업무단위별로 중복적인 카테고리가 거의 없고, 고객이 효과적으로 서치하기 위해서는 멀티 풀다운 메뉴가 필수입니다. 이론적으로 검토해본 결과 UI 나 웹 프로그래밍중에서 이보다 더 나은 방법은 없습니다.
PM : 그래요.. 흠, 개발팀장님? 이의 없죠?
개발팀장 : (끄덕끄덕)근데, 카테고리 입력은 기획팀에서 해주셔야 해요, 중복 되는 항목도 체크 해야 하고...
기획팀장 : 그건 DB 에서 script 로 일괄 작업하면 됩니다.
개발팀장 : 안돼요, 중복되는 것 때문에...
기획팀장 : 중복 되는거 없다니까요...
개발팀장 : 있을지도 몰라요... 게다가 이게 왜 우리 업무에요? 기획팀에서 확인하면서 넣어야할 업무죠
기획팀장 : 무슨 소리에요? 개발팀에서 하면 하루면 합니다.
개발팀장 : 할 사람 없으니까, 기획팀에서 관리자모듈을 통해서 입력하세요.
PM : ...
기획팀장 : 그럼, 디자인팀에서 하시죠? 안바쁜거 같은데...
디자인팀장 : (졸다가) 네???
프로젝트에서는 분업이란 단어를 분장으로 생각하는 경향이 있다. 위의 대화는 분업이라기 보다 분장에 대한 것으로 프로젝트 중에 흔히 발생하는 경우이다.
웹 프로젝트에서 프로젝트 관리자는 프로젝트 시작단계에서 기획, 디자인, 개발의 3가지 큰 축을 중심으로 팀빌딩을 하게 된다. 이때, 역할 명세서가 있지 않더라도 기본적인 역할을 정의하게 되는데 그건 위에 말한 3가지 큰 축과 다르지 않다. 프로젝트 업무분장은 프로젝트 scope 를 이해하고 있는 관리자가 팀 빌딩의 시점부터 정의해야 하는데 프로젝트 업무분장은 다음과 같은 input, output 을 가져야 한다.
input
- 인력명세서
- 조직도
- 프로젝트 정의서(대략적인)
- 프로젝트 일정표(대략적인)
- 클라이언트 TFT
output
- 상세 업무구분
- 업무 Matching Table > 상세 업무 : 프로젝트 팀원 : 클라이언트 담당자 : 업무별 일정(대략적인)
이러한 Matching Table 은 프로젝트 시작단계에서 관리자의 프로젝트 이해도에 따라 다른 효율성을 발휘하게 되는데, 이 효율성은 프로젝트 진행시 커뮤니케이션의 기초가 되면서 동시에 리스크가 된다. Matching Table 의 리스크는 프로젝트 진행 자체에 심대한 영향을 주게 되는데 이때 프로젝트 관리자가 리스크를 해결할 수 있는 가장 극적인 관리방법은 프로젝트 팀원의 교체로 이어지게 된다.
위의 대화처럼 프로젝트 진행의 업무분장은 단위업무의 수시발생성으로 생겨나는데 단위업무의 발생은 예측불가능한 것이 대부분이어서 관리자는 다음과 같은 input 으로 output 을 제공해야 한다.
input
- 업무의 이해
- 프로젝트 진행표(상세)
- 현재 인력 현황
- 중요도
output
- 업무 / 인력배분 / 일정의 지시
- 프로젝트 진행표 업무 업데이트
프로젝트 진행시 업무분장은 일정에 영향을 주지만, 업무분장의 지시는 빠르고 명확한 것이 좋다. 왜냐하면 업무로 인해 발생하는 일정변동은 전체 일정의 변동이 아니라 마일스톤의 변동으로 볼 수 있고 해당 업무의 분장은 일정관리가 아니라 커뮤니케이션 관리로 불필요한 커뮤니케이션 오류를 생산할 필요가 없기 때문이다.
분업이란, 단어 앞에서 고리타분이란 생각을 하지 않을 사람은 거의 없을 것이다. 국부론(國富論)의 서두에서 그 본질이 제기되고 18세기 산업혁명을 이끈 장본인이었지만, 고도의 현대화를 이룬 지금, 분업을 전근대적인 경제형태 또는 전문화를 저해하는 요소로 기억하는 것은 당연하다. 하지만, 웹 프로젝트의 실패와 전문성을 떨어뜨리는 요소로 관리와 기획의 통합이 왜? 기술적으로 분리되고 분업화되어야 하는지 고려해보고자 한다.
프로젝트의 분업화에 대한 얘기를 하기 전에 먼저 웹 프로젝트의 회의실로 들어가 업무분장에 대한 생각을 해보도록 하자.
PM : 지난번에 나왔던 이슈사항은 모였지요?
개발팀장 : 멀티 풀다운 메뉴에 대한 카테고리 적용부분입니다.
PM : (회의록을 뒤적이며) 그렇지, 결정이 안났었지요?
개발팀장, 기획팀장 :(동시에) 네...
기획팀장 : 현재 업무단위별로 중복적인 카테고리가 거의 없고, 고객이 효과적으로 서치하기 위해서는 멀티 풀다운 메뉴가 필수입니다. 이론적으로 검토해본 결과 UI 나 웹 프로그래밍중에서 이보다 더 나은 방법은 없습니다.
PM : 그래요.. 흠, 개발팀장님? 이의 없죠?
개발팀장 : (끄덕끄덕)근데, 카테고리 입력은 기획팀에서 해주셔야 해요, 중복 되는 항목도 체크 해야 하고...
기획팀장 : 그건 DB 에서 script 로 일괄 작업하면 됩니다.
개발팀장 : 안돼요, 중복되는 것 때문에...
기획팀장 : 중복 되는거 없다니까요...
개발팀장 : 있을지도 몰라요... 게다가 이게 왜 우리 업무에요? 기획팀에서 확인하면서 넣어야할 업무죠
기획팀장 : 무슨 소리에요? 개발팀에서 하면 하루면 합니다.
개발팀장 : 할 사람 없으니까, 기획팀에서 관리자모듈을 통해서 입력하세요.
PM : ...
기획팀장 : 그럼, 디자인팀에서 하시죠? 안바쁜거 같은데...
디자인팀장 : (졸다가) 네???
프로젝트에서는 분업이란 단어를 분장으로 생각하는 경향이 있다. 위의 대화는 분업이라기 보다 분장에 대한 것으로 프로젝트 중에 흔히 발생하는 경우이다.
웹 프로젝트에서 프로젝트 관리자는 프로젝트 시작단계에서 기획, 디자인, 개발의 3가지 큰 축을 중심으로 팀빌딩을 하게 된다. 이때, 역할 명세서가 있지 않더라도 기본적인 역할을 정의하게 되는데 그건 위에 말한 3가지 큰 축과 다르지 않다. 프로젝트 업무분장은 프로젝트 scope 를 이해하고 있는 관리자가 팀 빌딩의 시점부터 정의해야 하는데 프로젝트 업무분장은 다음과 같은 input, output 을 가져야 한다.
input
- 인력명세서
- 조직도
- 프로젝트 정의서(대략적인)
- 프로젝트 일정표(대략적인)
- 클라이언트 TFT
output
- 상세 업무구분
- 업무 Matching Table > 상세 업무 : 프로젝트 팀원 : 클라이언트 담당자 : 업무별 일정(대략적인)
이러한 Matching Table 은 프로젝트 시작단계에서 관리자의 프로젝트 이해도에 따라 다른 효율성을 발휘하게 되는데, 이 효율성은 프로젝트 진행시 커뮤니케이션의 기초가 되면서 동시에 리스크가 된다. Matching Table 의 리스크는 프로젝트 진행 자체에 심대한 영향을 주게 되는데 이때 프로젝트 관리자가 리스크를 해결할 수 있는 가장 극적인 관리방법은 프로젝트 팀원의 교체로 이어지게 된다.
위의 대화처럼 프로젝트 진행의 업무분장은 단위업무의 수시발생성으로 생겨나는데 단위업무의 발생은 예측불가능한 것이 대부분이어서 관리자는 다음과 같은 input 으로 output 을 제공해야 한다.
input
- 업무의 이해
- 프로젝트 진행표(상세)
- 현재 인력 현황
- 중요도
output
- 업무 / 인력배분 / 일정의 지시
- 프로젝트 진행표 업무 업데이트
프로젝트 진행시 업무분장은 일정에 영향을 주지만, 업무분장의 지시는 빠르고 명확한 것이 좋다. 왜냐하면 업무로 인해 발생하는 일정변동은 전체 일정의 변동이 아니라 마일스톤의 변동으로 볼 수 있고 해당 업무의 분장은 일정관리가 아니라 커뮤니케이션 관리로 불필요한 커뮤니케이션 오류를 생산할 필요가 없기 때문이다.
Trackback URL : http://drunkenstar.x-y.net/tt/trackback/57
Trackback RSS : http://drunkenstar.x-y.net/tt/rss/trackback/57
Trackback ATOM : http://drunkenstar.x-y.net/tt/atom/trackback/57
당신의 의견을 작성해 주세요.