들어가며
이 글은 장신쉬(张鑫旭)의 특정 포스팅을 요약한 것입니다. 원문 링크, 클릭은 권장하지 않으며 결과는 본인 책임입니다.
1. 이메일 보내기
연락 수단 선택은 매우 중요합니다. 이메일은 빠르지는 않지만 매우 신뢰할 수 있어 권장하는 방식입니다. 급한 용무라면 이메일 + 문자 + 전화를 병행할 수 있지만, 뒤의 두 가지는 이메일을 보냈다는 사실을 알리기 위한 용도일 뿐입니다.
QQ, 위챗과 같은 메신저는 최악의 선택입니다. 효율이 낮기 때문입니다. 한두 줄로 설명할 수 있는 일도 메신저로 대화하다 보면 30분이 훌쩍 지나가 버립니다.
2. 이메일 내용 다듬기
1. 쓸데없는 말로 시작하지 마라
예: "계세요? xxx 기술 잘 아시나요?", "안녕하세요, 질문 하나 드려도 될까요?"
선배들의 시간은 소중합니다. 불필요한 말을 읽을 시간이 없습니다.
2. 말투와 어조에 주의하라
예를 들어, '鑫大大(신다다)' 스타일:
안녕하세요, xxx님. 인터넷에서 쓰신 xxx를 보았는데 몇 가지 이해가 안 되는 부분이 있습니다. 답변해 주실 수 있나요? 확인하시면 회신 부탁드립니다. 감사합니다! 본인 xxx (제 QQ: ******* 친구 추가 부탁드립니다)
얼핏 보기에는 타당해 보이고 나름 존중의 의미도 담긴 것 같지만, 어조가 확실히 불편하게 느껴지지 않나요?
3. 내용을 명확하게 설명하라
예:
안녕하세요, 실례합니다. 제가 최근에 무엇무엇을 하다가 xx 문제를 발견했는데, 어떻게 된 일인지 아시나요?
형님, 지금 아주 골치 아픈 문제에 부딪혔습니다. xx를 어떻게 해야 x...
더 흔한 경우:
안녕하세요! xxx에서 만드신 이 도구를 보았습니다. xx에 적용해 보았는데 작동하지 않네요. 왜 그런 걸까요? 감사합니다! [rar 첨부 파일]
이런 문자 메시지 방식의 설명은 이메일에 매우 부적절합니다. 우리는 일정한 논리적 순서에 따라 문제를 설명해야 합니다. 예:
- 문제의 환경과 배경
문제는 보통 환경과 밀접한 관련이 있으므로 반드시 환경 배경을 설명해야 합니다.
- 발생한 문제 현상 설명 (스크린샷)
문제가 무엇인지 명확히 말해야 합니다. 스크린샷을 첨부하는 것이 가장 좋은데, 그림 한 장으로 무엇이 문제인지 즉시 파악할 수 있기 때문입니다.
- 문제에 대한 본인의 사고 과정과 견해
질문은 당연히 생각 없이 던져서는 안 됩니다. 선배의 시간을 존중해야 하며, 사고 과정을 설명하는 것은 문제를 더 명확하게 전달하는 데 도움이 됩니다.
- 필요한 핵심 소스 코드
개발자 질문에 필수적이지만, 너무 길어서는 안 됩니다. 핵심 부분을 표시하고 주석을 다는 것이 좋습니다. 선배들 역시 '너무 길면 안 읽기(TL;DR)' 때문입니다.
- 온라인 미리보기 데모
가장 효율적인 방식입니다. 온라인에서 문제를 재현할 수 있다면 선배가 즉시 문제에 직면할 수 있습니다. 이상적인 상황은 링크(문제)를 보내고 10분 뒤 선배가 링크(해결책)로 답장하는 것이며, 군더더기 말이 전혀 필요 없습니다.
4. 이메일 첨부 파일
다운로드 -> 압축 해제 -> 열기 과정을 거쳐야 하므로 가급적 첨부 파일을 넣지 마세요. 메일 본문에 명확히 설명하고 코드는 하이라이트를 적용하는 것이 좋습니다.
파일은 rar 대신 zip 형식으로 압축하세요. Mac에서는 rar을 바로 열 수 없기 때문입니다.
5. 한 번에 명확히 설명하라
이메일의 장점은 인사치레나 사담이 없다는 점입니다. 한 통의 메일로 문제를 명료하게 설명하여 상대방이 상황을 온전히 파악하고 해결책을 제시할 수 있도록 하세요.
메일을 여러 번 주고받으며 질질 끌게 되면 이메일의 장점은 사라집니다.
3. 기타 주의 사항
1. 시간
상대방이 바쁘지는 않은지? 근무 중인지? 월요일이라 짜증 나지는 않을지? 금요일이라 시간이 없지는 않을지?
상대방의 기분이 좋아야 성의 있는 답변이 돌아오지 않겠습니까?
2. 제목
이메일 제목은 중요합니다. 최대한 많은 정보를 담으세요. 메일을 열어보지 않고도 상황을 알 수 있게 하면 상대방의 메일 목록에서 중요도를 높여 주의를 끌 수 있습니다.
3. 간결함을 유지하라
역시 '너무 길면 안 읽기' 때문입니다. 1,000자짜리 서사 수필을 받으면 읽으시겠습니까? 저는 안 읽습니다.
이메일에 쓸데없는 말이 많고 요점이 없으면 상대방은 어떻게 답장해야 할지 모를 수 있습니다.
마치며
이 글을 쓴 이유는 원문에 쓸데없는 말이 너무 많기 때문입니다. 수다스러운 zxx의 신공간(鑫空间)보다는 sf의 프론트엔드 관찰(前端观察)을 더 선호합니다.
아직 댓글이 없습니다