목표
매뉴얼 작업 프로세스의 구체적인 정의
제품별 릴리즈 시점에 맞는 매뉴얼 발행
각 개발팀 / 기획팀과의 매뉴얼 작성 협의사항 정리
TW 프로젝트 QA 프로젝트에서 분리
이슈타입 정의
이슈타입 | 시작 | 진행 중 | 리뷰 중 | 기획팀 검토 | 완료 | 매뉴얼 적용 완료 / 하위 이슈 완료 / 결과물 작성 완료 | 비고 |
---|---|---|---|---|---|---|---|
Task | OPEN | In Progress | In Review | Done | Closed | 기타 작업 | |
Documentation | OPEN | In Progress | In Review | Resolved | Closed | 매뉴얼 작업 | |
Epic | OPEN | In Progress | Resolved | Closed | 매뉴얼 릴리즈 Epic | ||
Training | OPEN | In Progress | In Review | Resolved | Closed | TW 교육 | |
Sub-Task | OPEN | In Progress | In Review | Resolved | Closed | ||
개발 팀 이슈 | Answer Request | TW In Progress | Plan In Review | Apply Manual | Closed | 각 개발팀 이슈 중 매뉴얼 적용 이슈 |
한/영 매뉴얼 작업 순서
- 국문 매뉴얼 작업
- 국문 매뉴얼을 기준으로 영문 매뉴얼 번역
프로세스
초안작성 프로세스
작성된 Inline Comment, Page Comment 는 "매뉴얼 수정 요청 프로세스" 를 따른다.
제품 개발 중 매뉴얼 추가 이슈는
"Answer Request" 로 TW 로 요청된 이슈가 "TW In Review" 상태로
매뉴얼 위키 스페이스 관리
각 매뉴얼의 위키 스페이스 계속적인 위키 업데이트를 위해서 차기 버전 릴리즈 대상 위키를 유지한다.
발행한 제품의 매뉴얼 수정 요청은 차기 버전 릴리드 대상 위키에 기록한다.
최종적으로 수정된 위키 스페이스는 스페이스 복사로 릴리즈한다.
매뉴얼 수정 요청 프로세스
이미 작성된 매뉴얼 수정 요청은 위키에 기록한다.
해당 내용의 직접 수정일 경우 "Inline Comment" 로 "@"으로 기록하여 TW 로 매뉴얼 수정을 요청하고 전반적인 내용일 경우 최하단 코멘트에 "@"으로 기록하여 매뉴얼 수정을 요청한다.
위키 페이지에 기록된 내용은 매일 내용을 확인 및 수정하고 업데이트 된 내용은 이슈로 생성 후 1주 단위로 처리한다.
코멘트마다 이슈를 생성하지 않고, 제품별로 이슈를 생성하여 효율성을 높인다.
각 제품 릴리즈 일정 공유
제품별 매뉴얼 릴리즈의 일정은 개별 프로젝트의 "Releases" 에 기록된 릴리즈 일정을 기준으로 한다.
릴리즈 일정이 변경될 경우에 대해서 각 프로젝트의 custom event 를 추가하여 릴리즈일정 변경 시 TW 가 알 수 있도록 하고, 이 기능이 지원되지 않을 경우 각 팀장이 TW 에게 릴리즈 일정 변경을 알린다.
매뉴얼 작업 프로세스
매뉴얼 작업이 필요한 내용은 각 개발 이슈를 "Answer Request" 로 TW로 작업을 요청한다.
TW 작업이 필요할 경우 개발이슈는 다음의 워크플로우를 따른다. (Open → In Progress → In Review → Dev Resolved → Answer Request(TW요청) → TW In Progress(TW작업) → Plan In Review(기획팀 검토) → Apply Manual → Closed)
개발 완료 후 매뉴얼 작업이 필요한 내용은 "Answer Request" 로 "Assignee" 를 TW 멤버로 변경하여 매뉴얼작업을 요청한다.
매뉴얼에 적용될 내용은 해당 이슈에 코멘트로 작성하고 "TW In Progress" 로 상태를 변경한다.
TW 에서 내용이 작성완료되면 "Plan In Review" 로 상태를 변경하고 "Assignee" 를 기획팀 멤버로 변경하여 내용(기술적 내용)을 검토를 요청한다.
기획팀의 내용(기술적 내용) 검토가 완료되면 "Apply Manual" 로 상태를 변경하고 "Assignee" 를 TW 멤버로 변경하여 매뉴얼 작업을 요청한다.
TW 에서 위키 페이지와 매뉴얼 소스에 적용이 완료되면 "Closed" 로 상태를 변경하여 이슈를 종결한다.
매뉴얼 이슈 관리
매뉴얼 이슈 관리는 각 제품별, 버전별, 언어, 용도별로 Epic 이슈를 작성하고 하위 작업 이슈는 Sub-Task 로 생성하지 않고 가능한 한 이슈로 작성한다.
각 Epic 이슈는 각 제품의 릴리즈 시점에 맞게 로드맵 뷰 또는 표로 일정을 기록한다.
제품 매뉴얼 릴리즈 로드맵은 별도의 위키페이지를 작성하여 각 개발팀과 공유하고 릴리즈 일정이 변경될 경우 TW 에서 갱신한다.
매뉴얼 로드맵 예시
매뉴얼 Epic 이슈 관리 예시
공유방법
MCCS
일반 국문 매뉴얼
평소
제품 일정 수시 공유
개발팀-개발 중, TW-트래킹 중
1.
제품 개발 중에: 다음과 같은 사항이 있을 때는 지라의 해당 이슈에 "TW_제품명"으로 라벨 달기
- UI(화면)에 드러나는 변경 사항
- 추가된 기능, 삭제된 기능
- 사용법이 바뀐 기능
(TW가 UI 변경 부분을 제외하고, 먼저 적용해 두면 좋을 부분을 작업해 두기 위해서임.)
2.
- 지라의 해당 이슈에 릴리즈 버전 표기를 요망
- 제품 릴리즈 일정 항시 공유: 지라의 Project 항목에 Unreleased에 일정이 나타나도록 입력
- 다음 양식의 릴리즈 관련 정보를 정리한 페이지를 알파 주기 한번씩 넘어갈 때마다(A1, A2) 작성하여 공유
- 양식 예시: Release Note 4.5.1
3.
- 초안을 작성해서 준다면: 위키 페이지 계속 공유, 수정 부분을 다른색으로 표시한 후에 해당 위키 페이지에 답글 달아서 담당 TW에게 공지 메일 날아가도록 하기(실제로 MCCS 측에서 하고 있음)
- 초안을 작성하지 않는다면: 위 사항의 내역을 주기에 맞게 계속 공유
개발팀-알파테스트 시작, TW-매뉴얼 작업 개시
다음 항목을 Description에 표기해서 매뉴얼 작업 의뢰를 이슈로 작성해서 의뢰하기
- 넘겨줄 목록:
- 매뉴얼 초안 주소, 관련 사항에 대한 설명
- 릴리즈 버전, 테스트나 다음 버전 릴리즈 일정 정보
- 테스트 요청서(예시: QA-1267)에 첨부하는 릴리즈 노트: Release Note 4.5.1 형식의 요약본 공유
- 기술적 내용 검수자 지정: 매뉴얼을 작성한 후에 리뷰하면서 기술적 오류에 대해 수정해 줄 담당자. 보통 개발팀장
매뉴얼 작성 중
중간에 변동이 생기는 이슈에 대해서는 해당 이슈에 Comment를 입력하여 담당 TW에게 언급
매뉴얼 작성 마감 단계
- 매뉴얼 최종 검토자:
- 기술적 측면: 박 부장님or담당제품 개발팀장
- 문서적 측면: TW
기타 적용 사항, 매뉴얼 개선 작업 등
다음과 같은 페이지를 매뉴얼에 어떻게 적용할지 위와 같은 프로세스 다이어그램형(?) 등으로 작성해 본다/wiki/spaces/VM/pages/138805293
번역 맡길 때
제품 안내문구
지라로 번역할 대상 메시지 파일 링크 공유하기
매뉴얼이나 기타 문서
원본 파일 공유하기
목적, 일정, 작업 내역(번역해 놓은 파일이 있다면) 관련 설명
아이콘이나 디자인 작업 맡길 때
일정, 컨셉을 명확하게 공유해야 함