[제로베이스 PM 파트타임스쿨] 1일차 - pre-production

나는 회사에서 개발자로 일을 하고 있다. In-house SW를 개발하는 것으로 대규모 프로젝트를 하진 않지만 보통 상사가 아이템을 가지고 오면 스펙에 맡게 개발하곤했다. 그런데 외주개발자도 있다보니 개발보다는 기획쪽을 더 많이 한다는 느낌을 받아서 좀 더 체계적으로 배우고 싶어서 제로베이스 PM 파트타임스쿨을 등록하게 되었다. 

마침 2월에는 환급과정이있어서 100일간 매일 학습노트를 씀으로써 동기부여도 되고 환급도 받고자 한다.

(지금 임신 28주차인데 잘 할 수 있을지 조금 걱정이다 ㅎㅎ)

---

오늘의 강의는 pre-production에 대한 내용이다.

서비스를 기획하기 위해서는 크게 3단계로 진행된다고 했다.

 

각 단계를 비유하면 설계 -> 건축 -> 인테리어, 집값 올리기로 비유할 수 있다.

 

pre-production에서는 어떤 것을 해야할까?

어떤 필요사항들을 어떤 방식으로 녹여낼것인지. 왜 이 서비스를 만들어야하는지,  왜 필요한지 어떤 것들이 필요하고 어떻게 만들어져야하는지 최종산출물이 뭔지에 대한 내용을 문서에 담는 과정이다. 즉, production 커뮤니테이션을위한 자료 만들기(개발팀, 디자인 팀 등과 협업을 위함)다.

 

요즘 기존에 운영하던 웹서비스에서 새로운 기능이 추가되어서 그에 대한 리뷰를 진행했다. 나같은 경우에는 이미 진행하기로 된 아이템이어서 결정권자들을 설득한다던지 할 필요는 없었다. 그래서 왜 만들어야하는지, 왜 필요한지에 대한 내용을 작성하지는 않았다. 이미 상사가 그걸 했고 결정된 사항이었다.

 

그래서 나는 이미 운영중인 웹서비스에 기능을 추가하는 방향이라 사업성 검토라던지 리서치 등은 하지 않았다.    

 

 

---

pre-production의 첫번째 단계는 리서치이다.

최근에 맡게된 과제는 이미 결정된 사항이었지만 이전에 드롭된 과제중에는 완전 신규 웹서비스를 만드는 과제가 있었다.

그때 클라이언트의 요구사항을 들었고, 관련 서비스들이 없는지 조사를 했었다. 벤치마킹을 한것이다. 벤치마킹을 하면서 화면에 대한 구상도 진행했었다.    

최근의 과제는 새로운 서비스를 만드는 것은 아니었지만 기존에 JIRA에서 table 형태로 입력받는 부분을 입력폼으로 받으므로써 각 컬럼을 DB화 할수 있고 validation을 체크할 수 있도록 하는 과제였다. 그래서 VOC와 기존에 사용된 JIRA 이슈들의 공통점, 특이점등을 분석했다.  

* FGI 인터뷰란 focus group interview 우리 서비스 타겟층을 대상으로 하는 인터뷰로 좀더 심도있는 결과를 얻을 수 있다.

---

 

 

 

타당성 검토

의사결정권자들 또는 상위 매니저들과 검토단계에서 필요한 문서를 작성하는 단계이다.

왜 해야되나. 이 시장에서 우리는 이길수 있나. 어떤 베네핏을 제공할수 있나. 어떻게 사용자들에게 서비스를 제공할 것인가에 대한 내용이다. 

비록 최근 과제에서 나는 타당성검토를 하진않았지만 상사가 진행했으리라... 기존에 운영하던 웹서비스는 라이센스 발급요청을 받으면 그에 따라 벤더사 홈페이지에서 발급을 라이센스 관리자가 발급요청을 하고 메일로 라이센스 키파일을 받으면 그 키파일을 가지고 설치 후  요청자에게 설치여부를 안내해주는 서비스였다.

추가되는 신규 기능은 라이센스관련은 아니었으나 유사한 케이스로 HW 장비 렌트를 요청하는 서비스였다. 기존에는 JIRA로 입력받다보니 각 장비별, 부서별 현황이라던지 파악이 쉽지않고 텍스트로만 입력받아 커뮤니케이션비용이 증가하게되었다. 

이런 내용으로 상위 결정권자에게 기능 추가를 하겠다고 요청하지않았을까 싶다.   

 

나는 사업성 검토와 타당성 검토 부분이 조금 모호하다고 생각했다.  이 시장에서 우리는 이길수 있나. 어떤 베네핏을 제공할수 있나. 어떻게 사용자들에게 서비스를 제공할 것인가를 이미 타당성검토에서 하면서 클라이언트 요구사항과 VOC를 검토했을 것이라고 생각했기 때문이다. 

그러나 다른 부분은 이해가 됬다. 

카니발리제이션의 경우 새로운 서비스에 의해 기존 제품에 손해를 끼치는거나 사장되게 만든다던지 이런 부분의 검토이다.

 

실제로 나도 개발하면서 내가 개발하던 부분이 타부서에서 이미 개발중이거나 배포된 서비스임을 알게된 적도 있고, 완벽하게 요구사항에 맡지는 않으나 이미 요런 기능이 있어서 사용자가 약간의 불편함만 감수하면 쓸수 있는 경우도 있고 사용자가 몇명되지않ㅇk서 이걸 만드는시간 대비 유용한지에대한 부분도있었다.

     

내부 자산 활용 방안 검토의 경우 내부에서 이미 있는 api의 활용 등과 같이 중복작업을 최소화하기 위한 검토작업이다.

보통 알림을 메일로 보내는 형식을 이용했었는데, 메신저로 즉각적인 알림이 오면 모바일로도 확인이 가능하니 좋겠다는 요구사항이 있었던 적이 있다. 메신저는 우리팀에서 만든게 아니었는데 찾아보니 봇빌더라는 서비스를 이용해 adaptive card형태로 메신저를 보내거나 text 형태로 보낼 수 있는 api가 존재했다. 그래서 이걸 썼던 적이있다.

 

서비스 패키징 가능 여부는 기존에 있는 제품과 같이 포함해서 서비스를 할 수 있는지에 대한 부분인데, 최근 과제가 기존 서비스와 카테고리?는 달랐으나 결이 비슷해서 하나로 묶어서 제공하기로 했다.(기존 서비스 사용자들이 신규서비스를 대부분 이용하기도 해서 하나로 묶어서 통일된 UI로 제공하고 하나의 도메인에서 제공함으로써 유저가 여기저기 찾을 필요가 없도록)    

 

 

IA는 아직 잘모르겠다. 타겟팅을 잡아가는 과정인가?

 

 

개발팀과 논의 구현가능한지 초안....

구현방향. 어떤식으로 어떤 플랫폼에서 어떤 언어를 사용해서 구현할까.. 나는 개발자여서 그런지 기술적으로 가능한지 많이 찾아보고 외주 개발자에게 구상안등을 전달함으로써 구현이 가능한지 이슈는 없는지 확인했었다. 그래서 다음 단계인 화면 설계를 PPT로 작성후 설명을 넣어서 개발자와 함께 봤었다. 

 

 

플로우차트는 작성하지 않았는데 그래서인지 회의를 하다가 매끄럽지 못한 기능들이 몇 있었다. 정책정의서는 아직 잘모르겠다. 플로우 차트와 뭐가 다를지. In house SW여서 그런지 법률적인 부분이라던지 이런거는 신경쓰지 않고있다.