기획할 때 모르면 큰일 나는 개발지식
안녕하세요 저는 IT에이전시의 기획자 위치에서 협업을 경험한 밀룩이라고 합니다.
아마 이 글을 보신 대부분은 서비스 기획자를 꿈꾸거나 서비스 기획자로 현재 일하고 계신 분일 수 도 있을 것입니다.
그런 분들이라면 최고의 고민중 하나는 바로 개발이라는 큰 벽일 것입니다.
이 개발을 어디까지 알아야하고, 개발자랑 소통하려면 어떻게 해야하고, 왜 자꾸 개발자는 안된다고만 할까?등 각자 가진 고민들이 정말 많을 것입니다.
기획과 현재 개발을 하고있는 저로써는 기획자는 왜 그런 고민을 가질수밖에 없는지와 개발자는 왜 그렇게 답할수 없는지에 대해 명확하게 알고 있습니다.
앞선 기획자들의 고민들을 해결하고자 IT서비스에서 필요한 개발지식을 제가 전달드리고자 합니다.
만약 이 글을 끝까지 보신다면, 여러분들은 왜 개발자들이 그렇게 수동적일수밖에 없는지에 대해 조금이나마 이해가 될 것이고, 그런 사람들에게 어떻게하면 긍정적인 반응을 이끌어낼지에 대해 알게될 것입니다.
또한 아직 기획자를 꿈꾸고 있는 분들이라면 이 글 뿐만아니라 개발을 몰랐을때의 기획자의 인사이트를 제공한 칼럼들이 있으니 보는 것도 추천드립니다
그럼 거두절미하고 서비스 기획자는 왜 개발자와 소통이 힘들까에 대해 이야기 드리도록 하겠습니다.
첫번째 이유는 여러분은 개발에 대한 Flow를 모르기 때문입니다.
여러분께 한번 물어보도록 하겠습니다. 지금 여러분은 개발이 어떻게 시작되고 어떻게 마무리돼서 고객들에게 인수인계되는지 아시나요?
"뭐 그냥 코드로 구현해서 프론트엔드, 백엔드 나누고 서버 연동해서 하는거아닌가? "
아마 이정도로 알고 있는거면 상위 50% 이상이라고 말할 수 있습니다.
대부분의 서비스 기획자 분들은 개발을 모른다면 어떻게 개발이 시작되고 그안에선 어떤 일이 벌어지는지 구체적으로 모를것입니다.
서비스 기획자라는 직업은 다른 기획자와 달리 유저플로우, 스토리보드등 IT지식을 어느정도 가지면 할수 있기 때문에 개발을 모르더라도 할수 있게됩니다.
즉, 접근성이 생각보다 낮습니다.
예를들어, 우리가 인테리어를 한다했을때, 어떤식으로 꾸밀지에 대한 인테리어 기획을 한다고하면 어떤 자재를 활용해서 어떻게 배치할 것이고, 그렇게 해야하는 이유에 대해 잘알지 못할 것입니다.
마찬가지로 서비스 기획자도 결국엔 IT서비스를 만드는것이기 때문에 기획자라고 하면 반드시 개발지식을 알고 있어야 개발자들과의 소통이 원활하고 프로젝트를 실패하지 않게 될것입니다.
서비스 기획자임에도 불구하고 고객사 또는 내부 팀원들과의 협업 프로젝트에서 필요한 기능이 얼마나 시간이 걸리는지 모르기 때문입니다.
예를 들어 회원가입, 로그인 기능을 구현해야한다고 했을 때 이 기능들을 3단계 혹은 5단계로 분리해야되는 사실을 알고 계신가요?
[로그인/회원가입 예시]
1단계 (가장 Lean한 단계) : 구글 / 네이버 / 카카오 / 애플 로그인
2단계 (중간단계) : 자체회원가입 & 구글 / 네이버 / 카카오 / 애플 로그인
3단계 (고차원단계) : 회원별 로그인 분리 (관리자, 일반유저) & 자체 회원가입 & 구글 / 네이버 / 카카오 / 애플 로그인
이렇게 분리를 하고 각 단계별로 우리 개발팀이 얼마나 시간이 걸리는지 미리 정리를해야 개발 기능에 따른 시간도 측정이 가능하고 프로젝트 일정에 맞춰 세세한 개발기획이 가능한 것입니다.
이런 개념들을 모르고 프로젝트 일정을 짠다던지, 서비스 기획을 한다던지등을 하게되면 개발자들의 뜨거운 눈총을 받게되고 아무래도 성공률이 높은 프로젝트를 할수있다고 장담할 수 없습니다.
또한 어디까지 개발 기능을 요청해야할 지 모르는 근본적인 문제는 여기에서 오기때문에 여태까지 개발자의 태도들은 개발자가 너무 수동적이어서 안해주는거야등의 내용들이 정답이 아닐수도 있다는 것입니다.
기능에 따른 시간 측정이 이미 파악하기 위해 우리 개발팀의 효율을 개발팀장 혹은 기획자가 측정하고 그에 맞게 기획한다면 개발자의 소통에서 크게 트러블날일이 없어지게 됩니다.
=> 이러한 총관리를 하는 것이 바로 PM(Project Manager)가 하는 일
다만 주의해야할점은 기능별 시간은 반드시 근거있게 측정해야한다는 것입니다. 이시간안에 가능할거같은데? 라는 추상적인 의구심은 오히려 개발자를 화나게 할수 있게 됩니다.
그럼 너가 직접와서 만들어봐와 같은 공격적인 태도가 마음속에서 생길 수도 있기 때문에 근거있게끔 기능별 시간 측정이 필요한데요.
어떻게 하면 기능별로 정확한 시간 측정이 가능할까요? 이에 대한 내용은 2편에서 다뤄보도록 하겠습니다.
지금까지 서비스 기획자는 왜 개발자와 소통이 힘들까?에 대한 이야기를 풀어보았습니다.
아마 많은 분들이 공감하실 것이고 다른분들은 아닌것같은데... 라는 의견도 제시할 수 있습니다. 각자 처한 상황은 다를수도 있을것이니 당연한 것입니다.
그런 분들도 다음 이야기, 다다음 이야기에선 더 공감하고 배울게 있는 칼럼을 쓰도록 노력하겠습니다.
다음이야기는 소통이 힘들다면 어떻게 극복하는지에 대해 가르쳐드리고자 하는데요. 빠른 시일내에 쓸수있도록 노력하겠습니다.
긴 글 읽어주셔서 감사드리고 더 좋은 글로 찾아뵙겠습니다.