본문 바로가기

소프트웨어-이야기/소프트스킬

[IT기획] 과제 분석을 잘하는 방법 리서치

1. 프로덕트 스펙 문서 작성법 

과제 분석을 하는 일하는 방법이 고대로 써있다.

스펙문서를 작성해야하는 이유 3가지가 씌여져 있는데, 첫번째 이유가 나에게 가장 와닿았다.

과제분석을 시작하면서, 문제를 해결할 수 있는 가장 컴팩트한 방법이 뭔지 고민했었다.

그래서 영업실을 통해 받은 요구사항을 쪼갤 수 있는 방법을 생각했다. 

혹은 이 요구사항 외에도 문제를 해결할 수 있는 솔루션이 있는지 고민해봤다.

그리고 이 쪼갠 요소들 중에 문제를 해결하는 데에 결정적인 역할을 하는게 뭔지 고민했었다.


생각해보면, 

위에서 언급된 '비싼 작업'이 시작되기 전에 먼저 구체적인 부분에 대해서 생각하게 한다 는 장점(?)을 달성해가는 과정이였던거 같다.



포스팅에 참조되어있는 문서 예시는 아주 주옥같다 ㅎㅎ 
실무에 가까운 레포트인거 같아서 좋았다 


2. product requirements using written visual framework


나는 B2B 서비스인 애드네트워크 팀에 있기 때문에, 빨리 읽으려고 ㅎㅎ 

Product Requirements in B2B Software Markets 구절만 읽었다.


내용을 요약하자면,


B2B 소프트웨어 시장은 복잡하기 때문에 

사용자와 시장에 대한 문제 정의 뿐만아니라, 세부 기능들에 대한 문서화를 해주는게 필요하다.

그리고 이 문서는 엔지니어 / 디자이너들이 과제를 진행하면서 공유하고, 사용할 수 있어야한다.


그래서 이 글의 작성자는 보통 hybrid spec ticket을 사용한다고 한다.

드래프트 형태로 hybird spec ticket을 만들어놓고, 엔지니어들과 같이 일하면서 이에 대한 내용을 채워나가는거다.


그리고 이 글의 작성자는 제품의 기능을 정의할 때, 몇가지 핵심 이슈를 명확히하고, 요약하는 데에 중점을 둔다고 한다.


우선, 

이를 위해 아래의 관점에서 문제를 정리해나간다고 한다.

1. what : 문제가 무엇인지 

2. why : 이게 왜 문제인지 


그리고, 스펙문서에 아래의 내용을 포함시킨다고 한다. 

a. AS-IS : 지금은 이 문제를 어떻게 해결하고 있는지

b. GAP :  현재는 왜 이상적인 상태가 아닌건지 ( AS-IS <-> TO-BE 사이의 GAP )


2-A. HYBRID SPEC TICKETS

LEAN하게 PRD (Product requirements document) 문서를 사용하는 방법은,
엔지니어들이 PRD를 작성하는거다.

Spec ticket은 업무의 양을 작게 쪼갠 것을 말한다. ( 서브태스크 같은걸로 생각하면 되려나..? )

Spec Ticket에는 아래의 내용들이 공통적으로 포함되어야한다.

1. User Story 
: 한두줄이면 된다. 이 기능이 무엇인지 / 왜 해야하는지를 자세하게 작성해야한다.

2. Business case & supporting data
: 두세줄이면 된다. 
  비즈니스 사례와 관련 데이터를 써놓는 이유는, 나중에 다른 사람들이 과제를 이해하는 데에 도움을 주기 위함이다.

3. Features
: 3~10개의 주요 항목들에 대한 내용이 들어가야한다.
  와이어프레임이나, 눈에 보이는 목업이 2~3개 첨부되면 좋다. 
  필요하다면 if-then 로직이 들어가면 좋다.

4. Analytics
: 한줄이면 되고, 필요한 경우에만 작성하면 된다. 

  배포가 되고 나서, 이 기능이 잘 작동하고 있는지 분석하고 싶을 때,
  어떤 것을 트래킹하고 싶은지를 작성해야한다.

  예를 들면 어떤 요소를 모니터링하고 싶은지 작성하면, 
  엔지니어들은 이걸 보고 필요한 로그를 추가하거나, 분석할 수 있는 방법을 알려줄 수 있을 것 같다. 
   

5. 테스트
: 1~3개의 주요 항목들이 포함되어야한다.
  테스트를 할 때, 작동되어야하는 행동들을 대략적으로 작성하면 된다. 



3. 린 기획문서 작성법
https://brunch.co.kr/@jjollae/6





~ 포스팅 끝 ~

오늘도... 나의 포스팅은 번역체이다. ㅎㅎ