관점 대립

어느 회사에서 마케팅팀과 개발팀의 갈등이 있었습니다.

  마케팅팀은

  제품 판매에 용이하고 보다 개선된 수익모델을 위해

  제품의 모든 기능을 컴포넌트처럼 선택이 가능하도록 해야 한다고 했습니다.

 

  개발팀은

  이미 개발된 구조를 버리고 새로 개발해야하는 상황이며,

  새로 개발한다고 해도 마케팅팀이 원하는 수준의 컴포넌트화는 어렵다고 했습니다.

 

  사실 소프트웨어는 전혀 소프트하지 않습니다.

  일반인에게 아주 쉬워보이는 변화에도 엄청난 비용이 필요하게 됩니다.

  이부분은 개발자 이외의 인원들이 자주 간과하는 일입니다.

    더욱 위험한 것은

    개발 경험이 있거나, 방금 전까지 개발을 해왔던 사람들도,

    자신의 업무의 특성이 바뀌면,

    관점이 변한다는 것을 까맣게 잊어버리는 것 입니다.

  두 팀은 하염없이 논쟁을 하면서 시간을 보내고, 지쳐버렸습니다.

다른 회사에서 같은 일이 벌어집니다.

  개발팀은 마케팅팀의 관점에서 요구사항을 다시 해석합니다.

  "문제에 집중하면 해답을 찾기 어렵다"는 교훈을 가슴에 새기고,

  제품을 콤포넌트화라는 문제 또는 원인보다 그것으로 얻게되는 이득을 생각합니다.

 

  개발팀은

  개발된 제품의 모든 기능에 플래그를 다는 것으로 문제를 해결합니다.

  "컴포넌트화 되었다는 것은 사기다"라고

  목소리를 높이는 개발자도 있었습니다.

 

  하지만, 마케팅팀이 만족합니다.

  필요에 따라 기능을 언제든지 따로 설치할 수 있었기 때문입니다.

  물론 모든 기능은 이미 설치되어 있었지만..

 

  하지만, 고객이 만족합니다.

  필요없는 기능을 구매할 필요가 없었기 때문입니다.

  물론 마케팅팀은 그것을 감안하고 더 비싸게 팔고 있었지만..

 

  결과적으로 개발팀도 만족합니다.

  dll, com 등 다양하고 복잡한 컴포넌트화 악몽에서 벗어날 수 있었기 때문입니다.

  물론 여전히 간단해 보이는 플래그 관리에 시달리고 있었지만..

사실 마케팅팀과 개발팀 사이에는

이러한 것보다 더 많은 갈등이 항상 있어왔습니다.

해결책은 간단합니다.

  마케팅팀은 개발의 난이도를 직관에 의존하여 판단하지 않으면 됩니다.

  또한, 그 잘못된 판단으로 개발팀에게 압력을 주지 않으면 됩니다.

 

  개발팀은 요구된 기능/문제에만 집중해서는 안됩니다.

  "문제에 집중하면, 해답을 바라볼 수가 없습니다."