회고 때마다 ‘리뷰를 빨리 하자’고 적었는데 다음 프로젝트에서도 같은 문제가 나오나요? 배운 점을 정리하는 것과 실행할 일을 정하는 것은 다릅니다. 회고 문서의 마지막에 다음 번에 다시 확인할 개선 항목 하나를 붙여보세요. 사람 평가를 관찰한 상황으로 바꿔요 ‘팀원들이 소극적이었다’ 대신 ‘검토 요청에 마감 시점이 없어 요청자와 검토자가 서로 다른 일정을 예상했다’처럼 실제로 확인한 장면을 적습니다. 원인이 확인되지 않았다면 가설이라고 구분하세요. Atlassian의 회고 지침도 비난보다 개선에 집중하고, 실행 항목에 담당자와 기한을 정해 업무 계획에 반영하도록 안내합니다. 개선 항목은 작은 실험 카드로 아래는 폴리오쉽의 편집 제안입니다. [관찰] 어떤 일이 반복됐고 무엇으로 확인했나요? [시도] 다음 작업에서 무엇 하나를 바꿀 건가요? [담당·범위] 누가 실행하며 누구와 먼저 합의해야 하나요? [기간] 언제 시작하고 언제 다시 검토하나요? [확인 기준] 실행 여부와 도움이 됐는지를 각각 무엇으로 판단하나요? [부담] 새 절차가 추가하는 시간이나 불편은 무엇인가요? 담당자는 잘못한 사람이 아니라 실행과 점검을 챙기기로 합의한 사람입니다. 다른 팀이 해야 할 일을 동의 없이 배정하지 마세요. ‘리뷰를 빨리 하자’를 바꾼 가상 예시 시도: 다음 두 번의 문서 검토 요청에 ‘확인할 질문’과 ‘희망 답변 시점’을 함께 적는다. 검토자가 그 시점이 가능한지 확인하고 필요하면 조정한다. 담당: 요청 담당자가 작성하고 검토자와 일정을 합의한다. 검토일: 두 번째 검토가 끝난 다음 팀 회의. 실행 확인: 두 요청에 질문과 합의된 시점이 실제로 기록됐는가? 효과 확인: 검토자가 무엇을 봐야 할지 다시 묻는 일이 있었는가? 일정 조정은 제때 이뤄졌는가? 부담 확인: 요청문을 준비하는 시간이 과도하게 늘지는 않았는가? 이는 계획을 설명하는 예시이지 실제로 효과가 검증된 사례가 아닙니다. 횟수와 기간은 팀 상황에 맞춰 정하세요. 다음 회고에서는 세 갈래로 확인해요 ① 실행하지 못했다면: 효과가 없었다고 결론 내리지 말고, 권한·시간·범위 중 무엇이 막혔는지 확인합니다. ② 실행했지만 판단이 어렵다면: 관찰할 기회나 기록이 충분했는지 보고, 기준을 보완하거나 기간을 조정합니다. ③ 실행 결과가 확인됐다면: 도움과 부담을 함께 검토해 유지·수정·중단 중 하나를 정합니다. 양식을 채웠다는 사실만으로 검토 속도가 개선됐다고 쓰지는 마세요. 작업 난이도나 검토자 일정이 달랐다면 결과 해석에도 그 조건을 남겨두세요. 경력 기록에는 계획과 결과를 따로 남겨요 ‘리뷰 프로세스를 개선했다’ 한 줄보다 ‘무엇을 제안했고, 어디까지 실행했고, 무엇이 확인됐는지’를 구분해 적으면 내 판단을 설명할 수 있습니다. 공개 포트폴리오에는 동료 실명이나 내부 회의록 대신 공개 가능한 범위의 방식과 배움만 남기세요. 오늘은 가장 최근 회고에서 추상적인 다짐 하나를 골라 실험 카드로 바꿔보세요. 새 개선안을 더 만들기 전에, 그 카드를 다시 볼 날짜부터 정해두면 됩니다. 폴리오쉽 에디터 · 공식 에디토리얼 AI의 도움으로 작성한 정보성 글이며, 개인의 실제 경험담이 아닙니다. 참고: Atlassian Team Playbook · Retrospective https://www.atlassian.com/team-playbook/plays/retrospective