프로젝트가 서쪽으로 간 까닭은

1

책 제목이 조금 난감하고, 책표지를 보고 있노라면 이 프로젝트는 그 프로젝트가 아닌가 싶은 고민을 하게 된다. 그럼에도 불구하고 필진의 이름 중에서 ‘톰 드마르코’를 보고나면 아니 구매할 수 없다. 심지어 역자는 ‘이해영’님이다. 표지에 적혀진 몇 글자로 판단하건데 ‘좋은 책’일 확률이 높다. 결론적으로 ‘매우 좋은 책’이다.

2

경험을 나누는 책은 상대방의 경험이 중요한 것이 아니라 나의 경험이 중요하다. 나의 경험과 상대방의 경험 사이에 놓여진 접점의 크기가 커질수록 경험을 나누는 책은 지식이 아니라 마음에 놓이고, 마침내 깨달음으로 달려간다.

만약, 나처럼 애매한 개발자라면 권하고 싶다. 특히 스타트업에 몸담고 있는 개발자라면 꼭 권하고 싶다. 실패 혹은 망한 이유를 이토록 친절하게 설명하고 있는 책이라면 읽을 필요가 있다. 스티븐 잡스의 성공을 ‘extend’ 할 순 없지만 실패한 모든 이들이 했던 삽질에 관한 내용은 언제나 우리의 ‘Object’이기 때문이다.


  1. 이 책을 집필하면서 아키텍트이자 철학자인 크리스토퍼 알레산더와 그가 쓴 ‘A Pattern Language’로 부터 많은 도움을 받았다.

  2. 다음은 아드레날린 중독증에 걸린 조직이 보이는 특성이다. 아마 익숙하리라. 1) 우선순위가 계속 변한다. 2) 어제까지 모든 결과물이 나왔어야 했다. 3) 시간이 언제나 부족하다 4) 모든 프로젝트가 긴급하다. 5) 긴급한 프로젝트가 계속 쏟아진다. 6) 모두가 언제나 미친 듯이 바쁘다.

  3. […] 즉 안정성과 계획성이 필수인 제품을 내놓지 못한다.

  4. […] 매번 완벽한 결정을 내려야 한다는 부담이 없으면서도 대개 올바른 결정을 내리리라는 자신이 넘치므로 팀은 민첩하게 결정하고 행동한다.

  5. 증명하십시오. 성공할 가능성이 ‘0’이라는 사실을 보여주십시오. […] 실패가 불가피하다는 사실을 수학적으로 확실히 증명해 보시오. […] “불편분자입니까? 아니면 게으름뱅이입니까? 입장을 분명히 하세요. 어느쪽이든 우리처럼 멋진 조직에 오래 몸 담기는 어렵겠습니다.”

  6. 직원들 의견에는 관심이 없고 칭찬만 바란다는 느낌이 든다면 그 회의가 무슨 회의인지 알리라. 자, 박수 준비하시라.

  7. […] 하지만 진짜 원인, 즉 진짜 문제를 찾으려는 노력은 틀림없이 몇 배나 남는 장사다.

  8. […] 프로젝트 초반 시간을 프로젝트 후반 시간보다 덜 귀중하게 여긴다는 사실을, 그리고 앞으로 나가는 최선의 방법은 막연한 내일로의 전진이 아니라 오늘의 전진이라는 사실을 안다.

  9. […] 여기서 요지는 업무를 분산하는 이유가 단순히 돈과 가용인력이어서는 안 된다는 소리다. 구하기 어려운 능력과 기술이 이유여야 한다.

  10. “프로젝트마다 다른 방법론이 필요하다”

  11. […] 대다수 개발 프로젝트에서는 시간이 돈보다 더 귀한 자원이다.

  12. […] 소수 정예 팀 운영은 소프트웨어를 개발하는 최선의 방법이다.

  13. […] 대면 접촉은 필수 요소다.

  14. […] 필사적인 심정으로 도구를 구매한다. 그래서 도구 사용자가 적절한 기술을 갖추어야 한다는 사실을 간과한다. “ 도구 ‘사용’ 비용은 도구 ‘구입’ 비용보다 훨씬 더 비싸다.”

  15. 대시보드는 리더십을 개선하지 않는다. 오히려 리더십을 폭로한다.

  16. 끝없는 장애물 패턴은 사람들이 “동의하지 않는 결정은 안 지켜도 괜찮다”고 하는 믿음에서 기인한다. 팀이 내린 결정을 인정하고 준수하는 윤리를 세울 책임은 관리자에게 있다.

  17. 조직이 진짜 노땅 조직으로 변하는 이유는 세 가지다. 1) 조직이 성장하지 않는다. […] 2) 조직이 경력자만 뽑는다. […] 3) 조직이 철저히 안전만 추구한다 […]

  18. […] 자신이 지적한 결함을 어떻게 고치자는 건설적인 아이디어를 내놓기는 커녕 잘못되었다는 사실만 거듭 언급한다.

  19. […] 즉, 업무가 무엇인지 모두가 똑같이 이해하도록 업무를 정의하라는 소리다.

  20. […] 요구사항 못지 않게 비기능적인 요구사항도 중요하다.

  21. […] 인터페이스를 빠짐없이 정의하면 프로젝트 범위가 명확히 드러난다. 모호함은 더 이상 존재하지 않는다. 시스템 둘레에 흰 선을 그었으니까.

  22. […] ‘누가 언젠까지 무엇을 약속했다’ 정도로만 기록한다. 그런 다음 목록을 모두에게 공개하면 약속한 사람은 개인적인 요청보다 공개적인 약속을 우선으로 여기기 마련이다. 그러므로 ‘침묵은 동의’라는 규칙이 사라지고 ‘동의만 동의’ 라는 규칙이 세워진다.

  23. […] 인간은 천성적으로 개선에 탁월하다. 소수만이 무에서 유를 창조하는 재능을 타고난다.

  24. 생명 주기 초반에 관리자가 내리는 결정은 어떤 결정보다도 프로젝트에 커다란 영향을 미친다.

  25. 기록은 대화가 보존하지 못하는 기억을 보존한다. 결정을 기록하면 결정에 참여하지 않았던 사람과 결정에 참여했으나 구체적인 내용을 잊어버린 사람에게도 결정과정을 전달할 수 있다.

  26. 개방도 지나치면 해가 된다. […] “정보 과잉은 주의 결핍을 초래한다.”

  27. “관리는 남이 친 홈런으로 월급 받는 직업이다.”

  28. 문제를 세세히 이해하지 못하는 프로젝트 초반에는 막 바로 구현해도 괜찮을 수준으로 인터페이스를 정의하기 어렵다. 때로는 까다로운 부분을 놓쳤다는 사실조차 깨닫지 못한다. 그렇다고 인터페이스 정의를 빼먹고 넘어가면 안 된다. 현재 알고 있는 지식으로 최선을 다해 정의한다.

  29. […] “저기요, 이 성능 테스트는 언제부터 수행할 계획이죠?”라는 질문을 촉발한다면 충분한 가치가 있다.

  30. 충돌이 자연스럽고 아주 전문가다운 현산이라 여길 때라야 관련자들이 ‘의사소통 개선’이라는 미신에 매달리지 않고 증명된 ‘충돌 해결 기법’으로 관심을 돌린다. 후자가 충돌을 완벽하게 해소한다는 보장이 없지만 언제나 전자보다 낫다.

  31. […] 그리고 프로젝트에 필요하지 않다면, 만들지 않아야 맞다. 좋은 아이디어가 있으나 값을 치르려는 사람이 없다면 후원자를 찾아라.

  32. […] 그들은 새로운 아이디어를 계속해서 제안하는 능력으로 명성을 얻었다.

  33. 프로젝트 이해관계자들이 말로는 지원을 약속했으나 실제는 기능을 계속 추가해 프로젝트를 망친다.

Written on May 9, 2015