Chapter5.4 - 서사를 활용해 목차를 만들자 개발과 서사 서사: 사실을 있는 그대로 적는 것 그림이나 사진이 글과 붙어 있는 잡지처럼 글을 써야함 보통 글의 번호와 스크린샷 안의 번호를 같게하여 번호마다 글을 씀 독자의 수준 대신 기술의 범용성을 기준으로 쓰자 의미 있는 사건을 시간에 따른 전개 과정으로 써야 함 개발문서에서 서사는 개발자와 독자 사이에 줄다리기 범용성을 기준으로 기술하기! 순서에서 단계를, 단계에서 목차를 만들자 단계마다 나누어 단계별 목표를 정확히 하기 쉬운 단계 -> 어려운 단계 순 목차를 배치하여 링크를 거는 방법도 좋음 참고문헌: 개발자의 글쓰기
Chapter5.2 - 정확히 이해하도록 그림과 글로 묘사하자 글에 묘사를 더하면 이해가 빠르다 단순한 언어보다는 묘사를 위한 오감 추가하기 글과 그림의 내용을 일치시키자 그림에 있는 단어를 사용하여 글을 쓰기 객관적 묘사와 주관적 묘사 둘 다 하자 주관적 묘사와 객관적 묘사의 방식을 자유자재로 왔다갔다 할 수 있으면 개발이 쉬워짐 Chapter5.3 - 논증으로 유용한 정보를 제공하자 의견을 쓰려면 근거를 대자 논증의 기법 활용하기 개발자가 의견만 말하고 근거를 말하지 않으면 독자가 직접 테스트해볼 수 밖에 없음 거칠게도 공손하게도 쓰지 말자 ~할 수 있지만 ~하기 어렵다, ~ 해야 합니다만 반드시 해야하는 것은 아닙니다 -> ~하십시오, ~하지 마십시오 100% 확신은 불가능하지만 여지가 있다면 독자..
Chapter5.1 - 서비스 개념을 범주, 용도, 특징으로 설명하자 범주, 용도, 특징 버독자가 잘 아는 범주 -> 범주의 용도 -> 범주 내의 유사 서비스와 차별화하는 특징 범주를 정확하고 적절하게 선택하자 개발자는 독자가 이미 가진 범주를 사용함으로써 서비스의 개념을 간단하고 정확히 설명 가능 범주는 정확하고 적절하게 여러 경쟁사가 사용하는 보편적인 서비스 범주 참고 용도를 범주의 핵심 기능으로 기술하자 독자 관점의 용도 개발자 관점에서 핵심 기능 추리기 특징을 장점과 강점에서 뽑아 쓰자 범주와 용도는 보편적인 내용이지만 특징은 차별화하는 내용 장점: 자기 기준에서 잘하는 것 강점: 경쟁 서비스와 비교해서 나온 것 참고문헌: 개발자의 글쓰기
Chapter4.4 - 비즈니스를 이해하는 장애 보고서 쓰기 장애 보고서의 특징 장애 보고서는 개발자가 원할 때 쓸수 없음 장애 발생 후 부터 가능 장애의 1차 원인은 대부분 다른 원인의 결과 원인과 이유를 찾는 분석적 글쓰기 필요 장애 보고를 받는 윗사람은 대부분 개발자가 아님 그들과 소통하기 위한 비즈니스 관점 글쓰기 필요 장애를 해결했다고 해서 100% 해결한 것은 아님 보고할 때는 확정적이고 신뢰할 만한 결단을 정치적으로 내려야 함 질문에 대답하는 신속한 글쓰기 대화를 글로 옮기고 글쓰기에 그대로 적용하기 원인과 이유를 찾는 분석적 글쓰기 5Whys 기법 사물이나 현상, 동작이 문제를 초래하는 원인 + 사람이 문제를 초래한 이유 IT분야에서 장애는 대부분 재발하며 원인은 사람의 문제 개발자 사이의..
