대부분의 기업들은 생산성(productivity)에 대해 관심을 기울입니다. 왠만한 규모의 회사라면 생산성 관련 전문조직을 꾸려놓고 있습니다. 제 주변만 보더라도 팀이름에 "생산성 혁신"이라는 단어가 들어간 팀을 가진 회사가 여럿입니다.
관리자나 임원들은 특히나 생산성에 관심이 많습니다. 생산성은 조직의 실적과도 관계가 높으니까요. (조직의 실적은 본인의 실적이기도 하죠 :)
그러다 보니 때로 어떤 이야기가 나오게 되냐하면
"저 팀(혹은 조직)은 XX 기간 안에 YY 만큼을 해냈는데, 왜 여기는 그렇지 못하느냐?"와 같은 식의 다소 공격적 어조의 발언도 나오게 됩니다. 그러면서 해당 조직의 생산성에 의구심을 표명하다던가, 아니면 증가 방향에 대한 압박을 받게 되죠.
그런데, 사실 많은 사람들이 이야기 하는 "생산성"에는 곧 잘 두 가지의 큰 오해가 있습니다.
첫째. 생산량(output volume)과 생산성(productivity)을 혼동합니다.
타 조직과 비교해 가며 개발 생산성을 높이라고 하지만, 사실 알고보면 생산성이 아닌 생산량을 말하는 경우가 많습니다. "알고봤더니 몇 개월 만에 얼마얼마를 만들어낸 조직은 대부분 늦게까지 일하거나 야근, 휴일근무등등으로 도배가 되어 있었더라"와 같은 이야기는 아주 흔한 이야기입니다. 즉, 우리도 더 많이 일해서 더 많이 만들라는 이야기인데 이건 생산성을 높이라는게 아니죠. 생산량을 늘리라는 이야기입니다. 생산성은 동일한 작업 시간 대비 유효한 결과물을 뜻하기 때문입니다. 오버타임 근무를 할 경우 일반적으로 생산성은 오히려 낮아지게 되어있습니다. 시간내 집중도 및 작업량 대비 결함 발생율이 달라지기 때문입니다. 어떤식으로 달라질런지는 연구논문을 들지 않더라도 쉽게 유추 가능하실 겁니다.
어쨌든 저는 평균 근무시간이 긴 팀일 수록 생상성은 낮은 팀으로 간주해야 한다고 생각합니다. 그리고 그렇게 인식하는 문화를 만들어야 하는 것이 업계가 발전해 나가는 방향이라고 봅니다.
둘째. 소프트웨어는 완성될 한 개를 위해 대부분의 시간과 비용이 쓰이고, 하드웨어는 완성된 시제품의 복제에 대부분의 시간과 비용이 들어갑니다.
(이 항목에 대해 예외나 논란이 있을 수 있다는걸 알지만) 일반적으로 SW는 복제에 비용이나 결함이 거의 발생하지 않습니다. HW는 노력을 기울여 만든 시제품에는 없는 다양한 문제들이 복제단계, 즉 대량생산단계에서 발생해서 비용을 유발합니다. 그리고 이 단계에서의 문제점을 제거하고 효율을 높이는 걸로 생산성을 논합니다. 이건 산업간의 근본적인 차이를 나타내는 중요한 점 중 하나인데, 우리는 곧잘 이 부분에 대한 인식이 희박합니다. 그래서 다른 산업에서 들여온 방법론이 이상하게 현장에선 제대로 적용되지가 않거나 오해해서 적용하기가 쉽습니다. 재고, 복제 불량율, 반품율, 보존기간 등등의 요소가 판이하게 다르니까요. 생산라인 풀가동과 작업자의 두뇌 풀가동이 서로 연관이 없는 산업은 수치화된 생산성 측정과 개선이 훨씬 간단합니다. SW영역은 그렇지 않다는 걸 이해해야 합니다.
만약 한 명의 작업자(=개발자)가 동일한 if문을 하루에 100개 작성했는데, 하루에 200개 만들면 생산성이 두 배로 높아졌다고 보는 것이 공장제 산업기준의 생산성입니다. 당연히 IT영역과는 맞지 않습니다.
그럼 소프트웨어 개발에 있어 진정한 의미로서의 "생산성"을 높이는 방법에는 어떤것이 있는지 알아볼 필요가 있습니다.
그건 다음에 다시 이어서 쓰겠습니다. :)
여담입니다만, 글의 내용을 짧게하고 급 내용을 줄이는 이유는, 제가 요즘 글 쓰는데 살짝 슬럼프 인것도 있고, 또 하나의 글을 쓰기위해 너무 오래 걸려서 몇 달에 걸쳐 지리하게 쓰다 말다 하는 글들이 있어서 그렇습니다. 여기에는 SNS(twitter, me2day)등을 통해 에너지를 곧잘 방출해 버리는 것도 한 가지 이유가 아닌가 합니다.
호흡을 짧게해서, 조금씩이라도 자주 올릴 수 있도록 연습하려고 합니다. 양해해 주세요. (^_^);;
<그림출처>
http://www.ipc.co.ir/64/section.aspx/62
관리자나 임원들은 특히나 생산성에 관심이 많습니다. 생산성은 조직의 실적과도 관계가 높으니까요. (조직의 실적은 본인의 실적이기도 하죠 :)
그러다 보니 때로 어떤 이야기가 나오게 되냐하면
"저 팀(혹은 조직)은 XX 기간 안에 YY 만큼을 해냈는데, 왜 여기는 그렇지 못하느냐?"와 같은 식의 다소 공격적 어조의 발언도 나오게 됩니다. 그러면서 해당 조직의 생산성에 의구심을 표명하다던가, 아니면 증가 방향에 대한 압박을 받게 되죠.
[단지 퍼포먼스를 측정하는 중입니다.]
그런데, 사실 많은 사람들이 이야기 하는 "생산성"에는 곧 잘 두 가지의 큰 오해가 있습니다.
첫째. 생산량(output volume)과 생산성(productivity)을 혼동합니다.
타 조직과 비교해 가며 개발 생산성을 높이라고 하지만, 사실 알고보면 생산성이 아닌 생산량을 말하는 경우가 많습니다. "알고봤더니 몇 개월 만에 얼마얼마를 만들어낸 조직은 대부분 늦게까지 일하거나 야근, 휴일근무등등으로 도배가 되어 있었더라"와 같은 이야기는 아주 흔한 이야기입니다. 즉, 우리도 더 많이 일해서 더 많이 만들라는 이야기인데 이건 생산성을 높이라는게 아니죠. 생산량을 늘리라는 이야기입니다. 생산성은 동일한 작업 시간 대비 유효한 결과물을 뜻하기 때문입니다. 오버타임 근무를 할 경우 일반적으로 생산성은 오히려 낮아지게 되어있습니다. 시간내 집중도 및 작업량 대비 결함 발생율이 달라지기 때문입니다. 어떤식으로 달라질런지는 연구논문을 들지 않더라도 쉽게 유추 가능하실 겁니다.
어쨌든 저는 평균 근무시간이 긴 팀일 수록 생상성은 낮은 팀으로 간주해야 한다고 생각합니다. 그리고 그렇게 인식하는 문화를 만들어야 하는 것이 업계가 발전해 나가는 방향이라고 봅니다.
둘째. 소프트웨어는 완성될 한 개를 위해 대부분의 시간과 비용이 쓰이고, 하드웨어는 완성된 시제품의 복제에 대부분의 시간과 비용이 들어갑니다.
(이 항목에 대해 예외나 논란이 있을 수 있다는걸 알지만) 일반적으로 SW는 복제에 비용이나 결함이 거의 발생하지 않습니다. HW는 노력을 기울여 만든 시제품에는 없는 다양한 문제들이 복제단계, 즉 대량생산단계에서 발생해서 비용을 유발합니다. 그리고 이 단계에서의 문제점을 제거하고 효율을 높이는 걸로 생산성을 논합니다. 이건 산업간의 근본적인 차이를 나타내는 중요한 점 중 하나인데, 우리는 곧잘 이 부분에 대한 인식이 희박합니다. 그래서 다른 산업에서 들여온 방법론이 이상하게 현장에선 제대로 적용되지가 않거나 오해해서 적용하기가 쉽습니다. 재고, 복제 불량율, 반품율, 보존기간 등등의 요소가 판이하게 다르니까요. 생산라인 풀가동과 작업자의 두뇌 풀가동이 서로 연관이 없는 산업은 수치화된 생산성 측정과 개선이 훨씬 간단합니다. SW영역은 그렇지 않다는 걸 이해해야 합니다.
만약 한 명의 작업자(=개발자)가 동일한 if문을 하루에 100개 작성했는데, 하루에 200개 만들면 생산성이 두 배로 높아졌다고 보는 것이 공장제 산업기준의 생산성입니다. 당연히 IT영역과는 맞지 않습니다.
그럼 소프트웨어 개발에 있어 진정한 의미로서의 "생산성"을 높이는 방법에는 어떤것이 있는지 알아볼 필요가 있습니다.
그건 다음에 다시 이어서 쓰겠습니다. :)
여담입니다만, 글의 내용을 짧게하고 급 내용을 줄이는 이유는, 제가 요즘 글 쓰는데 살짝 슬럼프 인것도 있고, 또 하나의 글을 쓰기위해 너무 오래 걸려서 몇 달에 걸쳐 지리하게 쓰다 말다 하는 글들이 있어서 그렇습니다. 여기에는 SNS(twitter, me2day)등을 통해 에너지를 곧잘 방출해 버리는 것도 한 가지 이유가 아닌가 합니다.
호흡을 짧게해서, 조금씩이라도 자주 올릴 수 있도록 연습하려고 합니다. 양해해 주세요. (^_^);;
<그림출처>
http://www.ipc.co.ir/64/section.aspx/62
'이생각 저생각' 카테고리의 다른 글
엔지니어들이 빠지는 일급 함정 #1: 신기술과 엔지니어 (17) | 2011.09.18 |
---|---|
[dW Review] What is Watson ? (2) | 2011.08.30 |
[dW Review] 혁신적인 아키텍처와 창발적 설계: 재사용 가능한 코드 활용하기 #1 (0) | 2011.07.30 |
당신은 애자일 전문가 입니까? (Are you an agile expert?) (2) | 2011.05.30 |
세상을 구하는 용기 (The Courage that save the world) (5) | 2011.03.29 |