여기서 “기획자”란, 사업을 시작하려는 “예비창업가” 입니다.
비슷한 역할을 하는 “서비스 기획자”들을 지칭하기도 합니다.
벤처를 다니다 보면, 잡오퍼가 들어옵니다.
옮길 생각이 없냐는 거죠.
혹시… 싶어 만나보면
달랑 사업계획서 한 부 들고 있습니다.
어떤 경우는 사업계획서도 없고,
서비스 기획서만 가지고 있습니다.
두 개 차이를 구분하지도 못합니다.
아… 난감합니다.
어떻게 말해야 할지…
어쨌든 이들은 개발자를 간절히 구합니다.
좋은 개발자를 만나기만 하면,
자기 꿈이 이루어질거라 생각하죠.
사장님들 이야기 같지만,
서비스 기획자들도 이렇습니다.
대부분 같은 마음이죠.
재미난 건, 개발자들이 이런 마음을 잘 모른다는 겁니다.
개발자들은 대부분 사람에 대해 서툴고,
“기계적인 구현”에만 관심 있기 때문입니다.
그래서 합류해놓고 싸웁니다.
우당탕탕 하다 헤어지죠.
사업은 죽도 밥도 안됩니다.
음…
이런 일이 안 일어나면 좋겠는데,
생각보다 개발자들이 무심합니다.
그래서 정리해 보았습니다.
개발자들이 알았으면 하는 이야기.
“기획자들은 개발자를 어떻게 생각할까?”
01. 꿈을 이루어줄 소중한 사람
기획자들은 자기 기획을 굉장히 소중하게 생각합니다.
자기 자신과 동일시 하기도 하죠.
그래서 개발자를 구원자처럼 생각합니다.
내 꿈을 이루어줄 사람 말이죠.
그래서 매우 어려워 합니다.
어떻게 시작해야 할지 몰라 쩔쩔매죠.
그런데 그걸 개발자들이 모릅니다.
대화가 안통하고 빙빙 둘러 말하고,
뭔가 뚜렷하게 안 떨어지니까,
무얼 만들어야 할지 모릅니다.
그래서 화를 냅니다.
틱틱대며 싸우다 나가 떨어지고 맙니다.
이런 상황을 개발자들이 알아야 합니다.
어쨌든 이렇게 만났다는 건 두사람 모두에게 기회니까요.
이 문제를 해결하려면,
대부분 개발자들이 마음을 열고 다가가야 합니다.
기획이 서툴러도 이야기가 잘 안되어도,
따뜻한 마음으로 설명하고, 함께 답을 찾아야 합니다.
틱틱대고 선을 그으면서
마음의 선을 넘지 않는다면,
일이 잘되기는 힘들다고 봐야 합니다.
02. “기대”할 뿐 “예측”하진 못함.
기획자는 많은 것을 결정하는 자리입니다.
자기가 먼저 상상했기 때문이죠.
그런데 생각보다 많은 것을 결정하지 못합니다.
구현되는 실제 부분을 모르기 때문이죠.
“이렇게 되면 좋겠다” 이야기를 하지만,
그렇게 하면 원하는 결과가 만들어지는지 전혀 알지 못합니다.
그래서 개발자가 뭐라고 이야기해주길 원합니다.
반면 적지 않은 개발자가 이야기 도중에 포기합니다.
대화가 잘 안되니 결정해서 달라고 합니다.
그런데, 모든 실패는 거기서부터 시작되죠.
의사들은 어려운 의학용어를 쓰지않고,
쉬운 용어로 환자에게 설명을 합니다.
그러면 환자가 훨씬 더 쉽게 선택을 하죠.
개발자와 기획자의 대화는 그래야 합니다.
“기획자가 명확히 이야기해주지 않았어!”
“기획자가 잘못 결정한거야.”
책임을 넘겨봐야 좋아지는 건 없습니다.
문제를 해결하지 못하면 같이 망하는 거니까요.
03. 자신이 무얼 원하는지 모른다.
기획자들은 자기가 원하는 게 무엇인지,
생각보다 정확히 모릅니다.
그걸 그렇게 개발했을 때 그게 그렇게 동작할텐데,
그게 원래 만들려고 했던게 맞는 것인지,
진짜로 알지 못합니다.
엔지니어가 아니기 때문이죠.
그렇게 개발했을 때 그렇게 동작하는지
어떻게 알 수 있을까요?
한번도 개발해본 적이 없는데 말이죠.
그래서 스펙을 정해서 달라고 하면,
스펙을 제대로 정리하지 못합니다.
스펙이란 것 자체가 기술자 용어거든요.
그런데 스펙 쓰는 걸 기획자한테 맡깁니다.
그건 망하자고 말하는 거나 같은 의미입니다.
그런 회사가 없을 것 같죠?
아니오, 아주 아주 생각보다 많습니다.
좋은 개발자는 기획자와 대화를 통해 일합니다.
기획자와 함께 토론하면서 스펙을 만듭니다.
대화를 해야 내용을 몸 밖으로 꺼낼 수 있으니까요.
04. 아는 것처럼 보이지만, 모른다.
짬이 많은 기획자는 마치 개발가처럼 용어를 씁니다.
그런데, 사실… 개뿔도 모릅니다.
빅데이터… 운운해도, 그게 얼마나 걸리는 일인지,
어떻게 구현해야 하는지 전혀 알지 못합니다.
그래서 잘 안다고 생각하고 소통하면, 100% 실패합니다.
중요한 결정을 해야 할 때, 엉뚱한 선택을 하게 됩니다.
기획자는 기술을 모른다고 생각하세요.
짬이 아무리 많더라도 말이죠.
그냥 개발자가 나머지를 챙겨서 일해야 합니다.
05. 웹에이전시 기획자
웹에이전시 기획자들은 반복된 일을 합니다.
웹 페이지를 스케치하고 개발자에게 일을 던집니다.
그걸 1년 정도 하면 마스터가 됩니다.
일이 반복되기 때문에 소통방식도 정형화되어 있습니다.
그래서 개발자들에게 요구사항을 일방적으로 쏟아냅니다.
그래도 일이 됩니다.
일과 기술이 다 고만고만하기 때문입니다.
그래서 범위를 벗어나면 당황하기 시작합니다.
일방적인 전달로는 해결되지 않거든요.
스타트업처럼 삐뚤빼뚤 새로운 길을 찾는다면,
분업으로는 해결되지 않습니다.
서로의 역할에 빈틈이 생기는데,
기획자 혼자 모든 걸 생각할 순 없습니다.
서로의 입장에서 이해하며,
서로의 이야기를 해야 빈틈이 메꿔집니다.
기획자는 꿈을 꾸는 사람이고, 그림을 그리는 사람입니다.
개발자는 그걸 이해하고 구현하는 사람입니다.
기획자들에게 모든 책임을 미루지 마시고,
그들이 꿈을 꿀 수 있도록 손을 가볍게 해주세요.
그게 스타트업 개발자의 역할입니다.
SI 개발자와는 다르죠.
※ 참고 : SI 의 한계
1990년대 후반.
대한민국 최첨단 IT기술이 “Window 95 + 엑셀”이던 시절.
“갑” 들은 전산을 모르는 일반직원들이었습니다.
이 때 SI 회사들은 더 좋은 제안, 새로운 제안을 하기도 했습니다.
하지만, 나쁜 개발사 때문에 일을 망치다보니,
각 회사는 프로젝트를 관리하기 위한 전산실을 만들었습니다.
그래서, 제안, 개선, 기획작업은 내부 전산실이 하고,
SI 업체들은 단순 구현에만 집중했습니다.
그렇게 일처리가 분업화되고, 구현은 용역외주로 고착화됩니다.
그런데 분업이란, 반복적인 일상업무를 효율적으로 처리하기 위한 방법입니다.
시장을 탐색하며 새로운 발견을 해야 하는 스타트업 일은 분업으로 안됩니다.
모든 정보를 한데 모아 바라보고, 분석해야하기 때문입니다.
그래서, SI 현장은 책임공방만 무수할 뿐 되는 일이 없습니다.
그렇게 익숙해진 기획자와 개발자도 마찬가지죠.
분업형 개발자는 스타트업에 맞지 않습니다.
빈틈을 메꿀 수 없으니까요.
문제를 해결할 수 없죠.
스타트업은 서로 머리를 맞대야만, 해결되는 분야입니다.
개발자들이 기획자를 이해하고, 함께 해야 하는 건 그 이유 때문입니다.
그 차이를 알고 일을 하면 좋겠습니다.
끝.
IT의 중심에서 