by
Feb 11. 2022
IT에서의 '문제정의'란 말의 정의
문제점을 찾으란 말이 아니다.
PO/PM은 문제를 정의하는 역량이 중요하다?
문제를 잘 파악해서 정의할 수 있는 역량에 대한 이야기를 굉장히 많이 한다. 그런데 이 문제를 정의하는 역량이라는 것이 어떤 것이냐를 설명해보라고 하면 이해도의 차이가 굉장히 많다.
쉽게 생각하면 무언가 '사용자 관점의 문제점을 찾으라는 걸까?'라고 생각하기 쉽지만, 사실 사용자관점의 문제점이 비즈니스의 지향점과 충돌하는 부분도 있을 수 있기에 '문제'라는 단어는 굉장히 모호하게 느껴진다.
사실 문제라는 단어가 해외에서 Problem에서 왔다는 것도 주의해야할 지점인데, 사실상 Problem은 정답이 정해져 있는 Quiz가 아닌데 사람들은 정답이 있는 문제를 정의하려고 애쓰게 된다. 특히나 사내에서 요청을 직접적으로 받는 경우에는 이 문제정의라는 부분을 '어떻게 수행할 것인가'에 더 많이 쓰게 되기도 한다. 예전 구조적으로 불가능한 요구사항에 대해서 어떤 상무님이 '되는 방향으로 생각해와라'라는 지시에 격분했던 기억도 떠오르고 말이다.
제약이 많은 환경에서 오래 일하수록 '문제정의'를 '안되던 것을 어떻게 되게 만들어 낼 것인가'의 관점에서 고민하게 되는 경우가 많다. 그런데 그게 과연 정말로 'Problem'을 정의하고 해결하는 것이 맞을까?
요청자는 자신이 원하는 것을 정확하게 표현하지 못한다.
그들이 생각하기에 해답이라고 생각하는 것을 요청한다.
첫번째 책인 <서비스기획스쿨>에서 현업요청자와의 요구사항 리뷰 회의의 모습을 가상으로 보여준다. 리얼리티를 추구하면서도 물론 극단적인 예시를 들어서 설명하지만, 내용은 명확하다. 요청자가 원하는 형태가 아무리 구체적이더라도 실제 해결하고 싶은 '니즈'는 다를 수 있다고 말한다.
즉, '여기에 배너 하나 넣어주세요'라는 단어가 사실은 '이 화면에서 발생한 트래픽을 이용해서 매출을 높이고 싶어요'라는 단어로 치환할 수 있다는 점이다. 그런데 이 부분을 놓치게 되면 우리가 해결해야하는 문제는 '여기에 배너를 어떻게 넣느냐'에 집중하게 된다. 정말로 집중해야 하는 문제는 '이 화면의 트래픽을 이용해서 매출을 높일 수 있는 방법'이 되느냐인데 말이다. 이것이 '진짜 문제'를 정의한다는 의미라고 생각한다.
그나마 이 예시는 그래도 요청하는 것 그대로 구현이 가능한 상황이다. 더 끔찍한 케이스는 아예 현재의 시스템 구조적으로 해결할 수 없는 경우에 있다. 개선은 가능하겠지만 근본적인 구조를 다 고쳐야 가능한 경우, 이 경우에 할수 있는 대답은 '지금 못합니다' 또는 '오래 걸려요'에 해당한다. 하지만 이 것도 다른 방식으로 문제를 재정의해볼 수도 있다. 왜냐하면 '사용자의 문제'와 '개발의 문제'를 다르게 정의내릴 수도 있기 때문이다.
IT적인 예시는 너무 구체적일 수 있으니 비유적인 예시를 들어보겠다.
누군가 '2006년으로 돌아가게 해주세요'라고 요청을 했다고 생각해보자. 문장 그대로를 읽는다면 2006년으로 돌아간다는 것은 타임머신에 의한 시간여행을 의미한다. 그런데 우리의 기술력으로는 타임머신을 만들어 줄 수없다. 솔직히 시간과 노력을 들인다면 언젠가는 거대한 기술력을 해줄 수 있을지도 모른다. 그런데 그 사실은 장담할 수 없다. 그래서 '왜' 2006년으로 돌아가고 싶은지를 요청자에게 물어보면 이런 대답이 나온다.
"2006년이 가장 행복했던 시간이어서 그 시간으로 돌아가고 싶어요" 라고 말했다고 생각해보자.
여기까지 들어보면 애초에 이유까지도 우리가 해결해줄 수가 없는 니즈라고 판단할 수 있다. 여기서부터는 요목조목 문제를 뜯어서 정의해봐야 한다.
1) 2006년은 어떤 이유에서 가장 행복했던 시간인가?
2) 그 시간으로 돌아갔을 때, 얻을 수 있는 것은 무엇인가?
이 질문들은 사실상 구체적인 개발 프로젝트가 시작되기 전에 미리 고민되어야 하는 논리적 문제에 해당한다. 이런 질문들을 통해서 사용자의 문제를 좁혀 들어갈 수 있다. 인터뷰를 통해서 이렇게 답변을 얻었다고 생각해보자.
1)의 답변 : 2006년에 가족들이 모두 함께 했고, 가장 성적이 좋은 시기였다.
2)의 답변 : 살아있는 가족, 자기만족감
이 사람이 요청한 요구사항의 궁극적인 목적은 결국 '행복'이고, 이 행복의 조건은 '가족들의 존재, 그리고 자기만족감'에 해당한다. 여기까지가 요청자의 입장에서의 문제에 대한 정의다.
이 문제를 정의했다면, 이제 이 문제를 'IT 기술로 해결할 수 있느냐'에 대한 문제를 새로 정의해야한다. 프로덕트를 다루는 사람이라면 응당 개발을 해야한다고 생각할 수 있는데, 사실 개발없이 문제를 해결한다면 이거보다 좋은 상황은 없다. 프로젝트 하려고 존재하는 직무가 아니기 때문이다.
그럼에도 이 '사용자의 문제'를 IT기술로 더 혁신적으로 해결할 수 있는가를 고민해볼 수 있다. 이 문제는 IT요청사항이 아니었으니까, 무언가 인위적 행위로 해결할 수 있는지로 치환을 해보자. 여기서 고민해야하는 것은 전제조건이다. IT에서는 시스템이나 레거시가 바로 이 전제조건에 해당한다.
전제조건1 : 시간은 미래로만 이동이 가능하다.
전제조건2 : 이미 죽은 사람을 되돌릴 수 없다.
시스템적인 전제조건과 사용자의 여러가지 조건을 생각한다면, 요구한 것과 비슷하지 않더라도 행동해볼 수 있는 문제를 정의해볼 수 있다.
해결가능한 문제로 재정의 : 미래에 새로운 가족을 만들고, 자기만족감을 높여서 2006년보다 더 행복한 시간을 만든다.
이제 전제조건의 한계를 벗어나는 새로운 문제를 정의했다. 이 새로 정의한 문제가 바로 '프로젝트의 해결 대상이 되는 문제'가 된다. 그리고 이렇게 구성된 문제를 이제 프로젝트화 시켜서 다같이 해결해 나갈 수 있다. 타임머신을 개발하는 것보다 '가족을 구할 수 있는 배우자 매칭 서비스'나, 자기만족감을 높여줄 수 있는 '멘탈케어서비스' 혹은 '성적관리 서비스'가 실제 구현할 수 있는 대안적 서비스의 형태라고 할 수 있다. 그리고 그 모든 일의 지향점은 '2006년보다 더 행복한 시간을 미래에 만드는 것'이 된다.
불편함만을 찾아내는 것은 VOC에 지나지 않는다.
