인사 평가 피드백 문장 다듬기

메모가 사실·영향·짐작 세 묶음으로 갈렸고, 짐작 3건은 목록으로만 남아 평가 문장에 들어가지 않았다.

바뀌었으면 하는 점 — 상반기 초안 마감 세 번 중 두 번이 예정일을 넘겼습니다. 그때마다 검수와 디자인 일정이 뒤로 밀렸습니다. 하반기에는 마감 3일 전에 진행 상황을 한 줄로 공유하고, 늦을 것 같으면 그때 일정 조정을 요청해 주세요.

개편 성과처럼 근거가 없는 자리는 [사례 확인]으로 비었다.

인사평가 피드백 프롬프트에 메모를 던지고 "평가 코멘트 써 줘"라고 하면 대개 칭찬 두 줄과 "앞으로 더 성장하길 기대합니다" 같은 마무리가 돌아옵니다. 받는 사람은 기분이 나쁘지 않지만 무엇을 바꿔야 하는지 모르고, 반년 뒤 같은 문제로 다시 평가를 쓰게 됩니다.

그래서 이 프롬프트는 문장을 쓰기 전에 재료를 정리하는 단계를 앞에 두었습니다. 사실과 영향과 짐작을 세 묶음으로 나눠 놓고 세 번째는 문장에서 빼는 것인데, 평가에서 가장 다투기 쉬운 대목이 바로 짐작이기 때문입니다. "의욕이 없어 보였다"는 반박할 수 없어서 더 아픕니다. 짐작을 따로 목록으로 남겨 두면 면담에서 확인할 질문 재료가 됩니다.

역할을 평가를 쓰기만 한 사람이 아니라 직접 전달까지 해 본 팀장으로 둔 것은, 읽는 사람 앞에서 소리 내어 말할 수 있는 문장인지가 이 글의 기준이기 때문입니다. 제약 문단의 성격 규정 금지와 [사례 확인] 표시는 짝입니다. 하나는 사람을 평가하는 말을 막고, 다른 하나는 근거가 없을 때 지어내는 대신 빈칸을 남기게 합니다.

관찰 메모를 """ 로 감싼 데에는 이유가 있습니다. 메모에는 "회의에서 반대 의견을 잘 안 냄" 같은 조각글이 섞여 있는데, 감싸지 않으면 모델이 그 문장을 지시로 읽고 엉뚱한 방향으로 답할 수 있습니다. 성과 평가 문구를 만들 때는 자료와 지시의 경계를 분명히 해 두는 편이 안전합니다.

형식을 잘한 점 · 바뀌었으면 하는 점 · 먼저 물어볼 질문 세 부분으로 고정한 것은 순서 때문입니다. 개선점만 적으면 평가가 통보가 되고, 칭찬만 적으면 반년이 그대로 반복됩니다. 마지막의 질문 두 개는 면담을 내 이야기로 시작하지 않게 해 주는 장치입니다.

"업무에 성실히 임하였으며 협업 능력이 뛰어남" 같은 문장이 나옵니다. 어느 팀원에게 붙여도 말이 되는 글이라 받는 사람은 자기 이야기로 느끼지 않습니다. 메모에 있던 마감 지연은 "일정 관리에 다소 아쉬움이 있었음" 정도로 뭉개져 무엇을 바꿔야 하는지 남지 않고, 없던 성과 수치가 끼어들기도 합니다.