HARD CODE (에릭 브레히너, 2009) 독후감
마이크로 소프트(MS)가 어떻게 프로젝트, 사람을 관리하는지 살짝 엿볼 수 있는 책이다. 어떤 책인고 하니 MS에서 개발 혁신 부서장을 맡은 에릭 브레히너가 사내 웹진에 올린 글들을 묶어 놓은 책이다. 이 사람도 미지근하게 글을 안 쓴다. 한 마디로 깔건 확실하게 까는 스타일이지.
MS가 앞서 있는 건 분명하지만, 우리와 크게 다르지 않구나. 규모가 더 커서 우리와 다른 고민을 하기도 하지만 우리와 똑같은 고민을 하는 게 대부분이었다. 프로젝트, 사람 관리에 대한 고민과 해결은 얼핏 보면 별로 차이가 안 나지만 아주 조금씩 전진하는 밀리미터 싸움인지도 모르겠다. 15년 전에 나왔지만, 현재 상황과 차이가 별로 없는 소프트웨어 컨플릭트 2.0 처럼 15년 후에 이 책을 보고서 “에잉? 15년 전이야? 별로 달라진 게 없네”라고 말하는 상황이 될까 봐 살짝 걱정이 되기도 한다.
재미있었거나 곱씹어 봐야 할 내용을 정리해본다면
- 기본적으로 일정 예측에 리히터 척도(Richter scale)를 사용. 예측이 조금 빗나가는 것은 신경 쓰지 않는다. 대신 중간목표 점검일로 긴장감을 심어주고 보통 재미없는 ’반드시 출시할’ 기능 목록을 반드시 밝혀서 이 기능을 완료했을 때, 개발자에게 재미있는 일을 할 수 있게 했다. 이렇게 동기 부여.
- 합의가 어렵고 사적인 감정이 개입돼서 만장일치가 무리인 모임에선 반대자가 없으면 통과하는 ’퀘이커’식 합의를 사용.
- 회의. “왜 모였죠?” “목적이 뭐죠?” “저 사람들은 왜 참석했죠?” “왜 이제서야 말하죠?” “다음 단계는 뭐죠?”
- 명세서는 그만 쓰고 기능팀을 한곳으로 모으자. PM이 기능팀과 같은 공간에 온종일 같이 있어준다면 명세서가 필요한가?
- 명세서의 요구 사항은 테스트할 수 있는 항목이어야 한다. 테스트할 수 없다면 잘못 쓴 것이니 테스트할 수 있도록 다시 작성.
- 테스터는 개발자가 온 힘을 다해도 놓치는 문제를 잡아내 고객을 보호하는 사람
- 코드 검토는 목적이 명확해야 한다. ’아이디어와 해결책 찾아내기’ ’진행 중인 작업에 대한 피드백 받기’ ’완료한 작업의 품질을 진단하고 문제 찾아내기’
- jpg 파일을 복사해서 붙였을 때와 마우스로 끌어다 떨어뜨렸을 때 동작이 다르다. 크, 마소도 이렇구나. DRY(Don’t Repeat Yourself)는 진리. 여러 명이 개발하다 보면 예상하지도 못하게 발생할 수 있지만 이런 건 모두가 병적으로 싫어하고 장인 정신을 가져야지만 극복할 수 있다.
- 독립성을 제공할 정도로만 하향식 설계. 협력과 품질을 최적화할 정도로만 상향식 설계.
- 눈에 띄고 좋은 평가를 받는 기능을 구현하는지는 개발자 스스로의 책임. 고객과 비즈니스를 아는 수완 좋은 개발자 몫. 스스로 어떻게 하느냐에 달림
- 아무리 좋은 아이디어를 낸다고 해도 이해하고 인정하려면 시간이 걸린다. 게다가 아이디어도 쏟아지기 때문에 인맥이 없다면 다른 아이디어에 우선순위가 밀린다. 내 아이디어를 인정받으려면 내 아이디어를 인정할 사람들과 관계를 맺어야 한다.
- 협상이 끝나면 이긴 팀으로 모두를 포용. “이게 바로 우리가 만든 멋진 설계입니다.”
- 의외다. 두 가지 프로젝트에 전념할 때 생산성이 최고라니…
- 정직과 개방이 좋은 덕목이긴 하지만 나쁜 결과를 가져올 수 있다. 성실과 투명성이 추구해야 할 목표
- 왜? –> 답변 –> 왜? –> … 왜?로 시작해서 계속 왜?로 물어보면 진짜 속내를 알 수 있다.
- “XXX보단 제가 낫지 않습니까?” 이렇게 물어본다면 사람이 아니라 행동을 비교해서 설명하자
Update 표지 사진 교체
