광고, 마케팅, 사업 기획, 서비스 기획, 개발 기획 등 여러 다양한 분야 기획자로 실무를 하면서 느낀 점이 있습니다. 모든 기획은 세부 사항은 다를지언정 기획 사고의 전개 방식은 유사하다는 것입니다. 그러기에 전혀 다른 산업 분야, 다른 업무 부문에서 기획을 하다라도 문제가 없었습니다.
기획 사고와 업무
지금부터 하는 것은 개인적 경험에서 나온 개인적 생각입니다. 학문적으로 결정된 게 있거나 한 것은 아니라는 점 미리 밝혀둡니다. 이 블로그는 주로 업무적으로 경험한 개인적 생각을 적고 있습니다.
기획 사고는 기획 대상에 대한 설계를 할 때 생각의 흐름을 의미합니다.
마치 우리가 버스를 탈 때 앞문으로 타서 교통카드를 찍는 행동을 하는 흐름과 같습니다. 그리고 내릴 때도 교통카드를 찍습니다. 아니면 추가 요금이 나오게 됩니다. 과거 버스는 안내양이 있었고 뒤로도 탈 수 있었으며, 돈 통에 버스 요금이나 토큰을 넣었습니다. 그러다 지금과 같은 버스 시스템이 도입되었을 초기에는 버스 탑승 흐름에 대해 사람들의 인식을 바꾸어야 했습니다.
기획 사고는 우리가 버스를 타고 내릴 때 순서대로 하는 행동처럼 기획을 할 때 처리하는 정보와 작업의 흐름을 의미합니다.
그러나 기획 업무는 조금 다릅니다. 기획 업무 처리는 회사마다 조금씩 다른 보고 체계나 문서 양식에 따라 진행됩니다. 이는 관리의 영역의 제한을 받는 것이라 할 수 있습니다.
기업 업무가 때로는 기획적 사고를 방해하는 현상
정확히는 특정 양식의 기획 보고서를 만들어 제출해야 한다고 압박할 때 나타나는 현상이라 할 수 있습니다. 이러한 기획 보고서는 기획의 산물이라기보다는 기획자로 지명된 인력이 만들어 내야 하는 그 회사나 조직의 보고서인 경우가 많습니다.
물론 어떤 기업은 기획 사고 흐름에 따라 기획 보고서 단계를 설계하고 이에 맞추어 보고서를 요구할 수도 있습니다. 그러면 작성자는 업무를 하는 도중 자연스럽게 기획 사고를 습득하게 됩니다. 여기에 질 높은 기획서 또한 만들 수 있게 됩니다. 기획의 각 단계는 서로 영향을 주기 때문에 전 단계 기획서가 없는 최종 기획서는 부실할 수밖에 없습니다.
그러나 이러한 과정을 설계하고 작동시키는 것도 기획입니다. 즉 기획적 사고를 이해해야 할 수 있는 것이라는 점입니다. 문제는 이런 과정은 일반 업무를 진행하는 사람의 경우 이해하기도 어렵고, 자신이 전달받은 기획서와 다른 부분이 있어 선호되지 않는 경향이 있습니다. 그냥 최종 기획 산출물만 요구하는 것입니다.
최종 기획 산출물만 요구하는 경우도 기획 사고를 하는 기획자는 스스로 기획 단계별 산출물 만들어 최종 산출물 작업에 활용하기는 합니다. 이러면 그냥 바로 최종 산출물 작업을 하는 것보다 초기에는 느려질 것입니다. 그러나 뒤로 갈수록 작업 속도는 빨라지게 됩니다. 그리고 최종 기획서 수준도 향상됩니다. 문제는 조직은 이를 기다려 주지 않습니다.
부작용 케이스
기획 업무에 너무 치우진 기획 작업의 부작용 케이스를 소개하고 글을 마치겠습니다.
과거 대기업 사이트 개발 프로젝트에서 기획서 현행화를 담당하는 기획자로 투입된 적이 있습니다. 투입 전 전달받은 상황은 이렇습니다.
- 기획서(스토리보드)와 개발 내용이 맞지 않는다.
그래서 저의 업무는 기존 기획서와 개발 내용을 검토하고 맞추어 스토리보드를 현행화하는 것이었습니다.
프로젝트 기간도 개발 종료 시점까지 2달밖에 남지 않은 상황이기에 현행화를 위해 저 역시 최대 2달 계약으로 투입되었습니다.
그러나 개발 프로젝트에 들어가 자료를 본 내용은 투입 전 전달받은 내용과 완전히 달랐습니다. 이를 정리하면 아래와 같습니다.
- 완성된 기획서는 하나도 없었습니다. 단지 미완성의 여러 버전 스토리보드만 있을 뿐입니다.
- 그러나 디자인은 완성되어 있다고 전달받았습니다. 기획 PL로부터 디자인 파일을 보고 작업하라 전달받았습니다.
- 개발 내용은 확인이 안 되었습니다. 함께 투입된 개발자들도 과서 파일은 전달받았지만 현재 개발 내용은 전달받기 못한 상황인 것을 확인하였습니다. 그리고 메인 개발도 프로젝트 실이 아닌 모처에서 하고 있었는데 프로젝트 실 개발자들도 모르고 있었습니다.
- 프로젝트 실에는 너무 많은 회사의 인력들이 있었습니다.
현행화 업무만 놓고 보자면 작업할 대상이 존재하지 않은 상황인 것입니다. 2달 후면 개발이 종료되어야 하는 데 프로젝트에 선 투입된 기획자들이 아직도 스토리보드를 작업하고 있는 상황이었습니다. 그리고 이 또한 전체가 아닌 일부분이었고 개발에 전달되지도 못한 상태였습니다. 작업하는 속도로 추정하면 프로젝트 종료 시점까지 스토리보드 전체가 아닌 기존 기획자가 작업 중인 일부분도 완성되기 힘들어 보였습니다.
저 역시 프로젝트 기획 PL은 기획서 현행화가 아닌 스토리보드 신규 작성을 요구하였습니다. 이렇게 전달받은 제가 작업해야 하는 스토리보드 부분도 50페이지가 넘는 양이었습니다. 그리고 이는 사이트 핵심 부분으로 제품 관련 부분이었습니다. 기존 기획자는 고객센터 쪽 작업을 하고 있었습니다.
내부 사정 정보를 모아본 결과 프로젝트가 최종까지 올 수 있었던 것은 고객이 요구하는 과정 산출물이 지속적으로 나왔었기 때문입니다. 그러나 이는 기획 사고에 기반하여 기획의 대상이 해당 대기업 사이트 개발을 목적으로 한 것이 아니었다는 것이 지금 문제를 만든 이유였습니다.
스토리보드 버전에 여러 개인 것은 그동안 기획팀을 바꾼 횟수를 의미했습니다. 1년도 안된 기간에 기획팀을 4번 이상 바꾼 것입니다. 전해 들은 개발 히스토리도는 기획팀을 전체 물갈이 한 이후에는 개발팀도 바꾸었다고 합니다. 그래서 제가 투입될 때 개발자들도 함께 투입된 것이었습니다.
저는 맨 아래 협력사의 프리랜서였습니다. 문제가 되자 최상위 개발 업체 소속 직원인 기획자가 추가 파견되었습니다. 이 사람 역시 기획 사고는 없는 기획 업무를 담당하는 직원이었습니다. 아예 개발과는 상관없이 스토리보드를 만들라고 요구하였습니다. 요구사항 명세서도 고객 요구가 아닌 자신의 요구를 넣어 전달하였습니다. 일단 자신이 요구하는 데로 전체 스토리보드를 개발 종료 전까지 만들어 오라는 요구였습니다.
지정된 기획 업무에만 집중하다 보면 프로젝트 진행율이 올라가면 갈수록 프로젝트 팀 내 정치가 발생하게 됩니다. 기획 산출물은 기업 조직이 정한 대로 나와 있는데 결과는 이상한 곳으로 가기 때문입니다. 이 때문에 서로 책임지지 않으려는 정치가 발생하는 것입니다.
제가 기획서 현행화로 투입되었던 프로젝트도 그런 상태였습니다. 서로 책임지지 않기 위해 마지막까지 산출물을 만들라고 압박하고 있는 상황이었습니다. 최 상위 개발 업체 직원의 경우 실무 경험이 없기 때문에 압박하는 것입니다. 이들은 실제 개발이 아닌 주로 관리와 보고만 진행하는 것으로 보였습니다.
결국 대기업인 고객의 제품 사이트 개발 프로젝트였는데 기획은 개발과 별개로 진행되었던 것입니다. 처음부터 고객이 요구하는 인테리어 잡지 같은 사이트에 고객의 제품 정보와 대리점이 소개되는 사이트는 고려되지 않았던 것으로 파악되었습니다. 단지 프로토타입의 형태로 고객에게 그럴듯하게 전달해서 종료 시점까지 프로젝트를 이어 온 것으로 판단되었습니다.
이럴게 생각하는 이유는 있습니다. 일단 제가 받았던 기획 문서들에는 고객이 요구하는 기능과 구조를 만들기 위한 내용이 없었습니다. 설루션 역시 고객 요구 사항을 구현할 수 없는 것이었습니다. 확인할 수 있는 개발 결과물도 그냥 웹페이지 였습니다. 그냥 일반 쇼핑몰 정도였습니다. 그런데 디자인은 다 나와 있었습니다.
결국 이 프로젝트 기획은 해당 프로젝트 관리자가 지정하는 기업 업무에 맞추어 요구하는 산출물을 작성해 제출하는 것이었다 생각됩니다. 요구하는 산출물은 스토리보드이고, 이는 어떤 대상을 개발할지에 대한 것이 아닌 프로젝트 관리자가 만족하는 내용이어야 했습니다.
일반적인 기획 사고는 이 프로젝트의 목적인 대기업 제품 사이트의 개발이 될게 하는 것에 집중합니다. 이를 위해 개발자와 디자이너에 전달할 최종 산출물을 스토리보드의 완성도를 높이기 위한 프로세스 산출물을 생성합니다. 이 과정은 개발 내용과 개발 자원을 크로스 체크하고 지금까지 진행 내용을 기반으로 이후 진행 내용을 규정합니다. 이러한 과정이 기획 기간 전체에 작동하기에 기획 산출물이 개발 대상과 달라질 수가 없습니다.
그라나 이 프로젝트처럼 많은 개발 프로젝트들이 기획과 디자인, 개발을 분리하여 진행합니다. 개발과 상관없이 고객의 요구를 듣고 화면을 그린 후 이를 컨펌받으면 기획이 끝나는 것입니다. 이러한 스토리보드에는 그럴듯한 화면은 존재하지만 어떻게 개발해야 할지에 대한 내용은 없습니다. 그래서 개발자는 스토리보드는 단지 참고용으로 사용하고 스스로 설계해서 개발하게 됩니다. 이렇게 되면 기획 산출물인 스토리보드와 개발 내용이 달라지는 것입니다.
댓글