개발자의 글쓰기 5~7장

🖋 5장 : 설명, 묘사, 논증, 서사로 개발 가이드 쓰기

📎 서비스 개념을 범주, 용도, 특징으로 설명하자

• 개발자가 독자에게 서비스 개념을 설명할 때는 범주, 용도, 특징 수능로 쓰는 것이 좋다. 독자가 잘 아는 범주를 먼저 말한다.
• 범주의 용도를 말하면 독자는 자연스럽게 서비스의 용도롸 같음을 알아차린다.
• 마지막으로 그 범주 내의 유사 서비스와 차별화하는 특징을 말하면 독자는 서비스의 개념을 정확히 이해한다.
• 개발자는 독자가 이미 가진 범주를 사용함으로써 서비스의 개념을 간단하고 정확히 설명할 수 있다.
• 범주는 서비스를 소개하거나 설명하는 첫 문장인 만큼 정확하고 적절하게 정해야 한다.
  • 가장 좋은 방법은 여러 경쟁사가 사용하는 보편적인 서비스 범주를 따라 하는 것.
• 범주와 용도에는 보편적인 내용으 적는다.
• 특징은 차별화하는 내용을 적어야 함.
  • 개발자에게 차별화는 서비스의 장점과 강점
  • 장점은 자기 기준에서 잘하는 것, 강점은 경쟁 서비스와 비교해서 나은 것.
  • 서비스 개념에서 특징은 장점이자 강점인 것을 쓰는 것이 가장 좋음.

📎 정확히 이해하도록 그림과 글로 묘사하자

• 객관적 묘사로 요구사항을 정리하고 질의설르 만들어야 함.
• 개발자가 주관적 묘사를 객관적 묘사로 바꾸고, 그것을 다시 주관적 묘사로 바꿀 수 있으면 일하기 편함.

📎 논증으로 유용한 정보를 제공하자

• 논증은 객관적이고 논리적인 방식으로 어떤 사실을 증명해서 상대를 설득하는 일
• 주장을 했으면 이유를 바로 마래야함. 중복되더라도 이유를 함께 말하거나 이유를 찾을 수 있는 곳을 알려줘야 함.
• 해결 방법이 여러가지여서 그중 최선을 택하는 것이 개발 과정
• 개발문서가 사실상 문제 해결 문서이므로 문제 바로 다음에 답이 먼저 나와야 한다.

📎 서사를 활용해 목차를 만들자

• 서사는 사실을 있는 그대로 순서대로 적는 것을 말함
• 번호별로 글이 많지 않은 경우에는 한 문장으로 요약하고 단어 앞에 번호를 붙이는 것이 좋음.
• 의미 있는 사건을 시간에 따른 전개 과정으로 써야 함.
• 개발자는 어떤 행동에 의미를 두고 글로 쓸지 직접 결정해야 함
• 단계는 반드시 목표가 있어야 함
  • 첫 단계에서 쉬운 목표를 달성하면서 조금씩 어려운 단계의 목표를 달성하게 만들어야 함.

🖋 6장 : 수주를 돕는 SI 제안서 쓰기

📎 개발자가 알아야 할 제안서 작성 원칙

1. 제안요청서를 제대로 분석
   • 제안요청서는 고객이 제안을 요청하는 문서
   • 실제로는 답안지
2. 항목을 논리적으로 완결
   • 제안서를 읽는 일이 숨은그림찾기가 되면 안됨
   • 항목 안에는 항목에 관한 고객의 요구, 고려사항, 구성 전략, 구성 목표, 구성 방안, 구성의 특장점, 기대 효과가 들어가야 함

📎 고객의 문제 인식과 제안사의 문제 해결 능력

• 고객이 문제를 얼마나 중대하게, 또는 사소하게 인식하는지에 따라 제안서의 내용이 완전히 달라짐.

1. 경쟁사와 비교하여 제안하라

• 고객이 문제를 중대하게 생가갛고 제안사가 그 문제를 해결할 능력이 착월하다면 경쟁사와 세부 기능이나 스펙을 비교해 제안해야 함.
  • 제안사의 강점을 최대한 부각하는 방법이 경쟁사와 비교하는 것이기 때문

2. 일단 동감하고 다른 방안을 제시하라

• 고객이 문제를 중대하게 생각하지만 제안사가 그 문제를 해결할 능력이 미흡하다면 고객의 인식에 일단 동감한 뒤 다른 방안을 제시해야 함

3. 고객이 문제를 중대하게 인식하게 만들어라

• 고객이 사소하게 생각하는 문제를 젱안사가 착월하게 해결할 수 있을 때, 어떻게든 고객이 그 문제를 중대하게 인식하도록 만들어야 함.

4. 경쟁사의 전략을 확인해서 대처하라

📎 고객의 요구사항은 변할 수밖에 없다.

• 개발은 고객의 요구사항을 실현하는 것.
• 고객은 자기가 원하는 것을 모른다. 고객에게 요구사항을 제시해서 고객이 선택하게 만들어야 하고 그 선택에 따라 개발해야 함
• 가장 좋은 방법은 요구사항 정의와 구현, 고객의 검수 사이의 시간 차이를 줄이는 것.
  • 기능의 개발이 끝나면 즉시 고객에게 테스트를 요청하고 검수를 받는다.

📎 고객의 총 만족도를 높이자

• 요구사항은 개발자 관점과 고객 관점이 다름.
• 개발자의 자원을 고객의 총 만족도를 높이는 쪽으로 설계해야 한다는 뜻.
• 개발자는 기본적으로 기본 기능 요구는 모두 수용해야 함. 기능의 성능 요구는 한계를 정해야 함.

🖋 7장 : 기술 블록 쉽게 쓰고 운영하기

📎 기술 블로그를 쉽게 쓰는 방법 3가지

1. 주제 의식을 버리고 소재 의식 으로 쓰자

• 특정한 대상이나 상황에 대한 자기만의 관점이나 생각이나 해결 방안을 뜻함.
• 소재 의식은 독자와 상관없이 대상이나 상황에 맞닥뜨렸을 때부터 그 대상이나 상황에서 벗어날 때까지 겪은 일을 담담하게 정리해서 얘기할 뿐.

2. 독자 수준이 아니라 자기 수준 으로 쓰자

• 기술 블로그를 쓸 때는 독자 수준이 아니라 작성자 수준으로 쓰는 편이 낫다.
• 어려운 용어는 용어를 정의한 페이지나 세부 내용을 볼 수 있는 사이트나 문건을 링크로 걸어두는 편이 낫다.
• 핵심 내용만 쓰고 나머지는 독자가 공부할 수 있게 길만 터놓는 것이 현명한 방법.

3. 재미있게 글을 쓰자

📎 글의 종류별로 목차 잡는법 1 - 저술

저: 개발기는 목차를 잘 잡아서 본문부터 쓰자

• 저는 직접 경험한 것을 쓴 것.
• 목자만 제대로 잡으면 다른 종류의 글보다 쓰기 쉽다.
• 최종적으로 성공한 루트와 중간에 실패한 루트를 구별
• 본문 -> 맺음말 -> 머리말 순으로 작성하자

술: 원전을 비교하고 실험해 풀이해서 쓰자

• 술은 어떤 것을 분석해 의미를 풀이하고 해석한 것.
• 원전의 두 용어나 대상을 비교하면서 풀이하는 것이 바로 술의 역할
• 기술 블로그를 쓰는 개발자는 경전을 자기 방식으로 풀이하는 사람.
  • 특정 상황에서 이렇게 하는 것이 낫다는 정도로만 쓴다.

📎 글의 종류별로 목차 잡는 법 2 - 편집

편: 순서를 요약하여 쓰자

• 편은 산만하고 복잡한 자료를 편집해 질서를 부여한 것.
• 시간 순서로 일어난 일이나 해야 할 일을 쓴 것을 통칭
• 적정한 단계로 나눠서 설명함으로 질서 있게 보여주는 방식.
• 한 일을 먼저 시간 순서로 적은 뒤 단계를 만들어 하위 내용을 간략히 요약.

집: 글쓰기가 두렵다면 자료를 모아 핵심을 엮어서 쓰자.

• 집은 여러 사람의 견해나 흩어진 자료를 한데 모아 정리하는 것.
  • 내용을 많이 쓰는 것이 아니라 핵심만 간결하게 정리한 것이다.