[성장노트] 조직이 회고를 해야하는 이유

 

 

 

 

---

 

 

 

나는 IT스타트업에서 백엔드 개발자로 일하고 있다.

우리 팀은 모두 재택근무를 하고, 오프라인 미팅은 월 1회 진행하고 있는데 그 미팅 때 스프린트 회고를 한다.

 

(* 스프린트 : 짧은 단위인 스프린트로 계획을 세우고 중요 순서 순으로 반복 실행 & 요구조건의 변화 즉각 반영하며 개선해나가는 업무 방식)

 

 

일 하기도 바쁜데 회고까지? 대체 무슨 내용을 회고하지?

 

 

누군가는 위 같은 생각을 할 수도 있겠다. 나도 처음에는 대체 이 회고 때 무슨 이야기를 하는거지? 라는 생각이 들었다.

일할 때 이런 저런 상황에 부딪혔을텐데 막상 기억이 안나서 내용을 준비 할때 조금 막막했다.

 

그럼에도, 곰곰히 생각하고 되돌아보면 정말 사소하더라도 내가 느낀 것들이 있었다.

 

예를 들어, 사용자에게 제공하는 신규 기능을 만드는 스프린트가 끝났다고 가정하자.

• 좋았던 점 : 즉각적으로 사용자 서비스 반응을 볼 수 있는 기능을 만들어서 '살아있는 서비스'는 이런 것이구나 라고 느꼈다.
• 아쉬운 점 : 조금 더 다양한 데이터 기반이었으면 좋겠다.
• 부족한 점 : 배포 후 모니터링, 이슈 대응 체계가 부족하다.

대략 이런 식이다. 내용은 가벼워도, 무거워도 좋다. 대체 어떤 것을 느꼈는지 고민하다보면 결국 나만의 회고 리스트가 나오게 된다.

팀원 별로 이러한 회고 내용을 공유하면 서로가 어떤 부분이 힘들었고 무엇을 느꼈는지 조금이나마 공감할 수 있게 된다.

 

첫번째, 결국 무언가 만들고 끝이 아니라 동료가 느끼고 생각한 것이 서로 공유된다는 점을 통해 조직의 결속력이 생긴다.

 

그리고 두번째, 즉각적인 피드백을 통해 팀원, 서비스 모두 발전한다.

회고하는 과정에서 서로 간의 피드백을 주고 받게 된다. 이 부분에서 아쉬웠다면 다음엔 어떻게 하면 좋을지 자연스럽게 액션 아이템이 도출된다. 그 상황에서 새로운 업무를 진행하게 되면 무의식 중에 내가 아쉬웠던 부분을 개선하게 된다.

 

나는 지난 회고 때 '개발 뿐만 아니라 기획, 디자인 부분도 전체적으로 볼 수 있는 눈을 키워야겠다.' 라는 회고를 했었다.

실제로 이후 작업에서 '사용자의 관점에서 디자인의 아쉬운 부분'을 솔직하게 공유 했고 다시 한번 의견을 수렴해볼 수 있었다.

당시에는 무의식적으로 했던 행동이었지만 돌이켜보면 지난 회고 때 느낀 게 있었기 때문에 조금 더 인지하고 있었지 않았나 싶다.

 

회고 -> 피드백 -> 액션 아이템 도출 -> 실 적용 -> 개선

 

결국 이러한 사이클이 만들어져서 팀원, 서비스 모두가 발전할 수 있는 계기가 된다.

 

모든 상황과 예를 회사, 조직으로 들었지만 개인의 회고도 다르지 않을 것이다.

회고는 사실 굉장히 귀찮은 일이다. 하지만 매우 중요한 일이다.

더 나은 방향으로 가고싶다면, 혹은 내가 가야할 길을 잃었다면 회고를 해보자.

 

거창하지 않아도 좋다. 아주 작은 것이라도 느낀 것을 공유해보자. 내일의 우리는 달라져있을 것이다.

 

 

조직이 회고를 해야하는 이유
1. 서로 생각과 느낀점을 공유하며 조직의 결속력이 생긴다.
2. 즉각적인 피드백을 통해 팀원, 서비스 모두 발전한다.