긍정적 사고, 음식의 절제, 규칙적인 운동

화성에서 온 개발자, 금성에서 온 기획자

live.lge.co.kr/it_casting/

T 업계에 계시는 분들이라면 여러 프로젝트를 통해 다양한 캐릭터를 가진 기획자와 개발자들을 경험하셨을 겁니다. 기획자와 개발자는 ‘화성에서 온 남자 금성에서 온 여자’의 남자와 여자처럼 아주 가까운 대상이지만 때로는 서로 무슨 생각을 가지고 있는지 도저히 이해하기 힘든 대상이기도 합니다. 오늘은 제가 그들을 이해하기 위한 첫 번째 시간으로 기획자와 개발자에 있어 가장 중요한 역량에 대해 이야기 해 볼까 합니다.

기획자란 사전적 의미 그대로 ‘일을 꾀하여 계획하는 사람’입니다. 즉, 어떤 문제나 과제가 있다면 이를 파악하고, 분석한 뒤 실제 해결할 수 있는 방법과 실행을 위한 준비를 거쳐 결과물이 잘 만들어질 수 있도록 매개하는 사람입니다. 이에 반해 개발자란 ‘새로운 물건을 만들거나 새로운 생각을 내놓는 사람’이라는 의미로 어떤 과제가 주어지면 이를 실제 실행에 옮겨 결과물을 만들어내는 역할을 담당합니다.

즉, 기획자가 무엇을 만들 것인지 잘 설계하면 개발자는 그 결과물을 세상에 선보일 수 있도록 실현을 해주는 존재인 것입니다. IT 업계의 기획자와 개발자도 예외가 아닙니다. 어떤 제품 또는 서비스를 기획자가 기획하면, 실제 개발자는 고객이 사용하게 되는 제품 또는 서비스를 만들어주는 역할을 합니다.

이렇듯 서로 비슷한 듯 하면서 다른 두 그룹인 기획자와 개발자가 갖춰야 할 가장 중요한 역량이 무엇일까요? 저는 단연 ‘커뮤니케이션’을 이야기합니다. 다만, 기획자와 개발자가 집중하는 커뮤니케이션 대상이 다를 뿐인 것입니다. 기획자는 이해관계자들과 수 많은 커뮤니케이션을 하고, 개발자는 컴퓨터와 커뮤니케이션을 합니다. 이런 커뮤니케이션 능력이 바로 각자의 역할에서 얼마만큼의 성과를 낼 수 있는지의 중요한 지표가 되는 것이죠.

기획자는 다양한 이해관계자들과 여러 수준의 커뮤니케이션을 합니다. 이를 통해 그들이 꾀하는 일을 추진할 수 있도록 상대방을 설득하고, 때로는 개발자들과의 커뮤니케이션을 통해 원하는 결과물을 만들 수 있도록 설득합니다. 프레젠테이션 자료부터 프로젝트 개요까지 그들이 작성하는 모든 자료와 문서는 커뮤니케이션을 위해 사용된다고 해도 과언이 아닙니다. 다른 사람들에게 그들의 생각을 전하기 위한 과정인 것이지요.

반면 개발자는 주어진 목표와 일정 내에 결과물을 만들기 위해 그들만의 커뮤니케이션 방식인 프로그래밍 언어로 컴퓨터와 커뮤니케이션 합니다. 하루 일과 중 많은 시간을 일반인들이 이해하기 힘든 프로그래밍 코드를 작성하고, 컴퓨터와 대화를 주고 받는 과정을 통해 결과물을 만들어 가는 것입니다. 프로그래밍에 대한 지식이 없다면 무엇을 의미하는지 이해하기 힘든 것이 바로 프로그래밍 언어이지만 우리가 이야기하는 일상적 언어처럼 고유의 정해진 문법이 있고, 같은 결과물을 만드는 데에도 우리의 일상 언어처럼 표현방법이 무수히 많이 있습니다. 이를 얼마나 효과적으로 표현하고, 잘 다듬는지가 바로 개발자의 역량인 것입니다.

“멋진 서비스를 기획하여 오랜 시간을 설명하였는데 개발자가 나의 의도와는 전혀 다른 결과물을 만들어내는 상황을 경험하셨습니까?”, “분명 기획한 결과물대로 개발을 하였는데 만족스럽지 않다고 다시 개발해달라는 기획자가 이해되지 않으십니까?” 서로에 대해 오해하지 말고 각자가 중요하게 생각하는 커뮤니케이션 대상이 다르다는 것을 이해하고, 인정해 보시기 바랍니다. 그들에게는 커뮤니케이션 역량이 바로 능력을 보여주는 덕목이기 때문입니다.

이 세상의 수 많은 기획자와 개발자의 오해가 사라지는 그날을 위해…

개발자가 기획자를 쓸모 없다고 오해하는 이유

live.lge.co.kr/it_casting_3/

개발자들이 기획자에 대해 가지는 편견 중 하나가 바로 ‘기획자가 무엇을 하는지 모르겠다’는 것입니다. 실제 개발자 커뮤니티를 보면 기획자에 대한 불만의 글들을 종종 볼 수 있답니다. 기획자의 기획물이 개발자 본인이 생각하는 수준에 미치지 못한다 등 개발자 본인이 기획을 해도 훨씬 잘 만들 자신이 있다 등 다양한 의견을 볼 수 있습니다. 심지어 기획자들은 개발할 때 귀찮은 작업들을 대신해주는 사람들이라는 의견과 개발자 본인이 기획해도 훨씬 좋은 서비스를 만들 수 있다고 확신하는 개발자까지 있습니다.

이것이 바로 개발자들의 눈에 비춰진 기획자들의 모습입니다. 바로 ‘뜬구름 잡는 사람들 또는 귀찮은 일을 대신해 주는 사람들’이라는 것이죠. 오랜 기간 개발자 생활을 하였던 저도 왜 이런 생각을 하는지 공감하는 부분이 있습니다만 단순히 눈에 보이는 것이 기획 업무의 전부가 아니다라는 것을 제대로 이해하지 못해서 일어난 오해라고 생각합니다. 오늘은 이런 개발자들의 오해를 풀기 위해 기획자들의 기본적인 업무에 대해 소개하고자 합니다.

③ 개발자들이여, 기획자가 하는 일은 생각보다 많다

기획(企劃)은 한자로 ‘도모할 기’와 ‘그을 또는 계획할 획’의 조합으로 ‘계획을 도모하는 것’입니다. 그래서 영어로 기획을 Plan이라고 하지 않고, Planning이라고 합니다. 한 마디로 기획이란 ‘Why to do?’와 ‘What to do?’를 명확히 하는 것으로써 ‘왜 할 것인가?’와 ‘무엇을 할 것인가?’를 결정하는 것입니다. 이에 비해 계획은 ‘How to do?’ 즉, ‘어떻게 할 것인가?’를 정하는 것입니다. 왜 할 것인지를 결정하는 것이 기획이고, 어떻게 할 것인지를 생각하는 것이 계획입니다. 즉, 기획을 다시 한번 더 정의하면 기획자의 의도가 반영된 계획을 도모하는 일이라는 것입니다.

기획의 분야는 너무나 많습니다. 이 중 오늘은 개발자들과 함께 협업하는 분야인 서비스 기획(인터넷, 앱) 분야에 한정해서 기획자의 업무들에는 어떤 것들이 있는지 살펴보겠습니다. 서비스 기획이란 고객에게 웹과 앱을 통해 새로운 서비스를 제공하기 위해 기획하는 일입니다. 이를 위해 다음의 업무들에 참여하고, 내부 의사결정을 내립니다. 물론 회사의 규모에 따라 다음의 업무에 대한 절차와 복잡도는 줄어들 수도, 늘어날 수도 있습니다.

서비스 기획 업무

위 도표에서 보듯이 서비스 기획자는 크게 시장조사, 서비스 기획, 서비스 개발, 서비스 마케팅, 서비스 운영의 단계에 참여하게 됩니다. 많은 개발자들은 서비스 개발 단계의 서비스 기획 1차 이후의 단계에서 기획자들과 협업하지만 기획자들은 하나의 서비스를 만들기 위해 시장조사부터 전략 수립, 회사 내 의사결정 수렴 및 서비스 개발 이후의 단계까지도 많은 영역에서 다양한 부서의 담당자들과 함께 협업을 하고 있습니다. 물론 회사 규모가 작은 경우라면 한 두 사람이 모든 영역을 담당할 수도 있고, 또는 생략하는 경우도 있습니다만 해당 서비스가 커지고, 참여하는 사람이 많아지면 분명 각각의 단계가 서로 다른 사람들에 의해 진행되는 모습을 볼 수 있습니다.

서비스 기획을 단순히 서비스 기능을 정의하고, UI를 그린 후 개발자에게 넘기는 활동이라고 너무 좁게 생각하지 마시기 바랍니다. 물론 개발자들이 보는 결과물은 서비스 기획서, 요구사항 정의서가 전부인 것처럼 보이더라도 이런 결과물을 만들기 위해 내∙외부 조직들과 많은 커뮤니케이션과 협조를 끌어내는 것까지 숨어있는 활동이 많다는 것을 이해하면 좋겠습니다.

때로는 기획자들이 구현 불가능한 터무니 없는 기능을 개발해 달라고 해서 화가 나십니까? 비현실적인 일정과 이미 시장에 있는 다른 서비스와 유사하거나 또는 많은 서비스들의 장점을 마구잡이로 합쳐서 그저그런 서비스처럼 보입니까? 하지만 제대로 된 기획자라면 기획서 한 페이지, 기능 하나를 정의하더라도 이 서비스를 쓰게 되는 고객의 입장에서 어떤 가치와 어떤 영향력을 줄 것인지에 대해 많은 고민을 하고 있는 사람들입니다. 가끔은 그 결과물이 개발자의 눈에는 초라하게 보일지라도 기획자를 존중하고, 고객의 입장에서 서로 같은 방향을 두고 협업한다면 분명 의미 있는 서비스가 탄생할 것입니다. 성공적인 프로젝트, 성공적인 서비스를 위해 기획자의 업무를 조금 더 넓은 시각으로 이해해 보심이 어떨까요?

[개발人] 송창현 “개발자도 기획자다”

http://www.bloter.net/archives/166736

‘스스로 원하는’ 개발자가 되는 게 중요

송창현 연구센터장은 이 때 얻은 경험을 바탕으로 현재 네이버 개발자들을 가르친다. 2008년 네이버에 입사해 기술혁신센터를 비롯해 다양한 개발 조직을 이끌면서, 개발자들이 최대한 자유롭고 즐겁게 개발하면서 동시에 열정적인 개발자가 될 수 있는 환경을 조성하려고 노력했다. 실제로 그가 수장이 돼 운영하는 네이버랩스실 한 쪽 벽면에는 다음과 같은 글이 적혀 있다.

1. 팀이 없는 것처럼 협업하라. 같이 일을 하게 되면 자리를 옮겨서 같이 해라.
2. 지시하지 말고 토론하라.
3. 자신이 무엇을 하고 있고, 무엇을 잘 하는지, 무엇을 하고 싶어하는지 알려라.
4. 핵심기능·기술에만 먼저 집중하여 작게 시작하여 완성하고, 자신을 성장시키며 제품도 같이 성장시켜라
5. 자신보다 더 똑똑한 사람을 뽑아라. 단 팀플레이어만.
6. 자신과 생각이 다른 사람들과 가까이 하라. 불편함을 우정으로 풀어라.
7. 빠른 성장과 진행을 위해 팀을 작게 만들어라.
8. 잘못되어 가는 것이 보이면 빨리 뒤집어라. 고칠것이 있으면 자신이 고쳐라.
9. 자신이 만들고 있는 것이 어떤 유저의 어떤 문제를 해결하는지 자신에게 물어라
10. 항상 유저를 찾고 그들과 소통하라
11. 지식 공유를 하지 않는다는 것은 자신이 성장하고 있지 않다는 이야기다.
12. 결코 어른이 되지 마라. 기술에 대한 열정과 마음은 그대로 남아 있어라.