Talk about Software with hani

전자 제품을 만들기 위해서 여러 전문 분야의 사람들이 공동으로 작업을 해야 합니다. 즉, 마케팅, 영업, 디자인, 회로설계, 기구설계, S/W설계, 양산팀, 품질 검사팀 등 직접 언급은 하지 않았지만 이외에도 다양한 분야에서 전문성을 가진 사람들의 협업이 필요합니다. 그런데 문제는 이렇게 다양한 분야의 사람들이 협업을 하다 보면, 중요한 의사 결정을 할 때마다 전문성이 충돌할 때가 많습니다.

예를 들어서, 제품 개발 프로세스의 앞단에서 디자인 부서와 기구 설계 부서 사이에 의견이 충돌하는 경우가 종종 있습니다.(전자 제품의 외형을 구성하는 부품을 기구품이라고 부릅니다. 노트북을 예로 들자면, 키보드, 힌지, 노트북 케이스 등이 기구품에 속합니다.) 제품 개발은 마케팅 부서가 시장 조사를 해서 제품의 Concept을 정하는데서 출발합니다. 이 Concept이 정해지면 디자인 부서는 제품 Concept에 맞는 디자인 작업을 합니다. 이 작업을 하면서 디자인 부서는 여러 가지 디자인 후보를 만듭니다. 디자인 작업이 끝나면, 디자인 품평회라는 이벤트에서 영업, 마케팅, 기구 설계팀, 디자인 팀, 경영진이 모여 여러 후보 가운데 한가지를 선정합니다.

그런데 문제는 디자인 부서가 제품 Concept에 충실한 나머지 너무나 고객 지향적인 디자인을 하면, 기구 설계팀에서 최종 제품으로 만들 때 무척 고생을 합니다. 어쩔 때는 제품으로 만들지 못해서 디자인을 변경하는 경우도 있습니다. 반대로 기구 설계팀이 제품을 만들기 쉽게 디자인을 하면, 고객의 감성을 자극하지 못하는 기운 빠진 디자인이 됩니다. 디자인 부서와 기구 부서가 서로 자신의 이익을 극대화했을 때, 반대편에서 곤란을 겪게 됩니다. 하지만 두 부서의 이익에 부합하는 교집합이 커질수록 고객의 욕구를 짜릴하게 자극하는 대박 상품이 되죠.

따라서 디자인과 기구 설계팀의 원활한 의사 소통이 무척 중요합니다. 그러나 경영진이나 회사 분위기는 부서간의 벽없는 대화(Borderless communication)을 강조하지만, 대부분의 전자 회사나, 자동차 회사의 제품 개발 프로세스를 보면 이러한 Communication을 원천적으로 막는 모습입니다. 즉, 도덕 시간에 “내 이웃을 사랑하라.”고 배우지만, 법조문에는 “내 이웃을 사랑하면 벌을 받는다.”라고 적힌 모습이랄까요?

위에서 보시는 그림이 일반적인 제품 개발 회사에서 디자인 부서와 기구 설계팀이 협업을 하는 프로세스입니다. 품평회라는 일회성 이벤트에서 디자인 부서와 기구 설계팀이 만나서 의견을 교환하고 디자인을 확정합니다. 그러나 고도로 발달된 두 부서의 업무를 단순한 일회성 이벤트에서 조절하는 일이 불가능합니다. 반대로 서로의 전문성을 인정하지만 고객 만족이라는 공통의 목적 함수를 추구하기 위해서는 두 부서의 지속적인 대화가 필요합니다. 그렇게 하기 위해서 (우리가 지닌) 거대 프로세스는 약 98%가 부족하다는 생각입니다.

이런 목적 함수가 다른 두 부서를 통합하기 위해서, 생각나는 방법은 두 가지 정도입니다. 잡슨氏 같은 리더쉽을 겸비한 사람을 개발 프로젝트의 팀장으로 두고, 두 부서의 목적함수를 고객 욕구 만족이라는 하나의 목표에 맞추게 합니다. 서로 다른 부서의 의견을 조정하는 조정자 역할을 하는 사람을 두는거죠. 그런데 이렇게 하면, 잡슨氏 같은 강력한 리더쉽을 소유한 사람을 찾아야 한다는 문제가 생깁니다.

다른 방법으로 두 부서가 진정한 Communication할 수 있는 방법과 자리를 마련해 주는거죠. 물론 기존에도 프로세스는 저렇게 그려 놓았지만, 두 부서가 만나서 이야기하고 서로의 목적함수를 맞추는 일을 했습니다. 그러나 거대 프로세스 아래에서 두 부서의 협업은 고도로 조직화 되지 않았기 때문에, 고객 만족도를 최대로 하는 설계 변수를 찾지 못하는 경향이 있습니다. 위의 그림에서 디자인 부서와 기구 설계팀의 목적함수가 일치하는 x2, y1의 고객 만족도는 그다지 높은 편이 아닙니다. 두 부서간의 업무가 유기적으로 이루어진다면, 두 부서의 목적함수를 x1, y2으로 옮겨서 고객 만족도를 극대화할 수 있습니다.

제가 근무하는 곳에서는 TDR(Tear down & resign)이라는 활동을 합니다. 각 부서마다 인력을 뽑아서 제품 개발을 시키는 방법입니다. TDR을 조직하면, 마케팅, 영업, 개발팀, 디자인 부서 사람들이 참여해서 의견을 교환하기 때문에, 거대 프로세스 아래에서도 작업이 됩니다. 그러나 단순하게 사람을 모아 놓는다고 해서, 일이 잘 된다고 생각하지 않습니다. 이렇게 생각하는 이유는 다른 분야에서 모인 사람들이 TDR이라는 조직 특성에 맞는 프로세스를 사용하는 것이 아니라, 거대 프로세스를 이용하기 때문입니다.

따라서 단순하게 각 부서 사람들을 모아 놓았다고 거대 프로세스의 문제점이 해결되지 않습니다. 저는 이런 문제점의 대안을 애자일 방법론이 제시할 수 있다고 믿습니다. 애자일 방법론의 핵심은 Communication 하는 방법을 알려 준다는데 있습니다. 단순한 대화가 아니라, 고객의 욕구를 중심에 둔 대화이기 때문에, 앞에서 말씀 드렸던, 서로 다른 부서의 목적 함수를 자연스럽게 고객의 욕구에 맞추게 합니다. 이번 애자일 2006 컨퍼런스에서 이런 움직임이 조금씩 나타나는 듯 합니다.

This entry was posted on Saturday, August 5th, 2006 at 12:57 pm and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.