Chapter5.2 - 정확히 이해하도록 그림과 글로 묘사하자 글에 묘사를 더하면 이해가 빠르다 단순한 언어보다는 묘사를 위한 오감 추가하기 글과 그림의 내용을 일치시키자 그림에 있는 단어를 사용하여 글을 쓰기 객관적 묘사와 주관적 묘사 둘 다 하자 주관적 묘사와 객관적 묘사의 방식을 자유자재로 왔다갔다 할 수 있으면 개발이 쉬워짐 Chapter5.3 - 논증으로 유용한 정보를 제공하자 의견을 쓰려면 근거를 대자 논증의 기법 활용하기 개발자가 의견만 말하고 근거를 말하지 않으면 독자가 직접 테스트해볼 수 밖에 없음 거칠게도 공손하게도 쓰지 말자 ~할 수 있지만 ~하기 어렵다, ~ 해야 합니다만 반드시 해야하는 것은 아닙니다 -> ~하십시오, ~하지 마십시오 100% 확신은 불가능하지만 여지가 있다면 독자..
Chapter5.1 - 서비스 개념을 범주, 용도, 특징으로 설명하자 범주, 용도, 특징 버독자가 잘 아는 범주 -> 범주의 용도 -> 범주 내의 유사 서비스와 차별화하는 특징 범주를 정확하고 적절하게 선택하자 개발자는 독자가 이미 가진 범주를 사용함으로써 서비스의 개념을 간단하고 정확히 설명 가능 범주는 정확하고 적절하게 여러 경쟁사가 사용하는 보편적인 서비스 범주 참고 용도를 범주의 핵심 기능으로 기술하자 독자 관점의 용도 개발자 관점에서 핵심 기능 추리기 특징을 장점과 강점에서 뽑아 쓰자 범주와 용도는 보편적인 내용이지만 특징은 차별화하는 내용 장점: 자기 기준에서 잘하는 것 강점: 경쟁 서비스와 비교해서 나온 것 참고문헌: 개발자의 글쓰기
Chapter4.4 - 비즈니스를 이해하는 장애 보고서 쓰기 장애 보고서의 특징 장애 보고서는 개발자가 원할 때 쓸수 없음 장애 발생 후 부터 가능 장애의 1차 원인은 대부분 다른 원인의 결과 원인과 이유를 찾는 분석적 글쓰기 필요 장애 보고를 받는 윗사람은 대부분 개발자가 아님 그들과 소통하기 위한 비즈니스 관점 글쓰기 필요 장애를 해결했다고 해서 100% 해결한 것은 아님 보고할 때는 확정적이고 신뢰할 만한 결단을 정치적으로 내려야 함 질문에 대답하는 신속한 글쓰기 대화를 글로 옮기고 글쓰기에 그대로 적용하기 원인과 이유를 찾는 분석적 글쓰기 5Whys 기법 사물이나 현상, 동작이 문제를 초래하는 원인 + 사람이 문제를 초래한 이유 IT분야에서 장애는 대부분 재발하며 원인은 사람의 문제 개발자 사이의..
Chapter4.3 - 릴리스 문서는 문제 해결 보고서처럼 쓰자 문제와 문제점을 구별하자 목표: 바람직한 상태, 기대되는 결과 현상: 현재 모습, 예기치 못한 결과 현상을 목표에 일치시키기 문제의 3가지 종류 발생형 문제: 당장 해결해야할 문제 / 원상 복구 필요 / 프로그램 에러가 대부분 탐색형 문제: 현 상황 개선, 효율 상승 / 놔두면 해결할 수 없는 문제로 커짐 / 프로그램개선이나 시스템 효율화가 대부분 설정형 문제: 미래 상황에 대응 / 새로운 기능, 대폭적인 업그레이드가 대부분 문제와 문제점을 구분하기(도식화) 문제, 문제점, 해결책, 후속 계획 순으로 적자 문제: 사용자가 급증하면 서버가 정지 문제점: 잘못된 시스템 설정, 프로그램 비 최적화, 잘못된 DB설계 해결책: 시스템 설정 변경 후속..
