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