[Works] Man/Month
- Life/Essay
- 2018. 8. 17.
반응형
728x90
반응형
Introduction
석/박사 과정을 수행하는 대학원생은 국책과제를 진행 시 과제의 제안서 작성 및 예산편성을 하게 된다. 이때, 각 연구실별로 랩장또는 과제제안서를 작성하는 박사과정이라면 Man/Month에 대해 들어보았을 것이다. 이번 포스팅에서는 Man/Month에 대해 살펴보고자 한다. 오랫동안 대학원 생활을 하면서 그 많은 과제 제안서 및 예산편성과 관련된 자료 및 참여연구원 관리를 하였지만, 제대로 알지 모른 체 서류를 수식과 양식에 맞춰 작성하다 보니 업무의 양이 얼마나 많은지도 모르고 과제를 수행하였다. 그리고 2018년 7월 1일부터 종업원 300인 이상의 사업장과 공공기관을 대상으로 시행됐다. 이에 따라 많은 IT업계에 있는 인원들은 이에 맞춰 적응을 해야 한다. 이 인원들은 관리자뿐만 아니라 그 업무들을 수행하는 실무자도 시간 내에 모든 일들을 완료해야 한다. 앞으로 업무에 대해 어떻게 정리를 해야 할지에 대해 각자 고민을 해야 하는데, 나 또한 그 고민을 하고 있기에 먼저 정리를 해보려고 한다. 도움이 될지는 모르지만, 이글을 보는 다른 분들도 참고가 되길 빌며.
Index
-
Man/Month 란?
-
Man/Day and Man/Hour
-
Man/Month 에 투입되는 인력
-
Man/Month 에 투입되는 인력 계산
-
Man/Month 의 장단점을 사례로 살펴보자
-
Man/Month 에관한 개인적인 사견
Man/Month 란?
-
2017.02.07일자 네이버 지식백과 업데이트 참조
소프트웨어개발 사업의 대가를 계산하는 방식의 하나로 한 사람이 한 달 동안 할 수 있는 양을 계산해 사업비를 책정한다. 즉 사업에 투입한 인력 수를 기준으로 사업비를 책정하는 방식인 셈이다.
인력을 기준으로 사업비를 책정하기 때문에 발주자나 관리자 입장에서는 편리하다. 하지만 투입 인력의 수준과 관계없이 인력의 수에만 초점을 맞추다 보니 소프트웨어의 질을 확보하기가 쉽지 않다는 단점이 있다.
|
** (Man/Month => M/M으로 표기)
** 한글로 편하게 맨머스라고 읽는다.
쉽게 요약하자면 아래와 같다.
-
1 M/M 이면,
-
1명이 한달(22일)간 하면 끝나는 작업이다.
-
2명이 보름(11일)간 하면 끝나는 작업이다. 라고 표현이 가능하다.
-
5 M/M 이면,
-
1명을 투입하면 5달이 걸리는 작업이다.
-
5명을 투입하면 1달이 걸리는 작업이다.
위의 기준은 한사람(Man)이 하루 8시간, 한 달(month) 25일 근무하는 것을 기준으로 한다.
이때, 한 달의 기준은 주5일 x 4주이며, 각종 공휴일은 제외한다. (월 기준은 20일 + a라고 보시면 됨)
Man/Day and Man/Hour
-
Man/Day : 하루에 투입되는 인원
-
Man/Hour : 1시간에 투입되는 인력의 수
Man/Month 에 투입되는 인력
과제(Project)에서 투입되는 인력은 동등할 수 없기 때문에 등급을 분류하고 있다. 등급의 분류는 대학교에서는 아래와 같고, 회사의 경우는 직급에 따라 다르다. 아래의 예시는 온라인에 검색해보면 나오는 IT 기술자들의 등급에 따라 분류하고 있다.
-
대학교에서
-
학사과정/석사과정/박사과정/박사급으로 분류
-
회사에서
-
특급/고급/중급/초급으로 분류
등급산정은 어떻게 계산되는지 모르나, 한국소프트웨어산업협회를 참조하자면, 아래와 같이 분류를 하고 있다.
어느 한 블로그 에서는 아래와 같이 등급을 경력으로 산정하는 것을 보았다.
-
초급1 : 경력 2년
-
초급2 : 경력 3년
-
중급1 : 경력 4년
-
중급2 : 경력 6년
-
고급1 : 박사급
위 블로그에 따르면 해당 분야에서 일정 기간 동안 업무를 수행할 경우 경력으로 인정을 하도록 되어있다. 그 업무를 수행한 기간에 따라 (초/중/고)급 형태로 등급 산정을 하고 있다. 여기에 대해 의문이 드는 부분은 조금 더 뒤에 이야기하도록 하자.
Man/Month 에 투입되는 인력 계산
맨머스에 대해 간략히 살펴보았으니, 실제 과제가 진행될 때, 투입되는 인력을 계산 해보도록 하자. 그리고 계산된 부분에 포함되지 않은 것들이 무엇인지 확인하고 어떤 문제점들이 발생하는지 생각 해보도록 하자.
-
석박사과정은 대학마다 다를 수 있지만, 박사과정 250 / 석사과정 180 으로 작성
-
그외는 위에 명시된 표에서 한달(20일)을 곱하여 계산 / (표에는 한달 근무일을 22일로 명시되어있음)
이때, M/M = 1이란 의미는 다음과 같다.
-
하루(8H) x 한달(20일) = 160H 시간동안 처리하는 업무를 말한다.
즉, 동일한 시간 내에 위 직급/직책 또는 경력에 따라 하는 업무량에 따라 연봉이 달라지는 것이다. 여기에 또 의문점들이 여럿 생기는 부분은 있다 한 번에 정리하도록 하자. 그리고 한 달(160H)동안 업무의 양은 어떻게 판별할까? 경력에 따라 처리할 수 있는 시간 소요가 다르기 때문에 업무에 필요한 리스트를 작성 후 시간을 측정하여 160H가 된다면 1달 치의 업무량이다.
Man/Month의 장단점을 사례로 살펴보자
-
블로그내용 발췌, http://kpopbloging.tistory.com/152=> 블로그의 내용이 복사/붙여넣기가 안되는 관계로 링크를 타고 참조 바랍니다.
#문제점
-
개발자들에 대한 능력에 다한 부분이 구체적이지 않은 상황에 임금이 측정됨
-
문제점
-
시간이 지남에 따라 경력이 될 경우, 개발능력 및 업무의 능력이 향상되지 않더라도 연봉은 많이 받게 됨
-
연구과제의 발주로부터 1차 -> 2차 -> 3차 ->4차 -> 개발자로 넘어오게 될 경우, 각각 산하기관에서 수수료를 가져가고 남은 금액은 하청하게됨, 즉 과제 발주로부터 수주까지 생기는 문제점들이 많음
-
SW기술자등급 폐지 관련, https://www1.president.go.kr/petitions/205936?page=2=> M/M에 관한 자료를 검색 중 발견된 자료
#문제점
-
청원개요
-
정보처리기사 자격증이 없으면 경력 30년이라도 초급을 못벗어남
-
정보러치기사 자격증이 있다고 스프트웨어 개발을 잘한다고 하는 논리는 어디서 나왔는가?
-
문제점
-
기술자 등급 관리가 심할수록 누구에게 이익이고, 등급관리가 약할 수록 누구에게 이익인가? [Link]
-
SW분야 사례(위 링크 내용 발췌)
-
SW분야는 비전공자도 C/C++언어를 배우고 몇년만 지나면 중급/고급 경력자가 됨 => 문제 발생
-
개발 실력 입증은 불가능한 상황
-
사업자 : 값싼 개발자를 쉽게 구할 수 있음즉, 정말 실력있는 개발자는 위 값싼 개발자들에 의해 희생
-
SW분야쪽에서는 다양한 사람들이 존재
-
개발자 / 서버, 클라이언트, Web, 하드웨어, 알고리즘 코어 개발, 등
-
디자이너 / 3D디자이너, 2D디자이너, 및 미술관련분야의 다양한 디자인 세부분야 등
-
기획자 / 기획자는 다른 파트에 대해 전체 다 알고 있어야 한다고 봄.
-
=> 문제점으로, 각각의 분야가 생성이 될때마다 그 인력의 값어치를 판단하기 힘듬
-
참고링크
-
IT벤처에서의 소고, 맨머스 계산은 왜 중요한가? [Link]
-
개발자에게 있어 여유시간이란 무엇인가? 에 관한 내용을 생각하면 글을 읽어보도록 하자
Man/Month 에관한 개인적인 사견
업무를 수행하면서 맨머스를 이용하여 남을 평가하는 일을 해보면서 느낀 점은 다른 곳 어딜가든 이 개념을 가지고 누군가는 나를 평가하려 들 것이고, 나 또한 나보다 뒤에 들어온 후임을 평가하게 될 것이다. 그럼 과연 SW 개발 수준을 과연 M/M으로 평가하는 것이 옳은 것인가? 의문이 든다. 장단점이 분명 있다. 하지만, 누구를 기준으로 M/M이 작성되었는지 알 수가 없다. 그리고 이를 이용하여 연봉측정이 된다는 게 말이 될까?
#학교에서의 문제점
- 대학원에서는 교수님 연구실 아래, 박사과정 및 석사과정의 학생들로 구성이 된다. 이 구성은 근래에 들어 한국인+외국인으로 구성된다. 이 구성 마저 한국인이 점점줄어들고 외국인이 늘어나는 추세이다. 그럼 대학원의 실태는 어떠한가? 교수님의 재량에 따라 연구실 운영되는 부분은 많이 다르다. 하지만, 아직은 변하기 힘든 이상황에서 어떠한 문제가 있는지 이야기를 해보도록 하자.
- 과제(Project) 수행
- 과제를 수행하면, 과제 제안서를 작성하고 이에 대한 예산 및 참여 인력을 작성한다. 참여 인력은 M/M의 틀에 맞춰서 작성하게 된다. 이때, 과제 수행을 위해 참여하는 실제 인원은 몇 명이나 될까? 그리고 PM의 역할은 무엇일까? PM 외 참여 인력의 역할은 무엇일까? 연구과제는 연구를 위해 예산이 사용되는 것이 맞을까?
#초급개발자의 기준에서의 문제점
- 초급개발자라 하면, 비트 프로젝트 학원이나 기타 코딩 및 개발 등을 겸하여 갓 개발이라는 곳에 입문한지 0~6개월 된 인원이라 칭하자. 초급 개발자의 기준에서는 조금만 배우고, 일하여도 위의 표에서 보이는 연봉 (2700만원) 대를 받을 수 있다. 초급 개발자의 입장에서는 나이를 불문하고 IT업계에서 최저연봉이라 부를 수 있는 금액을 받을 수 있다. 그리고 경력 기간 산정으로 시간이 지남에 따라 점차 높은 연봉을 받을 수 있다. 이때, 경력 기간 산정을 기준으로 연봉이 오르는 것이 맞을까? 아니 옳은 것일까? 고민이 된다.
#중급개발자 및 고급개발자
- 초급에서 적어도 3~4년을 수행하였을 경우, 중급이상의 개발자가 될 수 있다. 그럼 중급개발자가 같은 능력을 지니고 있을까? 물론 아니다. 특정 상황에서 3~4년을 하였기 때문에 그 업무와 관련된 일이 아닌 이상 다시 초급개발자와 같은 맘으로 시작해야 한다. 하지만, 소설의 무림고수와 같이 한번 한 길의 끝까지 가본 사람은 다른 길을 가도 시작부터 막힘없이 나아갈 수 있는 차이점이 있다. 문제 발견 시 중고급 개발자가 되면 해결방안을 더욱더 빨리 찾고 그 문제를 해결하게 된다. 이처럼 중급 개발자에 해당하는 인력에 대해, 개발능력을 보는 것이 아니라 그 문제에 대해 해결방안을 모색하는 부분에 대해 더 집중하게 된다. 그럼 중/고급 개발자에서 더 상위로 가려면 무엇이 필요할까? 개발자가 경력이 쌓이다 보면, 이것저것 안 하게 되는 일은 없을 것이다. SW의 기본 틀은 C/C++에 시작해서 사람이 원하는 무엇인가를 위해 API등을 만들고, 그 API를 사용하여 어떠한 제품을 만들어 낸다. 이러한 과정에 있어서 기획자가 되는 게 개발자의 최종 목적지인 것일까?
마무리
하루하루 일을하면서, 내가 어떤분야에서 일을 빠르고 정확하게 처리할 수 있는지 파악을 하기위해 매일 시간마다 체크를 하고 있다. 자기개발서적들을 보면, 많이 나오는 이야기 이지만 정작 실천하기가 힘들다. 하지만, 앞으로 나이가 점점 들어가면서 자신의 업무량을 체크하고 그 일을 분산시켜서 작업을 할 수 있는 능력이 꼭 필요로 하는 것 같다. 지금은 업무량을 분업하는 부분을 잘 못하더라도 하나씩 연습하고 연습하여 조금 더 효율적으로 움직일 수 있도록 할 예정이다. 마지막으로 본 글에서 추가 작성하지 못한 글들은 따로 작성하여 계속 업로드 하도록 하겠다.
Reference
-
블로그(Mon/Month) 참조, http://forgiveall.tistory.com/162
-
블로그 투입인원 등급 산정, Link
-
소프트웨어 개발비 산출공식, http://nberserk.tistory.com/26
-
PERT, TestCase 공수 산정방법, http://egloos.zum.com/choungjae/v/470202
-
표지이미지, 구글링된 이미지사용
728x90
반응형
'Life > Essay' 카테고리의 다른 글
병원 수액을 맞아야 하는 이유? (2) | 2020.08.06 |
---|---|
엘리베이터 앞에서 (0) | 2018.09.26 |