기획 방법론 - 노노니의 앱 서비스 기획

어떤 팀프로젝트나 동일하겠지만 각 구성원간 커뮤니케이션은 프로젝트의 성공에 가장 기초되는 전제조건입니다. 한 두 명이 모든 것을 다 작업하는 소규모 프로젝트로 시작하여 여러 사람이 참여하는 프로젝트 일수록 커뮤니케이션의 중요성은 더욱 커 집니다.

 

실패하는 프로젝트

일부 프로젝트 팀을 보면 각자 해오던 업무룰이 틀려 서로 배타적인 반응을 보입니다. 프로젝트가 어떻게 될까요. 당연히 프로젝트는 엉망이 됩니다. 예외 없습니다. 

기간내에 맞추지 못하고 기획의도대로 만들어지지 않으며 서로가 작업한 것이 못마땅한 상태로 어떻게든 프로젝트가 끝나기만을 바라게 됩니다. 개인도 팀도 클라이언트도 모두 실패한 프로젝트가 됩니다.

 

 

 

 

커뮤니케이션의 중심은 서비스 기획자

웹기획자, 디자이너, 코더, 프로그래머 간의 커뮤니케이션이 시작되는 곳은 웹기획자 입니다.

무엇을 할 것인지가 있어야 프로젝트가 시작되기 때문에 당연한 것이죠.

 

 

 

 

 

 

팀PT의 중요성

기획자는 전체 메뉴체계와 이에 따른 화면전개를 알 수 있는 IA, 스토리보드를 작성하여 팀PT를 합니다. 이 최초 팀PT가 매우 중요한데 팀PT에서 아무 질문도 하지 않고 듣는 둥 마는 둥 하는 사람들이 더러 있습니다.

"작업 하면서 궁금한 것 있으면 그 때 물어볼께요" 라거나 "그냥 하면 되죠" 또는 "나중에 볼께요" 이 세 유형은 반드시 프로젝트에서 제외시키셔야 합니다. 좋은 게 좋다고 가다가 제대로 큰코 다칩니다.

 

전체 팀 PT가 있은 후 프로젝트 진행 중 디자이너와 개발자가 추가되거나 바뀌게 되면 기획자는 똑같은 PT를 수차례 진행할 수도 있습니다. 

 

 

 

 

 

 

추가 질문

기획자의 팀PT가 있은 후 각 분야에서는 다시 스토리보드를 리뷰하면서 기획자에게 의문점이나 추가 질문을 하게 됩니다.

 

 

 

 

 

 

디자이너와의 많은 대화

디자인이 진행되면 세세한 부분에 있어서의 질문을 기획자가 받게 됩니다. 

 

 

 

 

 

 

검수/수정 과정에서 나타나는 갈등

각 작업이 이루어질 때 마다 기획자는 기획의도대로 결과물이 만들어 졌는지 검수를 해야 합니다. 그래픽 디자인이 나왔을 때, 그래픽 디자인이 코딩되어 나왔을 때, 코딩을 바탕으로 기능구현이 프로그래밍 되었을 때.

결과물이 기획의도와 다르다면 반드시 수정요청을 통하여 바로잡아야 합니다. 검수 결과에 대하여 틱틱거리거나 "이렇게 하나 저렇게 하나 그게 그거다", "왜 진작 말해주지 않았느냐", "그렇게 하는건 불가능한 것이다" 정도로 반응을 한다면 다시 한번 팀에서 제외시켜야 할지 심히 고민해야 합니다.

PM이나 PL을 겸하고 있지 않은 기획자의 경우 팀원을 팀에서 제거할 재량이 없고 디자인 팀장이나 개발팀장이 비협조적이라면 정말 힘들 수 있습니다. 그러나 희망은 있습니다. 6개월 이내 이 프로젝트는 끝날 것이잖아요!! 다음에 같이 프로젝트 하지 않으면 됩니다. 

국가대표팀이나 드림팀도 마찬가지지만 잘난 사람들이 함께 모인다고 좋은 결과가 나오지 않습니다. 서로가 서로를 이해하고 도울때 제대로 된 팀제 프로젝트의 결과를 얻을 수 있습니다.

 

 

팀 플레이

팀제 프로젝트는 기획자의 일을 해주는 것이 아닙니다. 하나의 목표를 위하여 서로가 서로를 도우며 함께 가는 것입니다. 

 

실력으로 디자이너와 프로그래머를 능가하리라는 생각도 하지 마십시요. 이해에 기반하지 않고 싸워 이기는 것은 프로젝트를 망치는 공격행위입니다. 이는 클라이언트와 관계에서도 동일합니다. 클라이언트가 트집을 잡고 작업자가 클라이언트의 요구를 수용할 여지도 없다면 눈가림이 시작되는 것입니다. 승인한 스토리보드 그대로 작업하면서 후에 문제 발생 요인을 발견하여도 변경이나 개선하지 않고 정해진 대로만 작업을 끝냅니다. 시스템화 시켜야 하는 부분도 수동화 시켜놓고 관리자 페이지를 통하여 이루어져야 할 기능도 페이지에 직접 코딩으로 변경하게 해 놓는 등의 일이죠.

해당 작업자는 프로젝트 말미에 반드시 다른 프로젝트로 쫓겨나게 됩니다. 

 

새로운 작업자가 오면 기획자는 무엇을 해야 하는지 아시죠?

스토리보드를 리뷰해주고 의문사항의 질문을 받고 현재까지 작업 진척을 설명하고 어떤 이슈가 있는지를 전달해야 합니다. 어떤 작업자가 문제 발생으로 교체되기 시작하면 그에 영향을 받고 있던 다른 작업자와 작업결과의 문제점이 봇물터지듯 쏟아져나와 여러 작업자의 교체, 대체, 추가가 이루어지고 기획자는 스토리보드 리뷰를 동영상을 촬영해 놓을껄 하는 생각까지 하게 될 수 있습니다.

서로가 서로를 위하여 의기투합할 수 있도록 협업 커뮤니케이션을 잘 해야만 하는 이유입니다.

 

 

 

 

 

 

작업자간 커뮤니케이션

코딩이 끝나서 프로그래밍으로 기능을 구현할 때는 코더와 프로그래머 사이에 커뮤니케이션이 이루어집니다. 이 부분은 코딩을 다르게 바꾸어주어야 한다거나 프로그래밍이 끝난 후 레이아웃이 제대로 유지되었는지 조정해 달라거나 하는 것들 입니다.

 

커뮤니케이션은 서로에 대한 배려

기획자와 각 작업자간 이루어지는 커뮤니케이션이 어렵지는 않습니다. 다만 커뮤니케이션을 어렵게 하는 사람들이 있으며 이는 팀 플레이를 해치는 것이 되므로 조정이 되어야 할 부분입니다.

경력이 많고 무엇을 어떻게 해야 하는지 아는 배테랑 작업자는 기획자를 도와줍니다. 잘못된 부분도 확인하여 알려주고 수정되어야 할 사안도 해결책을 제시하며 클라이언트의 무리한 요구에도 대처해 줄 수 있습니다. 

일부 말썽쟁이 작업자에 낙심하지 마시고 좋은 서비스 많이 만드시기 바랍니다. 

 

- 새로운 프로젝트 기획서를 개발팀에 넘기고 나서 다시 읽는 이 포스팅은 나를 다시 돌아보게 만든다. 내일 가서 기획서를 다시 봐야겠다.