“프로젝트 관리자가 알아야 할 97가지”의 목차를 부분적으로 요약 설명과 함께 정리하였다. 다수 저자의 자료를 취합 정리하여 하나의 책으로 엮었으므로, 다소 산만하기도 하지만 프로젝트 관리의 다양한 관점을 제공하고 있는 유용한 자료이다. 상세한 내용은 원서와 번역서를 참고하기 바란다. 원서는 책이나 eBOOK으로 구매할 수 있고, 인터넷에서 무료 PDF 파일로 다운로드 받을 수도 있다.
1.
가능한 빨리 사용자를 참여시킨다 Barbee Davis
2.
두더지 게임 방식의 개발을 하지 마라 Venkat Subramaniam
3.
다국어를 지원할 경우 사소한 일로 인해 프로젝트 마감일을 놓칠 수 있다 Pavel
Simsa
4.
프로젝트 후원자가 본인들의 요구사항을 작성하게 하라 Miyoko Takeya
5.
복잡함보다 간결함을 추구하라 Scott Davis
6.
개발하면서 표준을 준수하지 않은 기술적인 빚을 갚아라 Brian Sletten
7.
팀에 기술이 아닌 재능을 추가하라 Richard Sheridan
8.
간결함을 유지하라 Krishna Kadali
9.
당신은 특별하지 않다. 품질높은 오픈소스나 상용도구를 사용하라 Jared Richardson
당신 프로젝트에서 이미 이용
가능한 컴포넌트를 다시 개발하지 마라 (Don’t let your
programmers reinvent the wheel). 내가 만들지 않았기 때문에 사용하지 않는 증후군으로 인해 많은 훌륭한 팀이
망가졌는데 (The “not invented here” syndrome derails so many great teams.), 당신 팀도 똑 같은 시행착오를 범하지
마라.
10.
과거의 경험으로부터 배워라 Kim MacCormack
11.
벤더 제품의 이슈 해결에 비용을 아껴라 Randy Loomis
12.
훌륭한 IT 개발자를 파악하는 방법
James Graham
§
조직 내 최고의 전문가를 참여시켜 인터뷰하고, 작성한 코드 또는 산출물을
검토한다.
§
동료, 고객 그리고 이해당사자에 대한 태도를 고려한다.
§
의사소통과 사교성을 검토한다.
§
극한 상황에서의 태도를 점검한다.
§
과거 일한 조직과 동료의 평판을 확인한다.
13.
숙련된 개발자와 평범한 개발자의 생산성 Neal Ford
숙련된 개발자와 평범한 개발자의
생산성은 수십배 차이가 난다. 의사소통 경로는 프로젝트 팀원이 n명이면 n(n-1)/2이다.
일반적으로 평균 개발자의
추가는 납기를 단축할 수 있고, 평균적인 속도로 평균적인 코드를 개발 할 수 있다는 믿음이 있다. 실제로는 평범한 개발자는 전반적인 생산성을 저하시키고, 프로젝트
납기를 지연시키다. 좋은 개발자가 평범한 개발자 지원으로 생산성이 낮아 질 수 있다.
14.
규모가 중요하다 Anupam Kundu
프로젝트 규모, 팀 규모, 산출물 규모 그리고 체크리스트 규모 – 프로젝트의 모든
것은 규모에 의존한다. 규모에 따라 프로젝트를 관리하는 규칙이 바뀐다.
15.
프로세스를 문서로 만들고, 이를 꼭 지키게 하라 Monte Davis
16.
프랙티스를 버리고 실행하라 Naresh Jain
완벽은 더할게 없고 버릴게
없을 때 달성된다. 일반적으로 관리자는 프로세스, 프랙티스, 체크리스트, 점검 (audits)를
필요 이상으로 강화하는 경향이 있다. 이것을 잘못 강화하면 문제의 근본원인을 찾는 것을 더욱 어렵게
한다. 꼭 필요한 것만을 만든다. 프로세스는 “더 적은 것이
더 많은 것이다 “less is more.” 라는 철학이 매우 중요하다.
원인은 프로세스를 왜 사용하는지를
모르거나 방법론을 잘 못 이해하고 있기 때문이다.
17.
요구사항 명세서의 모순 Alan Greenblatt
요구사항, 기능 (feature), 명세서
(specification)를 명확히 한다.
§
요구사항 - 사용자 인터페이스를 단순화 한다.
§
기능 - 동일 작업을 끝내기 위해 버튼 클릭 횟수를 2번으로 줄인다 (현재는 5번).
§
명세서 - 버튼 1, 2, 3 으로
실행하는 기능을 버튼 A 하나로 통합니다.
적절한 기술적인 전문성이
없는 관리자 또는 분석자가 구현방법을 결정하는 경우가 있다. 요구사항 정의와 분석 단계에서는 어떻게
구현할 것인지가 아닌 무엇을 개발할 것인가에 집중한다. 그리고 나서 전문성을 가진 엔지니어가 어떻게
구현할 것인지 결정하게 한다.
18.
성공은 항상 비즈니스 가치로 측정된다 Barbee Davis
19.
프로젝트 휴가를 생략하지 마라 Joe Zenevitch
프로젝트 관리자는 권한위임을
통하여 다른 팀원이 프로젝트관리 업무를 수행하게 하고 계획된 일정에 따라 휴가를 간다.
20.
집중을 위한 시간 (regular time) 을 제공하라 James Leigh
개발자는 미팅, 데모 등으로 인하여 업무 수행에 방해를 받는다. 방해를 받으면 원래
업무에 복귀하는데 20분이 걸리므로 5분 동안 방해를 받으면
업무는 25분의 지연이 발생한다. 평균적으로 28%의 개발자 시간이 이러한 방해로 인하여 낭비되는데, 이것은 개발자에게
심각한 좌절감과 스트레스를 준다.
이것을 피하기 위하여 회사들은
집중 근무시간 “10시 ~ 12시”을 이용하여 할 일을 계획하고, IBM은 “zero-email Friday”, Intel은 “Think Friday”를 운영한다.
21.
프로젝트 관리는 문제 관리이다 Lorin Unger
22.
개발자에게 권한을 위임하라 Ken Sipe
통제를 잘못하면 오히려 생산성이
떨어질 수도 있다. 더 할 수 있는 일을 못하게 할 수도 있고, 사기저하로
생산성 저하를 초래할 수도 있다.
23.
독창적인 (clever) 코드는 유지보수하기 어렵다 David Wood
개발 및 유지보수 시 혁신적인
개발은 바람직하나, 지나치게 복잡한 독창적인 구현을 못하게 한다. 독창적인
구현은 다른 개발자에 의한 유지보수가 어렵게 한다. 일반적으로 개발자는 직업 안정성 확보를 위하여 독창적으로
개발하려는 경향이 있다.
24.
프로젝트 관리의 인적 요소를 관리한다 James Graham
25.
위키를 사용하라 Adrian Wible
26.
잃어버린 연결 고리 Paul Waggoner
유지보수를 하면서 개발을
하는 것과 같이 전담으로 프로젝트에 참여하지 않을 경우에 프로젝트관리자는 참여하는 개발자의 갈등을 잘 관리하여야 한다.
27.
측정하고, 측정하고, 측정한다 Richard Sheridan
일반적으로 프로젝트를 시작하면서
측정하고 나서는 다시는 측정하지 않는다. 더욱 안 좋은 것은 견적이 어떻게 잘못되었는지를 파악하기 위하여
견적과 실적을 비교해 보지 않는 것이다.
측정 자료는 팀 평가나 처벌에
사용해서는 안 된다.
28.
개발자들을 통합한다 - PMO가 진화한다
Angelo Valle
29.
노력이 아니라, 결과에 가치를 부여한다
Venkat Subramaniam
30.
소프트웨어 실패는 조직의 실패이다 Brian Sletten
31.
고객에 의한 지나친 자동화 요구 Marty Skomal
32.
당신의 관점을 유지하라 James Graham
단기 미봉책으로 고객을 만족시키지
말고 문제의 근본원인에 파악하고 해결한다.
33.
완료 (finished) 기준을 정의한다
Brian Sam-Bodden
34.
60/60 법칙 David Wood
소프트웨어 비용 중 평균 60% (40% ~ 80%)는 유지보수, 나머지 40%는 개발에서 발생한다. 유지보수 비용 중 60%는 기능 개선, 23%는 이행
(migration), 17%는 오류 수정에 들어간다. 유지보수 비용 중 30% 정도 (기능개선 비용의
50%)가 요구사항을 이해하고 현행시스템을 분석하는데 들어간다.
소프트웨어 비용 중 60%가 유지보수 비용이고, 유비보수 비용 중 60%가 기능 개선에 들어 가는 것을 “유지보수의 법칙 (laws of
software maintenance)”이라고 한다.
35.
우리가 만난 적은 우리 자신이다 Barbee Davis
비효율적인 회의, 업무 간섭 (interruption), 다국어 프로젝트, 방법론 등
36.
주기를 가지고 일한다 (Work in Cycles) James Leigh
90분에서 180분 일하면 휴식을 취한다. 조사에 의하면 90분에서 180분을 집중하면 생산성이 떨어진다.
주간, 월간 단위로 반복하면서 일하는 것이 더 효율적이다. 반복 주기 별로
계획을 수립하고, 작업이 끝나면 반드시 피드백이 이루어 지도록 한다.
37.
프로젝트 관리자는 먼저 자기 자신을 통제할 수 있어야 한다 Harry Tucker
38.
회의는 코드를 개발하지 않는다 William J. Mills
잡담, 너무 깊게 빠지는 회의, 주제에서 벗어나는 회의, 시간 초과, 너무 자주하는 회의,
회의 중재 미흡 등을 피해야 한다.
39.
사용자와 유지보수 담당자에 대한 변화관리를 준비하고, 수행한다 Kathy MacDougall
40.
프로그램 차원의 비전 공유 David Diaz Castillo
다수의 개별 기술 프로젝트로
구성된 전사 차원의 프로그램을 관리하고, 프로그램의 비전을 개별 프로젝트가 공유한다.
41.
현실적인 계획 수립 Craig Letavec
42.
완벽한 실행의 허구 David Wood
소프트웨어는 규모가 커짐에
따라 인간이 관리할 수 없을 정도로 복잡해져서, 본질적으로 오류가 발생하기 쉽고, 변경이 잦고, 부정확하게 문서화된다. 결함이 없는 소프트웨어를 개발하는 것은 불가능하다.
43.
더 민첩한 소통 체계를 도입하라 Brian Sam-Bodden
15분 서서 하는 미팅 (stand-up meeting), 비동기 소통 도구, 위키 같은
협업 도구 등을 통하여 지속적인 피드백을 제공하여 소통의 단절을 방지한다.
44.
방법론을 경배하지 마라 Fabio Teixeira de Melo
어떠한 방법론, 프로세스 보다 건전한 상식이 더 중요하다. 프로젝트에 도움이 되는
프로세스만을 사용하고, 프로젝트를 가능하면 단순하고 효과적으로 관리한다.
45.
사람 이슈에 스프레드시트를 사용하지 마라 Anupam Kundu
할 일이 나열되어 있는 스프레드쉬트
목록을 가지고 이슈를 해결하려고 하지 말고, 할 일에 대하여 이해당사자와 협의하여 우선순위를 부여하고, 내재된 갈등을 해소한다.
46.
산출물 별 담당자를 한 명씩 정한다 Alan Greenblatt
47.
완벽한 지식의 허구 David Wood
소프트웨어 프로젝트에서 완벽한
서로 상충되지 않은 요구사항을 정의하는 것이 가능하다고 생각하는데, 현실은 소프트웨어 개발 기간 동안, 심지어 유지보수 기간에도 완벽한 요구사항을 파악할 수 없다.
반복적 점진적 개발, 애자일 접근법을 통하여 보다 상대적으로 더 완벽한 요구사항을 정의할 수는 있으나 간단한 업무가 아니면 완벽한
요구사항 정의는 가능하지 않다.
48.
스프린트가 아니라, 마라톤을 하도록 팀을 구성하라 Naresh Jain
49.
프로젝트 관리의 세가지 요소 Paul Waggoner
시간, 비용, 범위 관점에서 팀원들과 명확하게 소통할 수 있게 문서화한다. 프로젝트관리자는 새로운 팀원에게 30분 이내에 프로젝트를 소개할
수 있어야 한다.
50.
프로젝트 로드맵 - 최근에 우리는 무엇을 하였는지? Kathy MacDougall
51.
프로젝트 범위 기술서의 중요성 Kim Heldman
52.
비전과 예상 결과를 일치시킨다 David Diaz Castillo
53.
앨리스는 더 이상 여기 안 산다 Barbee Davis
다문화 프로젝트를 진행할
경우에는 기적 (Alice) 이 일어 나지 않는다. 모든
이슈를 파악하여 해결하라.
54.
계약 분쟁을 피하는 방법 Jorge Gelabert
분쟁을 피하는 가장 좋은
방법은 공정 (fair) 하여야 한다.
55.
측정한 것을 얻는다 Naresh Jain
56.
NIH 증후군에서 벗어나라 Paul Giammalvo
57.
미루지 말고 지금 당장 실행한다 Scott Davis
58.
속도가 생명이다, 많을수록 더 좋다 Matt
“Boom” Daniel
상황에 따라 다르다는 것을 알아야 한다.
59.
팀동기 부여 David Bock
§
팀이 프로젝트 진행에 영향을 주도록 한다.
§
관료화로부터 보호한다.
§
작업 환경을 개선한다.
§
팀워크를 구축한다.
§
일과 생활의 균형을 유지한다.
§
원인과 결과가 사기에 어떻게 영향을 미치는지 이해한다.
§
활동의 투명성을 확보한다.
60.
프로젝트는 팀워크에 영향을 받는다 Lelio Varella
61.
팀에 봉사하라 Karen Gillison
62.
큰 공에 대한 허구 David Wood
요구사항이 변하지 않고, 더 나쁜 것은 요구사항을 통제할 수 있다는 것은 환상이다 (큰 공에
대한 허구 - The Fallacy of the Big Round Ball). 이 것이 사실이 아니다는
것을 인정하고 설계의 적응성 (adaptability)과 유연성
(flexibility)을 제고하고 항상 변경할 준비를 한다.
63. 위기 대응 James Graham
64.
통합 지점을 파악한다 Monte Davis
65.
분산 프로젝트에서는 적극적으로 소통한다 Anupam Kundu
66.
결과를 염두에 두고 시작한다 Luis E. Torres
67.
분명한 거래 조건은 오랜 친분을 가져온다 Matteo Becchi
68.
최고의 측정자는 그 일을 하는 사람이다 Joe Zenevitch
69.
소통이 열쇠다 Gennady Mironov
70.
프로젝트는 해결책을 찾는 것이다 Cynthia A. Berg
71.
바보야, 문제는 사람이야 Adrian
Wible
72.
문서는 목적이 아니고 수단이다 Patrick Kua
73.
획득 가치와 속도 (velocity)는 보고서에 공존할 수 있는가? Barbee Davis
74.
범위는 변경된다. 그 것을 받아들여라
Pavel Simsa
75.
상용 소프트웨어 구매 Ernani Marques da Silva
구매 전에 적절하게 타당성을
검토한다. 벤더 영업이나 광고를 믿지 마라.
76.
프로젝트 스폰서 - 좋거나, 나쁘거나, 이상하거나 Jorge Gelbert
스폰서가 좋거나 나쁘거나
이상하거나 항상 정보를 제공하고, 필요할 때 참여시키며, 스폰서가
프로젝트를 통제하지 않게 한다. 스폰서의 성향에 따라서 준비하고, 대응한다.
77.
부족한 개발 또는, 초과 개발? Joe
Zenevitch
계약한 만큼만 개발하여 납품한다 (No more, no less).
78.
모든 프로젝트 관리자는 계약 관리자이다 Fabio Teixeira de Melo
79.
중요하지만 긴급하지 않은 일 Alex Miller
80.
프로세스를 가르쳐라 Richard Sheridon
81.
프로젝트 진척도의 허구 Udi Dahan
82.
그들이 듣고 싶은 것은? Martha Legare
83.
팀 사기에 대한 가치를 인식한다 David Bock
84.
모든 이해관계자를 프로젝트 기간 내내 참여시켜라 Lukeman Lawal
85.
계획의 가치 Derry Simmel
86.
항상 ”전달만 하는 사람 (the messenger)” 이 되지 마라 Matt Secoske
87.
산출물을 효과적으로 관리하라 Ernani Marques da Silva
88.
프로젝트 관리자이지 슈퍼영웅이 아니다 Angyne J. Schock-Smaith
89.
자주 그리고 즉석 미팅을 통하여 소통을 늘려라 Richard Sheridan
90.
유연성은 프로젝트 관리를 단순화한다 Krishna Kadali
91.
지금은 웹이 나아갈 방향이다 David Wood
92.
개발자는 현황보고를 싫어하고, 관리자는 좋아한다 Pavel Simsa
93.
통제하지 않는 것처럼 조심스럽게 통제한다 Patrick Kua
94.
비전을 공유하라 Jared Richardson
95.
진정한 성공은 지원 조직과 함께 이루어 진다 Cynthia A. Berg
96.
프로젝트관리 거버넌스를 구축하라 Ernani marques da Silva
97.
당신의 웹사이트를 싫어하는 9.7가지 이유
Barbee Davis
1.
느리게 나타나는 플래쉬 화면
2.
끔찍하게 큰 비디오 소리
3.
작동 안되는 뒤로 버튼
4.
잘 알아볼 수 없는 저해상도 색상
5.
다양한 휴대기기를 지원하지 않음
6.
전화 연락처 없음
7.
정보를 얻으려면 전화하라고 함
8.
고객 유형에 따른 차별
9. 쓸모 없는 검색 기능 제공
9.7 버튼 이름 잘못
지정
댓글 없음:
댓글 쓰기