기획이란 無 에서 有 를 창출하는 것.

기획이란 뜻을 세우고, 세운 뜻에 대한 조직적 합의를 기반으로, 조직의 자원과 힘을 집중시켜, 뜻한 바를 이루어 낼 수 있도록 하는 과정의 모든 일.

기획자는 항상 성과로 평가 받아야 한다. 그러나, 사업의 종류나 기획의 종류에 따라, 영업주기에 따라, 열매를 수확하는 데 상당한 시간이 소요될 수도 있다.

뜻을 세우다.

뜻을 세운다는 것은 “어디서?”, “무엇을?”, “언제?”, “어떻게/누가?”–산업마다 기획 업의 종류에 따라 순서는 다를 수 있음, 제품기획을 기준으로 한 필자가 생각하는 중요도에 따른 순서임–에 대한 복안이다. 그 밑 바탕에는 당연히 “왜?” 에 대한 논리가 있어야 한다.

다시 말하면,

• 어느 시장에서 플레이 할것인가?
• 무엇을 만들고 제공할 것인가?
• 언제 시작해서 언제 출시할 것인가?
• 그러기 위해서 어떻게 접근할 것인가?

에 대한 복안이다.

범용 반도체, Open OS 라는 이름이 의미하듯이, 내가 기획하는 제품 및 기술은 다양한 시장을 염두에 두고 있다–이하에 범용 반도체 기획을 예로 들고 있지만, 개발기획이든 기술기획이든 모두 동일한 과정을 거친다.

현실 세계를 좀 단순히 모델화 시키면, A라는 시장에서 필요한 제품을 구성하는 기술요소는 1/2/3 이고, B라는 시장은 2/3/5, C 라는 시장은 1/3/4라고 가정해 보자. 물론, A/B/C 시장은 다시 시장 세분화 변수에 의해, 가령 High-end/Low-end 등으로 더 쪼개지고, 각 세분시장이 요구하는 기술 요소도 달라지게 마련이지만 여기서는 고려하지 않는다.

시장의 성장성이나 산업구조 (5 Forces) 를 분석해 보니 A/C 시장을 공략하는 것이 가장 적합하다고 판단된다. 그럼, A/C 시장을 공략할 수 있는 1/2/3/4 라는 기능을 가진 제품을 기획하게 된다. 이를 “기능명세서 (Specification)” 라 한다.

시장	기술 요소	시장성	산업구조
A	123	Good	Good
B	235	Average	Not bad
C	134	Average	Average

굵은 숫자는 Must-have 를 의미한다.

이 때 주의할 점은 ‘조직이 만들 수 있는 제품’ 이 아니라, ‘시장이 요구하는 제품’ 을 기획해야 한다는 것이다. 기획자로서 조직이 보유하고 있는 기술적 역량을 파악하는 것은 상당히 중요하다. 하지만 그 보다 더 중요한 것은 시장의 트렌드를 읽는 안목이다. 시장에서 꼭 필요한데, 내부적으로 보유하지 못한 역량은 외부에서 얼마든지 보충할 수 있기 때문이다.

조직적 합의를 얻다.

기획에서 가장 어려운 부분이다. 모든 Stakeholder 들로 부터 합의를 얻어서 조직의 자원과 힘을 내 뜻에 집결시키는 부분이다. 이 과정에서 기획자의 “철학” 과 “지혜” 와 “용기” 가 필요하다. 조직은 항상 관성이 존재하며, 조직원들은 방어적 기질이 존재하기 때문에, 인내심을 가지고 설득해서 내 기획안의 수행에 대한 동의를 얻어야 하며, 그 과정에서 때로는 내 뜻을 수정하여 조율하기도 하고 때로는 원안을 밀어 부치기도 해야 한다.

“기능명세서” 를 들고 개발부서에 구현 가능성과 구현 일정을 묻는다. Must-have 기능에 대해서는 타협해서는 안되며, Nice-to-have 기능의 경우 여러 가지 정황을 고려해서 한발짝 물러 설 수도 있다. Must-have 기능 구현에 있어서 일정, 자원의 문제가 발생할 경우, 기획자는 Good Reason(왜?) 을 제공해야 한다. 정히 불가할 경우에는 다른 확보 방법론 (어떻게/누가?에 대한 결정. 외주, 라이센스인 등) 을 고려 할 수도 있다. 시장에서 필수로 요구하는 Must-have 기능을 포기해야 한다면, 최초 표적한 시장 A/C 를 변경해야 하는 사태가 발생할 수도 있다. 2 는 Nice-to-have 였으므로 버리기로 했고, 1/3/4 가 남았다.

기능명세서-1234

조율된 “기능명세서” 를 들고 영업부서에 상품화 또는 사업화 가능성을 묻는다. 영업부서에서는 “기능명세서” 에 대한 고객의 피드백을 제공하며, 그 과정에서 새로운 기술 요소 7/8/9 를 요구할 수 있다. 기획자의 시장과 기술에 대한 이해를 바탕으로 요구사항 7/8 을 수용하고 9는 버리도록 설득할 수 있어야 한다. 이제 “기능명세서” 에는 1/3/4/7/8 이 남았다. 또, 영업부서는 구현 일정에 대한 고객의 피드백도 제공한다. 말도 안 되는 일정을 제시할 수도 있다.

기능명세서-134789

조율된 “기능명세서” 와 구현 일정에 대한 고객의 피드백을 들고 개발부서를 다시 만난다. 구현 일정이 전혀 합리적인 않을 경우 다른 방법 (어떻게/누가?) 을 고려해야 할 수 도 있다. 또 영업부서를 만난다.

이런 Iteration 이 계속 발생하여 최종 “기능명세서” 가 만들어 지게 된다.

실행을 위한 준비

내 뜻에 대한 조직적 힘을 얻었다면 이를 기획서로 표현한다.

“기능명세서” 가 확정되고 나면, 내부에서 개발할 것, 외부에서 사올 것, 외부에서 개발할 것을 정리하여 개발비를 추산하고, 제품 원가를 계산하게 된다. 그리고, 가격정책에 따라 제품 판가를 결정하게 된다. 또, 영업부서는 매출 계획을 작성하게 된다.

사업성 분석을 하고, 기획서를 작성한다.

제품기획서

• 기획 의도 및 기대 효과 (“왜?”)
• 목표 시장 (“어디서?”)
• 목표 시장의 시장성 (성장성, 산업구조, 경쟁제품의 가격과 기능명세) (“어디서/왜?”)
• 제품 기능명세 (“무엇을?”)
• 목표 개발 일정 (“언제?”)
• 개발 방법 (“어떻게/누가?”)
• 고정원가 (개발비), 제품 원가
• 제품 판가
• 매출 및 이익 계획
• 시장 진입 및 경쟁 전략 (차별화, 저원가)
• 핵심 성공 요인, 위험 요소, 위험 회피 계획

Kick-off & Follow up

정리된 기획서는 적절한 승인권자의 승인을 얻어 최초 형상기준선을 확보해야 한다. 승인을 얻은 기획서를 기반으로 실행팀을 꾸미고, Kick-off 를 한다. 기획이나 전략은 “환경의 산물” 이다. 따라서, 환경에 변함에 따라 기획은 적응적으로 민첩하게 변해야 하며, 기획자는 실제 자신이 뜻한 바를 성공시킬 때까지 지속적으로 Follow Up 해야 한다. 변경된 기획서는 반드시 최초 승인한 사람의 승인을 다시 받고, 실행팀에 공유하고, 변경 내용을 설명해 주어야 한다.

가령 Kick-off 이후 시간이 흐르면서 시장이나 기술 트렌드가 변경되어, 공략하고자 했던 A/C 시장에서 필요한 기술 요소 6, 9 가 추가 될 수도 있고 4 가 삭제될 수도 있다. 또는, 그 과정에서 수정된 “기술명세서” 로 공략할 수 있는 시장 F/G 가 추가될 수 있고, 기획자가 “기술명세서” 로 Address 가능한 기존에 존재하지 않던 시장 Z 를 창출할 수도 있다.

시장	기술 요소	성장성	산업구조
A/C	1346789	기존 대비 좋아짐	기존 대비 조금 나빠짐
F	378	Average	Good
G	169	Average	Average
Z	37	Unknown	First-mover