개발자는 왜 서비스 기획을 하기 어려울까?

이 말은 반대로 서비스 기획자는 개발 업무를 어려워한다는 말이 될 수 있습니다. 특히 전문적일 경우 더 이런 경향성이 강하게 표출됩니다. 이유는 간단합니다. 서비스 기획과 개발을 위한 사사고의 방식이 다르기 때문입니다. 각 분야에 전문가가 될수록 사고 효율성을 위하 관성은 강해지고, 일반적 패턴은 자동 연산되기 때문입니다.

  

 

 

사고의 관성 및 업무 처리

 

초등학교를 들어가면 가장 먼저 하는 것 중 하나가 바로 구구단을 외우는 것입니다. 그리고 초등학생이 곱하기, 나누기를 배울 때 외운 구구단을 이용합니다. 3*2는 6은 구구단의 결과입니다. 3+3 또는 2+2+2를 해도 되는데 말입니다.

 

특정 분야 업무에도 일상적이거나 그냥 그렇게 되는 것이 당연한 프로세스의 경우 무의식적으로 처리하는 일들이 이렇게 구구단처럼 존재합니다.

 

해당 분야 경력이 길거나 전문성이 갖추어진다면 이러한 일은 입력 시 자동으로 프로세싱되도록 뇌에 저장되게 됩니다. 우리는 이를 사고의 관성이라고 부르기도 합니다.

 

사고의 관성은 무의식적이고 자동적이기에 그 사람은 인식하지 못하는 경우가 많습니다. 마치 사람이 지구상 동물에 속하지만 다른 동물과 다르게 두 발로 걷는 것이 너무 당연한 것과 비슷합니다.

 

일종의 분야 전문성에 따른 패시브 스킬이고 이는 해당 분야의 업무 처리를 빠르고 효율적으로 진행하는데 뿐 아니라, 일상적 업무 처리 시간을 줄여 좀 더 난이도 있는 일의 사고를 더 할 수 있게 도움을 주는 순기능도 있습니다.

  

문제는 다른 분야와 협업을 할 때 커뮤니케이션 오류를 발생시키는 요인으로 작용할 수 있다는 점입니다.

 

그래서 외주 개발 시 고객과 개발자 사이에 기획자를 두는 것도 이 커뮤니케이션 오류 때문입니다. 

 

 

 

공학도와 비즈니스 

 

"다음 문제의 솔루션을 짧게 말해 주세요."

여기서 짧게는 어느 정도를 의미하는 것일까 각자 생각해 보십시오.

 

1. 3줄에서 5줄 정도가 짧은 것이다
2. 10줄은 넘지만 15줄은 넘지 않는 것이 짧은 것이다.
3. 한 장을 넘지 않게 적는 것이 짧은 것이다.
4. 알 수 없다.

 

일반적으로 공학도라면 4)를 말할 것입니다. 짧다는 것은 주관적이고, 그러기에 유동적이기에 이에 대한 적절한 솔루션을 제시할 수 없습니다.

 

그러나 사업가라면 짧게 쓰라고 말하는 화자의 성향 및 전반적인 맥락을 살펴 짧은 수준을 1) ~ 3)으로 정리할 것입니다. 질문이 나온 이상 어쨌든 피드백을 전달해야 하기 때문입니다.

 

비즈니스에서는 맞고 틀리고도 중요하지만, 때로는 전반적인 맥락에서의 적절한 행동을 하느냐도 중요합니다. 만약 '짧게'라는 개념이 모호하므로 아무 대답도 하지 않는다면 상대는 계약을 하겠다는 니즈가 없다고 느낄 수도 있습니다.

 

이 케이스는 실제 제가 경험한 것입니다.

 

 

 

서비스 기획과 개발 설계

 

서비스 기획의 가장 대표적 업무인 '서비스 가설'과 개발의 대표적 업무인 '코딩'을 생각해 봅니다.

 

서비스 가설은 모호한 불확정적 상황을 타개하기 위한 작업입니다. 그러므로 추상적 현실을 바탕으로 설계를 하게 됩니다.

코딩은 정해진 정책, 기능을 구현하기 위한 작업입니다. 그러므로 구체적이고 명확한 사실을 바탕으로 설계를 하게 됩니다.

• 서비스 가설 - 불확실한 상황에서 프로세스
• 코딩 - 확실성하의 프로세스

 

그러므로 서비스 가설은 가정에 기반하고, 이 가정은 시간의 흐름에서 틀렸음이 확인되기도 합니다. 이때 당연히 서비스 기획자는 가설을 수정합니다.

 

개발자가 코딩 중에 정책이나 기능이 바뀐다면 다른 작업을 하게 된다고 생각합니다. 이는 기존 개발 업무와 별개의 추가 작업입니다. 그러므로 추가 개발비를 요청할 수 있습니다.

 

서비스 가설 기반 가정은 시장 현상을 기반으로 합니다. 만약 새로운 현상을 추가 발견하거나 기존 현상에 대한 분석이 데이터가 늘어남에 따라 샘플링 오차로 인한 틀린 것으로 파악된다면 당연히 변경되어야 합니다. 그게 시장 현상이고 서비스는 이 시장에서 수익을 올려야 하기 때문입니다.

 

그러나 정책이나 기능은 선택의 영역입니다. 맞고 틀리고 아니고 의사결정자의 니즈 또는 사업 전략에 따른 선택인 것입니다. 그러므로 바꾸는 것은 마음을 바꾼 것으로 개발자는 인식할 수 있습니다.

 

• 서비스 가설을 위한 정보 - 시장 현상으로 사실
• 코딩을 위한 정보 - 의사결정자 또는 사업 전략에 기반한 선택

 

이렇듯 개발과 서비스 기획의 목표와 환경이 너무 다르고, 이로 인해 각 업무를 처리하기 위한 효율적인 프로세스가 다르게 발전/체계화되어 왔습니다.

 

이 때문에 서비스 기획과 개발에 전문성을 갖추어 갈수록 서로 업무의 작업이 어려워지게 되는 것입니다. 단지 협업을 통해 의사소통 방식을 깨우쳐 가는 것입니다.

 

비전문가나 초보자의 경우 아직 뇌의 사고 시스템이 잡혀 있지 않아 그렇지 않을 수는 있습니다.

 

또한 예외적으로 천재인 경우 상관없이 서비스 기획과 개발 모두를 전문가 이상으로 잘하기도 합니다. 그러나 저를 포함하여 이 글을 읽고 있는 대부분은 천재급 개발자, 기획자는 아닐 것이라 추정되지 않을까요?