앱과 웹 관련 프로젝트를 하다 보면 해당 도메인 경험이 많아서 스카우트된 기획자가 있게 됩니다. 그런데 이러한 기획자가 때로는 도움이 되는 것이 아닌 프로젝트 진행에 걸림돌이 된다는 것입니다. 심지어 없는 편이 더 나은 성과를 보이기도 합니다. 이런 현상의 이유는 스펙을 중시하는 경향에 맞게 도메인 경험이 세팅되기 때문입니다.
도메인 경험의 유형
저는 통신 대기업을 다녔습니다. 제가 있을 당시 전체 인력은 정직원만 약 3천 명 정도였습니다. 지금은 모회사와 합병하여 약 2만 명 전후가 될 것입니다. 이것도 많이 줄인 숫자입니다.
이렇게 많은 인력이 모두 같은 일을 할까요?
사내 프로젝트를 할 때 모두 같은 정도의 역할을 부여받게 될까요?
제가 이 통신 대기업에서 프로젝트를 리딩할 때 수 십 개 부서와 연결되어 업무를 진행했습니다. 이 프로젝트가 끝난 이후 회사에서 저의 이름을 모르는 사람이 없을 정도였습니다. 협력 품의서가 수 십 개 부서와 그 부서가 속한 본부에 전달되었기 때문입니다.
그런데 통신 대기업을 나와 중소기업에 다니는 동안, 그 프로젝트를 자신이 리딩했다는 기획자가 나타나기도 했습니다.
저는 기억을 못 하는 인력이었습니다. 검토해 본 결과 이 수십 개 관련 부서 중 한 곳의 하청업체 인력 중 한 명인 적도 있습니다.
너무 오래전이라 제 기억이 정확하지는 않지만 이런 비슷한 일은 또 있습니다. 분명 경력과 경력기술 상 했을 가능성이 매우 낮아 보이는 프로젝트를 했다고 말하는 기획자였습니다.
이게 프로젝트의 경험의 차이인데, 경험을 부풀리고 실제 경험이 적은 기획자의 경우 이것이 그냥 넘어갈 것이라 생각합니다. 일단 해당 프로젝트를 진행했던 회사에 있었던 것은 사실이기 때문입니다.
그러나 경험이 많은 기획자는 이런 기획자가 자신이 했다고 주장하는 프로젝트 내용에다 몇 가지 기획 변수를 추가함으로 실제 했는지 아닌지를 파악할 수 있습니다.
기획 변수를 추가했다고 해도 어차피 그 프로젝트를 했을 때와 다를 것이 없기 때문입니다. 그러므로 진짜 프로젝트 기획을 했다면 바로 이야기할 수 있을 것입니다.
만약 다른 사람이 한 프로젝트에 관한 문서만 가져와서 본 것이라면 대답을 할 수 없을 것입니다.
이런 이야기를 한 것은 네이버, 쿠팡, 토스 등 유명 스타트업에 있었다고 다 같은 일을 하는 것은 아니라는 사실, 그리고 큰 프로젝트가 진행되기 위해서는 여러 하위 프로젝트가 진행된다는 사실 때문입니다.
스펙과 기획
수 십 년 동안 문서 헌터 기획자, 입 기획자, 미디어 기획자 등은 존재해 왔습니다. 이 유형의 기획자의 도메인 스펙은 실무를 진행하는 기획자보다 더 화려하고 좋습니다.
하지만 이런 기획자는 관련 도메인 분야에 있었을 뿐 실제 기획 작업을 하지는 않았습니다.
- 문서 헌터 기획자 : 프로젝트에 들어가면 다른 기획자가 작업한 문서를 모아서 다음 프로젝트의 자신의 스펙으로 활용하는 기획자
- 입 기획자 : 기획을 입으로만 하는 기획자.
- 미디어 기회자 : 언론이나 방송 노출만을 목적으로 하는 기획자
산업 분야를 불문하고 이런 기획자는 의사 결정자 잘 모를 경우 회사나 프로젝트팀의 헤드를 차지하게 됩니다. 조직 정치적으로 매우 뛰어나기 때문입니다. 아니 다른 기획자들이 기획을 할 때 정치를 하기 때문입니다.
도메인 기획
기획의 유형이 무엇이냐에 따라 도메인 지식보다도 기획 대상의 진행 역량이 더 중요할 수 있습니다. 이는 바로 최근의 비즈니가 대부분 생산 네트워크, 가치 사슬, 공급망 네트워크 같은 형식으로 진행되기 때문입니다.
그러므로 도메인 지식을 바탕으로 한 설계는 이미 다른 생산 단계의 기업에서 진행되었을 수 있습니다. 해당 생산 단계에서는 이 정리된 내용을 기술적으로 적용하면 되는 것일 수도 있습니다.
이 경우 도메인 지식은 용어를 이해할 수 있을 정도로만 알면 됩니다.
특히 앱/웹 개발의 경우가 바로 이것입니다.
제가 금융 시스템 개발 프로젝트에 기획자를 할 때, 금융 프로젝트 경험이 풍부하다고 해서 투입된 고급 기획자가 있었습니다.
문제는 이 기획자가 화면 개발과 서버 개발의 차이를 모른다는 것이었습니다. 또한 금융 시스템의 구성에 대해서도 이해를 전혀 하고 있지 못하고 있다는 것이었습니다.
저의 경우 대학을 경영학과를 나와서 금융 용어에 대해 대충은 알고 있습니다. 그런데 이 도메인 경험이 많다는 기획자는 특이한 용어와 금융 개념을 가지고 있었습니다.
물론 경력 기술서 문서 스펙적으로는 도메인 경험이 많은 기획자였을 것입니다.
그런데 기획자가 앱/웹 개발에서 무엇을 해야 하는지 전혀 알고 있지 못하였습니다. 심지어 리더 기획자로 투입되었는데 프로젝트 팀 관리에 대해서도 전혀 경험이 없는 사람처럼 행동했습니다. 모든 활동을 개인적으로 진행했으며, 업무 지시도 자신만 이해할 수 있는 방식으로 했습니다. 그래서 업무 지시를 사람마다 다르게 이해하여, 서로 자신이 어떻게 이해했는지 의견을 나누고 업무를 했습니다.
이런 경험으로 저는 도메인 경험이 많다는 말은 믿지 않습니다. 확인을 하고서 믿습니다.
대부분 IT 개발 분야의 도메인 경험은 말 그대로 어떤 일은 했는지 모르지만 관련 회사나 조직에 있었던 경력을 의미하는 것일 뿐이라 생각합니다.
2015년 이후 국가 교육, 다양한 교육 스타트업 등에서 배출된 무늬만 전문가, 3~6개월 교육만 받으면 주어지는 전문가 자격증, 전문 교육을 취업이 안된 학원 수료생이 하는 관례 등 때문에 더 믿지 않습니다.
그래서 도메인 지식 또는 경험을 강조하는 경우 더 의심하게 되었습니다. 이 사람이 모르는 것을 숨기려 더 강조하는 게 아닌가 말입니다.
실제 확률적으로 이런 케이스가 더 많기에 도메인 경험이 많다고 하는 기획자가 진행하는 프로젝트의 실패 확률이 더 높은 것이라 생각합니다.
'기획 일반' 카테고리의 다른 글
앱과 웹 서비스를 누구에게 어떻게 할 것인가 결정 방법 (기획 측면의 UI/UX 방법론) (0) | 2024.07.11 |
---|---|
UX 믹스와 로직 (0) | 2024.07.11 |
사용자 경험의 설계에 대하여 (0) | 2024.07.09 |
프로젝트 관리자(PM)의 역할. 고객 요구와 하위 개발 단위 안정성 (0) | 2024.07.09 |
온라인 서비스 기획과 UX 기획 실무 진행 차이에 대한 이야기 (0) | 2024.07.09 |
댓글