웹 기획 프로세스의 문제점과 대안 :: 2007/03/02 00:02



팀 동료가 쓴 에세이다.
잘 정리된 내용이다.





[Subject] 현재 기획 프로세스의 문제점과 대안


[Summary]

1.      Business Unit과의 전략 공유

Business 전략이 수립된 이후 기획이 그에 맞춰 진행되는 것이 일반적이지만 항상Business 전략과 기획의 전략 방향성은 공유되고 상보적이어야 .

2.      Requirement 개발의 Gap

개발을 고려하지 않은 기획은 반쪽 짜리 기획이며 여러 가지 개발적 이슈 개선 사항들이 같이 고려되었을 나은 기획이 만들어질 있음.

3.      Process 필요성과 유연성

요구사항의 정리가 서비스로 만들어져 서비스 되기까지 많은 공정이 있고 공정을 체계화하고 단축하기 위한 프로세스는 필요하지만 유연성 있게 대처할 필요가 있음.


[Body]

1.      Business Unit과의 전략 공유

보통 기획은 이러이러한 서비스가 필요하다는 Business 요청에 따라 필요한 부분에 대한 서비스 기획을 하는 것이 보통이다. 이러한 요청은 Business에서 수립된 전략을 충족하기 위한 Business적인 고민만을 담고 있기 때문에 서비스 전체에서의 고민 또는 기술적인 고민 개선 사항까지는 포함하고 있지 않다.

기획은 전체 서비스와 기술적인 부분까지 고민해야 하며 고민은 Business 고민과 전략을 충족하면서도 이상 전체 서비스가 나아갈 방향성과 전략을 담고 있어야 한다. 또한 그렇게 고민된 서비스의 방향성과 전략은 Business 그것에서도 감안이 되어야 하며 서로 상호 보완적인 관계를 유지해야 한다.

온라인 서비스란 일반적인 오프라인 서비스나 상품과는 다르게 기술적인 기반 위에서 사용자를 만나게 되기 때문에 사용자에게 제공하고자 하는 서비스의 요청은 기반 위에서 고민되고 적용이 되어야 한다.

또한 단순 Business 차원에서의 고민보다 기술 기반 위에서의 고민은 사용자에게 나은 서비스를 제공할 있다. 구글이 가장 대표적인 예로 Google earth 보면 기술의 경이로움과 그로부터 파생되는 Business들을 있다.

기술 기반 위에서의 고민은 Business 전략 영역을 넓혀줄 있는 장점이 있다. 검색이라는 기술은 새로운 많은 Business 창출하였고 (최근의 첫눈이 대표적인 예일 것이다.) 커뮤니티 사이트에 검색 기능이 없다면 적용할 있는 요구사항이 굉장히 제한적일 밖에 없지 않을까 싶다.

서비스는 Business 기술의 조화라고 생각하며 Business 기획의 전략과 방향성은 같이 고민하고 함께 수립해 나감으로써 진정 사용자들에게 다가설 있는 서비스를 만들 있다고 생각한다.

2.      Requirement 개발의 Gap

기획의 끝은 어디일까, 기획서를 만들고 디자인이 완료되면 기획은 끝이고 다음부터는 개발자들이 맡는 영역이라고 생각하는 경우가 많을 것이다. 하지만 기획은 개발이 완료되고 서비스가 사용자에게 Open 되어야 끝이지 않을까 생각된다. 그보다 관점으로 본다면 서비스가 Open되면 Business 운영을 하면서 다른 요구사항을 만들 것이고 “1, Business Unit과의 전략 공유에서 얘기했듯이 Business 기획 부분은 지속적으로 같이 고민해야 하기 때문에 순간 새로운 기획이 시작되는 것으로 수도 있을 것이다.

누군가 기획이 무엇이냐고 묻는다면 Business 기술의 마리아주라고 얘기할 것이다. 기획자는 Business 이해해야 하고 기술에 대한 이해도 가지고 있어야 한다. 기술에 대한 이해가 없다면 Business 요구사항을 개발에 정확하게 전달하기 어려울 하며 적용되는지 확인하는 것도 어렵지 않을까 싶다.

기획서가 개발 단계로 넘어가는 순간 기획이 끝났다고 생각하는 경우, 그리고 기획에 따른 개발이 어떻게 진행되고 있는지 이해하고 있지 않은 경우, 대다수가 처음 기획한 의도에 따라 개발되거나 또는 그보다 낫게 개발되기는 어려울 것이다. 물론 아주 뛰어난 개발자가 Business 요구사항까지 이해하고 기획 내용 이상의 서비스를 만들어 수도 있겠지만 아주 드문 일일 것이다. 개발이 진행되면서 처음 기획한 부분에서 고려하지 못한 요소들이 많게든 적게든 들어날 것이고 기획자가 개발자에게 그건 너희가 알아서 해야 하는 일이라고 밀어붙일 경우 개발자들은 방향을 잃을 수도 있을 것이다.

또한 개발자들이 개발을 진행하면서 추가적으로 나은 방법이나 개선점을 제안하는 경우도 많다. 때문에 기획자는 개발에 대한 어느 정도의 이해를 하고 있어야 하며 기획이 개발 단계로 넘어가더라도 지속적으로 이슈 부분을 체크하고 개발자와의 커뮤니케이션을 통해 나은 서비스를 제공할 있도록 진행해 나가야 것이다.

3.      Process 필요성과 유연성

기획자로서 Business Unit 개발 사이에서 일을 하기 위해서는 업무 Process 반드시 필요한 법이다. 정형화된 Process 없는 경우 기획자는 정리되지 않은 요구사항들을 문서, 메일 또는 구두로 전달 받을 있고 개발쪽에도 비슷하게 전달할 있으며 서비스가 어떻게 변경되는지, 어떻게 변화해가야 하는지 생각도 하기 전에 엄청나게 엉뚱한 모습으로 변화해 버릴지도 모르겠다.

하지만 필요한 체계적인 업무 Process 너무 비중을 두는 또한 문제가 있을 하다. 위에서 언급하였듯이 기획자는 Business mind 가지고 있으면서 기술적인 이해도 가지고 있어야 하며 중개 역할 아니라 요구사항 이상의 기획과 기획 이상의 서비스가 만들어지도록 노력해야 한다. 중간의 위치에서 Process 이렇게 정해져 있고 Business 요구사항은 이러하니 개발을 이렇게 해달라고 얘기하고 넘기기만 하여서는 기획자라기보다는 중개자 또는 전달자로서만 머물지 않을까 싶다.

기획이 Business 기술의 마리아주라고 표현하였듯이 기획자는 한쪽 발은 Business 다른 발은 개발에 걸치고 있어야 하지 않을까 싶다. Business 요구사항을 도출할 때는 범주에서 검토하여 같이 도출해내고 기획에 따른 개발 진행 기술적으로 나은 서비스를 만들 있도록 이슈를 검토하고 개발자들과 협조해나가야 한다. 그리고 나아가 Business에서 도출해내지 못하는 부분에 대해서도 전체 서비스를 고려하여 도출하고 기획해 나가는 것이 기획자의 역할이지 않을까 싶다.

기획자가 역할을 100% 이상 발휘하기 위해서는 체계적이고 효과적인 Process 정립하는 것과 Business 기술을 포용하면서 유연하게 대처하는 업무 자세가 모두 필요하지 않을까 싶다. 물론 Business 개발에서도 이러한 기획자의 역할을 기대하면서 그에 대한 협조와 이해가 필요할 하다.




Trackback Address :: http://read-lead.com/blog/trackback/141
NAME PASSWORD HOMEPAGE