문제 해결 관점에서 바라보는 프로젝트의 프로세스
프로젝트의 핵심은 일정과 비용, 인력 구성이 아니다
문제 해결 관점에서 프로젝트 매니저의 역할과 체크리스트
처음 프로젝트 매니저의 역할을 맡게 되었던 때에, 제법 많은 양의 아티클과 영상, 또는 도서를 살펴보았다. 설명하는 이들마다 세부적인 설명이나 노하우는 달랐지만, 공통적으로 언급되는 부분은 아래와 같았다.
1. 작업 범위 설정 및 합의
2. 비용/예산 관리
3. 인력/생산성 관리
이는 프로젝트project를 '특정 기간과 예산 내에 목표한 산출물을 내놓기 위한 일련의 과정' 정도로 정의하고, 특히 SI, 혹은 외주 프로젝트의 관점에서 바라보았기 때문인데,
문제를 발굴하고, 정의하고, 해결하는 관점에서 바라본 프로젝트의 정의와 프로젝트 매니저의 역할은 다소 달라 생각을 남겨본다.
문제 발굴-정의-해결 관점에서의 프로젝트의 정의
문제 발굴-정의-해결 관점에서 프로젝트를 다시 정의해보자.
1. 모든 프로덕트/서비스는 원론적으로 고객이 지닌 문제를 해결함으로써 (혹은 해결을 도와줌으로써) 그 대가로 수익을 내거나 기타 대가를 받는다.
2. 그리고 조직/팀이란 이러한 프로덕트/서비스를 고객에게 알맞게 제공하는 일을 하는 이들이다.
3. 이들이 하는 일은 1) 일상적인 테스크task와 2) 일정 기간 동안 진행하는 프로젝트project로 나뉜다.
4. 다만 프로젝트란 테스크와 비교해서 여러 이해관계자의 협업이 필요하고, 기간이 길다.
▶ 그렇다면 프로젝트란 "고객의 문제를 해결하기 위해 조직 내/외부 이해관계자들과 협업하여 일정 기간 진행하는 업무 또는 과정"이라고 정의해볼 수 있다.
고객의 문제를 해결하기 위해 조직 내/외부 이해관계자들과 협업하여
일정 기간 진행하는 업무 또는 과정
문제 발굴-정의-해결 관점에서의 프로젝트의 프로세스
위와 같은 정의를 바탕으로, 프로젝트는 다음의 절차/단계로 구성해볼 수 있다.
1. 문제 발견 및 제안 : 왜 문제를 풀려고 하는가?
이번 프로젝트를 통해 해결해야 할 문제가 무엇인지 발견하거나 제안한다. 프로젝트를 진행하는 배경, 맥락, 목적과 동일하다.
2. 문제 정의 : 풀려고 하는 문제가 구체적으로 무엇인가?
이번 프로젝트를 통해 해결해야 할 문제가 무엇인지 구체적으로 정의define하고, 그 범위 혹은 깊이를 명확히 한다. 또한 이에 대해 내부의 이해관계자들에게 공유하여 이해도를 합일시킨다
3. 상세 기획 : 이 문제를 어떻게 풀 것인가?
어떤 문제를 얼마나 풀 것인지 정의되었다면 이를 풀 방법을 구체적으로 기획한다. 보통 이야기하는 UX/UI를 설계 하고 세부 기능, 정책을 구성하는 일이 이 단계에 해당한다.
4. 기획의 검토 : 이 문제를 정말 그 방법대로 풀 수 있는가?
해당 기획을 이해관계자들에게 공유하여 실제 구현 가능성, 타당성, 효용성 등에 대해 검토하고 필요시 수정을 거쳐 확정한다.
5. 디자인 및 개발 : 그 문제를 실제로 풀기 위한 제작 과정
기획의 검토가 끝나 확정되었다면, 이제는 정말로 그 문제를 풀기 위해 제품을 제작한다. 보통 말하는 디자인, 개발이 이 과정에 해당한다.
6. 배포(납품) 준비 : 문제를 풀 제품이 출시될 준비가 되었는가?
제품 제작의 막바지에 도달한 즈음엔 일정 시간이 흘러가 있다. 우리가 풀기로 한 문제를 풀기 위해 제품이 이제 대부분 완성되었음을 고객과 이해관계자에게 알리고, 완성에 다다른 제품이 고객의 문제를 풀 준비가 되었는지 확인한다.
7. 배포(납품) 및 이슈 대응 : 실제로 문제를 해결하는가? 다른 이슈나 문제는 없는가?
문제 정의 및 기획 단계에서 설계한 가설이 실제로 맞는지-예상대로 고객이 반응하는지, 혹은 예상하지 못한 다른 이슈는 없는지- 확인한다. 이를 통해 프로젝트를 통해 내놓은 결과물이 고객의 문제를 제대로 해결하는지 검증한다.
결국 프로젝트의 모든 과정은 문제를 제대로 정의하고, 제대로 해결하고, 제대로 해결되었는지 확인하기 위함이다.
프로젝트의 모든 과정은 문제를 제대로 정의하고, 제대로 해결하고,
제대로 해결되었는지 확인하기 위함이다.
문제 발굴-정의-해결 관점에서 프로젝트 매니저의 역할 혹은 체크리스트
위에서 정의한 단계에 따라 프로젝트 매니저가 해야 하는 역할, 혹은 각 단계에서의 체크리스트를 살펴보자.
문제를 정의하고, 해결하기 위해 진행하는 프로젝트이므로, 담당자인 프로젝트 매니저가 해야 할 일 역시 모두 이와 관련되어 있다. 다만 짧은 기간, 적은 예산/비용으로 진행하는 테스크task와 달리 중장기간 많은 인력과 시간, 비용을 들이는 프로젝트의 특성상 '리스크를 최소화한다'는 역할이 추가된다.
즉, 프로젝트 매니저의 역할은
1) 프로젝트의 각 주요 지점에 고객/이해관계자를 참여시켜서
2) 제품 배포/납품 시점 이전에 미리 가설을 검증하고
3) 내부 이해관계자의 이해를 일치시켜서
▶ 리스크를 최소화하며 + 해결하기로 한 문제를 제대로 해결하기 위한 역할이다
해결하기로 한 문제를 리스크를 최소화하여 제대로 해결하기 위한 역할
자세한 사항은 위의 시트에 적어두었지만, 아래에 본문으로도 요약하여 남겨둔다
1. 문제 발견 및 제안
- 비즈니스의 목표to-be 이해하기 (ex: 어떤 지표를 올린다, 어떤 시장으로 확장한다 등)
- 문제의 상황as-is 이해하기 (ex: 현재 지표는 어떻다, 현재 시장에서 어떤 위치에 있다 등)
- 이 문제를 풀기 위해 풀어야 할 고객과 문제 생각해보기 (ex: 기존 고객 vs 신규 고객 / 충성 고객 vs 저관여도 고객 등)
2. 문제 정의
- 가설 세우기 : ~~ 한 유저가 ~~ 한 pain point를 겪고 있을 것이다
- 유저 인터뷰 : 만나보니 실제 유저들은 ~~ 한 pain point를 겪고 있다
- 인터뷰 분석 결과로 문제 정의 + 프로젝트의 과업 범위 논의
- 과업 범위 결정 및 유관자 공유 : "고객을 만나 발견한 n개의 문제 중에서, 이번 프로젝트에선 a, b, c를 해결한다"
3. 상세 기획
- 문제 정의 공유 및 User Story (고객이 문제를 해결하기 위해 할 수 있어야 하는 행동) 작성
- 아이데이션 + I.C.E. 등으로 구체적인 실행안 구상하고 + 합의하기
- 프로토타잎 제작: 결정된 실행안의 최소 단위 구현
- UT : 이 기획이 실제로 해결할 것 같은지 유저를 만나 확인하기
- UT 결과 반영하여 기획 수정 + 기획안 세부 디벨롭
- 필요시 위의 두 단계 반복
4. 기획의 검토
- 상세 기획 공유
- 개발/구현에 예상되는 작업 필요 사항, 충돌 사항, 소요 일정 검토
- 검토 사항 바탕으로 프로젝트 플랜 설계 (WBS, 칸반 등...)
- 유관자 공유 : "이번에 하기로 한 것들은, 실제로/구체적으로 이런 타임라인, 비용, 인력 등으로 진행할 예정이다"
5. 디자인 및 개발
- 작업 전반 과정 이슈 체크
- 제작에 필요한 기타 작업 서포트 (문서, 조율, 기타 행정 작업 등등)
6. 배포(납품) 준비
- QA
- (필요시) 홍보/마케팅 또는 기존 제품 출시에 대한 기존 고객 안내
- 제품 출시에 따라 변경되는 서비스 운영 사항 파악, 공유, 조율
7. 배포(납품) 및 이슈 대응
- 각종 지표 및 VOC 팔로업
- 이슈 사항 파악 후 상황 공유 to 고객, 유관자
- 이슈 대응 플랜 설계 + 우선순위 조율
위의 과정이 제대로 진행되지 않았을 경우 발생하는 이슈/리스크
이직 후 프로덕트 매니저로써 팀에 합류한 당시, 이미 팀에 먼저 합류한 프로덕트 디자이너님의 주도로 주요 기능의 리뉴얼 프로젝트가 진행되고 있었다. 기존 서비스를 확인하고, 대표님이 생각하는 앞으로의 방향성과 과제 등을 파악하느라 프로젝트에 대해서는 크게 생각하지 못했다. 그럼에도 프로젝트는 한동안 순조로웠다.
그러나 프로젝트의 후반부, 내/외부에서 이슈들이 생겨났는데 위의 단계 중 상당 부분이 진행되지 않은 탓이었다.
1. 고객 인터뷰를 하지 않은 경우 : 문제 정의가 불분명하다
어떤 고객의 문제를 풀 것인지, 그 고객의 어떤 문제를 풀 것인지 등은 모두 어디까지나 기획자의 가설에서 시작하다. 말이 좋아 가설이지, 검증이 없이는 그저 상상, 속된 표현으로 '뇌피셜'에 가깝다. 그래서 실제로 고객이 겪는 문제는 무엇이며 그 맥락과 배경은 어떤지 등을 알기 위해선 고객 이해가 필수다.
만약 문제 정의 단계에서 고객 인터뷰를 하지 않은 경우, 풀지 않아도 될 문제를 풀려고 하거나, 풀어야 할 문제를 제대로 풀지 못하게 되고, 이는 결국 할 필요가 없는 프로젝트를 하는 셈이 된다. 또한 이 경우 다음의 문제로 이어진다.
2. 문제 정의가 분명하지 않은 경우 : 프로젝트의 과업범위가 불분명해진다
풀어야 할 문제가 무엇이라고 감은 잡았더라도, 이를 구체적으로 정의하지 않는다면 결국 목적과 해결방안이 모두 두리뭉실해진다. 가령 고객 인터뷰를 통해 "사용이 불편해요"라는 문제점을 발견했다고 해서, 여기에서 그치면 안 된다. 구체적으로 어떤 환경과 맥락에서, 어떤 부분이 불편한지에 대한 추가적인 이해가 필요하다.
이 과정이 생략되어 문제 정의가 분명하지 않은 경우, 결국 "UX/UI 사용성을 높인다" 정도의 두리뭉실한 목표와 과업범위를 가진 프로젝트가 된다. 그리고 이는 다음의 문제로 이어진다.
3. 프로젝트의 과업범위가 명확하지 않은 경우 : 내부 고객과 이해관계자들의 불만이 쌓인다
풀어야 할 문제에 대한 명확한 정의가 없다면, 팀 내/외부 이해관계자들의 이해도가 서로 달라진다. "UX/UI 사용성을 높인다"라는 이름으로 기대하는 것이 서로 다르기 때문이다.
가령 운영 인력은 자신들이 주로 상대하는 고관여 고객, 혹은 진상 고객의 문제를 해결하길 기대하거나 혹은 은연중에 운영팀의 편의성을 높이는 기능을 기대할 수도 있다. 결제 관련 담당자는 UX/UI의 사용성이 높아지면 결제 방법 문의가 줄어들길 기대할 수도 있다. 그로스 매니저는 사용성이 높아지면 해당 페이지 내에서의 전반 전환율이 모두 높아지길 기대할 수도 있다.
그리고는 프로젝트의 막바지 검수 단계 또는 런칭 후 "어, 왜 제가 기대한 그 기능은 없죠?" "당연히 이런 것도 있어야 하는 거 아닌가요?" "제가 보기엔 여전히 불편한데요?" 같은 피드백이 쌓이게 된다. 과업범위가 명확하지 않고 이를 공유하지 않는다면, 내부 고객과 이해관계자의 이해가 서로 다르고, 무엇을 하든 불만과 불평만 쌓이게 된다.
4. UT를 하지 않은 경우 : 고객의 기대와 다르다는 걸 뒤늦게서야 알아차린다
인터뷰도 했고 문제 정의도 하여 팀 내 공유를 하더라도, 프로토타입 등을 통해 개발 착수 전 검증을 하지 않았다면, 결국 이 프로젝트가 고객의 문제를 해결하는지 혹은 그렇지 못한지는 제품 출시 후에서야 알 수 있다. 이미 N개월의 시간과 비용을 사용한 뒤에서야 "어라? 우리는 당연히 이러면 해결할 줄 알았는데 아니네?"라고 한다면, 이는 팀과 조직의 리스크자 실패다.
기획한 것이 실제로 고객의 문제를 해결하는지 알기 위해서 꼭 제품 출시를 기다릴 필요는 없고, 그래서도 안 된다. 제품 출시 후에야 긴급하게 주요 기능, UX/UI를 다시 개선하는 건 이를 사전에 검증하지 않았기 때문에 발생하는 이슈다.
