이런 업무까지 기획팀에서 해야 하나요? (R&R이야기)

서비스가 B2B 비즈니스 Friendly 일 때 기획자에게 주어지는 일

어느 날 팀원으로부터 온 메일 "팀장님. 이런 사항도 기획자가 들어줘야 하나요?"
왜 이런 메일이 왔는가? 저희 팀 사업계획에 버젓이 들어 가 있기도 한 업무 프로세스인데도 어떻게 이렇게 기획자의 관여도가 높아졌는지, 그래서 조정할 요소가 무엇인지 정리할 필요가 있었습니다.

저희는 회사의 주 비즈니스 중 하나인 교육행정에 대한 B2B 서비스를 기획하고, 만드는 일을 합니다.

B2C는 일반 대중의 고객에게 매력적인 상품을 제공해서 수익을 창출하는 서비스이겠고, B2B2C는 앱스토어, 오픈마켓처럼 플랫폼의 기업(개인) 고객에게 이용자를 유치해줘서 양사 쪽 또는 일방으로부터 수익을 얻는 서비스인데, 그와는 달리 저희의 서비스는 B2C 사업에서의 성공을 바탕으로 B2B까지 사업영역을 확대한 케이스로 볼 수 있습니다. B2B는 개인 대상 거래보다 건당 매출이 높고, 또 개인과 달리 기업은 자사 성장에 도움이 된다고 판단하면 지출을 투자로 간주하기 때문에 가격보다 질을 우선하는 경향이 있다는 점에 있어서도, 한 번 업무 협약을 맺으면 동시에 여러 분야의 매출기회도 얻을 수 있다는 것도 전략적인 판단에 한몫을 했고요.

대기업이 이미 메이저로 제공하던 중심의 시장이었는데, 내실 있는 서비스와 콘텐츠에 자신 있던 저희로서는 도전해볼 만한 부분이었기도 했지요.

2012년 당시 교육 B2B 시장으로 진출하기 위한 전략을 세웠을 때, 크게 4강 구도였습니다. S그룹 계열, K그룹 계열, H그룹 계열, W그룹 계열 제공사의 규모와 영업력에 (무모하게) 정면 승부하기로 결정했었는데요. 상대적으로 저희는 B2C 부문에서의 높은 인지도와 콘텐츠에 있어서는 메가 히트작들이 다수 존재하는 탄탄한 중소기업이었기 때문에 가능성이 제로는 아니었습니다.

기존 메이저 업체들이 제공하던 모델은 SaaS 모델이었는데요. 자체적으로 서버를 구축해서 시스템을 두는 비용에 비해, 저렴한 사용료 기반으로 인터넷 환경이 되면 어디에서든 교육행정, 학습 서비스와 관리 서비스를 제공받을 수 있고, 규모있는 대기업이기 때문에 인지도와 안정적인 환경에 대한 신뢰를 받고 있었지요.  

당시만 해도 서버 구성부터 개발까지 진행하면 거의 5~10억 가까운 투자비용 + 콘탠츠 비용이 드는데 비해, SaaS 모델로는 SaaS 사용료 + 콘탠츠 비용이라 콘탠츠 비용은 상품 가격이라 당연히 들어가는 비용이라고 보면 시스템 비용은 10분의 1이면 되는 비용으로.. 매우 큰 차이를 보였었거든요.

처음 이 시장에 진출한다고 했을 때 정말 많은 기업의 담당자들과 영업대표들을 만나서 요구사항들을 분석하면서 찾아낸 공통적인 고객의 불편이 있었습니다. 싸지않은 비용을 지불하는 고객임에도 기존 B2B 플랫폼을 이끌던 서비스공급자들이 회사마다 다른 기준과 명칭, 서비스를 만들기 어려웠거나, 업그레이드된 서비스를 제공받기 위해 오랜 기간 패치를 기다리거나 (그나마도 다 수용되지 않죠.) 본인이 요구하는 맞춤형 ㆍ추가 개발에 고비용이 들어서, 결국 플랫폼이 소화하지 못하는 기능들은 수작업으로 진행하거나, 다른 사이트의 서비스를 쓰거나 해서, 2중 투자가 일어나고 일원화된 관리도 어려운 상황이었습니다.

그에 따라 저희가 초기에 만들어 내는 과정에서 지금까지 이어가고 있는 전략은 맞춤형 SaaS 전략이었습니다. 초기 개발 프레임워크를 잡을 때도 이 부분을 매우 중요하게 생각했었습니다. SaaS 모델을 근간으로 하되, 기업고객의 코드에 따라 사이트 디자인, 메뉴, 페이지 구성, 버튼, 심지어 타이틀명까지도 맞춤형으로 설정 가능하고, 별도의 추가 기능들에 대한 커스터마이징을 수행할 때 사이드 이펙트 발생이 최소화되어야 했습니다.

또한 데이터가 다른 곳으로 분산되지 않고, 한 곳에 모일 수 있도록 하는 장치도 함께 설계해서 분석 가능한 자산으로 만드는 Digital Transfomation을 위한 기반을 만들 수 있어야 한다는 부분도 고려했었습니다. 제공기업의 정보자산이기도 하지만, 개인정보를 제외하면 훌륭한 빅데이터가 될 수 있는 우리의 자산일 수도 있었거든요. (사실 그때는 빅데이터까지는 생각 못하고, ^^;; 다른 곳으로 이탈하지 말자가 주였습니다.)

결과적으로 이 "전략" 은 주효했고, 매년 30% 이상의 성장을 이끄는 하드 캐리(Hard Carry) 서비스가 되었습니다. 주요 고객들의 요구를 분석하면서 기본 뼈대가 되는 기본 프로세스 모듈을 만들어서 버전 1.0으로 진행하고, 계속적으로 기업의 요구사항을 받아서 해당 기업을 위한 파일럿 서비스로 커스텀해서 활용하다가 특정 시점에 다시 모든 기업이 사용 가능한 모듈로 운영하는 방식을 사용해서 시스템을 고도화해 나갔습니다. 

아래와 같은 체계를 바탕으로 진행하고 있습니다.

(사실 초기에 시행착오가 굉장히 많았던 방식인데요, 현재는 안정된 프로세스와 서버 구성, 개발체계 수립을 통해 원활히 운영되고 있습니다. )

다시 여기서 우리의 기획자의 질문 "팀장님. 이런 사항도 기획자가 들어줘야 하나요?"는 이러한 시스템의 근간을 만드는 데 있어서는 기획자의 역할이 매우 다양하게 다방면에 걸쳐 있었기 때문이라고 말씀드릴 수 있습니다.

초기에 워낙 도전적으로 큰 메이저 기업 대비 강점을 어필하다 보니 영업대표들이 수주를 위해서 고객이 "이런 기능도 되나요?" 했을 때, "다 됩니다" 하고 오는 케이스, "언제까지 되나요?" 했을 때 "원하시는 시기에 되도록 하겠습니다."하고 약속 아닌 약속을 하고 오는 케이스 등으로 인해 (정말 사무실에서 소리 지르고 싸울 정도로) 뒷감당을 책임지는 역할을 하는 기획자와 디자이너, 개발자들로서는 곤혹스러우면서도, 어쨌든 해야 하니 밤을 새워야 하는 시기가 많았습니다.

하여 묘안을 내 본 것이, 가급적 설득적인 논리로 기존 모듈을 사용하도록 하고, 커스터마이징을 최소화하면서도 고객은 본인의 요구가 잘 받아들여졌다고 신뢰를 주기 위해서는 기술적인 미팅에 기획자를 참여시키도록 프로세스화 할 필요가 있다는 것이었습니다.

기획자의 역할을 잘 아시다시피,
고객의 애매한 요구를 개발자가 잘 이해할 수 있게 구체화하는 능력에 더해,
상세하고 어려운 개발 내용을 요청자에게 잘 설명, 설득하는 능력도
있거나, 있어야 했거든요.

기획자가 고객 요구에 기반한 기능, 서비스, UX에 운영, 개발, 보안까지 챙길 수밖에 없었던 이유입니다.

기왕에 기획자로서 요구사항 분석을 사전 사후로 하러 가게  된다면, 어느 방향으로 나올지 모르는 고객의 질문에 각 업무 단위별 담당자 모두를 데려가서 응대하도록 하는 것은 회사로서는 손실이니, 한 번의 방문에 이해하기 쉽도록 설명해서 재방문의 이슈를 줄이기 위해서는 다방면에 대해 얇지만, 해박해야 할 필요가 있었던 거지요.

그걸 업무 프로세스로 풀어보면 아래와 같습니다. (Before, On, After로 구분할 수 있습니다.)

회사와 팀의 성장을 위해 주도적으로 업무를 수행하고, 이끌어 오는 과정에서, 그만큼 업무 관여도도 여러 방면에 걸쳐 늘어나다 보니, "일이 되도록" 하는데 가장 많이 알고, 할 수 없이 해야 할 부분들이 많이 생긴 거죠. 그래서 그런 질문이 나올 수 있었던 겁니다. (이러니 리더인 제가 팀원들의 원망을 듣는 게 당연.. ㅡ.ㅡ) 

현재는 기술영업, 기술PM 부분의 담당자가 별도로 분리되어 Before 업무 비중을 축소하고, 기획자는 보다 기획 본연의 업무에 집중할 수 있도록 하고 있지만, 역시 바쁘면 구원투수로 불려 다니기는 여전합니다. ^^;;

현재는 일이 되게 만드는 역할이라는 것이 동료들에게 얼마나 기대를 심어주는지 알기 때문에 항상 긴장하고 신중하게 업무를 분석하고, 피드백 하고 있습니다.