예쁜 보고서가 팀을 망치는 순간
작게 시작하는 전환: 예쁜 보고서에서 ‘로그 중심’으로
1. Fail Up System이 제안하는 대안 보고서 대신 ‘로그’를 남기자
그래서 저는 Fail Up System(FUS) 안에서
이렇게 기준을 바꿔 보자고 제안합니다.
“예쁜 보고서” 대신
“정직한 로그”를 남기는 조직·개인으로.
여기서 말하는 로그(Log)는,
잘한 것뿐만 아니라
망한 실험, 틀린 가설, 어색했던 순간, 숨기고 싶은 선택까지
함께 기록하는 날것의 데이터입니다.
그리고 이 로그의 질을 보기 위해
FUS에서는 이런 지표들을 씁니다.
RI (Recovery Index) 실패 후 다시 시도하기까지 걸린 시간
LV (Loop Velocity) 일정 기간 동안 내가 돌린 실험 루프의 수
LCR (Loop Consistency Rate) 계획했던 실험 중 실제로 끝까지 돌린 비율
이 지표들은
“우리가 얼마나 자주, 얼마나 꾸준히 배우고 있는지”를 보여줍니다.
성과가 결과를 평가하는 숫자라면,
이 지표들은 학습의 속도와 루프의 밀도를 보여주는 숫자에 가깝습니다.
2. 예쁜 보고서에서 ‘로그 중심’으로 옮겨가는 작은 실험들
한 번에 문화 전체를 바꾸기는 어렵습니다.
그래서, 지금 당장 해볼 수 있는 아주 작은 실험 두 가지를 제안해볼게요.
실험 1. 보고서에 ‘이건 실패였습니다’ 박스를 하나 넣기
다음 보고서를 쓸 때,
슬라이드 한 장만 이렇게 써보는 겁니다.
[이번 프로젝트에서 실패라고 느끼는 지점]
우리가 잘못 세운 가설 1개
다시 돌아가면 바꾸고 싶은 의사결정 1개
다음에는 절대 똑같이 하지 않을 선택 1개
여기에는 변명 대신,
“내가 인정하는 실패”만 담습니다.
이 한 슬라이드 덕분에
팀원들이 서로의 솔직한 시각을 확인할 수 있고
다음 프로젝트에서 가장 먼저 수정해야 할 지점을
훨씬 빠르게 합의할 수 있습니다.
실험 2. 결과 슬라이드보다 ‘과정 로그’ 슬라이드를 1장 더 만들기
보통은 이렇게 끝나죠.
프로젝트 개요
실행 내용
성과 지표
향후 계획
여기에 한 장만 더 추가해 봅니다.
[과정에서 남기고 싶은 로그]
예상보다 힘들었던 지점
뜻밖에 수월 했던 지점
중간에 바뀐 가설/전략
팀 안에서 나온 중요한 대화 한 줄
이건 상사를 설득하기 위한 슬라이드가 아니라,
다음 루프를 위한 메모에 가깝습니다.
이 슬라이드가 쌓이면,
조직의 “집단 로그 데이터베이스”가 생깁니다.
나중에 누군가 비슷한 프로젝트를 할 때
이 예쁜 로그들이 실제 생존 가이드가 되어 줄 겁니다.
3. 마무리 – 예쁜 보고서 대신, 정직한 로그를 남기는 사람으로
예쁜 보고서 이론은
“보고서를 예쁘게 만들지 말자”는 이야기가 아닙니다.
우리가 바꾸고 싶은 건,
“우리는 무엇을 위해 보고서를 쓰고 있는가?”
라는 질문에 대한 답입니다.
상사를 안심시키기 위해서만 쓴다면
보고서는 계속 예뻐질 겁니다.
하지만 나와 팀의 학습을 위해 쓴다면
보고서는 조금 덜 예뻐지는 대신
훨씬 더 살아 있는 기록이 될 겁니다.
실패는 낙인이 아닙니다.
로그로 남길 수 있다면, 곧 데이터가 됩니다.
그리고 그 데이터를 바탕으로
RI, LV, LCR 같은 루프 지표를 조금씩 올려갈 때,
결국 성과도 따라오게 됩니다.
이제, 보고서를 쓸 때 한 번쯤 이렇게 물어보면 좋겠습니다.
“이 문장은 나를 방어하기 위한 문장인가,
다음 사람을 돕기 위한 문장인가?”
예쁜 보고서가 아니라
다음 사람의 실수를 한 번 덜어주는 정직한 로그를 남기는 것.
그게 Fail Up System이 꿈꾸는 보고 문화입니다.
