Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

회고 (Retrospective)에 대한 정리 및 설계 #8

Closed
JaeYeopHan opened this issue Apr 18, 2018 · 7 comments
Closed

회고 (Retrospective)에 대한 정리 및 설계 #8

JaeYeopHan opened this issue Apr 18, 2018 · 7 comments
Labels
for: share For sharing issue type: document Personal documents

Comments

@JaeYeopHan
Copy link
Owner

What?

회고란 무엇인가

사전적 정의를 먼저 살펴보자면, "돌아다봄", "지나간 일을 돌이켜 생각함" 등을 의미한다.

'프로젝트 회고'라는 부분으로 구체화시키는 경우, 프로젝트의 큰 생명 주기에서 특정 시점 (이 시점은 프로젝트 구성원들이 정하기 나름이다.)에서 진행하는 회의의 일종으로 볼 수 있다. 이 회의는 '이전 시점'에서 '현재 시점'까지 발생한 일들을 돌아보며 좋았던 부분과 아쉬웠던 부분을 리스트업하고 아쉬웠던 부분을 어떻게 개선할 지에 대한 논의를 진행한다. 궁극적으로는 아쉬웠던 부분들을 개선하여 프로젝트의 생명주기에 활력을 불어넣는 계기로 만드는 것이 목표이다.

Who?

회고는 누가 하는가?

프로젝트 회고일 경우, 해당 프로젝트에 참가한 사람이 함께 회고를 진행한다. (퍼실리테이터가 있다면 함께 진행한다.)

Why?

회고는 왜 하는가

하나의 이터레이션 또는 프로젝트 릴리즈 후 회고의 시간을 가짐으로써 지난 시간동안 '잘 된점'과 '아쉬운 점', 그에 따른 후기 등을 서로 공유할 수 있다. 이를 기반으로 아쉬웠던 부분을 바로잡고 프로젝트가 좋은 방향으로 발전할 수 있도록 한다. 이는 중간 점검의 일종으로 볼 수 있지만 '프로젝트가 어느 정도 진행되었는가' 와는 별도로 진행되어야 한다.

How? - 프로세스

회고 자체를 어떻게 진행할 것인가

중점을 둬야하는 부분

  • 회고할 때 나는(혹은 다른 사람들은) 부정적 감정을 무시하지 않으면서 전반적으로 긍정적 감정을 많이 겪는가?
  • 회고할 때 나는(혹은 다른 사람들은) 점차적으로 생각을 더 적극적으로 해서 새로운 이야기를 만들어 가는가?
  • 회고할 때 나는(혹은 다른 사람들은) 시각의 전환을 자주 하게 되는가?
  • 낙관적으로 회고하되 부정적인 사건을 인정해야 그 회고의 효과가 높다.

구체적인 프로세스

  1. 사전 준비하기 (개인)
    1-1. (회고가 처음일 경우) 회고에 대한 이해
    1-2. 어떤 방식으로 회고를 할 것인가에 대한 정리 (with 회고하는 인원)
    1-3. 무엇을 회고할 것인가 (targeting) (with 회고하는 인원)
    1-4. 자신을 회고
    1-5. 프로젝트에 대한 회고
  2. 회고 (Check-In)
    2-1. (정한 회고 방식에 따라 진행)
  3. 마무리
    3-1. 감사인사
  4. 회고의 회고

How? - 방법론

KPT

K, P, T를 기준으로 action item을 도출한다.

  • Keep, Problem, Try 세 부분으로 나눈다.
  • Keep
    • 좋았던 점을 기반으로 도출되며 앞으로 프로젝트를 진행할 때, 계속 유지해야할 사항
  • Problem
    • 아쉬웠던 점을 기반으로 도출되며 앞으로 프로젝트를 진행할 때, 개선되어야 할 사항.
    • 일어난 사건 자체 뿐만 아니라 좋았거나 나빴던 일에 이르는 과정에 대해 쓰는 것이 좋다.
  • Try
    • 도출된 problem의 원인을 파악하여 이를 기반으로 어떠한 시도들을 해볼 수 있는지에 대한 내용.
    • Try을 고려할 때 포인트는 구체적인 액션에까지 구체화 시키는 것이 중요

타임라인 리뷰

프로젝트 진행 기간 동안 이슈 사항 또는 사건들을 타임라인으로 표시하여 프로젝트를 되짚어보며 진행한다.
프로젝트 기간이 너무 길 경우, 주요 사건들에 대해 리뷰를 진행할 수 있다.

주요 사건을 5F로 공유하기

5F란 다음을 의미한다.

  • 사실(fact)
  • 느낌(Feeling)
  • 교훈(finding)
  • 향후 행동(Future action)
  • 피드백(Feedback)

즉, 프로젝트를 진행하면서 있었던 주요 사건들을 시간축으로 정렬해서 5가지 F로 나누어 돌아보는 방법이다.

So what?

위 내용들을 정리하자면 다음과 같이 진행할 수 있다.

  1. (타임라인 리뷰) 프로젝트의 처음 시점으로 돌아가서 진행된 프로젝트의 흐름을 따라가며 변곡점들에 어떤 일들이 일어났는지 살펴본다.
  2. 좋았던 부분, 아쉬웠던 부분 등을 정리한다.
  3. 내용을 토대로 Keep, Problem을 다시 정의하고 Try를 설정한다.
  4. Problem을 취합하여 문제가 발생한 원인을 파악하고 파악된 원인들을 어떻게 개선해나갈 수 있을지 브레인 스토밍을 진행한다. (Try 도출)
  5. 여기에 개인적인 바램이나 앞으로의 계획에 대한 부분을 추가하여 실현 가능성을 검토 후 계획에 추가한다.

JFYI

  • 불보듯 뻔한 회고는 안하느니만 못하다.
  • 당연한 얘기보다 내면에 있는 솔직한 이야기가 수면 위로 드러났을 때, 비로소 제대로 된 회고가 될 수 있다.
  • 진척 회의는 반드시 별도로 진행한다.

Reference

@JaeYeopHan JaeYeopHan added type: document Personal documents for: share For sharing issue labels Apr 18, 2018
@wlsgussla123
Copy link

👍

3 similar comments
@honux77
Copy link

honux77 commented Nov 11, 2019

👍

@devwon
Copy link

devwon commented Dec 4, 2019

👍

@CoodingPenguin
Copy link

👍

@minkj1992
Copy link

👍

2 similar comments
@jennybehan
Copy link

👍

@n0hack
Copy link

n0hack commented Sep 5, 2023

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: share For sharing issue type: document Personal documents
Projects
None yet
Development

No branches or pull requests

8 participants