1. 프로덕트 스펙 문서 작성법 ★★★★★
과제분석을 시작하면서, 문제를 해결할 수 있는 가장 컴팩트한 방법이 뭔지 고민했었다.
그래서 영업실을 통해 받은 요구사항을 쪼갤 수 있는 방법을 생각했다.
혹은 이 요구사항 외에도 문제를 해결할 수 있는 솔루션이 있는지 고민해봤다.
그리고 이 쪼갠 요소들 중에 문제를 해결하는 데에 결정적인 역할을 하는게 뭔지 고민했었다.
생각해보면,
위에서 언급된 '비싼 작업'이 시작되기 전에 먼저 구체적인 부분에 대해서 생각하게 한다 는 장점(?)을 달성해가는 과정이였던거 같다.
나는 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 )
~ 포스팅 끝 ~
오늘도... 나의 포스팅은 번역체이다. ㅎㅎ
'소프트웨어-이야기 > 소프트스킬' 카테고리의 다른 글
스포티파이 모델을 따라하지 말고, 스포티파이의 사고방식을 따라해라! (0) | 2018.04.04 |
---|---|
TDD와 테스트코드의 장점 (0) | 2018.03.11 |
프로젝트를 시작하는 방법 (ver.2017) (2) | 2018.02.14 |
Lean Coffee? Ring Coffee? - 이야기 주제 없이 모여도, 잘 이야기 하는 방법! (0) | 2017.07.13 |
[비주얼씽킹]비주얼 씽킹 기본 요소 (0) | 2016.01.21 |