댓글에 답하는 법: 수락·질문·수정 요청을 짧게 전하기
이 연재에 대하여
「팀에서 쓰는 태스크 관리 요령」은 태스크 관리나 프로젝트 관리 도구를 쓰기 시작한 팀을 위한 전 8회와 번외편의 연재입니다. 업종에 상관없이, 어느 회부터 읽어도 됩니다.
- 일은 어떤 단위로 나눌까?
- 잘 전달되는 태스크 작성법
- 태스크는 얼마나 잘게 나눌까?
- 담당자와 기한 정하는 법
- 댓글에 답하는 법이 글
- 진행 상황은 어떻게 전할까?
- 외부 사람과 주고받을 때의 작성법
- 마무리하는 법곧 공개
번외편 「언어가 다른 멤버에게도 전해지는 작성법」(곧 공개)
태스크 댓글란에서 같은 이야기가 몇 번이고 오간다. 답이 없어서 읽었는지조차 알 수 없다. 이런 일은 쓰는 방식을 조금만 바꿔도 꽤 줄일 수 있습니다.
참고: 이 글은 GeckoFlag 개발자가 작성했습니다.
결론: 첫 줄에 결론, 마지막 줄에 부탁
읽는 사람은 첫 줄을 보고 ‘나와 관계있는 일인지’를 판단합니다. 결론을 먼저 쓰고, 상대가 해 주었으면 하는 일을 마지막에 씁니다. 그 사이에는 판단에 필요한 내용만 둡니다.
상황별 작성법
알겠다고 답할 때
‘알겠습니다’만으로는 무엇을 알겠다는 건지, 언제 무엇을 할지 알 수 없습니다. 다음에 할 일을 함께 씁니다.
| 좋지 않은 예 | 좋은 예 |
|---|---|
| 네, 알겠습니다. | 알겠습니다. 목요일 오전 중에 첫 번째 안을 올리겠습니다. |
답이 필요 없는 연락에는 ‘봤습니다’ 정도의 짧은 반응이면 충분합니다. 도구에 리액션(이모지로 반응하는 기능)이 있다면 그것을 씁니다.
질문할 때
- 질문이 여러 개라면 번호를 붙인다. 답하는 쪽도 ‘1은…’처럼 번호로 답할 수 있다
- 되도록 선택지를 주고 묻는다. ‘어떻게 할까요?’보다 ‘A와 B 중 어느 쪽으로 할까요?’가 답하는 쪽의 부담이 적다
- 언제까지 답이 필요한지 쓴다
돌려보낼(수정을 부탁할) 때
- 고칠 곳을 구체적으로 짚는다: ‘2페이지의 제목’, ‘오른쪽 아래의 전화번호’
- 이유를 덧붙인다: 이유를 알면 비슷한 부분도 상대가 스스로 고칠 수 있다
- ‘꼭 고쳐야 할 것’과 ‘가능하면’을 나눈다: 모두 같은 무게로 쓰면 상대는 어디부터 손대야 할지 헤맨다
- 서두는 짧게 한다: 딱딱하게 들리지 않으려고 서두를 길게 늘어놓으면 정작 중요한 부탁이 묻힌다. 좋았던 점을 전하고 싶다면 한 줄이면 충분하다
완료를 보고할 때
무엇이 끝났는지, 어디에 있는지, 남은 일은 없는지를 씁니다. ‘끝났습니다’만 쓰면 받는 쪽이 결과물을 찾아다녀야 합니다.
그대로 쓸 수 있는 문장 템플릿
○ 부분을 바꿔서 쓰세요.
수락
알겠습니다. ○일 ○시까지 ○○하겠습니다.
질문
○○와 관련해 두 가지 여쭤보겠습니다.
- ○○는 A와 B 중 어느 쪽인가요?
- 이번에도 ○○가 필요한가요?
○일까지 답변 주시면 일정대로 진행할 수 있습니다.
수정 요청
확인했습니다. 아래 두 가지를 수정 부탁드립니다.
- (필수) ○○의 ○○를 ○○로 바꿔 주세요. 이유: ○○ 때문입니다.
- (가능하면) ○○를 조금 더 크게 해 주세요.
나머지는 지금 그대로 괜찮습니다.
완료 보고
○○ 작업을 마쳤습니다.
- 위치: ○○
- 남은 일: 없음(또는 ○○)
확인 부탁드립니다.
지연 연락
○○를 ○일 기한까지 마치기 어렵게 되었습니다.
이유: ○○
○일까지는 올릴 수 있습니다. ○○만 먼저 드리는 방법도 있는데, 어느 쪽이 좋으실까요?
쓸 때 지킬 세 가지 규칙
1누가 읽어야 하는지 분명히 한다
여러 사람이 보는 댓글란에서는 받는 사람이 정해져 있지 않으면 아무도 자기 일이라고 생각하지 않습니다. 이름을 쓰거나, 알림을 보낼 사람을 고릅니다.
2답이 필요한지 쓴다
‘답장은 안 주셔도 됩니다’, ‘○일까지 답변 부탁드립니다’라고 쓰기만 해도 답을 기다리는 시간이 줄어듭니다.
3태스크 하나에서는 한 가지 이야기만 다룬다
다른 이야기가 시작되면 새 태스크를 만듭니다. 한 댓글란에 여러 이야기가 섞이면 나중에 무엇이 정해졌는지 되짚을 수 없게 됩니다.
말하기 어려운 것을 전할 때
지연, 실수, 거절처럼 말하기 어려운 일일수록 서두가 길어지기 쉽습니다. ‘무슨 일이 있었는지 → 어떤 영향이 있는지 → 어떻게 하고 싶은지’의 순서로 사실을 짧게 씁니다. 사과는 한마디면 되고, 그만큼 다음에 할 일을 구체적으로 씁니다.
메신저와 구분해서 쓰기
간단한 상의는 메신저가 더 빠릅니다. 다만 메신저에서 정해진 일은 태스크 댓글에 한 줄로 남깁니다. 메신저 대화는 흘러가 버려서 나중에 찾을 수 없게 되기 때문입니다(입문 연재의 「메일이나 메신저로 받은 부탁은 왜 흘러가 버릴까?」에서 자세히 설명하고 있습니다).
예를 들면, 이런 일이 있었습니다
수정 요청을 ‘전체적으로 좀 더 밝게, 글자도 크게, 그리고 사진도…’라고 한 문장으로 썼더니, 어느 것이 필수인지 전해지지 않아 세 번이나 주고받았습니다. 번호를 붙이고 ‘필수’와 ‘가능하면’을 나눈 뒤로는 한 번에 수정본이 돌아오는 일이 늘었습니다.
GeckoFlag에서는 이렇게 주고받을 수 있다
- 댓글은 리치 텍스트로 쓸 수 있고, 번호 목록도 쓸 수 있습니다. 게시하기 전에 미리 보기로 확인할 수 있습니다.
- 댓글을 게시하면서 상태, 우선순위, 담당자를 함께 바꿀 수 있습니다. 예를 들어 완료 보고를 쓰면서 상태를 ‘확인 대기’로 바꾸고, 담당을 부탁한 사람에게 되돌릴 수 있습니다.
- 알림을 보낼 멤버를 게시할 때마다 고를 수 있습니다. ‘누가 읽어야 하는지’를 매번 정할 수 있습니다.
- 댓글에는 20종류의 아이콘으로 리액션할 수 있습니다. ‘봤습니다’뿐인 답글을 줄일 수 있습니다.
- 화면에는 최근 댓글 3개가 표시되고, 그 이전 댓글은 접힙니다. 긴 대화 끝에 정해진 일은 이슈 설명에도 반영해 두면 읽기 쉬워집니다.
실제 화면은 데모에서 직접 써 볼 수 있습니다.
정리
댓글은 첫 줄에 결론, 마지막 줄에 부탁을 씁니다. 누가 읽어야 하는지, 답이 필요한지를 덧붙이기만 해도 오가는 횟수가 줄어듭니다. 다음 회에서는 진행 상황을 전하는 ‘상태’를 정하는 법을 설명합니다.
연재제4회 「담당자와 기한 정하는 법」도 함께 읽어 보세요
연재다음 회, 제6회 「진행 상황은 어떻게 전할까?」