秃头警告 | 年薪50万PM总结的20个成功项目管理经验
我们在项目型企业中，项目经理的能力很大程度上决定着项目的成败，而项目经理的项目管理经验也是必不可少。那么，项目经理在项目推进过程中，应该重视哪些方面的能力和技巧呢?
下面给大家分享的项目经理的20个成功的项目管理经验。
01
定义项目成功的标准
在项目的开始的时候，要保证风险承担者对于他们如何判断项目是否成功有统一的认识。
通常情况下，想要成功，就首先得跟紧预定的进度，但是肯定还有其他的影响因素存在。比如，增加市场占有率，获得指定的销售量，取得特定用户满意度，淘汰一个高维护需求的遗留系统等。
02
识别项目的驱动、约束和自由程度
每个项目都需要平衡它的功能性、人员、预算、进度和质量目标。
我们把以上五个项目方面中的每一个方面，可以定义成一个约束，而你必须在这个约束中进行操作，换句话说就是，你得在一个规定的范围内调整。
03
定义产品发布标准项
在项目早期，你就要决定用什么标准来确定产品是否准备好发布了。
你可以把发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其他方面表明项目已经达到了它的目的。
不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与你的客户要求的“质量”是一致的。
04
沟通承诺
尽管可能无意中承诺了不可能的事件，但不要做一个明知不能实现的承诺。
坦诚地与客户、管理人员沟通那些可能会产生的实际成果。
你以前项目的数据可能成为你说服他们的依据，虽然这对于不讲道理的人来说没有真正的作用，但是你最好还是要准备好。
05
写一个计划
困难的部分不是写计划。
困难的部分是作这个计划——思考，沟通，权衡，交流，提问并且倾听。
你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外风险。
06
把任务分解成棋子大小的小圆石
棋子大小的小圆石是缩小了的里程碑。
把大任务分解成多个小任务，可以帮助你更加精确的估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。
07
为通过的大任务开发计划工作表
如果你的团队经常承担某种特定的通用任务，你需要为这些任务开发一个活动检查列表和计划工作表。
每个检查列表应该包括这个大任务可能需要的所有步骤。
这些检查列表和工作表，将帮助小组成员确定和评估与他们必须处理的大任务的每个实例相关的工作量。
08
在质量活动控制后应该有修改工作
几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。
你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。
如果你事实上不用作任何的修改，很好，你已经走在了本任务的计划前面。
但是不要去指望它。
09
为过程改进安排时间
你的团队成员已经淹没在他们当前的项目中，如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投资一些时间在过程改进上。
从项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。
不要把项目成员可以利用的时间100%的投入到项目任务中，否则你会惊讶：为什么他们在主动提高方面没有任何进展。
010
管理项目的风险
如果你不去识别和控制风险，那么它们会控制你。
在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。
011
根据工作计划而不是日历来做估计
人们通常以日历时间作估计，但是我倾向于估计与任务相关联的工作计划(以人时为单位)的数量，然后把工作计划转换为日历时间的估计。
这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求，会议，和所有其他会让时间消失的地方。
012
勿安排超过工作时间80%的任务量
跟踪你的团队成员每周实际花费在项目指定工作的平均小时数，这会让人吃惊。
与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。
一个员工一周理论上工作40小时，但不要只是因为有人在一项特定工作上每周花费10小时，就去假设TA可以马上做4个这种任务，如果TA能够处理完3个任务，你就很幸运了。
013
将培训时间放到计划中
确定你的团队成员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。
你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。
014
记录你的估算和你是如何达到估算的
当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。
理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。
015
记录估算并且使用估算工具
很多商业工具可以帮助你估算整个项目。
根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。
它们同样能够帮助你避免进入“不可能区域”，即将任务量、小组劳动力和进度安排组合起来看，根本不可能成功。
016
遵守学习曲线
如果你在项目中第一次尝试新的过程，工具或技术，你必须认可付出短期内生产力降低的代价。
不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。
017
考虑意外缓冲
事情不会像项目计划一样准确地进行，所以你的预算和进度安排应该在主要阶段后面，包括一些意外的缓冲，以适应无法预料的事件。
不幸的是你的管理者或客户可能把这些缓冲作为你的托辞，而不是明智地承认事实确实如此。
向他们说明一下以前项目不愉快的意外，来证明你的深谋远虑。
018
记录实际情况和估算情况
如果你不记录花费在每项任务上的实际工作时间，并和你的估算作比较，你将永远不能提高你的估算能力。
你的估算将永远是猜测。
019
只有当任务100%完成时，才认为该任务完成
使用棋子大小的小圆石的一个好处是，你可以区分每个小任务要么完成了，要么没有完成，这比估计一个大任务在某个时候完成了多少百分比要实在的多。
不要让人们只知道他们任务的完成状态。
要使用明确的标准来判断一个步骤是否真正的完成了。
020
公开、公证地跟踪项目状态
创建良好的风气，让项目成员对准确地报告项目的状态感到安全。
努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。
使用项目状态信息在必要的时候进行纠正操作，并且在条件允许时进行表扬。
以上总结的这些提示或经验，或许不能保证你的成功，但是它们将帮助你在你的项目上获得一个坚实的把手，并且保证你做了所有你可以做的事来让项目在这个疯狂的世界上成功。
以上，希望对你有所帮助。