[12월 독서] 현업 기획자 도그냥이 알려주는 서비스 기획 스쿨

[인상깊은 부분]

린 UX 에서는 필요한 부분을 빠르게 바꾸고 측정하여 올바른 방향으로 계속 나아가야 한다고 강조한다. 이는 연구 가설이 옳았는지 보려면 전략적으로 바꾸려고 하는 부분 외에 나머지 부분은 모든 조건이 동일해야 한다는 뜻이다. 관계없는 개선사항이 끼어드는 순간, 오픈 후 서비스가 정말 전략대로 수정되었는지 확인할 수 없다.
그러므로 목표한 바를 위해 딱 필요한 만큼 수정할 기능을 콤팩트하게 정의하는 연습이 필요하다.

어떤 양식으로 요구사항 정의서를 쓰느냐는 사실 중요한 것이 아니다. 이 요청사항을 하루라도 빠르게 전달해서 협업자들이 앞으로 해나가야 할 일의 중요성이나 방향성, 스펙에 대한 감을 잡고 파악할 수 있도록 하는 것이 중요하다. 그들도 받자마자 컴퓨터 앞에 가서 바로 코딩할 수 있는 것이 아니기 대문이다. 비즈니스 전략 기획의 산물이 서비스 기획이라면 개발자의 역할은 이 서비스 기획을 실제로 구현되게 만드는 것이다. 우리가 고민한 시간만큼 또 다른 고민이 시작된다. 그래서 개발하기에 잘 정리된 내용이 아니면 난감해할 때가 많다.

 

 

[시사점]

나는 요구사항 정의서를 쓸 때 얼마나 많은 것들을 놓쳐왔는가

1. 시스템 구분 : Front / Adminstrator / 기타(API, BATCH 등)

2. 기능 신규 여부 : 신규 / 기존 수정

3. 요구사항 번호 : 모듈명 + 숫자 (예. Order001)

4. 요구사항명

5. 요구사항 상세 설명과 분석

6. 비고 : 다른 요청사항과 선후 관계나 연결 여부 등

7. 개발 수용 여부 : Y / N / 보류

8. 완료 여부 : Y / N

 

> 개발 수용 여부, 완료 여부를 요구사항 정의서 안에 넣으면 작업 추이를 확인하는데 훨씬 효율적이겠다고 생각.

> 기존 요구사항 번호는 임의로 막 지정했는데, 보통 모듈명 + 숫자 조합으로 쓴다니 ^^ 약간 뻘쭘

 

 

작가님의 번지르르한 '똥' 공격에 어질한 브리. 그간 같이 일해준 개발자분들 감사합니다..