제품 팀과 소프트웨어 팀은 모두 문서라는 공통의 버그베어를 공유합니다.
제품 문서는 제품의 워크플로와 사용자 인터페이스를 설명하는 사용자 대상 매뉴얼 및 가이드를 의미합니다. 일반 사용자가 이 제품을 어떻게 하면 생산성을 높일 수 있을까요? 이러한 의미에서 제품 문서는 소프트웨어 제품에 사용될 수 있습니다.
소프트웨어 문서는 소프트웨어 제품의 기본 기술, 전제 조건 및 구성 가능한 속성을 나타냅니다. IT 관리자는 사용자를 위해 소프트웨어 제품을 어떻게 구성, 모니터링, 호스팅 및 배포할까요? 이러한 유형의 문서는 특히 여러 버전 또는 브랜치가 혼합되어 있을 때 중요합니다.
어떤 의미에서 제품 문서는 누군가에게 자동차 운전 방법을 가르치는 것과 같습니다. 핸들을 돌리고 가속 페달을 밟으면 차가 움직이고 브레이크 페달을 밟으면 차가 멈추죠. 소프트웨어 문서는 자동차가 어떻게 작동하는지 알려줍니다. 휠은 앞 차축에 연결되어 앞 타이어를 돌려 주행 방향을 바꾸고, 가속 페달은 엔진으로 유입되는 공기 흐름을 증가시켜 더 많은 연료를 끌어와 토크와 마력을 생성합니다.
두 가지 문서 유형 모두 중요합니다. 하나는 사용자를 교육하고 다른 하나는 관리자와 개발자를 교육합니다. 사람들에게 자동차 운전 방법을 보여주는 것은 좋지만, 아무도 자동차가 어떻게 작동하는지 모른다면 자동차가 고장 나면 어떻게 될까요?
제품 문서와 소프트웨어 문서의 사소한 차이점
제품 문서와 소프트웨어 문서에는 알아야 할 사소한 차이점이 있습니다:
소프트웨어 및 제품 문서 ###: 대상 고객 및 페르소나
제품 문서는 단 한 명의 대상, 즉 사용자를 대상으로 합니다. 사용자가 기술 지식이 없다고 가정하고 전문 용어를 최소화한 평이한 영어로 소통합니다. 기술 견습 과정이나 대학 학위 과정과 마찬가지로, 이론이나 개념 지식에 중점을 두지 않고 어떻게 일을 하는지에 대해 교육합니다.
소프트웨어 문서는 IT 관리자, 엔지니어 및 개발자를 대상으로 합니다. 소프트웨어의 설계 및 아키텍처, 명령줄 설정 지침, API 및 통합 지원, 데이터 관리 및 보고, 네트워크 토폴로지 등 기본적으로 시스템을 작동하게 하는 톱니바퀴와 같은 내용을 다룹니다. 이러한 문서는 IT 담당자가 소프트웨어 애플리케이션을 모니터링하고 문제를 해결할 때 참조할 수 있는 SSOT(단일 소스 오브 트러스트)를 형성합니다.
소프트웨어 및 제품 문서: 업데이트 주기
소프트웨어 문서는 새로운 커밋이 메인 릴리스 채널에 병합될 때 지속적으로 업데이트되어야 합니다. 소프트웨어 문서는 새로운 기능과 명령을 강조하고 오래된 기능은 사용 중단해야 합니다. 새롭거나 변경되는 종속성을 문서화해야 하며, 모든 대상 플랫폼에 대한 기능 지원을 명확히 해야 합니다(예: 한 기능이 Windows에서는 작동하지만 Linux에서는 작동하지 않는 경우).
제품 문서는 기본 소프트웨어 편집으로 인해 워크플로 또는 사용성이 변경되는 경우에만 업데이트가 필요합니다. 개발자가 결제 게이트웨이의 코드를 변경하더라도 사용자의 결제 프로세스는 동일하게 유지되므로 업데이트가 필요하지 않습니다.
이는 소프트웨어 제품 문서의 자연스러운 계층 구조를 보여줍니다. 기술 소프트웨어 문서가 기초를 형성하고 후속 제품 문서는 이 기초를 기반으로 합니다. 따라서 훌륭한 소프트웨어 문서가 더 훌륭한 제품 문서를 낳기 때문에 훌륭한 소프트웨어 문서를 만드는 데 중점을 두어야 합니다.
제품 및 소프트웨어 문서 서식 프레임워크 예시
제품 문서는 이 프레임워크를 따를 수 있습니다:
-
제품 이름
-
제품 목적 개요
-
설정 가이드
-
기능 1 설명 및 이미지
-
기능 2 설명 및 이미지
-
고객 지원 링크
마찬가지로 소프트웨어 문서도 이 프레임워크를 따를 수 있습니다:
-
소프트웨어 이름
-
소프트웨어 목적 개요
-
소프트웨어 종속성
-
설치 가이드
-
기능 1 설명 및 이미지
-
기능 2 설명 및 이미지
-
기술 지원 링크
분명히 이 두 가지 문서 유형은 서로 밀접한 관련이 있으며 비슷한 구조를 따릅니다. 즉, 제품 팀과 소프트웨어 팀은 서로 배울 점이 많으며 문서 공동 작업을 할 때 많은 잠재력을 가지고 있습니다.
제품 및 소프트웨어 문서 팀은 서로를 보완할 수 있습니다.
제품 문서와 소프트웨어 문서 사이에는 뚜렷한 유사점이 있습니다. 따라서 제품 팀과 소프트웨어 팀이 함께 작업할 수 있을까요?
네, 그럴 수 있고 그래야 합니다!
소프트웨어 팀은 기술 전문 용어와 기반 기술을 이해합니다. 제품 팀은 사용자가 보고, 원하고, 필요로 하는 것, 즉 사용자 경험을 이해합니다. 소프트웨어 문서 작성자는 상세한 기술 정보를 제공할 수 있으며, 제품 문서 작성자는 일반 사용자가 읽을 수 있도록 기술적인 세부 사항을 희석할 수 있습니다.
일반인이 이해할 수 있는 용어를 공식화하는 데 필요한 높은 수준의 이해 없이 일반인의 용어로 무언가를 설명하려고 한다고 상상해 보십시오. 소프트웨어 문서보다 제품 문서가 먼저 작성되면 이런 일이 벌어집니다.
양자역학이란 무엇인가요? 아마 슈뢰딩거의 고양이가 가장 먼저 떠오르실 겁니다! 하지만 양자역학이 고양이와 무슨 관련이 있을까요? 사용자에게는 중요하지 않습니다. 물리학자에게는 모든 것을 의미합니다.
소프트웨어 문서로 시작하여 더 나은 제품 문서로 끝내는 Docsie
결론적으로, 소프트웨어 문서를 후속 제품 문서의 템플릿으로 사용하면 많은 이점이 있습니다. 소프트웨어 문서는 IT 담당자와 제품 문서 작성자가 신뢰할 수 있는 단일 소스 역할을 해야 합니다. 제품 문서 작성자는 작성 후 교정 및 품질 보증을 위한 기술 지침과 함께 사용자 친화적인 지식을 단순화하고 고객과 공유할 수 있는 명확성과 이해도를 갖추게 됩니다.
간단히 말해, 훌륭한 소프트웨어 문서로 시작하면 작성자는 더 훌륭한 제품 문서를 만들 수 있습니다!
고객이 더 많은 일을 할 수 있도록 도와주는 문서 작성을 시작하세요. 시작 요금제 ](https://www.docsie.io/pricing/)(영원히 무료로e!)에 가입하고 Docsie로 문서 작성의 즐거움을 선사하세요!