돌아보지 않으면, 돌아버린다.
- 뱅크샐러드 PM은 이렇게 회고합니다: 진짜 문제를 찾는 법
(0/3) 그림의 떡이 되지 않으려면
소개할 포스트의 내용은 완벽하다. 그런데 배운 것을 적용한다고 생각하면 이런 생각이 들기 쉬울 것 같다.
"인민재판, 자아비판, 공개 처형의 장이 되겠구만"
좋은 팀이란 희귀한 것이다. 그렇기에 '좋은'이란 수식어가 붙는다.
그림의 떡이 되지 않으려면, 팀 관점을 놓치지 않고 개인을 비판/비난하는 자리가 되지 않으려면
'리더'의 역량이 가장 중요하다. 좋은 팀을 만들어가는 가장 큰 책임은 리더의 몫이다. 물론 모두의 몫이기도 하지만, 리더를 이길 수 있는 팀원은 없다.
이런것(회고) 안하던 회사에서 갑자기 한다고 생각해보자. 회사 내의 관계지형과 힘의 역학에 따라 얼마든지 '잘해보려고 한 시도'가 파국으로 이어지는 결과를 맞이할 수 있다.
힘이 센 사람은 책임전가하기 쉽다. 힘이 약한 사람이라고 책임전가, 회피 못한다는게 아니라 그 난이도를 말한다. 리더말고도 힘 센 사람이 책임전가하기 시작하면 힘약한 사람들은 책임회피밖에 할 게 없다. 그런 일이 일어나지 않도록, 분위기가 이상하게 흘러가지 않도록 리더가 개입해서 방향추를 잡아줘야 한다.
팀 관점이 정착될 때까지. 이게 '팀' 빌딩이다.
-
(0/3) 회고를 하는 근본 목적
같은 실수를 반복하지 않기 위하여. 개인의 힘으로 어쩔 수 없는 근본적인 문제를 찾아내 개선하기 위하여.
-
(1/3) 개인이 아닌 '팀' 차원에서 문제를 찾는다.
'왜 일정이 늦어졌는지' 회고하자고 했을때 예상되는 흔한 그림은 이렇다.
담당자: 담엔 더 보수적으로 일정을 잡아야겠어요. 제 불찰입니다. 앞으로는 밤을 새서라도 일정 지킬게요. 죄송합니다.
ㄴㄴ 이러면 안됨. '누구' 잘못인지, '누구' 때문에 일정이 늦어졌는지 찾아내고 정의하는 것은 회고가 아님. 그런 식의 회고를 하는 사람은 리더가 아닌거고 희생양을 찾는 사람일 뿐임. 최소한 '팀'을 빌딩할 생각은 없는 사람임.
-
(2/3) 스무고개는 좀 길고, 5why 방법론
왜?를 계속 던지며 양파 껍질 벗겨내듯 문제의 근원까지 내려가야 함.
ex)
문제발생: 일정이 늦어짐
왜?
> 정확한 일정 산정 실패,
왜?
> 회의 때 개발자 혼자였고, 다른 개발자 검토 못받음.
왜?
> 경험자 휴가 + 기획서만으로 스펙 산정하기 어려웠음.
왜?
> 기획서만으로 산정하기 어려웠던 이유=개발 스펙 문서 없음
왜?
> 회사 내 어떤 개발자도 개발스펙문서 작성해본 적 없음
표면적 문제: 개발 일정이 늦어짐
근원적 문제: 개발스펙문서가 없음
-
(3/3) 해결책 적용 후 평가
해결책은 개발스펙 문서를 작성하는 것이 될 것. 도출된 해결책이 유효했는지 평가하는 시간이 필요함.
적절했을 경우: 정기회고를 하는 팀이라면 알아서 좋은 사례로 이야기가 나올 것.
적절하지 않았을 경우: 정기회고 시간에 개선해나가면 됨.
정기회고를 하지 않는 팀이라면? 해결책이 유효했는지에 관한 회고를 하는 시간이 필요함. (회의를 위한 회의 느낌이 드니까 정기회고를 하는게 좋음)
-
(4) 읽다보니 개인 차원에 적용할 수도 있다는 생각이 들었다.
1. 회고한다. 지난 기간의 삶에 반복되고 있는 잘못된 점을 찾아낸다.
2. 문제를 유발하는 근본 원인을 분석한다.
3. 찾아낸 뿌리를 제거한다.
주기적으로 개인 회고의 시간을 갖는게 좋겠다. 나중에 말고 지금 바로 정한다. 매일의 일기 말고, 주중에 한 번이 좋겠다. 앞으로 매주 토요일 오전을 회고 시간으로 정한다.
-
*
링크를 누르면
결제하지 않고 (가입은 해야함)
전문을 보실 수 있습니다.
https://publy.co/content/5167?s=cb9bhm
