brunch

매거진 같이 알면 좋은 것들

라이킷 88 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Shaun Aug 26. 2019

효율적 Process.

Episode 29

"효율적으로 해야지!"

"지금 효율적으로 하는 거 맞죠?"

"또! 언제 시안 잡고 컨펌받냐..."

RFP에서 Prototype까지.

프로세스.

보통 '일에는 순서가 있다.'라고 말한다. 맞는 말이다. 모든 일에는 순서가 있고, 순서에 맞게 해야 할 일들이 있다. 프로젝트도 마찬가지다. 프로젝트도 순서가 있고 프로젝트 순서, 즉 프로세스에 맞게 진행해야 할 일들이 있다. 다만, 동일한 프로젝트라도 프로세스를 어떤 방식으로 진행하는지에 따라 효율적일 수도 있고, 아닐 수도 있다. 꼭 프로세스에 맞게 일을 해야 효율적인 것은 아니다. 그렇다면 프로세스는 왜 중요할까? 그 답은 '협업'이다. 혼자 일하는 사람은 매번 일의 순서가 달라도 문제 되지 않는다. 하지만 조직에서 프로젝트는 협업으로 진행된다. 그럴 때 일의 프로세스는 협업을 위한 일종의 약속이 된다. 그 약속은 한정된 기간과 리소스를 효율적으로 활용하기 위한 운영이다. 보통 실무에서 프로세스 과정은 RFP(제안 의뢰서)로 시작된다.

work process.

RFP는 프로젝트의 시작을 알리는 요청서로 프로젝트의 이유, 개선사항, 프로젝트가 완료됐을 때 기대 효과 및 러프한 일정 등을 정리한 사업계획에 대한 문서다. 에이전시나 인하우스나 형식만 다를 뿐 개념은 동일하다. 에이전시로 배포되는 RFP는 내/외부의 이해관계를 위해 좀 더 형식적일 뿐이다. 프로젝트는 보통 RFP를 토대로 background(배경)을 정리하고, analysis(분석), strategy(전략), concept(컨셉), prototype(시안) 순으로 프로세스를 진행한다. 과연 이런 프로세스는 효율적인 것인가?

프로세스마다 하는 일.

프로젝트는 보통 단계적으로 진행된다. 첫 번째, RFP를 토대로 background(배경) 정리를 한다. 이때, 각 파트는 프로젝트 공동의 목표에 대해 논의하고, 상호 객관적 프로젝트 goal을 설정한다.

background.

두 번째, background(배경)을 기준으로 analysis(분석)를 진행한다. 현재 진행하는 프로젝트가 마켓에서 어떤 포지션인지? 또는 어떤 포지션을 선점해야 할지에 대해 분석한다. 주로 사용자 분석, 시장분석, 경쟁업체 또는 성공사례들을 토대로 분석하고, 카테고리별로 분류해 정리한다.

analysis.

세 번째, 정리한 analysis(분석) 자료를 토대로 strategy(전략)을 잡는다. 전략은 마켓 안에서의 포지션, 그 포지션을 선점하기 위한 방법과 그 과정을 설정하는 과정이다. 그 과정에서 각 파트는 전체 전략을 맞추는 과정을 거친다. 각 파트의 전략과 아이디어를 공유하고, 그것들을 서비스 중심으로 사유하는 과정을 거친다.

strategy.

네 번째, 전략이 확정되면, 전체 전략을 묶을 수 있는 concept(컨셉) 작업을 한다. 전략은 마켓 안에서 포지션을 잡는 과정이라면, 컨셉은 그것을 가시화시키는 과정이다. 전략적 컨텐츠와 그것을 어떻게 보이게 할지에 대한 구체적인 과정이다.

concept.

다섯 번째는 prototype(시안) 과정이다. 실제 전략과 컨셉의 아웃풋이다. 전략과 컨셉이 부합할 때까지 서비스 인터페이스와 컨텐츠를 수정하고, 디벨롭한다.

prototype.

위에서 프로세스마다 일반적으로 하는 일을 명시했다. 과연 이런 방식이 효율적인 것인가? 프로세스의 단계가 명확하면 효율적인 것일까? 프로세스의 단계가 중요하긴 하지만, 그것만 중요한 것이 아니다.

그것은 효율적인 프로세스인가?

앞에서 말한 과정을 보통 워터풀 방식이라고 말한다. 원하는 아웃풋이 나올 때까지 그 과정을 반복하는데, 반복하는 횟수가 늘어날수록 많은 시간과 리소스가 투입된다. 보통 워터풀 방식은 클라이언트를 만족시켜야 하는 에이전시, boss(보스)를 만족시켜야 하는 대기업 조직에서 찾아볼 수 있다. 이 방식이 무조건 잘못된 방식은 아니다. 워터풀 방식으로 성공한 제품과 서비스도 많다. 하지만 워터풀 방식이 효율적이지 않은 이유는 각 과정을 거치는 과정에서 최종 결정권자(boss)와 커뮤니케이션이 제한적이라는 것이다. 아래 그림을 보면 파란색과 붉은색의 구간이 분리되어 있다. 대부분의 워터풀 방식의 조직에서는 최종 결정권자(boss)와의 커뮤니케이션이 가능한 구간은 파란색 구간이다. 나는 이 구간을 boss(보스) 구간이라 말한다. 반면 붉은색 구간은 실무진 구간이다.

boss(보스)와 커뮤니케이션이 가능한 구간 파란색.

boss(보스)와의 커뮤니케이션은 파란색 구간에서만 가능하다. 즉, 사업계획 그리고 시안을 보고하는 구간에서만 커뮤니케이션이 가능하다. 하지만, 실무진 구간에서의 오류나 리스크 발생 시 그것을 결정해줄 boss(보스)가 필요한데, 워터풀은 방식은 실무진 구간에서 boss(보스)와의 커뮤니케이션이 쉽지 않다. 아니 거의 불가능하다. 그렇기 때문에 보스와의 커뮤니케이션을 위해 실무진 구간에서 소모적으로 프로세스 1사이클을 진행해 보스를 만나러 가야 한다. 좋은 제품과 서비스를 만드는 과정의 대부분은 커뮤니케이션이다. 커뮤니케이션을 제한적인 단계에서만 할 수 있다면, 효율적인 프로세스를 유지하기 어렵다. 제품의 퀄리티나 포퍼먼스를 위해서 커뮤니케이션에 장벽이 없어야만, 효율적인 프로세스를 유지할 수 있다. 최종 결정권자(boss)와 커뮤니케이션이 원활할수록 리스크와 오류도 줄어든다. 또 효율을 위해서 최종 결정권자(boss)와 커뮤니케이션이 가장 중요하다.

효율적으로 일하기 위해서는?

커뮤니케이션이 중요한 이유는 바로바로 결정을 할 수 있기 때문이다. 프로젝트가 진행되는 중에는 항상 결정의 기로에 서있다. 하지만 결정할 수 있는 권한은 제한적이다. 결정도 부여된 권한이 있어야 가능하기 때문이다. 그때마다 결정을 하기 위해서는, 권한을 가진 결정권자와(boss) 커뮤니케이션이 중요하다. 하지만 결정권자와의 커뮤니케이션이 단계적으로 제한되어 있다면, 굉장히 비효율적인 프로세스를 거쳐야 한다. 바로 프로세스 1사이클을 소모적으로 진행해야 할 때이다. 프로젝트를 진행하는 과정에서 바로바로 결정권자와 커뮤니케이션을 진행해야 리소스의 소모를 막고, 효율을 유지할 수 있다. 그것을 위해 커뮤니케이션은 폐쇄적이 아닌 개방적이어야 한다. boss(보스)도 프로세스를 진행하는 동안 팀원이어야 한다.

프로젝트를 위한 boss(보스)의 결정은 실무진 구간에서 항상 가능해야 한다.

각 구간에서 사업계획에 대한 부분이 잘못됐다고 판단되면, 붉은색 실무진 구간에서 바로바로 boss(보스)와 커뮤니케이션할 수 있는 구조가 되어야 한다. 또 커뮤니케이션을 통해 잘못된 것은 바로 폐기하고, 다시 포지셔닝할 수 있어야 한다. 효율은 동일한 리소스와 동일한 기간에서 상대적 더 좋은 퍼포먼스를 내는 것이다. 그렇기 위해서는 판을 뒤집어야 할 때 바로바로 뒤집어야 한다. 모두 오답이 나올 것이 뻔하다고 말하는데, 그 문제를 계속 풀어가는 것이 좋을까? 아니면, 판을 뒤집어 다시 포지셔닝하는 것이 좋을까?

keyword