[4장] 독자 관점에서 릴리스 문서와 장애 보고서 쓰기

01. 체인지 로그를 분류, 요약, 종합하는 법

 

체인지 로그를 적절한 양으로 쓰려면 최대한 많이 써야 한다. 그리고 순차적으로 선정, 분류, 요약하는 기술이 필요하다.

 

 

 

1. 선정하기

 

체인지 로그의 양을 줄이려면 체인지 로그 중 쓸 것과 없앨 것을 구분하는 기준이 필요하다. 이때, 독자의 입장에서 생각하는 것이 중요하다. 

 

더 나아가 회사 입장도 고려해야한다. 체인지 로그는 회사의 공식 발표이며, 독자와 직접 소통하는 문건이다.

 

개발자가 개발자 입장에서만 체인지 로그를 써서는 안된다. 따라서 다음 표와 같이 회사, 개발자, 독자의 관심을 가지고 분류하여 체인지 로그를 선정할 수 있다.

 

 

2. 분류하기

 

체인지 로그를 선정하고, 이후 비슷한 체인지 로그끼리 묶어야한다.

 

1. 개발 관점에서 비슷한 작업으로 묶는 방법(독자가 개발자인 경우에 유용) (기능 추가, 기능 개선 등으로 묶기)
2. 사용자 관점에서 비슷한 것 끼리 묶는 방법(독자가 일반 사용자인 경우 유용)  (게임 준비 단계, 게임 종료 단계)

 

3. 요약하기

 

체인지로그를 문장 단위로 요약하는 차례이다.  서술식 문장-> 개조식으로 바꾸어 준다

 

4. 종합하기

 

엘리베이터 스피치
짧은 시간에 사업 계획의 핵심만 종합해 말하는 방식이다. 

체인지 로그도 마찬가지이다. 릴리즈 내용 전체를 종합해 한 문장으로 만들고, 체인지 로그 첫 줄에 작성할 것

 

 

02. 고객에게 유용한 정보를 쓰자

체인지 로그란 개발자가 변경한 내용을 적은 것이다.

 

 

개발자의 문제 : 화면이 멈춘 것

고객의 문제 : 애니메이션 스티커를 댓글에 사용할 수 없는 것

현재 문제 상황

↓

 

애니메이션 스티커를 정상적으로 댓글에 사용할 수 있습니다. (화면 멈춤 문제 해결)

고객의 문제해결을 앞쪽으로 옮기고, 개발자의 문제는 짧게 줄임

↓

 

애니메이션 스티커를 댓글에 정상 사용 가능(화면 멈춤 문제 해결)

개조식으로 수정

 

 

체인지 로그는 하나의 관점으로만 쓸 필요는 없다. 내용에 따라 관점을 적절히 선택하는 것이 중요하다. 

 

 

03. 릴리스 문서는 문제 해결 보고서처럼 쓰자

• 발생형 문제 : 우리 눈 앞에 발생해 당장 걱정하고 해결하기 위해 고민하는 문제(프로그램 에러)
• 탐색형 문제 : 현재 상황을 개선하거나 효율을 높이는 문제(프로그램 개선, 시스템 효율화)
• 설정형 문제 : 미래상황에 대응하는 문제. 앞으로 어떻게 할 것인가 하는 문제(대폭적인 업그레이드)

 

버그 수정, 기능 개선, 새로운 기능 추가 모두 문제를 해결하는 것이다. 하지만 여기서 문제와 문제점 구별해야한다. 하나의 문제에 문제점은 여러가지이고, 이를 모두 해결할 수는 없기 때문에 특정 문제점을 선택할 수 밖에 없다. 따라서 어떤 문제점을 선택하느냐에 따라 문제 해결 방법은 완전히 달라진다.

 

릴리스 문서는 결국 개발자가 문제점 하나를 선택해서 해결한 결과

 => 독자에게 어떤 문제점을 선택했는지 정확히 알려줘야 한다.

 

릴리스 노트 작성 순서
문제->문제점->해결책->후속 계획

 

릴리스 노트 예시

ㅁㅁ서비스에 사용자가 급증하면 ㅇㅇ 서버가 정지하는 문제는 시스템 재 설정으로 해결했습니다. 추후 프로그램 최적화와 DB설계도 검토하겠습니다. 

 

 

릴리스 노트의 핵심은 문제 해결의 과정과 결과를 "고객"에게 알려주는 것이다. 따라서 계약에 의한 산출물로 취급될 수 있다. 따라서 이를 계약서에 준하는 문서로도 판단 가능하다. 릴리스 노트를 통해 거래 회사 개발자에게 어떤 행동을 유도할 때는 그 행동이 필수인지, 권장인지, 선택인지 명확하게 알려줘야한다. 또한, 독자가 필수, 권장, 선택 외에 문제가 생길 떄는 대비해야한다. 이 예외사항도 명시해야만 면책이 될 수 있다.

 

04. 비즈니스를 이해하는 장애 보고서 쓰기

 

장애 보고서의 특징

1. 장애보고서는 개발자가 원할 때 쓸 수 없다.
2. 장애의 1차 원인은 대부분 다른 원인의 결과다
3. 장애 보고를 받는 윗사람은 대부분 개발자가 아니다
4. 장애를 해결했다고 해서 100% 해결한 것은 아니다

 

따라서 장애보고서를 쓸 떄는 다음과 같은 글쓰기 기법 필요

 

1. 질문에 대답하는 신속한 글쓰기
2. 원인과 이유를 찾는 분석적 글쓰기
3. 상사를 고려하는 비즈니스 관점의 글쓰기
4. 원하는 것을 얻는 정치적 글쓰기