PM+P 문제집(PMP 수험문제집) 중에서
1. 일정, 원가 목표를 달성하기 힘든 프로젝트 일수록 성공하면 회사 내에서 인정받을 가능이 높다. 아무도 하지 않으려고 할 때 과감하게 지원하라.
2. 고객만족은 직원만족보다 우선이고 회사의 존재 이유이다. 고객의 요구사항은 항상 수용하라.
3. 검증되지 않은 IT에 대하여 개척자 정신을 발휘하여 과감하게 채택하라.
4. 고객은 시스템을 보고 나서 본격적인 요구사항을 제시하게 되어있다. 개발 완료 이후부터 쏟아지는 변경사항을 최대한 수용하라.
5. 계약 시에 모든 업무범위를 명확하게 하는 것은 불가능하다. 이런 경우엔 가능하면 “기타”나 “-등”을 최대한 활용하라.
6. 고객과의 중요한 업무 협의 시는 개발 담당자가 직접 고객과 협의하게 하라. 업무를 잘 아는 당사자가 훨씬 협상을 잘 한다.
7. 고객과의 업무 범위협의 시 이슈가 되는 사항은 무조건 뒤로 미루어라. 고객은 기억력이 없기 때문에 나중에 잊어버린다.
8. 일정이 촉박할 경우에는 산출물(특히 프로그램 사양서)작업을 뒤로 미루어라. 종료 시에 외부 감리가 예정되어 있는 경우에는 더욱 효과적이다. 바뀔 것을 알면서도 미리 작성하는 것은 바보짓이다.
9. 고객의 모든 요구사항을 문서화 한다는 것은 불가능하다.불가피하게 고객이 산출물을 요구하는 경우에는 문서를 최소화하여 형식적으로 작성한다. 개발자의 부담을 줄여 개발자 본연의 업무인개발에 집중할 수 있도록 하는 것이 PM의 중요한 역할이다.
10. 형상관리는 이론적인 이야기이다. 하면 좋지만 프로젝트 업무수행 도중 형상관리까지 하는 것은 너무 큰 부담이 된다.
11. 계약서에 명시하기 힘든 요구사항은 이면사항으로 합의하라.
12. 프로젝트 관리자가 모든 업무 내용을 상세하게 파악하여 미세 관리를 하도록 하라.
13. 기존 전산실 요원이 요건 정의를 하도록 하라.
14. 고객 요구사항은 개발이나 테스트 할 때 반영할 요량으로 분석, 설계가 미진진한 상태로 개발을 강행하라.
15. 분석이나 설계를 할 때는 상상의 나래를 펴서 창의적으로 요구사항을 정의하라.
16. 불공정한 계약을 수정 없이 추진하라.
17. 수주제일주의만이 SI프로젝트의 나아갈 길이다.
18. 고객의 시스템 요구사항은 얼마든지 변경할 수 있다.
19. 반쯤 구워진 아이디어를 실현 가능한 기술로 믿으라.
20. 분석단계에서 업무범위에 대하여 고객과 합의 할 수 있다는 믿음을 버려라.
21. 분석단계는 에너지 충전의 단계로 십분 활용하라.
22. 분석단계는 여유를 가지고 너그럽게 관리하라.2
23. 분석 간계의 모델링은 말 그대로 모델링일 뿐이다.
24. 분석은 개념적인 단계이므로 개략적인 “what”만 정의하면 충분하다.
25. 프로젝트의 순익을 올리는 가장 효과적인 방법은 싼 단가로 아웃소싱(외주업무)계약을 체결하는 것이다.
26. 턴 키로 아웃소싱 업무를 위탁한 경우에는 “원 청자”와외주업체가 직접 업무를 협의하도록 하라. 업무내용도 잘 파악하지 못한 상황에서 업무를 검토하는 것은 비 효율적이다. 어차피 원청자가 승인하여야 한다. 두 번 작업할 필요가 없다.
27. 프로젝트 공동수행 시 (특히 공동이행 방식 계약의 경우) 컨소시엄 업체의 선행공정의 진척 상황을 무시하라.
28. 발주자가 원하는 시스템 벤더(vendor)나 업체는 다소 미흡하더라도 수용하라.
29. 최대한 아웃소싱을 배제하고 자체 개발하라.
30. 원가절감은 PM에게 주어진 절대 절명의 과제이다. 인건비 절감이 힘들 경우에는 계획에 책정된 경비(예를 들어 잔업 비, 교통 비 등)를 줄여서라도 원가를 줄여라.
31. 위험 항목은 착수 시에 전반적으로 파악하게 되므로 계속 모니터링 한다는 것은 불필요한 낭비이다. 한번이면 충분하다.
32. 위험에 대한 평가는 PM 혼자서 하면 충분하다. 팀원이 참여하면 의견이 분산될 뿐만 아니라 프로젝트 수행에도 지장이 있다.
33. 프로젝트에 문제가 있을 경우에는 그 요인을 외부(주로 고객)에게 찾아야 한다. 그러면 팀 내부 결속력이 높아져 팀워크가 향상된다.
34. 현재 나타난 문제점이 전부라는 낙관적인 생각을 하라.
35. 고객 비위만 잘 맞추면 프로젝트의 위험관리는 별로 필요하지 않다. 선거 때 받아먹을 것은 받아먹고 막상 투표를 원하는 사람에게 하는 심정을 이해하라.
36. 믿을 것은 산출물밖에 없다. 모든 진척 관리의 기준은 산출물을 기준으로 하라.
37. 납기 지연은 있어도 공정 지연은 없다. 공정진척 률 95퍼센트까지는 계획대로 진행된다고 보고하는 것이 고객과의 불필요한 논쟁을 최소화하는 길이다.
38. 가장 효과적인 진척통제의 기준은 계획 대비 실적이다. 원가와 일정의 계획 대비 실적을 신봉하라.
39. 인수인계보다 개발이 중요한 것이 SI의 본질이다. 인수인계는 개발이 완료된 시점부터 논의하는 것이 효과적이다.
40. 업무범위 변경과 관련해서는 구두로 협의하여 진행하는 것이 효과적이다. 공식적인 문서를 남겨 고객과의 관계를 껄끄럽게 만드는 것은 바람직하지 않다. 또한 일일이 문서화 하는 것도 득보다 실이 크다.
41. 계량적인 데이터는 측정하기 힘들 뿐만 아니라 신뢰 할 수 없다. 이보다 PM의 직관이 더 믿을 수 있다.
42. 조직을 효과적으로 관리하기 위해 계층적 조직구조를 만들고, 의사소통도 계층구조를 준수하는 것이 바람직하다.
43. 업무 진척 성과는 보고되는 자료를 100퍼센트 신뢰하라. 프로젝트 관리자가 이를 확인하려고 하는 순간 프로젝트 관리자와 개발팀 간에 불신의 싹이 튼다.
44. 최종 검수를 받기 위해서는 이면 약속을 하는 것도 무방하다. 일단 검수를 받고 나면 갑과 을의 위치가 바뀌므로 무조건 검수부터 받아라.
45. 팀원에게 받는 모든 보고는 공식 문서(formal document)로 받는 것이 바람직하다. 글로 표현하다 보면 본인의 생각이 정리되고 향후 근거로 남는다.
46. 프로젝트 진척 현황은 대외 보고용과 내부 관리용을 별도로 관리하라.
47. 중요한 의사결정은 팀원의 합의도출에 있을 때까지 연기하라.
48. 당장의 손실(예산초과)을 생각해 팀원의 요구를 무시하라.
49. 프로젝트 구현 시점에 시스템 운영자의 참여를 배제하라.
50. 시스템 개발을 할 때는 내가 사용할 시스템이라는 몰입을 버리고 한발 물러서서 판단하라.
51. 고객의 인수, 운영 능력은 프로젝트 종료와 상관없다.
52. Output control 보다 time control을 하라.
53. 프로젝트란 것은 과업 지향적인 업무이다. PM도 관리 스타일도 과업지향적으로 발휘하는 것이 효과적이다.
54. 개발 팀으로 하여금 Multi-tasking을 수행하게 하라. 생산성이 급격히 높아질 것이다.
55. 프로젝트는 팀워크가 중요하다. 할 수 있으면 같이 퇴근하도록 하라. 휴일, 전원 출근을 하여 어려움을 같이 하는 것은 팀워크 향상에 아주 도움이 된다.
56. 공정한 업무 분배를 위하여 가능하면 코팅의 분량을 동일하게 분배하라. 그렇지 않으면 개발자들이 반발할 것이다.
57. 개발자 모두가 수긍하는 업무 평가는 불가능하다. 차라리 돌려가면서 업무평가를 하는 것이 불만을 최소화 하는 길이다.
58. 프로젝트 수행 도중 인력이 퇴사하는 것은 프로젝트에 아주치명적이다. 퇴사하려는 사람과 몇 번이고 면담을 해서라도 인력을 잔류시키기 위한 노력을 다하라. 신규 인력 세 명보다 기존 인력한 명이 실질적인 도움이 된다. 특히 기술력이 뛰어난 핵심 인력은 절대로 놓쳐서는 안 된다.
59. 프로젝트 관리자는 관리직이지 기술직이 아니다. 기술적인 부분에 대하여 관여하기 시작되면 세세한 업무도 관여하게 되어 업무 위양이 되지 않는다. 관리 본연의 업무에 충실 하라.
60. 고객관리는 술자리에서 이루어진다. 아무리 힘든 업무라도 근무지 밖에서 개인적으로 해결하는 것이 프로젝트 관리자의 역량이다.
61. 공정이 지연되는 경우에는 인력을 추가 투입하라. 일정이 당겨질 것이다.
62. 업무의 진척이나 완성도가 낮은 사람이 있을 경우 담당 업무를 바꾸어 분위기를 쇄신하라.<BR>63. 프로젝트 진행과 관련된 정보는 PM이 독점하라. 그래야 PM의 권위가 서고 개발 팀원들이 PM을 따른다.
64. 어떠한 경우에도 출근 시간은 지키는 것이 직장인의 기본 예절이다. 쉬러 가는 한이 있어도 정시에 출근을 해야 한다.
65. 팀원들이 프로젝트 수행 도중 휴가를 사용하지 못하게 하라.
66. 직급과 남성 위주로 중요한 업무를 배분하라.
67. 비 경험자들로 고급 인력의 50퍼센트 이상을 구성하라.
68. 고객이 바뀌는 것은 무시하라. 공공 프로젝트의 경우, 프로젝트에 착수할 때와 수행 도중, 그리고 종료할 때 참여 고객이 거의 전부 바뀌는 것은 운명이다.
69. 프로젝트 관리 이론을 신봉하라.
70. 인수조직의 계층을 다원화하라.
71. 고객은 파트너가 아니라 극복의 대상이라고 생각.
72. 프로젝트는 팀워크 보다 창의적인 개성이 우선이다.
73. 협력업체는 무조건 일만 하면 된다.
74. 고객관리는 영업에서만 담당하면 된다.
75. 인력관리는 고과라는 무기만 있으면 된다.
76. “내가 프로젝트를 얼마나 많이 했는데, 문제 없어!”라는 자세를 견지하라.
77. 프로젝트 이행 당사자는 고객 측 대표자 한 명이면 충분하다.
78. 인원이 없으면 기술력에 상관없이 대기 인력이라도 투입하라.
79. 고도로 복잡한 프로젝트에 숙련되지 않은 프로젝트 관리자를 선임하라.
80. 프로젝트 영역을 관리 가능한 ‘부분들’로 나누지 말고 전체로 통제하라.
81. 일정(오픈)이 지연될 때는 납기지연을 최소화하기 위하여 최소한의 기간만 연장하라.
82. 방법론은 프로젝트를 성공으로 이끄는 만병통치약(Silver bullet)이다. 어떠한 상황에서도 방법론을 지켜라.
83. 프로젝트는 지연될 수밖에 없다. 적어도 목표 기일보다 30퍼센트 이상 단축한 개발 기간을 개발자에게 제시하라.
84. 프로젝트를 착수할 때에는 수행 Activity, 기간, 산출물이 불확실할 수 밖에 없다. 개략적인 계획만 수립하고 계속 보완하라.
85. 프로젝트 기간을 산정할 때, 운영 지원을 위한 기간을 고려하지 마라. 고객에게 잡히기 시작하면 한없이 길어져 개발자만 고생한다. 오픈 하는 순간 철수하는 것이 지상의 목표로 설정하라.
86. 납기를 최우선 항목으로 관리하라.
87. 팀원에게 비현실적인 프로젝트 마감 시한을 요구하고 명령하라.
88. 프로그램의 품질은 개발자 자신의 책임이다. 본인이 테스트하고 본인이 결함을 수정하는 것이 효율적이다.
89. 자동화 툴이나 CASE툴은 생산성 향상과 기법 숙지의 첩경이다. 모든 개발자에게 생산성 향상을 위한 툴 적용을 강제하라.
90. 프로그램 코딩 관리에서는 품질보다 일정이 중요하다. 어느 정도 완료되었으면 코딩 완료로 인식하고 미흡한 사항은 통합 테스트를 할 때 보완하는 것이 효과적이다.
91. 결함을 발견하면 직접 개발자에게 구두로 이야기하여 신속하게 수정하게 하라.
92. 품질을 높인다는 것은 생산성을 저하시키는 길이다.
93. 분석과 설계단계에서 품질을 검토하는 것은 시간 낭비이다. 어차피 시스템을 개발하고 나면 테스트 기간 중에 고객의 변경사항은 나오게 되어 있으며 그때 반영하면 된다. 미리 에너지 낭비하지 마라.
94. 프로젝트 수행표준을 무시하고 창의성을 발휘하라.
95. 고객이 생각하지 않은 깜짝 놀랄 기능을 준비하라. 마지막 검수에 아주 유효한 카드로 활용될 것이다.
96. 응답속도, 허용 오차율 등의 중요 검수 기준을 사전에 정하려고 하지 마라.
97. 선택한 기술의 변화에 대해선 무시하라. 낙장불입.
98. Prototype을 만드는 경우 시간을 충분히 가지고 충분히 검토하라.
99. 여러 가지 오류나 결함들은 일괄적으로 모아서 수정하라.
100. 각종 명명 규칙은 개발자의 편의를 고려하여 임의로 하도록 하라.
101. 그리고 당신, PM.