구글 엔지니어는 이렇게 일한다: 팀워크
in BOOK on 구글 엔지니어는 이렇게 일한다, Teamwork, Postmortem
1. 천재 신화
천재든 아니든 사회성이 부족한 사람은 팀원으로 적합하지 않다.
우리의 경력을 미래로 이어주는 핵심은 다른 사람과 얼마나 잘 협력하는냐 이다.
2. 숨기는 건 해롭다.
아이디어를 숨기고 완벽해질때까지 숨기는 것은 위험하다.
초기 설계에는 근본적인 실수가 스며있기 쉬우며, 협업이 주는 이점도 얻지 못한다.
우리가 올바른 일은 하고 있는지, 이미 다른 누군가가 해놓은 일을 하는 건 아닌지 확인해보아야 한다.
피드백을 조기에 받을 수록 이런 위험을 크게 줄어든다.
‘홀로 일하기’ 는 ‘함께 일하기’ 보다 본질적으로 더 위험하다.
다른 사람이 아이디어를 훔친다거나 본인이 똑똑하지 않다고 생각하는게 두려워도 잘못된 일에 천금 같은 시간을 낭비할 가능성을 더 걱정해야 한다.
3. 모든 건 팀에 달렸다.
<협업의 기본>
- 겸손(humility)
- 당신은 우주의 중심이 아니다. 겸손한 사람은 배움에 열려있다.
- 존중(respect)
- 동료를 친절하게 대하고 그들의 능력과 성취에 감사해한다.
- 신뢰(trust)
- 필요하면 동료들에게 스스로 방향을 정하게 한다.
사회적 관계의 힘을 과소평가하면 안된다.
사람을 속이거나 뒤에서 조정하는게 아니라 일이 진행되도록 관계를 형성해야 한다.
4. 겸손, 존중, 신뢰 실천
4.1. 자존심 버리기
회의실에서 가장 중요한 인물인 것처럼 행동하는 사람과 함께 일하기를 좋아하는 사람은 없다.
겸손은 중요하지만 바짝 엎드리라는 의미가 아니라, 그저 모든 걸 다 아는 듯 행동하지 말아야 한다.
본인의 자신감보다는 ‘집단적 자존심’ 을 높이는 것이 좋다.
자신이 잘 아는 분야에 대해 걱정하는 대신 팀의 성취와 단체의 자부심을 높이는 것이 좋다.
4.2. 비평하고, 비평받는 법
건설적으로 비판하는 사람은 상대방을 진심으로 생각하고, 상대방의 업무가 개선되길 바란다.
누군가를 진심으로 존중한다면 자연스럽게 재치있고 도움되는 표현을 고르려 신경쓰게 될 것이다.
예를 들어 ‘이 메서드의 제어 흐름을 완전히 잘못됐어요. 다른 사람들처럼 xxx 패턴을 적용했어요.’ 라는 피드백은 해선 안될 행동이 가득하다.
세상은 흑 아니면 백이 아니듯 누군가에세 ‘잘못 했다’라고 해서는 안된다.
무언가를 ‘고치라고 요구’해서도 안된다.
또한 바로같은 기분이 들도록 ‘다른 사람들과 다르게 했다고 비난’해서도 안된다.
대신 ‘이 메서드의 제어 흐름이 좀 헷갈립니다. 혹시 xxx 패턴을 적용하면 좀 더 명확해질까요? 나중에 관리하기 쉬워질수도 있겠네요.’ 라고 해보자.
상대가 아닌 자신을 겸손하게 낮추었음에 주목하자. 상대가 틀린 게 아니라 내가 코드를 이해하는데 문제를 겪고 있는 것이다.
이런 피드백은 프로젝트의 장기 지속 가능성이라는 목표에 보탬이 될 뿐더러 나처럼 한 번에 이해하지 못한 다른 이들을 위해 로직을 더 명확하게 정돈하는 방법을 제시하였다.
아무것도 요구하지 않고 동료가 제안을 거부해도 부담을 느끼지 않도록 배려하였다.
4.3. 빠르게 실패하기
‘가끔씩 실패하지 않는다면 충분히 혁신적이거나 위험을 충분히 감수하지 않은 것이다’ 라는 말이 있다.
실패를 ‘배우고 다음 단계로 넘어갈 수 있는 절호의 기회’라고 생각하는 것이다.
같은 이유로 동일한 일은 반복해서 실패(= 다음 단계로 넘어가지 못함)한다면 이것은 실패한 것이 아니라 무능한 것이다.
4.4. 비난없는 포스트모템(postmortem) 문화
실패한 근본 원인을 분석하여 문서로 남기는 것은 실수로부터 배우는 핵심이며 이를 포스트모템(postmortem)이라고 한다.
포스트모템은 프로젝트를 마친 뒤 전 과정을 되돌아보며 잘된 점과 잘못된 점을 되돌아보는 사후 검토 작업을 말한다.
포스트모템 문서가 사죄, 변명, 지적으로 채워지지 않도록 해야 한다.
포스트모템에는 무엇을 배웠는지와 배운 것을 토대로 앞으로 무엇을 바꿀지가 담겨야 한다.
훌륭한 포스트모템에는 아래 내용이 담겨야 한다.
- 사건의 개요
- 사건을 인지하고 해결에 이르기까지의 타임 라인
- 사건의 근본 원인
- 영향과 피해 평가
- 문제를 즉시 해결하기 위한 조치 항목(소유자 명시)
- 재발 방지를 위한 조치 할목
- 해당 경험에서 얻은 교훈
4.4.1. 인내심
페어 프로그래밍을 하는 두 사람이 있다.
한 사람은 먼지 구덩이에 뛰어들어 많은 것을 빠르게 시도해보고 세부사항은 넘기면서 길을 찾는 상향식 엔지니어이고, 한 사람은 먼저 전체를 파악하고 필요한 거의 모든 메서드를 구현한 뒤에야 버그를 찾는 하향식 엔지니어이다.
이 차이로 인해 페어 프로그래밍을 할 때 의견 충돌이 생길 수 있다.
이 때 새로운 협업 방식으로 의견 충돌을 해소할 수 있다.
함께 버그를 확인한 후 각자의 자리로 돌아가 각자의 방식으로 문제를 해결한 후 알아낸 사실을 가지고 다시 모이는 것이다.
4.4.2. 마음을 열고 받아들이기
타인으로부터 배우는 데 열려 있을수록 나의 영향력도 커진다.
아무리 설득해도 고집을 굽히지 않는 사람이 껴 있는 팀을 생각해보자.
경험상 고집불통 팀원의 의견이나 반대에는 더 이상 귀를 기울이지 않고, 대신 공인된 장애물 취급하며 피해다니게 된다.
이런 사람이 되지 않기 위해서 ‘다른 사람이 나의 생각을 바꿔도 괜찮아’ 라는 생각을 항상 머릿속에 담아두길 바란다.
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 구글 엔지니어는 이렇게 일한다 를 읽으며 정리한 내용들입니다.
