VLSI Wiki

IT기업의 Lessons Learned: Retrospect이란? Post mortem이란?

​

회사에서 Lessons Learned는 두가지로 나뉩니다.

1. Retrospect, 성공회고록

2. Postmortem, 사후부검

​

반도체 설계회사에서는 Project 완료. 즉, Mask tape out(MTO) 후, 축하 파티 하기 직전에 했던 것을 리뷰합니다.

어떤 Project도 순항하는 Project는 없을 것이라고 생각합니다. 오래된 기술의 Project들은 가격과 인력에 대한 압박이 있을 것이고, 최신 기술의 Project들은 처음 만나는 기술적 과제들이 존재하게 됩니다. 스타트업은 일을 한 사람이 넓은 영역을 처리해야하고, 대기업은 전세계의 모든 케이스에서도 사용 가능하도록 세부 사항들을 완벽하게 만들어야 합니다.

​

Retrospect란?

같이 일하면서 내가 이렇게 했더니 이거 꽤 어려워보였는데 성공적으로 되었다!, 옆 팀에서 이번에 이렇게 해주니까 이번에 우리팀이 너무 편했다!, 이거 내가 자동화 했어! 이런 이야기입니다. 그래서, “우리 이렇게 해서 꽤 좋았어, 너네 팀이 이렇게 해주니까 우리팀이 너무 편하더라. 이것보다 더 좋은 방법 있을까?” 이런 논의를 모든 팀원들과 하는 것입니다.

​

Post mortem란?

누군가 만든 사고에 대해, 발생한 원인부터 재발방지책까지 모아서 다음에 같은 사고가 생기지 않게 하자는 의미입니다. 이 사고 문서에 이름이 올라간다고 해서 직접적인 불이익이 생기는 건 아니었지만, 조심스러운 것은 사실입니다.

한국어로는 “사후 부검”입니다. 엔지니어링에서 사후 부검은, 프로젝트의 일부가 망가졌는데, 이것에 대해 다같이 부검을 하는 것이죠.

​

누가 책임 질거야? 이런게 아니라…

이거 다음에 이런 이슈가 절대 발생 안 되려면 어떻게 해야할까? 이런걸 보는거죠.

국과수 부검실한국 정서로는 시말서, 경위서에 더 가까워 보이지만, 미국 회사에서는, 책임자에게 책임을 묻는 회의가 아닙니다. 만약 실수한 사람 또는 문제의 책임자에게 비난의 화살이 돌아간다면, 아무도 자신의 잘못을 위로 보고하지 않을 것입니다. 여기서 대충 그 팀 안에서 재발 방지책을 정의하고 끝낸다면, 이 스노우볼이 굴러 회사의 존립 자체를 결정하게 될 수도 있습니다.

​

그래서 Postmorterm이 좀 더 중요하다고 말할 수 있겠습니다. “문제 정의 -> 원인 분석 -> 왜 일어났는가.. -> 근본 원인 분석 -> 개선책 도출 -> 문서화 및 전사 공유”을 위해, Blameless Retrospectives, 5 Whys, Fishbone Diagram 등을 이 회의에서 주로 사용합니다.

​

이런 문서화들은 당연히 역사가 긴 IT 대기업에서 잘 되어있습니다.

Google 출신의 교수님과 최근에 티타임을 가졌는데, 회사근무시간 9to5 절반은 “이러한 회의 + 문서화”에 대해 쓴다고 하더군요. 지구상의 모든 소프트웨어이슈는 대부분은 구글 문서내에 다 있을 것이라고 :)

같이 나누고싶은 이야기들을 블로그에 한 번 써보려고 합니다!

해시태그 :