2편-개발자가 기획자와 일하는 법 이라는 글도 있어요. 그리고 "3편-개발자vs기획자, 피드백과 달라진 생각들"에 대해서도 써볼까합니다.
-------모티브는 여기에서.
개발자와 일하는 법 ( 원문링크 ) by Julie Zhuo / Product design director @ Facebook
아무래도 디자이너 입장에서 적어내려간 내용이다 보니 국내와는 맞지 않는 부분도 있어 조금 한국적인 방법으로 풀어보려고 한다.
자칭 기획자가 개발자와 일하는 법! ㅋㅋ 숫자와 관련된 모든 언급은 100% 추측이므로 감안하고 봐주셨으면! (왜냐면 야매니까~)
그리고 5~6년차 고급기획자분들을 위한 글은 아니다. 그냥 기획자 지망생이나, 기획자 1,2년차 정도가 적당한 대상독자가 될 것 같다.
개발자는 ‘을’이 아니다
- 물건취급 하지말 것. 개발자도 사람이다.
- 기획자 감투쓰고 쓸데없는 고집부리지 말 것. 갑도 아니면서.
개발자는 리소스가 아니다. 그렇지. 근데 리소스 취급이면 그나마 낫다고 본다. 거의 부품수준으로 취급해버리는 국내 개발실정에 비춰볼 때, 인간적인 대우를 받아가며 개발자로서의 역량을 펼치는 사람은 50%도 안된다고 본다.
( 관련영상 : SI 프로그래머의 현실 )
원인은 IT업계의 중추적 역할을 수행하는 개발자를 ‘을’취급하는 임원급관리자와 실무기획자라고 본다.
임원급 관리자들은 을취급 하다못해 부품취급을 하기에 1명이 2달 걸리는 프로젝트에 4명을 넣으면 보름이면 만들 수 있다고 생각해버린다.
임원들이야 일을 어떻게 하는지 잘 모른다고 가정하고 관대하게 넘어가보자.
무엇보다 기획자가 문제다.(본격 디스? 나도 기획자라는 거.) 통상 기획자라고 명했으나, 기획자일수도 있고, 디자이너일수도 있고, 일정관리 위주의 PM일수도 있다.
그중에 가장 많이 부딪히는 기획자와 싸우는 가장 큰 이유는 ‘그냥 해주세요’ vs '못해요(아니 안해요-_-! 내가 왜?)' 레벨의 대화일까.
개발자가 왜 못하는지, 그리고 되더라도 그렇게 하면 안되는 이유를 설명하더라도 ‘기획서에 있는거니까’, ‘그럼 한번 돌아가는거 보고 다시 얘기해봅시다’, ‘다 생각해서 한거예요. 그냥 해줘’ 라는 논리(라고 쓰고 지랄이라고 읽는다)로 강하게 어필하는 경우가 왕왕 있다.
이런 저런게 필요하다고 해서 기획자에게 요구사항을 말해도, 기획자의 숭고한 회의 일정에 밀려 정작 피드백을 늦게 받거나 하는 상황에 있어서도 ‘줬으니까 됐지? 언제까지 만들어줘’의 고집을 부리는 것도 봤다.
내가 이제까지 말도 못하고 봐왔지만, 내 블로그니까 한 줄을 빌려 얘기하자면 ‘작작 좀 해라’
개발자는 ‘아이언맨’이 아니다
- 기획서를 점검해보자. 기획자 실명제로 오픈소스로 올릴만한 퀄리티인지.
- 내가 갖고 싶은대로 끊임없이 요구하자. 최대한 구체적으로.
개발자가 똑똑하긴 하지만, 컴퓨터와 철조각만 있다고 로봇을 만들어내는 토니스타크가 아니다. 코딩하다가 손놓고 기획서만 뚫어져라 쳐다보고 있는 개발자를 보는 기획자의 시각은 둘중에 하나일거다. ‘뭐가 부족한가?’ vs ‘왜 일안하지?’
지금 그 개발자에겐 기획서에 온통 물음표만 보인다는데 왼손모가지를 건다. 기획자가 쓴 용어들은 개발용어가 아니라 기획용어에 가까워 실제 개발에서 부르는 컴포넌트명, 메소드명도 아닐 뿐더러 몇몇 기획자들은 잘난척하느라 인터넷에서 주워들은것도 막갖다 쓰기도 하니까.
기획자는 생각하는 사람이다. 그리고 그 생각을 개발자는 실물로 만들어준다. 그 가운데서 통신병 역할을 하는 녀석은 기획서라는 문서 쪼가리 몇장이다. 문서에 다 적지 못하는 애매한 것들은 구두로라도 설명해야된다. 손그림 발그림이라도 그려서 대충이라도 말해줘야 한다. 기획서만 띡 던져주고, 개발해라 하는건 여러모로 아닌게다.
디자이너 포함해 보통 3~5명을 최소한의 팀이라면 더 좋다. 기획서를 잘 쓸 자신이 없으면 그냥 옆에 붙어서 쫑알쫑알 얘기해가며 해도 된다고 본다.
1 to Call이라는 앱을 개발할 때에는 애니메이션을 글로 표현할 방법이 없어서, ‘상세 페이지가 위에서 퉁 하고 떨어지며, 필드들이 차르륵 펼쳐졌다가 팅 하고 살짝 튕기며 올라가 제자리로 위치하게 구현해달라’고 설명했다. 내 의성어와 의태어를 이해할때까지 그림으로 그려가면서 -_-; (첨보는 사람은 그게 말이야 막걸리야 하며 비웃겠지만)
아 그러고보니, 와이어프레임의 영역을 텅비워놓고 당신의 크리에이티브로 알아서 채워주세요 하는 사람도 봤다. 기획자 크리에이티브는 얼어죽었나? 왜 개발자한테 그걸 채우라는거여… 하라는대로 개발하기도 빡센 사람한테.
개발자는 ‘도큐먼트’가 아니다
- 개발 못한다고 무시하지 말자. 적어도 당신보다는 잘한다.
안드로이드 개발자라고, 아이폰 개발자라고 모든 것을 해보고 할 줄 아는게 아니다. 하다보니 배우는거고, 그러다보면 업데이트되면서 새로운게 추가되는거고, 그러다보면 그걸 또 하게되고…
내가 기획자에게 들은 개발자에 대한 편견 중에 ‘할 줄 알면서 개발하기 귀찮아서 못한다고 한다’라는게 있었다.
단언컨데, 개발자도 못하는게 있다. 그게 자의든 타의든간에. 디바이스의 한계가 있어서 하고싶어도 못하는게 있을 수 있고, 아직 안해봐서 못하는게 있을 수 있다. 전공분야가 아닐수도 있고. 개발직군은 자기 영역에 대해 자부심과 자존심이 강한 직군이라 ‘못한다’라고 얘기하는 걸 어려워하기도 한다. 그럼 같이 검색해줄 수도 있고, 같이 고민해볼 수도 있다. 안되는걸 되게 하기 위해서 기획방향을 바꿀 수도 있고, 내가 보고싶어 하는 기능을 좀 더 수월한 방식으로 구현할 수 있도록 우회로를 터줘야 하는게 기획자의 역할이라고 생각한다. 그런 식으로 아이디어를 공유해보다보면 새로운 방식이 생각나 다른 방식으로 코딩할 수도 있다.
그냥 저 개발자는 실력이 없네.. 하고 말아버리는 기획자들은 뒤에서 개발자들이 숟가락 집어 던지며 그럼 니가 코딩하던가!! 하며 씹는것도 모를거다.
그 외에
- 기획서를 버전으로 관리하자
회의를 통해 기획이 수십번씩 갈아엎어지다보면 기획서도 함께 업데이트 되어야 한다. 간혹 파일명 1개로 (프로젝트기획서.pptx) 기획서를 공유하며, 지난주에 수정한 버전을 공유했는지, 방금 수정한 버전을 공유했는지 까먹을 때가 있다. 내가 제일 툴툴대는 부분이기도 한데, 기획서도 Github처럼 버전관리를 할 수 있었으면 좋겠다.
- 최소한 로직은 공부하자.
내 프로그램이 어떤 프로세스를 거쳐 돌아가는지 정도는 알아야 되지 않을까. 개발문서까지 보면 좋겠지만, 어떻게 돌아가는지 정도라도 이해하려고 노력해야 한다. 개발자가 알아서 하겠지. 라고 두지 말고, 옆에 앉아서 물어보자. ( 검색은 귀찮으니까? ^^* [퍽!] )
- 질문하자. 몰라도 아는 것처럼, 알아도 모르는 것처럼.
개발을 배우자. 그리고 관심있게 이것저것 찾아보자. 용어정의가 헷갈리면 물어보면 된다. 로직이 헷갈리면 물어보면 된다. 제약조건이 많으면 그 또한 물어보자. 이때 써야하는 대사는 “알려주시면 고려해서 기획하려구요.” 개똥같은 기획서를 받지 않기 위해서 개발자는 아는만큼 알려주고, 알려주다 애매하거나 헷갈리는게 있으면 찾아서 알려주고, 찾다가 이런게 있다고 또 새로운걸 알려주게 될거다. 그럼 “아 그렇구나. 잘 생각해서 기획할께요”하면 된다. 나이스샷~ 개발자를 잘 조련한 셈이다. 기획할 내용에 대해 미리 스터디를 시킨 셈이니. (물론 당신도 스터디를 한 것!)
- 상사에게 휘둘리지 말자
우선 개발이 들어가기 시작하면 내가 최종본이라고 찍은 기획서를 개발하는 개발자들의 편을 들어줘야 한다. 사장이 그건 좀 별론데? 라고 했다고 해서 그럼 바꾸겠습니다! 하는게 아니라, 그건 이런저런 기획의도를 가지고 있고, 개발자들이 열심히 개발하고 있는 부분이니 지금바꾸는건 아니라고 봅니다. 라고 쉴드쳐줘야 한다. 바꾸겠습니다! 라고 하는건, 내 얼굴에 침뱉는거라는것도 잊지 말자. 그 정도도 고려안하고 기획한데다가, 그걸 개발자에게 내똥치워줘라고 던지는건 실력없는 기획자라는걸 공인하는 셈이다.
- 개발자 말을 들어주자
일정을 짤 수 있는 권한이 있다면, 개발자의 말을 믿어주자. 언제까지 개발할 수 있을 것 같다는건 개발자가 산정하는 부분이니 기획자맘대로 정해서 던지지는 말자. 그리고 너무 길다 싶으면 너무 긴것 같다고 말하면 된다. 기획자가 PM이라는 가정하에 말하는 것임. 만약 약속한 일정이 틀어지면 그때 다시 불러서 이러저러한 사정을 듣고, 그때 쪼던지, 일정을 조절하던지 하면 되는 일이니까.
- 근데, 개발자 말을 다 믿지말자
이건 인기있엇던 블로그 글로 토스. 개발자가 3일이라고 말하면 팀장님은 한달이라고 들으세요
급 마무리하며
요즘들어 긴 글의 마무리가 어려워졌다. 여튼 급마무리하자(꼬리밟히기 전에 :b)
내 가정환경도 컴퓨터공학자들의 피가 흐르는 집안에서 자란데다, 전전전남친, 전전남친, 전남친 모두 컴퓨터과 or 프로그래머였고, 나 스스로도 컴퓨터관련과를 나와서 개발의 세계에 대해 모르는게 아니다. 더불어 매일 열댓명씩 늘어나는 트위터 팔로워(왜 자꾸늘어나는건지 알수가 없네-_-)들을 꾸준히 지켜본 소감을 말하자면,
대한민국을 통틀어, 개발자만큼 말 잘듣는 착한 사람 없다.
인간답게 대우해주고, 잘하는 것 잘한다 인정해주고, 무리한 것 요구하지 않으며, 무리한 것이라 해도 요구함에 있어 정당성을 갖춘다면 군말없이 해주는 순수한 집단이다. 비전까지 주면서, 이걸 당신이 했을 때 당신은 더 능력있는 개발자가 될것이라는 걸 끊임없이 주입시키면 최상의 조건이다. 고집불통이고, 오덕오덕하며 다른세계에 산다고 생각하고 벽을 쌓아버리는건 기획자, 당신이 아닐까 한다.
의외로 말도 잘하는 편이라 (물론 모국어보다 프로그래밍 언어를 더 잘하는 경우도ㅋㅋㅋㅋ) 도란도란 얘기하며 배우면 기획자로서의 사전지식도 많아지고, 그런 기획자들에게 알려주는 개발자도 더 배우게 되고, 더불어 이 기획자가 뭘 모르는지 알게 되어 욕은 못하게 된다.(ㅋㅋㅋㅋ)
여러모로 윈윈!
너무 개발자만 위한 방법이 아니냐 할지 모르겠다. 어느정도 이런 개발지식과 개발자들과의 커넥션이 형성되고, 짬이 쌓이고 나면... 그때부터는 맘껏 싸워도 된다. 이렇게 하면 되잖아요. 이게 안되면 저런식으로 바꿔서 차선으로 구현해주세요 등등~ 지피지기면 백전백승이다. 개발자하고 싸우고 싶으면, 개발과 개발자에 대해 이해해야지않나? 응? 안그래? (아님 말고... ;ㅁ;)
