[Book] 마음을 움직이는 프로젝트 관리 - 스콧 버쿤

제목 - 마음을 움직이는 프로젝트 관리(The Art of Project Management)
저자 - 스콧 버쿤
출판 - 한빛미디어
분량 - 496P
ISBN- 8979144091

한 마디로 정말 좋은 책이다. 저자의 엄청난 노력을 가슴깊이 느낄 수 있다. 마치 교과서처럼 밑줄을 그으면서 읽어가고 싶을 정도의 내공이 느껴지는 책이다. 물론, 이 책에서 언급된 것처럼 우리가 수행하는 프로젝트들을 모두 세세하게 관리할 수는 없다. 다만, 기술된 내용들 하나하나를 조금씩 조금씩 적용해볼 수는 있을 것 같다.

사실, 나도 이번에 수행한 프로젝트를 진행할 때 단계별로, 책을 참조하면서 해보겠다는 의지로 읽어갔다. 물론, 곧이곧대로 적용하겠다는 것은 아니었기는 하지만.. 그래서 사무실 책상 위에 올려놓고, 짬날때마다 조금씩 읽었더니, 벌써 5개월이 걸렸다.. 하하..

하지만, 매우 좋은 그리고 다시 읽어볼만한 책이었다는 점, 실제 프로젝트에 참여하는 실무자, PM의 입장에서 현장의 감각을 느낄 수 있는 내용들로 구성되어 있다는 점들이 감동적이다.

그간 요약한 내용으로 마무리한다.

===

The Art of Project Management (마음을 움직이는 프로젝트 관리)

- 스콧 버쿤 -

서문(Preface)

Microsoft Engineering Excellence Group - 소프트웨어를 개발하는 데 있어 사용하는 방법론을 강화하기 위한 임무를 맡은 그룹, 사람, 프로세스, 도구에 초점을 맞춰 규범적이며 권위있는 기본 가이드라인을 제공하는 책임을 짐

1. 프로젝트 관리의 간추린 역사 - 프로젝트 관리가 중요한 이유

• 여러 사람의 작업을 모아서 사람들 혹은 고객에게 유용한 무언가를 창조해내는 것
• 프로젝트 관리와 소프트웨어 개발은 신성한 예술이 아니다.
• 시각을 단순화할수록 집중력과 성취도가 높아진다.
• 단순함이 쉬움을 뜻하지는 않는다.
• 프로젝트 관리 활동 - 프로젝트를 파악하고, 팀을 이끌어서, 설계와 개발 과정을 돌보고, 프로젝트를 완료로 이끄는 활동
• 마케팀/비즈니스 부서 <=> 엔지니어링 부서 사이의 조율 담당자 필요 = 프로그램 관리자 (from MS)
• 프로그램 관리자의 역할 - 명세서 작성, 마케팅 계획서 검토, 프로젝트 일정 수립, 팀 관리 , 전략적 계획 수립, 버그/결함 선별, 팀 동기 고취 등을 수행하는 사람
• 프로젝트 관리자는 균형 잡힌 사고를 유지해야 합니다.
• 프로젝트 관리자는 프로세스와 방법론보다 팀에 신경을 써야 합니다.
• 프로젝트 관리자가 프로젝트를 대하는 태도는 팀원 전부에게 전염됩니다.
• 프로젝트 관리 - 필요한 모든 수단을 사용하여 긍정적인 결과를 도출할 가능성과 속력을 높이는 일

2. 일정에 관한 진실

• 일정을 수립하는 방법 - 3등분하라 (설계 -> 구현 -> 검증), 각 부분을 생략하지 말라
• 좋은 예측은 믿을만한 설계와 믿을만한 요구사항에서만 나올 수 있다.
• 일정을 맞추는 방법
  • 중간목표 기간은 프로젝트 변동성과 조화를 이뤄야 합니다. (변경 가능성이 높을수록 중간목표 기간을 짧게 잡아야 한다. 일정검토 간격을 짧게)
  • 비전은 낙관적으로, 일정은 회의적으로 바라봅니다.
  • 설계에 승부를 걸어라.
  • 작업을 추가하거나 추려낼 점검지점을 계획하십시오.
  • 팀에게 계획수립의 근본원리를 알리십시오.
  • 해결하려는 문제와 팀 경험을 가늠하십시오.
  • 팀이 함께 일하면서 쌓은 경험과 자신감을 가늠하십시오.
  • 위험은 초반에 잡습니다.

3. 할 일을 파악하는 법

• 모든 프로젝트 참여자가 알고 있어야 하는 것
  
  • 요구사항 결정 권한은 누구에게 있습니까 ?
  • 설계 권한은 누구에게 있습니까 ?
  • 기술 권한은 누구에게 있습니까 ?
  • 예산 권한은 누구에게 있습니까 ?
  • 요구사항과 설계는 얼마나 자주 검토하며 어떻게 조정합니까 ? (동기화 작업)
• 계획을 보는 세가지 관점 = 비즈니스 관점 + 기술 관점 + 고객 관점

4. 좋은 비전 작성하기

• 올바른 방향을 잡는 일뿐만 아니라, 올바른 방향을 유지하는 일도 매우 중요함
• 비전 - Vision Statement, 전체 프로젝트의 상위 단계 목표를 정의
• 팀 목표 - 특정 팀이 책임지는 비전의 일부 (비전보다 상세화)
• 개인 목표 - 팀 목표 중에서 개개인이 책임지는 목표
• 좋은 비전이 가지는 5가지 특징
  • 단순화, 의도적(목표지향적), 통합적, 고무적, 인상적
• SMART - 목표설정 기법
  
  • 구체적 - Specific, 무슨 일을 해낼 것인지 정확하게 표현
  • 측정가능 - Measurable, 확실한 사건과 날짜
  • 행동지향적 - Action-oriented, 해야할 일들을 확정
  • 현실적 - Realistic, 주어진 여건에 상관없이 이루어 낼 수 있는 목표
  • 적시성 - Timely, 허용된 시간이 합리적이고 너무 길지 않음
• 프로젝트를 발주하는 이유는 기술문제만이 아니라, 현실문제를 해결하기 위해서임을 이해해야 한다.

5. 아이디어 내기

• 요구사항 정의시 주의사항
  • 요구사항을 협상하고 반복할 계획을 제시하십시오
  • 잘못된 가정을 찾아 제거하십시오
    
    • 왜 이 기능이 필요합니까 ?
    • 이 기능이 어떤 문제를 해결합니까 ?
    • 이 기능은 누구의 요구사항입니까 ?
  • 누락된 정보를 찾아 보충하십시오
  • 각 요구사항에 상대적인 우선순위를 매기십시오
  • 모호한 표현을 고치거나 없애십시오
  • 설계와 요구사항 사이에는 피드백 순환이 있어야 한다
  • 좋은 질문을 던져야 좋은 아이디어가 나온다
  • 좋은 아이디어에서 좋은 설계가 나온다.
    • 건축에서 가장 중요한 도구 두 개는 도면실의 지우개와 건설 현장의 큰 쇠망치이다. - 프랭크 로이드 라이트
    • 물리학자의 최고 도구는 휴지통이다. - 알버트 아인슈타인
    • 작품 다섯 편을 그리는 때도 있다. 그러나 스무 편 중 한 편만이 성공적이라는 사실을 알아야 한다. - 빈센트 반 고호
    • 실패란 없다. 너무 빨리 포기했을 뿐이다. - 조나스 소크
    • 더 나은 방법이 있으면 찾아라. - 토마스 에디슨
    • 실패하라. 다시 실패하라. 더욱 잘 실패하라. - 사무엘 베게트
    • 성공하고 싶다면 실패율을 두 배로 높여라. - 탐 왓슨
    • 명작 한 페이지당 쓰레기 아흔 아홉 페이지를 집필한다. - 어니스트 헤밍웨이
  •  설계활동은 하향식으로 시작되어야 한다. - 고객이 볼 화면에서 출발하여 상위 컴포넌트로, 그리고 작업항목으로 내려오는 방식

6. 아이디어 관리하기

• 프로토타입은 하향식으로 진행해야 합니다. 사용자가 볼 화면에서 시작하여, 사용자가 화면을 보게될 순서대로 작업을 진행해야 합니다.
• UI가 없는 경우, 가장 어렵고 복잡한 기술적 난제를 골라서 수행하는 것이 좋습니다.
• 친화도(Affinity Diagram)를 이용하라
  • 아이디어, 벽, 포스트잇, 팀
  • 각 아이디어를 간단히 요약하여 벽에다 부친다. 아이디어간의 관계나 관련성에 따라 묶는다.
  • PM은 전체 목록을 관리하고, 팀원들은 친화도를 이용하여 문제를 이해하고, 처리한다

7. 우수한 명세서 작성하기

• 프로젝트에서 문서를 활용하는 효과적인 방법 또는 태도 (p190~p191)

• 명세서의 역할 - 정의서/설계서

  • 구축할 제품의 기능을 효과적으로 묘사
  • 구체적인 결정을 요구하여, 설계자의 결정을 확정하도록 지원
  • 구현 돌입전 구체적인 계획을 검토하고, 의문을 제기하고, 논의할 수 있음
  • 한 사람에서 여러 사람으로 정보를 전달
  • 팀이 구체적인 계획을 참조할 수 있는 기준점 제공
  • 팀이 목표로 삼을 수 있는 자연스런 일정 중간목표를 제시
  • 작성자가 버스에 치이는 사태 대비
  • 건전한 토론을 장려하고, 개선하고, 횟수를 증가시킴
  • 리더에게 피드백 제공, 품질목표를 정할 수 있는 기회 제공
  • 팀이 정신을 차리도록 하며, 자신감이 생기도록 함

  
  

• 명세서가 해서는 안되는 일

  • 팀원 사이에 토론의 여지를 없앰
  • 작성자가 얼마나 똑똑한지를 팀에게 증명
  • 기능이 얼마나 중요한지 증명
  • 사람들을 철학적 관점으로 돌아서게 함
  • 작성자의 비지오나 UML 사용기술을 맘껏 펼치도록 함

  
  

• 명세서 주요 내용
  
  • 요구사항 - 고객 및 PM, 분석가가 정의
  • 기능명세서 - PM이나 설계자가 정의
  • 기술명세서 - 개발자가 정의
  • 작업항목 목록 - 개발자가 정의, WBS
  • 테스트 기준과 중간목표 종료 기준
• 명세서를 작성하는 이유는 다른 사람이 최대한 이해하기 쉽도록 무언가를 설명하는 것
  • 다른 명세서에서 우수한 설명을 빌려와라
  • 전문용어나 모호한 언어는 피해라
  • 옛날에 작성했던 명세서를 보관하라
  • 구체적인 독자를 염두에 둬라
  • 비지오나 흐름도에 집착하지 마라
  • 전체 API를 설명할 필요는 없다 - 전체 목록은 별도로 목록화
  • 의사코드(Pseudo code)나 일반언어 차원에서 묘사해라
• 명세서 완료여부를 판단하는 유일한 방법은 검토라는 절차이다.
• 명세서의 검토는 팀 작업이어야 한다. - 함께 일해야 할 모두가 동의함을 확인하는 작업이다.

8. 올바른 결정 내리기

• 결정에 따르는 손익 파악하기
  • 의사결정의 첫 단계는 내려야 하는 결정의 중요성을 판단하는것
  • 결정에서 핵심이 되는 문제는 무엇인가?
  • 프로젝트에 영향을 미치는 기간? - 장기적인 결정이라면 끈기와 절제를, 단기적인 결정이라면 속력과 명확성을 추구
• 선택방안을 찾고 경중을 가리기
  • 상관없는 일은 정말로 상관하지 말아야 한다.
  • 결정에 관련된 책임이 비록 자신에게 있더라도 그 과정을 타인에게 공개함으로써 최선의 행동방침에 대한 더 나은 견해를 얻을 수 있다

• 결정하는 용기

  • 옳은 결정을 하는 것과 옳은 결정을 내리는 것은 다르다.
  • 우수한 리더일수록, 다양한 결정을 내리는 과정에서 더 많은 용기가 필요하다.

9. 의사소통과 관계

• 문제는 의사소통의 품질과 효과이다. 속도는 더 이상 문제가 아니다.
• 소 프트웨어 개발처럼 복잡하고 상호의존적인 작업에서는 의사소통만으로 충분하지 않습니다. 함께 일하는 사람들 사이에 효과적이고 건전한 관계를 형성해야 합니다. 공유하는 결정과 공동으로 수행하는 작업이 너무나 많기 때문에, 좋은 관계를 쌓지 못한다면 의사소통을 아무리 많이 해도 소용이 없습니다.
• 일반적인 의사소통 문제
  
  • 네가 하는 말이 아니라, 남이 듣는 말이 중요하다
  • 사람들이 관리자에 대한 관계에 얼마나 공을 쏟든, 관리자는 사람들에 대한 관계에 공을 들여야 합니다.
  • 프로젝트 관리자는 팀원들과 맺는 관계만큼만 우수합니다.
  • 다른 팀원의 가치를 최대한 증대시키는 역할이 PM 입니다.

10. 사람들을 괴롭히지 않는법 : 프로세스, 전자편지, 회의

• 자신이 나쁜 전자편지를 보낸다는 사실을 인정하는 사람이 거의 없다

• 전자편지 작성 가이드

  • 간결하고, 간략하게, 요점만 말하라
  • 조치와 기한을 제시하라
  • 우선순위를 정하라
  • 사람들이 읽는다고 가정하지 마라
  • 실황중계는 피하라
  • 정보성 편지(FYI)를 분리하라
  • 전화를 활용하라

  
  

• 정기회의는 회의 가치가 사라진 후에도 오랫동안 남아있기 쉽다. -> 이에 대한 적절한 대안을 모색할 필요 있음

11. 난관에 대처하는 법

• 프로젝트 난관 대처 가이드

  • 침착하십시오 - 숨을 고르고, 주의를 집중하라
  • 프로젝트와 관련지어 문제를 평가하십시오 - 정말 문제인지, 어느 정도 영향을 미치는지, 누구의 문제인지를 생각하라. 반응하기보다는 생각하라
  • 다시 한번 침착하십시오 - 감정을 안전하게 표현할 방법을 찾아 해소하고, 다시 문제로 돌아와라.
  • 필요한 사람을 한 자리에 모으십시오 - 문제를 토론하고, 위임하라. 문제를 맡아서 해결할 책임이 누구에게 있는지 분명히 하라
  • 대안을 궁리하십시오
  • 가장 단순한 계획을 짜십시오
  • 실행하십시오
  • 보고하십시오

  
  

• 서두르면 실수는 반복이 된다. 신중하면 실수는 교훈이 된다.
• 언제나 문제는 발생하기 마련이고, 우리는 해결해야 한다.

12. 리더십이 신뢰를 바탕에 두는 이유

• 신뢰 : 개인의 성실성, 능력, 인격에 대한 확고한 믿음
• 위임 : 다른 사람이 결정을 내리도록 신뢰하는 행위
• 기가 하고자 하지 않는 일은 남에게 베풀지 마라

13. 일을 추진하는 방법

• 일을 추진하는 능력 = 너무나도 다양한 상황에서 촉매제 혹은 책임자가 되는 방법을 아는 능력 + 촉매제가 되겠다는 용기
• 작업의 우선순위를 부여하고, 그에 따라 진행하라
• 조직에서 임계 경로(Critical Path)를 개선하는 가장 좋은 방법은, 새로운 절차나 계층을 만드는 대신에, 절차를 없애고 권한을 아래로 내려보내 팀내로 분산시키는 것임
• " 아직 전화해보지 않은 사람은 누가 있죠 ? 이런 문제에는 전자 편지가 적당하지 않아요. 저쪽 사람들, 즉 우리 의견에 찬성하지 않는 사람들 중 그나마 우리 의견에 가장 수긍하는 사람은 누구죠 ? 원하는 바를 얼마만큼 열심히 설득했죠 ? 내가 관여해서 위선부터 처리할까요 ? 이게 과연 도움이 될까요 ? 우리 VIP는 어때요 ? 우회책을 찾아보라고 엔지니어링을 어느 정도 독려했나요 ? 조금 ? 많이 ? 최대한 ? 술 한잔 사겠다고 했습니까 ? 저녁은요 ? 일대일로 이야기하거나 그룹으로 이야기한 적이 있습니까 ? 계속 계속 계속 밀고 나가세요. 방도를 찾을 겁니다. 당신을 믿습니다. 당신을 이 문제를 해결할 겁니다. 계속 밀고 나가세요."

14. 게임중반 전략

• 움직이는 과녁 맞추기

  • 계획에 따라 승리한 전쟁은 없다. 하지만 계획없이 승리한 전쟁도 없다. - 아이젠하워
  • 결 코 계획대로 전쟁을 할 수는 없다네. 계획은 단지 변화에 대한 공통 토대일 뿐일세. 모두가 계획을 알아야 한다는 사실이 중요하지. 그래야 쉽게 변경할 수 있거든. 현대전은 아주 유동적이라서 결정을 아주 빨리 내려야 하는데, 대부분 계획에 따라 결정을 내리지는 않지. 하지만 적어도 모두가 어떤 근거에서 결정이 나왔는지 그리고 어디로 가려는지 대충은 이해해야 한다네. - 단 라너 (이스라엘 장군)

15. 게임후반 전략

• 행 운의 여신이 당신 손을 들어서 프로젝트가 세상에 나오게 된다면, 기뻐하십시오. 아주 아주 기뻐하십시오. 자신의 잘못이 아님에도 불구하고 많은 사람은 이런 기회를 결코 얻지 못합니다. 웅장한 밤을 계획하십시오. 아주 흥겹고 사치스러운 행사를 벌이십시오. 여러 해 동안 화제로 등장할 이야기거리를 만드십시오.

16. 권력과 정치

• 의사소통을 잘하는 팀은 정보를 전달하기에 그치지 않고, 이해했는지 그리고 가능하다면 동의하는지까지 확인합니다.