이미 진 게임 vs. 이기고 시작하는 게임

쉽게 얻으려고 하면 아무것도 이루지 못한

이순신 장군이 무패의 영웅이 된 것은 질 전투를 하지 않았기 때문이라고 합니다.

이미 이길 수 있는 방침과 방책을 정해두고 싸웠기 때문에, 적에게 질 수 없었다는 것이죠.

모듈러 디자인 활동을 하는 과정에서 들려오는 불만 중 안타까운 것들이

"이걸 해서 무엇이 좋아지냐?"

"뭐 하나 기존과 바뀐 것이 없다."입니다.

첫 번째는 성과에 대한 것이고, 두 번째는 일하는 방식에 대한 것입니다.

모듈러 디자인 활동을 저는 모듈러 아키텍처링, 모듈러 오퍼레이팅 (모듈러 디자인 운영 관리), 모듈러 디자인 성과관리로 나눕니다. 그리고, 이것이 모듈러 디자인을 수행할 시점의 실행 순서이기도 합니다.

그런데, 개별 활동을 단절적으로 봐선 안됩니다.

즉, 모듈러 아키텍처링을 끝내고, 모듈러 오퍼레이팅을 하고, 모듈러 오퍼레이팅을 끝내고 성과관리를 하는 식이 아니라는 겁니다.

가장 큰 오해를 받는 것이 모듈러 아키텍처링 활동입니다.

모듈러 아키텍처링은 모듈러 디자인 활동을 하기 위한 기준과 절차를 만드는 과정이라고 설명을 합니다.

실제로 성과를 내는 활동이 아니라고 말하죠.

그렇기 때문에 성급하게 성과를 논해서는 안된다고 말합니다.

그런데, 모듈러 아키텍처링만 해놓으면 당장 뭐가 바뀔 것처럼 말하고, 성과가 당장 나올 것처럼 이야기를 합니다.

표시판을 만들어뒀다고, 누구나 교통질서를 지킬까요?

그렇다면, 모듈러 아키텍처링 활동을 할 때는 운영 관리나 성과관리는 신경을 안 써도 될까요?

아닙니다.

그렇게 하면 위 안타까운 질문을 받게 되는 겁니다.

모듈러 아키텍처링은 결국 현 제품을 모듈러 디자인에 적합한 형태로 기준과 절차를 설계를 하는 겁니다.

그런데, 그것은 가장 먼저 이걸 해서 무엇이 좋아질까? 어떤 효과를 얻을 수 있는지를 상정하고 시작해야 합니다.

모듈러 디자인은 하나의 툴입니다.

원하는 목적에 맞지 않는다면, 도입해선 안 되는 툴입니다. 그 목적이 무엇인지, 목적에 맞는지를 고민해야 합니다.

그다음에 달성하고자 하는 목적에 맞추기 위해서 일의 방식을 어떻게 바꿔야 하는지 고민해야 합니다.

현재 제품을 만드는 방식, 제품을 구성하는 방식, 제품을 관리하는 방식을 목적에 맞게 뜯어고쳐야 합니다.

그다음에 그 방식에 맞게 모듈러 아키텍처링을 하는 겁니다.

즉, 실행 순서는 모듈러 아키텍처링, 모듈러 오퍼레이팅, 모듈러 디자인 성과관리 일지 모르겠지만,

고민해야 하는 순서는 성과관리, 모듈러 오퍼레이팅, 모듈러 아키텍처링이 되어야 합니다.

이게 안되니까

이걸 왜 하는지 모르겠어요, 무엇이 바뀌는지 모르겠어요라는 말이 나오는 겁니다.

예전에 특정 컨설팅 회사에서 고객사의 경쟁사가 모듈 구조 정의 (모듈러 아키텍처) 한 결과를 알고 싶어 한 적이 있습니다. 정말 아무 소용없는 짓입니다.

모듈 구조 정의한 결과에는 왜 그렇게 모듈 구조 정의를 했는지, 무엇을 성과로 얻을 수 있는지, 일하는 방식은 어떻게 바뀌는지는 하나도 나와있지 않습니다.

그냥 껍질만 베끼는 겁니다.

경쟁사가 모듈 구조 정의를 어떻게 했는지 알고 싶어 할 시간에

우리가 달성하고자 하는 목적, 그것을 위해서 해야 할 프로세스의 변화, 그것을 위한 제품의 변화를 고민하고

그것을 모듈러 아키텍처에 담으세요.

그렇게 하면 이미 이긴 게임을 하는 겁니다.

그게 아니고, 다른 회사의 모듈러 아키텍처 결과물을 고민 없이 베끼는 것은 최악이고,

누가 시키니까 고민 없이 모듈러 아키텍처링을 하는 것이 차악입니다.