317 lines
11 KiB
Markdown
317 lines
11 KiB
Markdown
# 관리페이지 개념 설명
|
|
|
|
> 운영팀이 관리페이지의 구조와 용어를 처음 접할 때 읽는 문서로 정리
|
|
>
|
|
> 실제 처리 순서는 [관리페이지 운영팀 사용 가이드](<./관리페이지-운영팀-사용가이드.md>)에서 확인
|
|
|
|
## 1. 관리페이지가 하는 일
|
|
|
|
여러 서비스에서 들어온 Q&A를 한곳에 모아 확인하고 처리하는 화면으로 정리
|
|
|
|
사용자가 남긴 질문이나 요청을 운영팀이 읽고, 담당자를 정하고, 답변하고, 필요한 개발 작업까지 연결할 수 있도록 구성
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
A[서비스에서 Q&A 작성] --> B[관리페이지에서 피드백으로 확인]
|
|
B --> C[답변 또는 내부 처리]
|
|
C --> D[필요 시 이슈 연결]
|
|
D --> E[처리 결과 안내]
|
|
```
|
|
|
|
## 2. Q&A와 피드백
|
|
|
|
Q&A와 피드백은 서로 다른 글이 아니라 같은 요청을 화면별로 다르게 부르는 이름으로 구분
|
|
|
|
| 사용하는 곳 | 부르는 이름 | 의미 |
|
|
| --- | --- | --- |
|
|
| 사용자가 글을 작성하는 화면 | Q&A | 사용자가 남긴 질문·요청·불편 사항 |
|
|
| 운영팀이 글을 처리하는 화면 | 피드백 | 관리 대상이 된 Q&A |
|
|
|
|
```text
|
|
사용자 화면: Q&A
|
|
↓
|
|
관리페이지: 피드백
|
|
```
|
|
|
|
따라서 운영팀은 “새 피드백이 들어왔다”고 말하지만, 실제로는 사용자가 작성한 Q&A가 관리페이지에 표시된 것으로 이해
|
|
|
|
## 3. 역할 구분
|
|
|
|
관리페이지와 Q&A 화면에서 역할을 다음과 같이 구분
|
|
|
|
| 역할 | 역할의 의미 | 주요 관심사 |
|
|
| --- | --- | --- |
|
|
| 시스템관리자 | 전체 시스템과 여러 프로젝트를 관리하는 역할 | 전체 현황, 프로젝트별 업무 확인 |
|
|
| 프로젝트 담당자(읽는 당사자) | 맡은 프로젝트의 Q&A를 읽고 처리하는 역할 | 담당자 지정, 답변, 내부 협업, 이슈 처리 |
|
|
| Q&A 작성자 | 서비스에서 질문이나 요청을 남긴 사람 | Q&A 작성, 답변 확인, 추가 문의 |
|
|
|
|
권한에 따라 확인할 수 있는 프로젝트와 실행할 수 있는 작업이 달라질 수 있도록 구성
|
|
|
|
## 4. 프로젝트와 채널
|
|
|
|
### 4.1 프로젝트
|
|
|
|
프로젝트는 하나의 서비스나 업무 단위를 묶는 가장 큰 관리 단위
|
|
|
|
예시
|
|
|
|
- 사내 시스템
|
|
- 인트라넷 Q&A
|
|
- 특정 업무 서비스
|
|
|
|
### 4.2 채널
|
|
|
|
채널은 프로젝트 안에서 Q&A를 받는 세부 접수 창구
|
|
|
|
하나의 프로젝트에 여러 채널을 둘 수 있고, 문의 종류를 나누는 기준으로 사용
|
|
|
|
예시
|
|
|
|
```text
|
|
인트라넷 Q&A 프로젝트
|
|
├── 계정 문의 채널
|
|
├── 권한 문의 채널
|
|
└── 시스템 오류 채널
|
|
```
|
|
|
|
### 4.3 프로젝트와 채널의 관계
|
|
|
|
| 구분 | 프로젝트 | 채널 |
|
|
| --- | --- | --- |
|
|
| 범위 | 큰 서비스·업무 묶음 | 프로젝트 안의 세부 접수 창구 |
|
|
| 확인 질문 | 어느 서비스의 요청인가? | 어떤 종류의 요청인가? |
|
|
| 관리페이지 열 | 프로젝트 | 채널 |
|
|
| 예시 | 인트라넷 Q&A | 계정 문의 |
|
|
|
|
Q&A는 반드시 하나의 프로젝트와 채널을 기준으로 관리되도록 구성
|
|
|
|
```text
|
|
프로젝트
|
|
└── 채널
|
|
└── Q&A
|
|
└── 피드백
|
|
```
|
|
|
|
프로젝트와 채널을 먼저 확인해야 담당자와 처리 방향을 잘못 정하지 않음
|
|
|
|
## 5. 피드백과 이슈
|
|
|
|
### 5.1 피드백
|
|
|
|
피드백은 사용자의 Q&A 자체를 처리하는 항목
|
|
|
|
주로 다음 내용을 관리
|
|
|
|
- 사용자의 질문과 요청
|
|
- 작성자 정보
|
|
- 중요도
|
|
- 담당자
|
|
- 댓글/답변
|
|
- 담당자 내부 메모
|
|
- 연결된 이슈
|
|
- 피드백 상태
|
|
|
|
### 5.2 이슈
|
|
|
|
이슈는 피드백을 해결하기 위해 필요한 개발·수정·확인 작업
|
|
|
|
예시
|
|
|
|
- 로그인 오류 수정
|
|
- 화면 문구 변경
|
|
- 권한 확인 및 수정
|
|
- 특정 조건에서 발생하는 오류 조사
|
|
|
|
### 5.3 연결 관계
|
|
|
|
한 피드백에 이슈가 없을 수도 있고, 여러 이슈가 연결될 수도 있도록 구성
|
|
같은 원인으로 들어온 여러 피드백을 하나의 이슈에 연결할 수도 있도록 구성
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
F1[피드백 A] --> I[이슈: 로그인 오류 수정]
|
|
F2[피드백 B] --> I
|
|
F3[피드백 C] --> I
|
|
```
|
|
|
|
이슈를 연결했다고 피드백이 자동으로 완료되는 것은 아니므로 각각의 처리 상태를 따로 확인
|
|
|
|
## 6. 피드백 상태와 이슈 상태
|
|
|
|
피드백 상태는 사용자의 요청이 어디까지 처리되었는지 나타내고, 이슈 상태는 개발 작업이 어디까지 진행되었는지 나타내도록 분리
|
|
|
|
| 상태 | 공통 의미 |
|
|
| --- | --- |
|
|
| 신규 | 아직 본격적으로 확인하지 않은 상태 |
|
|
| 접수 | 내용을 확인하고 처리 대상으로 받은 상태 |
|
|
| 진행중 | 답변·확인·개발 작업을 진행하는 상태 |
|
|
| 완료 | 필요한 처리와 안내가 끝난 상태 |
|
|
| 보류 | 일정·추가 정보·외부 사유로 잠시 멈춘 상태 |
|
|
|
|
상태 흐름은 다음처럼 이해
|
|
|
|
```text
|
|
신규 → 접수 → 진행중 → 완료
|
|
↘ 보류
|
|
```
|
|
|
|
보류는 영구 종료가 아니라 다시 처리할 수 있도록 잠시 멈춘 상태로 구분
|
|
보류로 변경할 때는 보류 사유를 함께 남기는 방식으로 정리
|
|
|
|
### 상태를 따로 관리하는 이유
|
|
|
|
| 상황 | 피드백 상태 | 이슈 상태 |
|
|
| --- | --- | --- |
|
|
| 고객에게 답변했고 개발 작업이 없음 | 완료 | 해당 없음 |
|
|
| 개발 작업을 시작함 | 진행중 | 진행중 |
|
|
| 개발은 끝났지만 고객 안내가 남음 | 진행중 | 완료 |
|
|
| 고객 안내까지 끝남 | 완료 | 완료 |
|
|
|
|
개발 이슈가 완료된 뒤에도 피드백에 결과를 답변하고 피드백 상태를 완료로 바꾸는 작업이 필요
|
|
|
|
### 6.1 핵심 처리 순서
|
|
|
|
세부 자동화 동작은 제외하고, 운영팀이 기억할 핵심 순서만 다음과 같이 정리
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
A[사용자가 Q&A 작성] --> B[관리페이지에 피드백 등록<br/>상태: 신규]
|
|
B --> C[담당자 지정 및 내용 확인<br/>상태: 접수]
|
|
C --> D{개발 작업이 필요한가?}
|
|
D -- 아니오 --> E[댓글/답변 작성]
|
|
D -- 예 --> F[이슈 생성 또는 기존 이슈 연결]
|
|
F --> G[이슈 처리<br/>상태: 진행중]
|
|
G --> H[이슈 완료 여부 확인]
|
|
H --> E
|
|
E --> I[처리 완료 안내]
|
|
I --> J{작성자 확인 또는 확인 기간 만료}
|
|
J --> K[피드백 완료]
|
|
```
|
|
|
|
### 순서도 읽는 법
|
|
|
|
1. Q&A가 등록되면 관리페이지에서 피드백 `신규`로 확인
|
|
2. 담당자가 내용을 처음 확인하면 `접수`로 처리
|
|
3. 개발 작업이 없으면 답변 후 완료 안내를 진행
|
|
4. 개발 작업이 있으면 이슈를 연결하고, 이슈가 끝난 뒤 답변과 완료 안내를 진행
|
|
5. 작성자가 완료를 확인하거나 확인 기간이 지나면 피드백을 `완료`로 처리
|
|
|
|
### 꼭 기억할 예외
|
|
|
|
- 처리하기 어려운 사유가 있으면 `보류`로 바꾸고 사유를 남겼음.
|
|
- 보류 중인 항목은 댓글이나 외부 상태 변경만으로 자동 진행하지 않았음.
|
|
- 완료 안내 뒤 작성자가 다시 문의하면 피드백을 다시 확인
|
|
- 완료된 이슈와 피드백은 각각 별도로 완료 처리
|
|
|
|
## 7. 댓글과 담당자 내부 메모
|
|
|
|
두 입력 영역은 읽는 사람이 다르므로 목적을 분리
|
|
|
|
| 구분 | 댓글/답변 | 담당자 내부 메모 |
|
|
| --- | --- | --- |
|
|
| 읽는 사람 | Q&A 작성자와 운영팀 | 운영팀과 관리자 |
|
|
| 목적 | 고객에게 처리 결과를 안내 | 운영팀끼리 내용을 공유 |
|
|
| 작성 예시 | 확인 결과, 조치 내용, 추가 안내 | 재현 방법, 원인 추정, 인수인계 |
|
|
| 작성 시 주의 | 고객이 이해할 수 있게 작성 | 고객에게 공개되면 안 되는 내용도 작성 가능 |
|
|
|
|
고객에게 전달할 내용은 댓글/답변에 작성하고, 내부 협의 내용은 담당자 내부 메모에 작성하도록 구분
|
|
|
|
## 8. 담당자와 중요도
|
|
|
|
### 담당자
|
|
|
|
담당자는 피드백이나 이슈를 실제로 확인하고 처리할 사람
|
|
|
|
담당자가 지정되지 않은 항목은 처리 주체가 불명확해질 수 있으므로 확인 후 담당자를 지정
|
|
|
|
### 중요도
|
|
|
|
중요도는 먼저 처리해야 하는 정도를 나타내는 정보
|
|
|
|
중요도가 높거나 오래 업데이트되지 않은 피드백부터 확인하면 처리 우선순위 판단에 도움
|
|
|
|
## 9. Gitea 이슈
|
|
|
|
Gitea 이슈는 개발자가 실제 수정 작업을 진행하는 외부 개발 작업 항목
|
|
|
|
관리페이지의 이슈와 Gitea 이슈를 연결하면 운영팀이 개발 작업의 번호와 상태를 함께 확인 가능
|
|
|
|
```text
|
|
관리페이지 이슈
|
|
↕ 연결
|
|
Gitea 개발 이슈
|
|
```
|
|
|
|
기존 Gitea 이슈가 있으면 검색해 연결하고, 관련 작업이 없으면 새 개발 이슈를 생성해 연결
|
|
|
|
Gitea 연결 여부와 피드백 완료 여부는 별개이므로 개발 이슈를 연결한 뒤에도 고객 답변과 피드백 상태를 확인
|
|
|
|
## 10. 목록의 주요 정보
|
|
|
|
### 피드백 처리 목록
|
|
|
|
피드백 처리 목록은 사용자의 Q&A를 찾아 답변하고 처리하는 데 필요한 정보를 표시하도록 구성
|
|
|
|
| 항목 | 의미 |
|
|
| --- | --- |
|
|
| 프로젝트 / 채널 | 요청이 들어온 서비스와 접수 창구 |
|
|
| 제목 | 피드백의 제목과 상세 진입점 |
|
|
| 작성자 | Q&A를 남긴 사람 |
|
|
| 담당자 | 현재 처리하는 사람 |
|
|
| 피드백 상태 | 고객 요청의 처리 단계 |
|
|
| 중요도 | 우선 처리 정도 |
|
|
| 최근 업데이트 | 마지막으로 변경된 시점 |
|
|
| 연결 이슈 | 관련 개발 작업 |
|
|
| 등록일시 | Q&A가 등록된 시점 |
|
|
|
|
### 이슈 처리 목록
|
|
|
|
이슈 처리 목록은 개발 작업을 찾고 연결된 피드백까지 확인하도록 구성
|
|
|
|
| 항목 | 의미 |
|
|
| --- | --- |
|
|
| 프로젝트 / 채널 | 이슈가 속한 서비스와 접수 창구 |
|
|
| 제목 | 이슈의 제목과 상세 진입점 |
|
|
| 담당자 | 이슈를 처리하는 사람 |
|
|
| 이슈 상태 | 개발 작업의 처리 단계 |
|
|
| 최근 업데이트 | 이슈가 마지막으로 변경된 시점 |
|
|
| 연결된 피드백 | 해당 이슈와 관련된 Q&A |
|
|
| 이슈 등록일시 | 이슈가 등록된 시점 |
|
|
|
|
연결 항목이 여러 개이면 대표 항목 뒤에 `외 N개`로 표시
|
|
|
|
## 11. 한눈에 보는 전체 구조
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
P[프로젝트] --> C[채널]
|
|
C --> Q[Q&A]
|
|
Q --> F[피드백]
|
|
F --> R[댓글/답변]
|
|
F --> M[담당자 내부 메모]
|
|
F -. 필요 시 연결 .-> I[관리페이지 이슈]
|
|
I -. 개발 작업 연결 .-> G[Gitea 이슈]
|
|
```
|
|
|
|
정리하면 다음 구조로 이해
|
|
|
|
```text
|
|
프로젝트
|
|
└── 채널
|
|
└── Q&A = 피드백
|
|
├── 담당자
|
|
├── 중요도
|
|
├── 댓글/답변
|
|
├── 담당자 내부 메모
|
|
└── 이슈 ── Gitea 이슈
|
|
```
|
|
|
|
## 12. 핵심만 다시 정리
|
|
|
|
- Q&A는 사용자가 작성한 글이고, 피드백은 관리페이지에서 부르는 이름
|
|
- 프로젝트는 큰 서비스 단위이고, 채널은 프로젝트 안의 세부 접수 창구
|
|
- 피드백은 고객 요청을 처리하는 항목이고, 이슈는 개발 작업을 처리하는 항목으로 나누었음.
|
|
- 댓글/답변은 고객에게 공개되고, 담당자 내부 메모는 운영팀끼리만 공유
|
|
- 피드백 상태와 이슈 상태는 서로 영향을 주지만 자동으로 합쳐지지 않도록 분리
|
|
- 이슈가 완료되어도 고객 답변과 피드백 상태 변경을 별도로 처리
|