티스토리 뷰

안녕하세요?  야메군 입니다.

오늘 이야기 할 웹기획 가이드는 백오피스 기획에 대한 내용인데요, 백오피스(BackOffice), 같은 단어 임에도 불구하고 사용하는 업종이나 분야에 따라 그 의미가 천차만별인데, 웹/모바일 분야에서의 백오피스는 보통 관리자 페이지라고 합니다.  즉, 일반 고객이 접근하는 프론트페이지(Front page)의 운영과 관리를 뒷받침하는 여러 요소들을 담고 있고, 여기에 경영관리나 회계, 마케팅 등 회사의 모든 지원요소들을 포괄하고 있습니다. 호텔업계에서 사용하는 백오피스의 의미와 비슷하죠.


이렇게 말씀드리면, '어? 그거 ERP아냐?' 라고 생각하시는 분도 계실텐데, 사전적인 의미만 놓고보면, 전사적 자원관리(Enterprise Resource Planning)의 약자인 ERP와 백오피스는 비슷한 의미를 가지고 있습니다.  하지만 흔히 현업에서는 백오피스의 상위단계를 ERP라고 보는 경향도 있습니다만, 이는 잘못된 이해이니 참고하시기 바라며..

 

오늘 이야기 할 백오피스는 많은 기획자들이 최소한 한 번쯤은 접해봤을 겁니다. 하지만 의외로 이 백오피스를 실제로 기획해 본 기획자는 전체 기획자의 20%에 불과할 정도로 매우 드문 편입니다. 대부분은 고객들이 직접 접하는 프론트 페이지 중심의 기획만을 경험하는데, 그 이유와 원인을 알아보고 백오피스 기획의 노하우를 하나씩 전달해 드리겠습니다.

 

 

백오피스 기획을 경험해 본 기획자가 적은 까닭은?

 

아무리 별볼일 없는 웹사이트라 할지라도 백오피스는 존재하기 마련입니다. 백오피스가 하늘에서 뚝 떨어지는 게 아닌만큼, 프론트 페이지에 대한 기획이 있다면, 당연히 관리자페이지에 대한 기획도 따라오기 마련이죠. 하지만 의외로 관리자페이지에 대한 기획 경험을 가진 기획자가 별로 없는 아이러니한 상황.. 체감적인 수치 상으로는 백오피스 기획을 경험해보지 못한 기획자는 70% 정도에 이르지 않을까 생각하는데.. 이러한 현상, 어떻게 이해해야 할까요?

 

그 이유는 여러가지가 있겠지만, 대표적으로 "세부적인 스케줄링의 부재"와 "잘못된 기획순서" 그리고 "실 사용자에 대한 니즈분석의 부재"에서 그 원인을 찾아볼 수 있습니다.  첫 번째로 시간배분의 실패는 프로젝트 스케줄링의 실패와 같은 맥락인데, 일반적인 웹(모바일) 프로젝트의 대략적인 진행순서는 다음과 같습니다.

 

① 서비스 벤치마킹 및 상위기획(전략기획).

② IA 설계 및 스케줄링

③ 메인 페이지 및 주요 페이지의 컨셉 기획안 및 디자인 시안 작업.

④ 프론트 페이지 스토리보드 작성.

⑤ 백오피스 스토리보드 작성.

⑥ 디자인 시안 및 세부페이지 디자인 진행.

⑦ 개발 진행.

⑧ 테스트 및 오픈.

 

대략적으로 이와 같은 순서로 작업이 진행되겠죠. 이 중 ②번의 스케줄링 과정에서 기획과 디자인, 개발 스케줄링을 하는 과정에서 러프하게 기획은 몇 주, 디자인은 몇 주 하는 식으로 작성하게 됩니다. 이때 스케줄을 러프하게 잡게 되면, 각 단위 별 기획 '마이페이지의 작업범위는 어디까지인지, 기간은 몇 일이 필요한 지...'와 같이 규모와 시간을 분배가 불명확할 수 밖에 없습니다. 그러면 자연스럽게 초반에는 좀 놀다가 스케줄 막판이 되어서야 비로서, "X 됐다!!" 하면서 몇날 몇일 밤을 새는거죠.



백오피스 기획을 잘 못하는 이유!? ①, ② - 스케줄링의 부재.. 그리고 잘못된 기획순서..

 

문제는 날밤을 새서라도 작업이 가능하다면 다행(?)일 겁니다. 하지만 거의 대부분은 그 '작업완료가 되지 않는다는 것'이고, 프론트 기획을 이것저것 수정하다보면 자연스레 웹 서비스의 가장 중요한 요소라 할 수 있는 백오피스 기획은 뒷전으로 밀릴 수 밖에 없습니다. 그러다보면 결국 백오피스 기획이 없는 상태에서 개발자에게 떠넘겨지는 경우가 비일비재하죠. 이 경우 사용자 요구분석 혹은 UI나 UX 등에 대한 사전적인 지식이 부족한 개발자들은 개발 편의성에 따라 백오피스를 설계/개발하게 됩니다. 그리고 결과적으로 백오피스의 운영 효율성을 담보할 수 없는... 막장 백오피스가 만들어지게 되는것이죠. 개발자 분들을 욕하는 것이 아니라는 사실!!

 

기능 별 세부적 스케줄링 예시.

 

이런 막장 상황을 방지하기 위해서는 기획중심의 세밀한 스케줄링이 필요합니다. 예를 들어, 하나의 서비스를 기획하는데, 게시판 리스트 페이지는 몇 일, 읽기 페이지는 몇 일, 쓰기 페이지는 몇 일 하는 식으로 IA 기반의 스케줄링을 해야 합니다. 이렇게 각 단위 서비스의 일정이 명확하게 구분되어야 기획자 본인의 스케줄 뿐만 아니라, 전체 스케줄 컨디션을 적절히 유지할 수 있습니다.  즉... 기획자, 디자이너, 개발자가 마감에 임박해서 밤샐 필요가 없다는 소리죠. 기획적인 세부 작업범위가 일정으로 정리될 경우, 이 일정을 근거로 개발과 디자인 포지션에서도 기간에 따른 규모를 예측할 수 있기 때문에 타 포지션에서의 작업 스케줄 산정이 정확하게 수립될 수 있습니다.

 

두 번째로 잘못된 기획순서 입니다.  보통 현업에서는 프론트 기획을 마무리 한 시점에서 백오피스 기획을 들어가게 되는 경우가 대부분인데, 기획순서를 조금 조정해 줌으로서 백오피스가 기획되지 못하는 첫번째 원인인 세부적인 스케줄링의 부재를 보완할 수 있습니다.

 

즉, ②번 과정 완료 후, ④의 프론트 페이지 스토리보드 기획이 아닌, ⑤번에 배치된 백오피스 기획을 우선적으로 진행하여, 시안작업 과정에 백오피스 기획을 완료하는 스케줄로 구성하게 되면, 백오피스의 기획적 완성도를 높이게 됨으로서 백오피스의 운영 편의성이 동반상승하는 결과를 얻을 수 있습니다.

 

백오피스 기획을 잘 못하는 이유?! ③ - 사용자 니즈 분석의 부재..

 

마지막 세번째는 실 사용자에 대한 니즈분석 부재 입니다.

보통 사업기획을 하거나 프론트 기획을 할 때, 실제 사용자나 시장규모에 대한 분석이 이루어지는데, 의외로 백오피스 기획 시, 이러한 사용자 분석과정이 과감하게 생략되는 경우가 빈번합니다.  아니 외부고객이냐, 내부고객이냐의 차이만 있을 뿐 어짜피 고객이 이용하는 것은 매 한 가지인데 어떤 건 분석하고 어떤 건 분석하지 않을까요?

 

그 이유는 아마, '업무일정 상'이라는 핑계 혹은 '실 사용자의 비협조 및 인터뷰 방식의 이해부족' 정도가 가장 큰 이유가 아닐까 싶습니다. 업무일정 상 인터뷰를 생략하는 것. 즉, 바쁘다는 이유로 니즈분석을 못한다는 소리겠죠? 왜 실 사용자에 대한 니즈분석이 해도 그만 안해도 그만인 필요충분 업무로 전락했는지는 잘 모르겠습니다. 하지만 니즈분석이 따르지 않는 백오피스는 정말 있으니만 못한 아주 불편한 골칫덩이가 되어 버릴 가능성이 높습니다.

 

웹기획자를 하다보면 UI나 UX가 중요하다는 말을 참 많이 듣곤 합니다. 적어도 일반적인 웹 서비스에서의 UI나 UX는 기본만 하면 된다는 게 제 생각입니다. 웹 상에서 UI/UX 요소가 충족되지 않더라도 컨텐츠나 커뮤니티적인 요소가 갖춰진다면 사용자들은 어느정도의 불편함이나 보기싫음은 감수할 수 있다고 생각합니다만, 백오피스는 좀 상황이 다릅니다. 

 

고객에 대한 진단이 필요합니다.


지금까지 접해본 대다수의 백오피스는 디자인적인 요소들이나 사용자 편의, 경험적인 이슈들은 철저히 배제된 채, 개발과 유지보수 편의성 중심으로 이루어진 경우가 대부분이었습니다. 그리고 이를 바로잡는 과정에 이해하게 된 내용이 "백오피스에서의 UI/UX 요소는 프론트 웹의 그것보다 훨씬 중요한 순위를 차지한다."인데, 백오피스의 이용은 업무의 효율성과도 직결된 부분이며, 이 효율성이 담보되지 못할 경우 업무의 능율저하로 이어지게 된다는 것이죠.

 

쉽게 얘기해서 백오피스 어떤 업무를 처리한다고 가정해보죠. 이때 고객니즈의 반영을 통해 1분이면 처리할 수 있는 업무가 UI/UX 설계 미비로 인해 10분씩이나 걸린다면 하루에 처리해 낼 수 있는 업무의 절대적 양이 줄어들게 됩니다. 더 나아가 업무를 처리하는 당사자 역시도 업무에 대한 흥미나 관심도가 좋지 못한 방향으로 흐르게 되며, 궁극적으로 서비스의 질적하락으로 이어지게 됩니다.  뿐만 아니라 백오피스라는 것은 한 번 만들어놓으면 대대적인 개편이 어려운 서비스 중 하나 입니다.

 

백오피스 개편을 하기 위해서는 많은 인적/물적 자원이 투입되게 되는데, 백오피스를 직접 이용하지 않는 경영진 입장에서는 아무리 백오피스 개편의 필요성을 어필해봐야 아니.. 만들때는 뭐하고 지금 지랄이냐는 소릴 들을 수도.. 먹히지 않기 때문에 대단위의 개편이 어려울 수 밖에 없으며 주간 업무일지를 작성하는 1년 내내 "백오피스 개선기획" 항목이 들어갈 수 밖에 없는 것이죠. 

 

백오피스의 설계는 기획자 혼자만의 업무가 아니며, 백오피스 기획이 잘 나오지 않는 것은 기획자만의 책임으로 몰기에도 무리가 있는 게... 백오피스란 다수의 관련인력들이 설계와 검수과정을 거쳐야만 완성되는 복합적인 결과물인데 실제로 백오피스를 사용할 내부고객들이 자신의 바쁜 업무 핑계로 백오피스 기획 전에 진행해야 할 니즈분석에 협조적이지 않을 경우, 결과적으로 그 피해는 내부고객 본인들이 고스란히 받게 되며, 단지 자신들이 생각하던대로 결과가 나오지 않았다고 해서 생각을 이야기하란 말이다!! 기획자를 탓할 수는 없는 것입니다.

 

반대로 기획자 역시도 인터뷰를 통해 무엇을 얻을 것인가도 생각하고, 그에 대한 질문항목을 사전에 정리하여 인터뷰를 진행해야 의도하던 결과를 얻을 수 있는데, 꼴랑... "백오피스, 어떻게 만들었으면 좋겠어요?" 라거나.. "그동안 뭐가 불편하셨어요?" 같은 X드립은 답변자로 하여금 뭘 어떻게 이야기해야 할지를 고민하게 할 뿐입니다.

 

때문에, 백오피스를 이용하는 내부고객들.. 마케터나 MD, CS 담당자들이 백오피스 내에서 각각의 업무를 어떤 식으로 진행하는지에 대한 프로세스를 얻을 수 있어야 하고, 그 프로세스에 대해 "이렇게 바꾸면 어떨까요?" 같은 역제안을 줌으로서 내부고객들의 인사이트를 끌어 낼 수 있으며, 여건이 된다면 각각의 업무 프로세스에 기반한 프로토타입의 인터페이스를 발싸믹 목업(Balsamiq Mockups)이나 액츄어 같은 전문적인 UI 설계용 프로그램을 통해 구현해 봄으로서, 앞으로 작업될 페이지를 시각적으로 접하게 하여 만들어질 백오피스에 대한 실제 이용편의성을 체크하는데 유리합니다. 

 

아울러 내부고객들은 눈으로 직접 보기 전까지는 인지하지 못한다는 점을 간과하시면 안됩니다.  보통 백오피스를 설계하고 커뮤니케이션하는 과정에서 내부고객들은 설계범위나 실제 어떻게 구현될 지에 대한 감이 없는 관계로 큰 이견 없이 OK하는데, 작업완료 이후 테스트 과정에서 승인했던 내용을 뒤집는 경우가 허다합니다.  "내가 언제 이렇게 요청했냐?" 하는 것이죠.  이런 예측 가능한 결과를 미연에 방지하기 위해서라도 프로토타입 형태의 인터페이스 구현은 필요하며, 이 같은 과정을 거쳤을 때와 그렇지 않았을 때의 고객반응에 큰 차이가 있다는 것을 꼭 기억하시기 바랍니다.

 

지금까지 백오피스 기획에 대한 개략적인 방법론을 정리해 봤는데요, 다음 편에서는 백오피스 설계를 위한 사전 인터뷰 방법과 기획자가 백오피스 기획에 있어 어려움을 느끼는 화면설계를 쉽게 하는 방법들을 살펴보도록 하겠습니다. 아울러 이 글을 보시는 여러분들의 공감댓글 한마디가 더 좋은 글이 나오는 원동력이랍니다. 글을 통해 도움이 되셨거나 기획과 관련해 궁금하신 점이 있다면 언제든 댓글 남겨주세요..^^ 



야메군. Web와 Mobile, Digital 카테고리 SME(Subject Matter Expert). 웹기획 18년차로 네이버 웹기획자 커뮤니티 "웹(WWW)를 만드는 사람들"에서 운영진으로 활동하고 있으며, 딴지일보를 시작으로 아이러브스쿨, 짱공유닷컴, YES24 등의 회사를 거쳐, 민간 IT 원천기술 연구소 "Valhalla Lab"에서 Pattern recognition과 Machine learning, Natural Language Processing 기술의 상업적 이용방법에 대해 연구. 현재 하나투어에서 데이터 기반 서비스 설계 중. 2016년 7월 7일, 웹/모바일 기획자의 업무능력 향상으로 위한 Guide Book "처음부터 다시배우는 웹기획(정재용, 최준호, 조영수 공저)" 출간.


반응형
댓글
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday