철수네 소프트웨어 세상 [본점]

소프트웨어와 관련이 있다면 뭐든지 – I no longer work for Microsoft.

"개발자와 기획자, 상생의 길"을 읽다가…

with 7 comments

Linus Home 개발자와 기획자, 상생의 길 – 해당 프로젝트에서 좋은 해결방안을 찾은 경우인 것 같고 프로젝트가 잘 되었다고 하니 툴을 만들기 위한 시간이 스케줄에 영향을 많이 미친 것도 아닌 것 같구요. 이런 해결책을 적용할 수 있는 프로젝트(혹은 그 종류)가 많지는 않을테지만, 이 경우를 한가지 예로 생각하고 조금 더 광의에서 생각해봅니다.

다음과 같은 기본적이고도 당연한 가정을 일단 생각해봅시다:

  1. 기획자가 기획을 한다.
    개발자나 다른 사람들로부터 피드백을 받거나 할 수 있지만, 결국 기획은 기획자가 하는 것이다. 그러니 기획에 대한 책임은 기획자가 지는 것이다.
  2. 개발자는 기획자가 만들어 놓은 틀에서 개발 결과를 만들어낸다.
    기획자가 문서로 주었든 말로 전달을 했든 결과는 개발자가 만들어내는 것이다. 개발자는 전달된 내용으로 구현을 하는 것이 책임이다.
  3. 기획이 완벽할 수 없으며 틀이 갖춰지지 않은 부분의 구현은 서로의 책임이다.
    기획자는 구멍을 만든 책임, 개발자는 구멍을 때운 구현의 책임.

위의 것은 잘 지켜지지 않습니다. 서로 이해하지 못하는 이유인데 다음의 것들을 생각해봤습니다:

  1. 기획은 반드시 바뀐다.
    기획자의 책임이니 아니다 싶으면 바꾸게 되는 것은 당연하죠. 바뀐 기획을 반영하는 것이 개발자의 몫이기 때문에 그것도 당연하지 않느냐! 는 이야기를 하죠. 필연적이지만 당연하지는 않다.
  2. 개발 세부도 반드시 바뀐다.
    기획이 바뀌듯이 개발 일정을 왜 못지키느냐, 개발자들은 뭘 하냐는 이야기는 즐.^^
  3. 기획의 범위는 애매하다.
    디자인/개발 세부까지 아우를 수 있는 반면, 둘다 전혀 상관 없을 수도 있다. 기획자의 배경과 재능에 따라 어느쪽으로 어느정도 디테일을 가지느냐는 천지차이로 달라질 것이다. 디테일하다는 것이 좋은 것이라는 이야기는 아니다. 되려 독이 될 수도 있다.
  4. 구현과 기획의 괴리는 반드시 발생한다.
    개발자 배경인 기획자라고 하더라도 기획이 개발 세부에서 나오는 괴리를 모두 커버할 수는 없다. 반면, 기획자가 내가 개발자냐라고 반문한다면 이를 존중하지 않는 것이겠죠. (엄청나게 많은 사람들이 참여해서 만드는 표준을 구현한 구현체들이 각기 동작이 다르듯이 말이죠.) 극단적인 예를 들어, 기획서에 “목록”이라고 되어있다면, 개발자에게 있어서 “목록”이라는 구현은 수십가지인데 그 중에서 기획자가 원하는 것을 찾을 방도는? 기획서에 나온대로 할 수 없는 기술적인 장벽도 존재한다.
  5. 개발자는 디자이너가 아니다.
    개발자가 만들면 투박하기 쉽다는 말은 틀린 것이 아니라 당연할 가능성이 큰 것이니까 할 필요가 없다. 개발자한테 이거 왜 인터페이스 디자인이 후져?라고 하지 말지어다. 개발자가 디자인을 맡지 않은 한 디자인을 잘할 필요가 하등 없다.
  6. production 개발과 prototype 개발은 다른 것이다.
    이리해보고 저리해보고 하는 것은 구현의 결과를 예측하기 힘들기에 당연하지만 올바른 기획자라면 당연시하기보다는 최소화해야한다. 결정을 내리는 입장의 짐은 그만큼 무거운 것이다. 위의 Linus님이 하신 이야기는 이를 프로젝트의 성격에 맞게 해결하기 위해서 잘하신 일일것이다. (단, 스케줄에 지장이 없을지어다)
  7. 개발은 예외없이 버그를 양산한다.
    말할필요도 없다. 왜 버그가 많냐고 말할 시간에(많고 적음은 개발팀의 몫) 버그를 얼마만큼 줄이자는 말이 그리고 그 시간을 존중해주는 것이 훨씬 낫고 맞다. 버그의 수가 중요한 것이지, 버그가 있냐 없냐는 무의미한 말이다. 흔히 스케줄에 버그를 고치는 기간같은 것을 반영 안하는 경우가 많은데, 위의 가정을 생각하면 작은 프로젝트라도 꼭 넣어야하고 없다면, 이런 시간이 있다는 것을 최소한 고려해줘야한다.
  8. 기획도 예외없이 버그를 양산한다.
    이리해보고 저리해보는 것을 버그로 인식하지 않는 것은 틀린 것이다. 기획서에 나와있는 말대로 구현되고나서 해보고 기획한대로 안되면 일단 버그인 것이다. 기획서에 한줄이 바뀌면 구현의 임팩트는 수십수백수천 혹은 수만라인의 코드가 될 수도 있는 것이다. 이에 대한 영향은 7번에서 이야기 했듯이 개발로 인한 버그를 만들어내는 것과 동일하다는 것이다. 이렇게 생각하면, 이리저리 바꾸는 것을 트래킹해야하는 것은 당연하지 않은가. 버그를 무조건 부정적인 것으로 생각하지 말아야한다.

이 중에서 7과 8에 무게를 두고 싶은건 왜일까요.ㅎㅎㅎ

(사실 이는 정해진 스케줄과 리소스 내에서 뻔한 사실 두가지로 귀결됩니다. 각자의 영역에 대한 유연성 부족. 서로의 롤에 대한 이해 부족. 나를 중심으로 원이 형성되어있습니다. 그 원이 일하는 상대의 원과 너무 멀면 기획과 개발의 차이는 커지고 말썽이 많아지는 것이고, 너무 가까우면 서로의 영역에 침범하는 것이 됩니다. 하지만, 이를 이해하고 인정하면 일은 좀 더 쉬워집니다. 원을 늘일 수는 없지만 유연하게 잠시 줄일 수는 있고, 멀면 멀다는 것을 인정하고 – 툴을 만들어주는 등^^ – 임하면 되는 것입니다.)

Written by charlz

2007년 4월 7일 , 시간: 오후 4:20

Uncategorized에 게시됨

7개의 답글

Subscribe to comments with RSS.

  1. 개발자의 버그와 기획자의 버그의 차이가 있다면, 개발자가 만든 버그는 개발자가 시간/노력을 쏟아서 수정해야 하지만, 기획자가 만든 버그는 (물론 기획자가 다시 수정해서 개발자, 디자이너에게 전달하지만) 개발자가 시간/노력을 쏟아서 수정해야 한다는 점이겠죠.

    미안해 하기야 하지만, 기껏 스펙대로 만들어놨더니 “아 생각해보니 이게 아니네요. 저렇게 하는게 낫네요. 다시 만들어주세요. 미안해요. 아, 싸그리 다 다시 짜야 된다구요? 아니 뭐 이거 조금 바뀌는거 갖고 그래요” 라는 식.. -_-

    항상 그런건 아니지만요. 또, 기획자에게는 물론 기획, 결과에 대한 책임이 따르지만요. 저도 요즘 상생의 길을 열심히 찾아보고 있는 중…

    프리버즈

    2007년 4월 7일 at 오후 5:06

  2. 공감합니다.. 서로 이해하고 인정해주는 분위기를 만들 수 있다면 엄청난 전력보강이 되는 셈이죠.. 서로 탓하기 시작하면 게임오버입니다..

    미친병아리

    2007년 4월 8일 at 오전 2:35

  3. 확실히 상생의 길을 찾아가야겠죠. 사실 저희는 functional 조직 어쩌고 해서 기획, 개발, 운영, 마케팅, QA가 완전히 쪼개지면서 예전에 비해 더 쉽지 않은거 같더라고요. -0-

    전문성을 가지고 분야별 영역을 가진다는 점에서는 괜찮은거 같으면서도 결국 일이라는게 인간적인 유대 관계 없이는 불가능하다는게 딜레마인 듯..

    오스카

    2007년 4월 9일 at 오전 9:53

  4. 잘 읽었습니다. 현재 얼마 안있으면 회사를 떠나야하는데 기획 단계에서 얼마나 specification 문서들이 필요할지, 개발 자체가 우선일지 고민하게 되네요. 1-8까지의 이유들이 와닿고 있다는..

    비밀+

    2007년 4월 10일 at 오전 12:15

  5. […] “개발자와 기획자, 상생의 길”을 읽다가…를 읽고 문득 또 이런저런 생각이 들었다. 지금 내가 기획하는것들도, […]

  6. 가장 중요한 건 커뮤니케이션이 아닐까 싶습니다. 어쨌든 “괴리” 라는 게 발생하는 것은 기정 사실이라고 하면, 그걸 좁혀 나가는 것은 전적으로 커뮤니케이션 스킬에 dependent 한게 아닐까 생각합니다.

    CK

    2007년 4월 10일 at 오후 6:48

  7. […] 개발자와 기획자 상생의 길을 읽다가.. 개발자와 기획자가 서로 이해하지 못하는 이유에 대해서 적어놓고 […]


답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: