기술 문서 작성 방법

1. 준비 준비 단계

준비 단계의 작업에는 주로 다음 사항이 포함됩니다.# 🎜🎜 #

·문서 요구 사항 지우기

·문서 대상 지우기

#🎜🎜 #·

문서 범위 정의문서를 작성하기 전에 문서 요구 사항을 명확히 해야 합니다. 이 문서를 작성하려는 이유와 이 문서를 작성하여 달성하려는 목적이 무엇인지 이해해야 합니다.

문서의 대상도 명확하게 정의되어야 합니다. 관객의 성향에 따라 내용이 달라질 수 있습니다. 예를 들어 개발자와 비개발자/일반 사용자를 위한 문서의 콘텐츠 구성은 서로 다릅니다.

또한 문서의 범위를 정의합니다. 이 문서에서 다루어야 할 내용이나 모듈과 다루지 않을 내용을 생각하고 결정하십시오. 이렇게 하면 나중에 정보를 수집할 때 어느 정도 집중할 수 있고, 글을 쓸 때 모호하지 않게 됩니다.

관련 추천: "

php 입문 튜토리얼

"

2. 연구 연구 단계

# 🎜🎜# 기술 문서 작성 경험이 있는 친구들도 확실히 같은 느낌을 받을 것입니다. 이해가 되지 않는 부분이 있으면 문서를 작성하는 것이 너무 고통스럽습니다.

그러면 전혀 모르는 낯선 주제에 직면했을 때 어떻게 이 고통을 피할 수 있을까요? 물론, 나는 그것을 이해하려고 최선을 다합니다.

그런데 구체적으로 어떻게 해야 할까요? 쉽게 말하면 정보를 수집한다는 뜻이다. 그렇다면 정보를 수집하는 방법은 무엇입니까? 저자는 다음과 같은 점에서 출발할 수 있다고 믿습니다.

(1) 보다 대표적인 유사 제품이나 유사한 제품의 관련 문서를 조사하여 다른 사람의 문서가 어떻게 작성되는지 확인합니다.

아무것도 모를 때는 다른 사람의 경험과 실천을 통해 배우는 것이 좋은 선택입니다. 여러 제품의 문서를 비교함으로써 작성하려는 문서에 대한 대략적인 프레임워크를 설정할 수 있습니다.

참조는 사본이 아니라 아이디어를 제공하는 데만 사용되며 제품마다 문서의 구조 계획이 다릅니다.

(2) 작성 중인 문서와 관련된 모든 정보를 가장 효과적인 방법으로 수집하세요.

수집된 정보는 기술 작성자가 발췌하고 정리한 후 게시된 문서의 일부가 될 가능성이 높습니다.

인터넷 검색, 설문지, 인터뷰, 실험은 물론 이메일 토론, 보고서, 기술 기사 등 정보를 수집하는 방법은 다양합니다. 어떤 방법을 사용할지는 상세한 분석이 필요하며, 문서 요구사항, 기한, 기존 데이터의 풍부함 등의 요소를 바탕으로 필요한 데이터를 빠르고 정확하게 수집할 수 있는 방법을 선택해야 합니다.

일부 글쓰기 주제의 경우 인터넷 검색으로는 거의 모든 도움을 제공하지 못할 수도 있습니다. 이런 종류의 콘텐츠라도 개발자에게 필요에 따라 정보 제공을 요청하거나 내부 시스템의 개발 노트 및 토론을 통해 필요한 정보를 얻을 수 있습니다.

소프트웨어 제품 문서의 경우 기술적인 정보가 있더라도 테크니컬 라이터가 직접 사용하여 작업 단계를 직관적으로 이해하고 문서에 대한 정보를 직접 얻을 수 있는 경우가 많습니다. 글쓰기.

3. 정리 문서 구조

정보가 거의 수집되면 이 문서의 구체적인 구조를 정리할 수 있습니다. 현재로서는 이 문서의 구체적인 구조를 정리하는 것이 도움이 될 수 있습니다.

일반적인 제품 사용 가이드의 경우 일반적으로 설치 순서나 사용 순서로 구성되어 있으며, 기타 비 가이드 문서의 경우에도 특정 순서나 논리를 따라야 합니다.

또한 문서에 사진을 첨부해야 하는지, 표를 사용해야 하는지도 고려해야 합니다. 사진을 추가해야 하는 경우 다른 사람의 도움이 필요한지 아니면 직접 완료해야 하는지 명확하게 표시하세요. 좀 더 복잡한 그림을 그리는 것도 시간이 많이 걸리는 작업이고 소요되는 시간도 고려해야 합니다.

상세한 문서 구조가 완성되면 다음 작성 단계로 넘어갈 수 있습니다.

4. 글쓰기 문서 작성

처음 몇 단계만 잘하면 글쓰기가 매우 간단해집니다. 해당 내용만 작성하면 됩니다. 문서 구조에 정확하게 채워져 있습니다. 이 과정에서 문단이나 구체적인 단계를 작성해야 합니다. 이것은 당신의 언어와 글쓰기 능력을 되돌아보는 시간입니다.

일부 Technical Writing 책에서는 문서를 작성할 때 문법, 단어, 구두점에 대해 걱정할 필요가 없으며 이러한 세부 사항은 Revision 단계에서 개선되어야 한다고 말합니다.

Expand your outline into paragraphs, without worrying about grammar, refinements of language usage, or 
punctuation. 
Writing and revising are different activities; refinements come with revision. - Handbook of Technical 
Writing

저는 이에 대해 다른 견해를 가지고 있습니다. 자격을 갖춘 테크니컬 라이터는 문법, 표현, 구두점 등 가장 기본적인 세부 사항을 혼자서 해결해야 하는 문제가 되어서는 안 됩니다. 표준적인 문법, 품위 있는 표현, 정확한 구두점은 추가적인 노력이 필요하지 않고 시간도 거의 들이지 않는 글쓰기 습관이 되었을 것입니다.

첫 번째 초안이 거칠고 수정해야 할 작은 세부 사항이 많으면 검토하는 동안 작업량과 시간 비용이 확실히 증가하여 문서 처리가 지연됩니다.

아마도 이 방법은 분업이 정교하고 개인이 작은 연결 고리만 담당하는 대기업에 채택될 수 있습니다. 그러나 이는 빠르게 발전하고 민첩한 문서 개발이 필요한 스타트업에는 적용되지 않습니다.

5. 수정 검토 및 수정

문서의 첫 번째 초안을 작성한 후에는 일반적으로 추가 수정과 개선이 필요합니다. 여기서 개정은 검토 후 수정을 의미하므로 이 단계를 검토 및 개정이라고도 합니다.

그럼 누가 리뷰를 해야 할까요? 기술 문서에는 일반적으로 다른 파트너의 두 가지 유형의 검토가 필요합니다. 즉,

·기술 검토: 기술적인 관점에서 문서의 설명이 정확하고 효과적인지 확인합니다.

·언어 검토 : 언어 수준에서 문서 내 표현이 간결하고 적절한지 확인

검토자의 피드백을 받은 후 , 테크니컬 라이터는 적시에 판단하고 수정해야 하며 모호한 부분은 리뷰어와 논의해야 합니다. 변경한 후 검토자에게 검토를 요청하세요. 새로운 문제가 발견되면 다시 수정해야 합니다. 이 검토-수정 프로세스는 여러 번 반복될 수 있으며 이는 정상적인 현상입니다.

물론 다른 사람에게 리뷰를 요청하기 전에 Technical Writer가 직접 검토하여 낮은 수준의 실수를 방지하고 다른 사람의 시간을 낭비할 수도 있습니다.

하하, 또 문제가 생겼네요~ 보통 기사를 막 쓴 사람들은 자신이 쓴 글을 읽기를 매우 꺼려합니다. 이때 문법 및 맞춤법 검사 도구를 사용할 수 있습니다. 당신을 돕기 위해 오고 있습니다.

당신이 충분히 조심스럽고 보조 도구가 필요하지 않다고 생각한다면 당신의 능력에 감탄하지만 여전히 도구를 사용하는 것이 좋습니다. 몸 상태가 안 좋을 때도 있고, 피곤해서 졸고 있을 때도 있고, 도대체 무슨 글을 썼는지 모를 때도 있으니까... 자신과 기기를 가혹하게 여기지 마세요.

6. 배송 문서 배송

문서가 확정된 후 일반적으로 운영하기 쉬운 플랫폼에 게시할 수 있습니다. 회사마다 문서 게시 플랫폼이 다르며 기술 작가가 사용하는 작성 도구도 다릅니다.

문서가 공개되었다고 해서 끝이 아닙니다. 내 업무 경험에 따르면, 출판된 문서라도 대기업이나 중소기업의 문서라면 여전히 문제가 있을 수 있습니다. 예: 발견되지 않은 텍스트 오류, 끊어진 링크, 더 이상 최신 제품과 일치하지 않는 설명 및 단계 등. Technical Writer는 적시에 문서를 업데이트하기 위해 제품 개발 상황을 따라잡아야 합니다.

위 내용은 기술 문서 작성 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!