문제 해결 방법의 우선순위설정
문제 해결 방법을 바라보는 관점
사람은 자신이 갖고 있는 모든 지식을 다 활용하려고 한다.
또한, 문제를 해결하기 위해서 자신의 지식이 닿는 선에서 모든 가능성을 검토하고, 그 가능성 중에서 가장 좋은 방법을 선택하는 것이 좋은 방법이라고 배우기도 한다. 자신이 알고 있는 지식을 모두 이용해서 문제를 해결하고자 하는 방법은 굉장히 모범적이지만, 사용자 경험을 기획하고 관리하는 입장에서는 이러한 방법이 때론 합리적이지 않을 수도 있다. 적은 자원으로 문제를 해결했다면 '좋은 방법'일까? 빠르게 문제를 해결할 수 있었다면 '좋은 방법'이었던 걸까? 문제 해결에 있어서 좋은 방법이 무엇인지 합의가 이루어져있지 않기 때문에, 때론 내가 아는 것을 모두 활용한 문제 해결이 관점에 따라서는 안 좋은 선택이 될 수도 있다.
인식된 문제와 문제의 우선순위
우리가 직면하고 있는 문제가 하나뿐이라면, 그리고 그 문제를 해결하는 데 사용할 수 있는 자원이 무한하다면, 문제를 해결하는 방식은 단순하다. 문제 해결을 위해서 가능한 모든 지식을 활용하면 된다. 하지만, 기획자 혹은 프로젝트 매니저가 마주하는 문제가 하나가 아니라는 것이 문제다. 조직에서 일을 하는 기획자는 무수히 많은 문제를 마주하고 있을 가능성이 높다. 이러한 문제를 모두 동시에 해결할 수 없기에, Trello나 Jira 같은 태스크 관리 도구를 사용하고, 인식된 문제의 목록을 만들어서 관리하는 것이 일반적이다. 또한, 이러한 문제들의 목록이 모두 같은 긴급도를 갖고 있지 않기 때문에, 업무 우선순위를 설정하기도 한다.
얼리슬로스 조직에서 사용하는 JIRA. 업무별로 중요도를 설정하여 관리한다.업무 우선순위를 설정하는 방법은 조직에 따라 다르겠지만, 일반적으로 사용하는 방법은 리스크 관리에서 사용하는 '문제의 중요도'와 '문제의 시급성' 매트릭스다. 각 문제를 '중요도'와 '시급성'을 축으로 갖는 분산 차트를 통해서 중요도를 관리하는 것이다. 나의 경우에는 중요도가 높고 시급성이 높으면 매우 우선순위가 높은 일이겠고, 시급성이 높으면 우선순위가 높은 일, 중요도가 높으나 시급성이 낮다면 중간 정도 우선순위를, 중요도와 시급성이 낮은 경우 긴급하게 처리하지 않아도 되는 일로 관리하고 있다.
얼리슬로스의 문제 처리 우선순위 설정 방법문제와 해결 방안은 한 세트가 아니다
인식된 문제를 해결함에 있어서 한 가지 더 고려해야 하는 것은, 기획자나 프로젝트 매니저가 마주하는 문제도 여러 가지이지만, 각 문제를 해결할 수 있는 방법도 여러 가지라는 것이다. 서비스 기획 일은 수학 문제 같은 것이 아니어서, 동시에 여러 가지 답을 가질 수 있으며, 동일한 답을 내는 방법 또한 다양하다. 하지만, 기획자나 프로젝트 매니저를 위해서 작성된 글들을 보면, '문제 인식'과 '우선순위 설정'의 중요성은 굉장히 많이 강조되지만, '문제 해결 방법의 우선순위 설정'을 다루는 일은 많지 않다. 강조되지 않았을 뿐이지, '문제 해결 방법의 순위 설정' 역시 '문제의 우선순위 설정'만큼이나 중요한 일이다.
11개의 단서가 있는 수도쿠 문제지 경우의 수는 놀랍게도 6,337,174,388,428,800개라고 한다.예를 들어, 우리가 운영하고 있는 웹페이지에 '긴급 공지'를 올리는 일이라고 생각해보자. 2019년 10월, 우리 조직은 프론트엔드 기능을 배포하면서, 미처 인터넷 익스플로러 호환성을 확인하지 못했었다. 배포가 완료된 지 얼마 지나지 않아서, 우리는 인터넷 익스플로러를 사용하는 고객의 문의 전화를 받고, 문제를 인식할 수 있었다. 우리는 '서비스 배포 롤백'과 '긴급 공지 후 핫픽스' 중, '긴급 공지'하는 방법을 선택했다. 하지만, 긴급 공지함에 있어서 한 가지 문제가 있었다. 우리 웹사이트 구조상 '긴급 공지'를 할 수 있는 시스템이 없었던 것이다.
재미있게도, 긴급 공지를 할 수 있는 방법은 여러 가지가 있다:
· 운영 조직에서 등록할 수 있는 배너 시스템을 구축한다.
· 이번에만 사용할 수 있도록 긴급 공지 배너를 하드코딩한다.
· 모든 고객에게 이메일을 발송한다.
· 다른 방법을 탐색해본다.
이 선택지에서, 문제 해결 방법 역시 문제의 우선순위처럼 동일한 형태의 매트릭스를 통해서 설정할 수 있을까? 예를 들어, 해결방법의 난이도와 소요 시간을 각 축으로 갖되, 높낮이를 역전시킨 매트릭스를 그리면 문제 처리 우선순위와 동일하게 해결할 수 있을까? 만약 이러한 문제 해결 방법 탐색 매트릭스를 따른다면, 우리 조직이 취했어야 했을 행동은 '모든 고객에게 이메일을 보낸다.'였다. 하지만, 당시 내가 선택한 흐름은 '이메일을 보낸다.'가 아니었다.
① 운영 조직은 배너 시스템 구축이 필요하다고 생각했으나, 시급도가 높은 다른 일(인터넷 익스플로러 호환성 문제 해결)이 있었기에 배너 시스템을 구축할 수 있는 여유는 없었다.
② 긴급 공지 배너를 하드 코딩하는 것과 모든 고객에게 이메일을 발송하는 것은 유력한 해결방법이었다. 문제는 인터넷 익스플로러를 이용하지 않는 60%의 고객은 문제가 없음에도 불구하고 배너를 확인해야 하며, 이메일을 보내는 것은 마침 당일 서비스를 이용 중이지 않아 문제를 인지하지 못한 고객에게도 장애를 알려야 하기에 피하고 싶은 선택이었다.
그래서 당시 우리가 선택한 방법은 '다른 방법을 탐색해본다.'였다. 고객과의 실시간 소통을 위해 웹사이트에 삽입해두었던 '채널톡'의 문구를 수정하는 것으로 갈음한 것이다. ①별도의 개발 리소스 투입이 없었기에, 온전히 시급도가 높은 문제 해결에 집중할 수 있었고, ②인터넷 익스플로러를 이용하는 고객이 정상 작동이 되지 않음을 확인했을 때, 취할 행동인 '채널톡으로 문의한다'에서 파생되는 행동이기에 정상 사용자들은 문제가 있음을 인지하지 못하거나, 일부만 인지시킨 채 '긴급 공지'를 해결할 수 있었다.
정상 사용자와 오류 발생 사용자가 이용할 것으로 예측하는 서비스 이용 흐름은 다르다여기서 알 수 있는 것은 문제 인식의 우선순위와는 다르게, 문제 해결 방안의 우선순위 설정은 한 가지 차원이 더 존재한다는 것이다. '해결 방법에 따른 사용자 경험'이 그것이다. 두 가지 차원으로 놓고 문제 해결 방식을 탐색한다면, 당연히 '빠르고, 쉬운 문제 해결 방법'이 우선순위에 올라가야 한다. 문제를 해결했을 때 사용자 경험이 어떻게 변화하는지, 혹은 운영을 하는 입장의 경험이 어떻게 변화하는지, 앞으로도 이런 문제가 지속적으로 유지될 것인지를 고려해서 문제 해결 우선순위를 설정하지 않으면 안 된다.
난이도도 쉽고, 소요 시간이 짧지만, 사용자 경험이 확실히 개선되는 문제 해결 방안과 난이도도 어렵고, 소요 시간이 길지만 사용자 경험이 개선될지 안될지 확실하지 않은 문제 해결 방안이 있다고 가정해보자. 이 경우에서 선택은 단순하다. 쉽게 금방 끝낼 수 있으며, 사용자 경험이 확실하게 개선되는 방법을 선택하면 된다. 하지만, 소요 시간이 짧고 쉽지만 사용자 경험 개선 정도가 낮은 해결 방법과, 소요 시간이 길고 어렵지만 사용자 경험이 크게 개선되는 해결 방법 중에 어떤 것을 선택하는 것이 좋을까? 기획자와 프로젝트 매니저에게 요구되는 능력이 까다로운 것은, 갖고 있는 문제 해결 방안을 잘 배열하고, 각 방안의 장단점이 잘 파악되어있다고 하더라도 어떤 것을 선택하는지 애매한 순간이 찾아온다는 것이다.
이러한 순간까지 왔을 때, 내가 사용하는 나의 액션 리스트는 이렇다:
· 가능하면 쉬운 방법으로 해결하자. 일단 문제를 해결하면 나중에 여유가 났을 때, 개선할 수 있다.
· '좋은 사용자 경험'을 제공하는 궁극적인 목적은, 보다 큰 가치를 창출하기 위해서다. 이 사용자 경험을 개선했을 때, 얻을 수 있는 금전적 이득이 없거나 적다면 과감하게 미루자.
결국에는 경영도 고려해야 한다
문제를 인식하고, 해결할 우선순위를 설정하고, 문제를 해결하기 위한 방법을 선택함에 있어서 다양한 방법을 고려할 수 있다. 하지만, 여러 가지 방법을 고려했음에도 불구하고 '가장 좋은 해결 방법'을 선택하기 어려울 때가 많다. 서비스 기획자나 프로젝트 매니저가 문제 해결의 좋은 방법을 선택하기 위해서는, 결국 경영 상태를 고려하지 않을 수 없다.
과거에 작성한 이야기지만, 우리 조직이 사용자 경험을 개선할 때 경영 관점에서 개선한 두 가지 일화를 소개한다:
부끄러운 이야기를 당당하게 해 보자면, 우리 회사가 제공하는 서비스는 '회원 탈퇴' 페이지가 존재하지 않는다. 그렇다고 아무도 회원 탈퇴를 요청하지 않았는가? 그렇지도 않다. 우리는 회원 탈퇴 요청이 있을 때, 직접 데이터베이스에서 회원 정보를 삭제 처리하고 결과를 메일로 통보해주고 있다.
가입할 때는 마음대로였지만 나갈 때는 아니랍니다.너무 당연히 있어야 할 것 같아서 많은 디자이너들이 당연히 기획하는 기능이지만, '회원 탈퇴'도 역시 다른 기능들과 동일한 '기능'이다. 회원 탈퇴 페이지 레이아웃 디자인과, 회원 탈퇴에 이르기까지의 와이어프레임 설계, 그리고 개발자의 기능 개발이 모두 필요하다. 즉, 이 사용자 경험을 만들기 위해서는 많은 자원이 필요하다는 뜻이다.
회원 탈퇴를 하고 싶은데, 어떻게 하나요?
우리가 회원 탈퇴에 대해서 문의를 받은 적이 없는 것은 아니다. 회원 탈퇴 방법이 없다고 강한 불만을 제기받은 경험도 있다. 그때, 우리 조직에서는 회원 탈퇴 페이지를 만들어야 한다는 의견을 제시했지만, 나는 회원 탈퇴 페이지를 만들지 않는 방향으로 결정했다. 내가 이 부정적 사용자 경험을 개선하지 않은 이유는 다음과 같다:
· 사용자 경험을 개선하기 위한 조직의 자원은 한정적이다.
· 탈퇴를 결심한 사용자의 사용자 경험을 개선하는 것보다는, 사용하는 사람의 경험을 개선하는 것이 우선이다.
· 사용자가 탈퇴를 결심한 시점에서 이미 우리는 그 사람에게 만족스러운 경험을 제공하지 못한 것이다. 떠나는 소를 위해 외양간을 고치는 게 무슨 의미인가.
· 사용자 탈퇴 요청은 1년에 2회 정도 발생한다. 1회를 처리하는데 걸린 시간은 10분 내외다. 사용자 탈퇴 기능을 개발하는데 걸리는 시간은 디자이너, 개발자의 공수를 합쳐서 적어도 6시간은 소요되는 일이다.
· 즉, 개발에 투입된 자원 이상의 효과를 내려면, 최소 36명 이상의 탈퇴가 자동으로 이루어져야 하는데, 이 속도로라면 18년 후에야 투입 자원의 손익분기를 넘길 수 있다.
그렇다고 우리가 기능을 개발하지 않고 방치만 한 것은 아니다. 기능을 개발하지 않는 대신 우리가 사용하는 문의 서비스 내에서, "회원 탈퇴"에 대한 요청을 우리가 제공하는 설문조사 폼을 통해서 받도록 수정해두었다. 개발 조직이나 그래픽 디자이너의 도움을 전혀 받지 않고, "회원 탈퇴"가 불가능하지는 않도록 만든 것이다.
경영자의 관점에서 기획하는 방법과 사례는 기존 발행한 다른 글을 통해서 확인할 수 있습니다.
때로는 방치하는 것도 답이 될 수 있다
이 글을 작성하게 된 이유는, 우리 조직이 지난주에 겪었던 일을 정리하기 위함이다. 우리 조직은 최근 기존에 구성되어 있던 기능을 향후 유지보수 편의성을 가져가기 위해서 리팩토링(재개발)을 수행하고 있다. 그런데, 재미있는 것은 이러한 재개발은 우리 조직의 액션 플랜 중 가장 후순위에 있는 일이라는 것이다. 우리 조직이 자원을 투입하는 순위는 ①비즈니스 영역을 확대하는 일, ②서비스의 가치가 올라가는 일, ③기존 업무의 효율을 제고하는 일,.... 그리고 마지막에 있는 것이 정상적으로 제공 중인 기존 서비스를 리팩토링 하는 것이다. 그럼에도 불구하고 가장 마지막 순위에 있는 리팩토링 업무를 수행하고 있는 이유는, 서버 개발자와 기획자가 다른 업무를 수행하고 있는 동안 프론트엔드 개발자끼리 할 수 있는 일 중, 우선순위가 가장 높은 일이 리팩토링이기 때문이었다.
우리는 리팩토링 과정에서 기존 제공하던 서비스에서 발견된 불편한 점과 아쉬운 점을 함께 개선하기로 했다. 운영조직과 기획자, 그리고 고객의 목소리를 기반으로 기획서를 만들었을 때, 우리는 뭔가 잘못됐음을 알았다.
프로젝트에만 집중하고 있으면, '왜 이 일을 하고 있는가'를 망각할 때가 있다. 리팩토링 프로젝트를 수행하는 이유는 다른 조직의 리소스가 활성화되기 전까지 할 수 있는 일을 하는 것이었는데, 사용자 경험을 고려해서 모든 기획을 다 넣다 보니 '총력전'을 감안해야 하는 업무 범위가 되어버린 것이다.
예를 들면 이런 기능 개선 아이디어가 있었다:
· 포켓서베이 서비스는 문항 간 이동 시 '포커스'라는 개념을 이용한다. '포커스'는 문항을 클릭하거나, 직전 문항에 답변을 하면 자동으로 변경되며, 읽기 좋은 위치로 자동으로 스크롤해준다.
· 설문조사 구성 시 선택지를 아주 많이 사용하는 경우, 편의 기능인 '자동 스크롤'로 인하여, 하단 부의 선택지를 확인하고 선택하는 것이 번거로운 문제가 발생한다.
· 이를 해결하기 위해서, '포커스' 개념을 재정립하고, 신규 기능을 개발해야 한다.
우리는 이러한 유형의 문제를 금번 개발에서 모두 덮어두고 가기로 했다. 이러한 문제로 인해서 사용자가 불편함을 겪는 것도 맞고, 이 문제를 해결하면 사용자 경험이 개선되는 것은 확실하지만, 모든 사용자가 동일한 경험을 하는 것은 아니기 때문이다. 기획자는 어떠한 문제를 해결하는 방법을 선택함에 있어서, 개선 방법도 확실하고, 난이도 또한 고려했으나, 다른 중요도 높은 일을 수행하기 위해서 '지금 당장 문제를 해결하지 않음'이라는 선택지를 고를 수도 있어야 한다.
아래 모든 질문에 '아니오'라고 답변할 수 있는 문제는, 지금 당장 해결하지 않는 것이 좋은 답일 수도 있다.
· 지금 이 문제를 해결하지 않으면, 서비스 제공이 불가능한가?
· 대다수의 사용자가 동일한 불편함을 겪고 있는가?
· 불편한 정도가 향후 서비스 사용을 고려하지 않을 정도인가?
우리는 어느 한 업무에 몰두하다 보면, 양 옆을 가림막으로 가린 채 앞만 보는 경주마처럼 주변을 인식하지 못하기도 한다. 실제 업무를 수행하는 사람들은 이러한 성향이 좋을 때도 있다. 하지만, 기획자나 PM처럼 조직의 길을 제시하는 사람이라면, 경주마들이 제대로 달릴 수 있도록 길을 유도해주어야 한다. 그 길을 유도하는 방법은 간단하다. 문제 해결하는 방법의 우선순위를 설정하고, 조직이 합의한 '좋은 문제 해결 방법'을 탐색할 것. 눈에 보이는 문제를 모두 해결하려고 하지 않을 것.
