프로젝트 회고: 질문, 진행 순서와 템플릿

프로젝트 회고란 무엇인가요?

회고는 팀이 정해진 기간의 경험을 돌아보고 무엇을 바꿀지 결정하는 회의입니다. 프로젝트나 단계, 반복되는 작업 주기가 끝난 뒤 진행할 수 있습니다. 협업과 업무 절차, 조건을 중심으로 이야기하며 책임을 추궁하지 않습니다.

일반 진행 회의에서는 완료되거나 늦어진 일을 살핍니다. 회고에서는 왜 그렇게 진행됐고 다음에는 어떤 작은 행동이 도움이 될지 묻습니다. 어려움을 나열하는 데서 그치지 말고 확인할 수 있는 결과를 정하세요.

회의를 경영진 앞에서 보고서를 변호하는 자리로 만들지 마세요. 솔직히 말하면 불이익이 있다고 생각하는 사람은 유용한 세부 사항을 말하지 않을 수 있습니다. 진행자는 목적과 규칙을 미리 설명하세요.

팀을 준비시키는 방법

“잘 안되는 모든 것” 대신 “교육 웨비나 준비와 시작”처럼 범위를 정하세요. 해당 과정에 참여하고 다른 관점에서 설명할 수 있는 사람을 초대합니다.

각자 구체적인 일을 하나 준비하도록 하세요. 무엇이 언제 일어났고, 어떤 결과가 있었으며, 무엇이 도움이 됐는지입니다. 미리 메모를 모으고 회의에서 조용히 생각할 시간을 주면 가장 적극적인 사람의 의견만으로 시작하지 않을 수 있습니다.

사실을 확인할 계획, 작업 기록, 승인 버전 또는 프로젝트 메시지를 준비하세요. 기록이 없다고 행동이 없었다는 뜻은 아닙니다. 의견이 저장되지 않았다고 해서 아무것도 하지 않았다고 단정할 수 없습니다.

회고의 진행 순서와 질문

아래는 소규모 팀을 위한 시간 배분의 예입니다. 필요에 맞게 바꾸고 복잡한 주제는 별도 회의로 다룰 수 있습니다.

누가 평소에 일을 잘못하는지 따지기 시작하면 구체적인 사례로 돌아가세요. “우리는 제대로 된 자료를 받은 적이 없어” 대신 “이번에 어떤 자료가 부족했고 언제 알아챘나요?”라고 묻습니다.

한 번에 모든 문제를 풀려고 하지 마세요. 업무에 영향을 주며 실행할 방법이 있는 문제를 고르세요. 다른 질문은 잊히거나 담당 없는 약속이 되지 않도록 따로 적으세요.

불만에서 검증할 수 있는 변화로

팀은 웨비나를 준비했습니다. 시작 전날, 승인된 수정 사항 일부가 발표 자료에 빠져 있었습니다. 회고에서 “또 마지막 순간에 전부 고쳐야 했어요”라는 말이 나왔습니다. 불만만으로는 해결책을 알 수 없습니다.

참여자는 자료를 열어 어떤 일이 있었는지 확인했습니다. 의견이 두 채팅방으로 들어왔고 일부 수정은 했지만 상태를 공유하지 않았습니다. 팀은 목록 하나로 최종 승인 전에 누락을 찾을 수 있다고 가정했습니다.

다음 교육 웨비나에서 시험합니다. 코디네이터 마리나가 준비 전에 목록을 만듭니다. 의견마다 “수락”, “진행 중”, “확인 완료” 또는 거절 이유를 적습니다. 시작 전날 편집 담당자가 목록과 최종 발표 자료를 대조합니다.

다음 회고에서 승인됐지만 빠진 수정이 있는지, 목록을 관리하기 쉬웠는지 확인합니다. 누락이 반복되면 도구를 탓하기 전에 불명확한 설명이나 늦은 변경 등 다른 원인을 살펴봅니다.

회고 결과 템플릿

프로젝트와 기간:
참여자:
도움이 된 점과 유지할 점:

선택한 문제:
관찰과 구체적인 사례:
추정 원인:
아직 모르는 것:

진행할 실험:
담당자:
준비 기한:
진행 상황을 기록할 곳:
결과를 확인할 기준:
결과를 논의할 때:
확인 후 결정: [유지 / 변경 / 중단]

다음에 논의할 다른 주제:

참여자에게 요약을 보내 부정확한 부분을 고칠 수 있게 하세요. 참석하지 않은 사람의 결정이 필요하면 의존 사항으로 기록하세요. 동의 없이 그 사람에게 업무를 맡기거나 약속을 적지 마세요.

• 논의 범위가 명확하다.
• 사실과 추정을 구분했다.
• 팀이 유지하고 싶은 점이 있다.
• 실행 가능한 변경을 골랐다.
• 담당자가 업무에 동의했다.
• 결과 확인 시점을 정했다.