장애보고서 3가지 글쓰기

장애보고서 

개발자만 쓸 수 있다. 보통의 개발 문서랑 다른데.. 

1. 무엇보다 신속한 글쓰기가 중요하다.

장애 보고서는 개발자가 원할 때 쓰는 것이 아니다. 문제(장애)가 발생하고 인지하는 순간부터 장애를 해결한 직후, 또는 그 다음날 오전까지 쓰는 것을 추천한다. 

2. 원인과 이유를 찾는 분석적 글쓰기가 필요하다 

장애의 재발을 막으려면 원인을 해결하는 것이 아니라 원인이 발생한 이유와 예방을 막기 위한 방법 등을 ㅅ알아내야 한다. 즉 분석적 글쓰기가 필요하다. 

3. 비즈니스 관점의 글쓰기가 필요하다. 

임원들은 장애 보고서를 보고 결과론적으로 손익에 대해 묻는다. 따라서 그들과 소통하기 위해 비즈니스 관점의 글쓰기가 필요하다. 

 

 

각각 요구에 따라 쓰는 법 

1. 신속한 글쓰기 

사용자가 결제를 할 수 없다. 

처럼 주어 목적어 서술어를 단순하게 쓰자. 육하원칙을 생각하면 더 쉽다. 

1. 내용 : 무슨 일 

2. 영향 : 어떻게 (과정) 됐어 

3. 원인 : 왜 그렇게 

4. 조치 :  그래서 넌 어떻게 해결하려 했어

5. 결과 : 지금 결과는? 

6. 향후 : 이제 더 무슨 행동을 하려고 

 

예시) 

1. 사용자가 결제를 못했다. 

2. 결제 시도 10%가 실패했다. 

3. 모듈 변경에 대한 보고를 하지 않았다. 

4. 모듈을 확인하고 코드 수정 

5. 지금은 잘 된다. 

6. 보고서 작성하고 상사한테 올린다. 

 

 

2. 분석적 글쓰기 

근본적인 원인을 찾기 위해 5번 why를 물어보도록 하자 

 

3. 비즈니스적 글쓰기 

비즈니스적 관점으로 쓴다는 건 매출과 비용 관점으로 설명한다는 것 

(개발자 관점) 사용자가 1시간 동안 결제 화면에서 멈춰 있음 

(비즈니스적 관점) 접속 불가로 인해 0000만원의 매출 손실이 발생함 

 

+ 상사한테 말할 때 퍼센티지로 말한다 

재발 가능성 20%라고 말하기 (20%면 재발할지도 모른다 정도임)

장애가 발생할 확률이 10%도 안되는데 90%인 양 호들갑을 떨지 말라는 것 

 

 

from (개발자의 글쓰기)