협업의 기술

협업의 기술
브라이언 피츠패트릭 & 벤 콜린스-서스먼 지음, 장현희 옮김 / 제이펍 / 2013년 5월

250페이지가 미처 되지 않아 두껍지도 않고 들고 다니면서 출퇴근 시간을 이용하여 읽었다.

직업을 가지고 일을 하다 보면 아무래도 협업에 자유로울 순 없다. 그런 고민의 연속 중에 이 책이 눈에 띄었고, 저자들의 경험과 지혜가 큰 귀감이 되어 글을 남긴다.

특히 안티패턴의 사례들은 내가 직접 겪은 패턴이라 큰 공감과 동시에 사람 사는 것은 비슷하구나라는 동질감마저 느껴졌다. 가장 보편적인 사례들이기에 따로 적진 않겠다. 그 대신 아래에 도움이 되길 바라며 책에 나온 좋은 글귀를 남겨 놓았다.

차분히 원인에 대해서 파악하고 지혜로운 방법으로 문제를 해결해나가는 모습이 프로그래밍과 맞닿아있음을 다시금 깨닫는 계기가 되었다.

그러려면 심적인 여유 즉, 책에서 말하는 선사가 되어라 처럼. 현재 상황의 번뇌를 벗어나서 현상에 대해 지켜볼 수 있는 심적 여유를 가져야 하겠지만 항상 쉽지가 않다.

내가 느끼는 이 책의 핵심은 두 가지다.

첫 번째.

HRT

Hurt가 아닌 Heart라고 발음하는데, 그 이유는 고통을 감소시키고 사람들을 해하지 않기 때문이다.  (p. 20)

• 겸손 Humility
  
• 존중 Respect
  
• 신뢰 Trust

다만 여기서는  소프트웨어 개발의 협업에 대한 이야기를 하기 위해 사용되었지만,

겸손 → 존중 → 신뢰로 이어지는 순차적인 흐름속에 신뢰가 쌓이는 상호작용에 대한 이야기다.

초반부는 자기계발 서적을 읽고 있는 듯한 착각에 빠질 정도다.

두 번째.

모든 배에는 선장이 필요하다.

다수와 논의를 하겠지만 거기서 타협점을 찾지 못한다면, 결국 리더의 결정이 필요한 순간이 온다.

그때는 그 리더의 결정을 존중해야 할 것이다.

아래는 책의 내용을 발췌한 부분이다.

p.10

숨긴다는 것은 해로운 것이다

p.11

좋은 아이디어를 숨기고 그것을 잘 갈고 닦을 때 까지 누구에게도 보여주지 않는다면, 당신은 큰 도박을 하는 셈이다.

그렇게 하면 초기부터 기본적인 디자인 결함을 지니기 쉽다. (중략) 또한, 협업 덕분에 얻을 수 있는 이점도 포기하는 것이다.

p.12 일찍 실패하고, 자주 실패하라.

이른 시점에서 공유하는 것은 단지 개인적인 실수를 미연에 방지하는 것 뿐만 아니라 당신의 아이디어를 미리 검토한다는 의미도 있다.

버스 팩터(Bus Factor): 프로젝트가 완전히 망할 때 까지 버스에 치어 죽는 사람의 수

P. 16

위험을 감수하고 실패를 두려워하지 말자.

당신이 1년간 단 한번도 실패한 적이 없다면 당신은 위험을 충분히 감수하지 않은 셈이다.

만일 업무를 수행하면서 위험을 감수하지 않는다면, 실패할 확률은 적어지겠지만 크게 성공할 가능성도 줄어든다.

좋은 관리자들은 그들이 할 수 있는 것과 할 수 없는 것을 보기 위해 (그리고 그 과정에서 많은 것을 배우기 위해) 한계를 초월할 의지가 있는 팀을 원한다.

이러한 관리자는 당신이 실패하면 그 책임을 가지고 누군가를 탓하지 않으며, 어떤 일이 있었고 같은 실패를 다시 경험하지 않기 위해서는 무엇을 해야 할지를 문서로 남긴다.

p. 31

잘 정리된 포스트모텀 문서는 다음과 같은 내용들을 포함하고 있어야 한다.

• 간단한 요약
  
• 현상의 발견부터 그에 관한 연구 및 조치 사항에 대한 시간순 서술
  
• 현상의 발생 원인
  
• 영향 및 피해에 대한 평가
  
• 문제를 즉각적으로 해결하기 위한 활동 내용
  
• 같은 문제의 재발 방지를 위한 활동 내용
  
• 배운 점
  

P. 134

• 명확한 사명을 가지고, 무엇이 당신의 목표이며, 어떤 것이 목표가 아닌지를 명확히 한다.
  
• 이메일 논의에 적합한 에티켓을 확립한다. 이를 보존하고, 새로운 구성원이 읽을 수 있도록 하며, 일부 시끄러운 소수에 의해 의사 결정이 방해받지 않도록 한다.
  
• 모든 기록을 문서로 만든다. 단순한 코드 변경 기록뿐만 아니라 디자인 결정, 중요한 버그 수정과 주요 실수 등을 모두 문서로 만든다.
  
• 효과적으로 협업한다. 버전 관리 시스템을 사용하여 코드 변경을 최소화하고, 리뷰가 가능한 상태로 유지하며, 소유욕을 예방하기 위해 '버스 팩터'를 확산시킨다.
  
• 버그의 수정 및 테스트, 소프트웨어의 릴리즈에 있어 명확한 정책과 절차를 수립한다.
  
• 새로운 구성원의 합류에 대한 진입 장벽을 간소화한다.
  
• 합의 기반의 의사 결정을 바탕으로 하되, 합의에 이르지 못했을 때의 충동을 해결하기 위한 프로세스를 확립한다.
  

P. 153

무지함으로 충분히 설명될 수 있는 일을 악의의 탓으로 돌리지 마라.

P. 195

소프트웨어를 사용하는 사용자에게 인정받아야 한다는 말을 하고 싶은 것이다.

많은 프로그래머가 여기에서 멈춘다. 그들은 스스로 소프트웨어를 작성하고, 그 결과에 기뻐하며 승리를 선언한다.

당신이 개발한 소프트웨어는 많은 사람이 사용하고 또 즐거워하는 것이어야 한다. (중략)

사람들은 당신이 작성한 소프트웨어를 사용하며, 당신은 그들의 요구를 수렴해야 하며, 계속해서 제품을 발전시켜야 한다.

당신은 고객과 피드백을 다루는 방법을 배워한다.

p. 232

(중략) 우리가 소프트웨어를 작성하고 있는 이유를 쉽게 잊게 하곤 한다.

소프트웨어를 만드는 이유는 당신 본인을 위한 것도, 당신의 팀이나 회사를 위한 것도 아니며, 오로지 사용자들의 삼을 더욱 풍성하게 만들기 위한 것이다.

따라서 그들이 무슨 생각을 하며, 당신의 제품에 대해 어떤 말을 하는지, 그리고 시간이 지나면서 어떤 경험들을 하고 있는지를 주의깊게 살펴보아야 한다.

사용자는 소프트웨어 성공을 위한 생명선이다. 결국, 당신이 뿌린 대로 거두게 될 것이다.