(1편) 기획자가 개발자와 일하는 법

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 프로그래머였고, 나 스스로도 컴퓨터관련과를 나와서 개발의 세계에 대해 모르는게 아니다. 더불어 매일 열댓명씩 늘어나는 트위터 팔로워(왜 자꾸늘어나는건지 알수가 없네-_-)들을 꾸준히 지켜본 소감을 말하자면,

대한민국을 통틀어, 개발자만큼 말 잘듣는 착한 사람 없다.

인간답게 대우해주고, 잘하는 것 잘한다 인정해주고, 무리한 것 요구하지 않으며, 무리한 것이라 해도 요구함에 있어 정당성을 갖춘다면 군말없이 해주는 순수한 집단이다. 비전까지 주면서, 이걸 당신이 했을 때 당신은 더 능력있는 개발자가 될것이라는 걸 끊임없이 주입시키면 최상의 조건이다. 고집불통이고, 오덕오덕하며 다른세계에 산다고 생각하고 벽을 쌓아버리는건 기획자, 당신이 아닐까 한다.
의외로 말도 잘하는 편이라 (물론 모국어보다 프로그래밍 언어를 더 잘하는 경우도ㅋㅋㅋㅋ) 도란도란 얘기하며 배우면 기획자로서의 사전지식도 많아지고, 그런 기획자들에게 알려주는 개발자도 더 배우게 되고, 더불어 이 기획자가 뭘 모르는지 알게 되어 욕은 못하게 된다.(ㅋㅋㅋㅋ)
여러모로 윈윈!

너무 개발자만 위한 방법이 아니냐 할지 모르겠다. 어느정도 이런 개발지식과 개발자들과의 커넥션이 형성되고, 짬이 쌓이고 나면… 그때부터는 맘껏 싸워도 된다. 이렇게 하면 되잖아요. 이게 안되면 저런식으로 바꿔서 차선으로 구현해주세요 등등~ 지피지기면 백전백승이다. 개발자하고 싸우고 싶으면, 개발과 개발자에 대해 이해해야지않나? 응? 안그래? (아님 말고… ;ㅁ;)

앱 & 서비스 기획자입니다. 잘하고 싶어요.

  • Pingback: (2편) 개발자가 기획자와 일하는 법 | Minieetea()

  • ckliengt

    ‘대한민국을 통틀어, 개발자만큼 말 잘듣는 착한 사람 없다.’ 라는 말과 그 아래 글들.
    말 자체가 좀 심하지 않나? 지나가다 급짜증 나려함. 개발자가 말을 들어야 한다?
    나 참 어이없음. 전 세계에서 잘나가는 서비스, 거의 다 기획자라는 직업 자체 없이 성공한 사례이다.

    똑바로 알자.

    국내 메이저 기업서 근무 5년 했고, 현재까지 해외 근무 8년차이고, 네군데의 소프트웨어 회사를 다녔고, 현재도 서비스 회사 다니고 있다.
    일반적으로 미국, 캐나다 등지의 소프트웨어 회사에서 개발을 할 때에는, FrontEnd Developer, BackEnd Developer(SD), Business Analyst(BA), Marketer, Business Process Manager(PM), Project Manager(PM), Communitcation Manager로 구성이 되어 있다. 이 사람들은 서로가 채워 줄 수 없는 부분을 채워줄 수 있으며, 애초에 모두가 기획자이다.
    참고로 수많은 글로벌 기업 역시 전문 기획자라는 직업은 애초에 없다.
    대한민국이 말하는 기획 애초에 모두가 기획자이다. 그런거 필요도 없고 있어야 할 이유도 없다.
    일반적으로 개발자가 평균적으로 인터넷 서비스를 일반인에 비해 2배 이상 사용하고 있다.
    일반적으로 Front End Developer는 인터넷 서비스에 있어 일반인보다 유난히 창조적인 획기을 보이고 있으며, Marketer는 컨텐츠의 의도와 전달하려는 주제에 무게를 두도록 한다. BA의 경우 현재의 서비스가 우리의 비지니스에 적합한지를 조율하며, PM은 정확한 방향성을 제시한다.
    애초에 전문 기획자라는 말 자체가, 대한민국에서나 통하는 일이지 기획은 기본 모두의 몫인 것이고, 결국 인터넷 서비스를 하는 데 있어 반드시 필요한 직업은 아니다.

    • 서두에 적었던 것처럼, 기획자 경험이 많지 않은 상태에서 지금까지 겪었던 것들을 정리한 글이었구요. 더군다나 아직 제가 다 적지 못한 부분이 있고, 일종의 연재형식으로 작성하려던 글이었던지라, 일부 그렇게 비춰질만한 소지가 있는 것은 인정합니다.
      개발자는 기획자 말을 들어야 한다고 단정하려던 것도 아니고, 기획자가 자기 주장을 똑바로 하려면, 개발프로세스에 대해 충분히 이해하고, 그 기획이 개발되어야 하는 이유에 대해 타당성을 충분히 가져야 한다는 맥락에서 마무리한 부분이니 기분이 나쁘셨다면 죄송하단 말씀을 드립니다. 의견 감사드립니다.

    • underdrumer

      난 이렇게 자기세상만 잘났고, 남의 세상을 인정못하는 사람들이 있기때문에, 이런글에 감놔라배놔라 하기도 싫어지던데…

      그 말대로라면,
      이런식의 의견도 가능한가?

      태어날때부터 청소부가 존재했나?

      원래부터, 애초부터, 처음부터, 이랬다 저랬다 란 말은
      개발자라는 직업은 처음부터 있었나?
      무슨 말도 안되는원리로, 자신들의 세계가 최고라는 말을 하는지,

      암만 능력있고 실력있어도,
      겸손과 배려를 모르는 인간은 채용을 안하는게 상책이다……….

      그렇게 엄청난 실력을 가진 능력자면,
      왜 지금 그런사람들은 스티브잡스처럼 못살고있나 지금은?

      한가지 쓴것중 왜그런지에 대한 걸 말해보자면,

      왜 우리나라에만 기획자가 존재하냐고?

      그건 우리나라 인간들이 하도 틀에 같힌 교육만 받고 자라서
      창의성이 부족해서거든.

      그래서 창의성을 전문으로 키우는 기획자라는게 생긴것 뿐이야.

      개발자라니까 무슨 외국에 있는 개발자와 같은 느낌인줄 아나본데
      그냥 한국에서 주입식 교육받고 자라서, 생각의 틀이 고정되어있는
      단순하게 프로그래밍만 열심히 하는 개발자일 뿐이란 뜻이지.

      지금, 뭔가 획기적인 아이템이나 사이트, 기술등도 없나?
      그저 자랑이라고 쓰는게, 메이저기업이고 해외기업이고,
      그렇게 다녔는데도, 뭐 하나 세상을 놀라게 할만한 개발이 없나?

      그럴거면, 다른사람들의 직업에 대해서도
      편견이나 쓸데없는 고퀄리티 자존심가지지 말고,
      배려하고 이해하고 서로 협조해가며 일하려고 생각해보는게 좋지않을까 싶다.

      배려와 존중없이 자만심에 가득한 글을 보고 울컥한
      세상에 대한민국밖에 없는 직업을 가진 13년차 기획자.

    • 한국식 교육때문에 기획자라는 직군이 생겼다는 것은 제 생각과 맥락이 같으시네요. 아무래도 영향이 클수밖에 없죠. 주입식 교육을 20년 가까이 받아야 되는 경우가 많으니까요. 그렇다고 해서 기획자가 창의적이라는 생각은 안합니다. 다만 그 창의력이라는 것 자체가 연습과 반복을 통해 어느 수준까지는 키워나갈 수 있기 때문에 그나마 자주 생각하는 기획자가 좀 더 유리한건 사실이니까요.
      의견 감사합니다.

  • light

    기획자로서 굉장히 공감하는 글이네요 ㅋㅋㅋㅋ

    • 아마 10%쯤 공감하셨을 것 같습니다. 분야별로 다르고, 제가 겪은 내용을 바탕으로 작성한 글이니까요?

  • spai006

    위에 올리신 글이 기획자가 개발자들과 일하는 법이라고 적으셨는데,
    제가 보기에는 기획자가 개발자를 다루는 법을 적으신 것으로 보이네요.

    • 글 쓴 취지는 기획자도 개발에 대해 이해하려고 해야한다, 그리고 개발자를 먼저 생각해야 한다. 였는데, 몇몇 단어로 인해 오해하신 것 같기도 하네요. 오해하기에도 충분할만큼 비루한 글 실력이라 많이 부족합니다.

  • bebe

    Reblogged this on Simple ideas, taken seriously.

Sliding Sidebar