标签：style blog http color 使用 ar sp div 2014
场景再现
=====================
{电话对话}
甲方{小刘}：喂，你好，是李经理吗？
乙方{小李}：你好，我就是。
甲方{小刘}：刚才接到A工厂负责人的电话，他们希望在原系统上针对A工厂做一些特制机能模块追加。
通过某些“开关”设置，不会影响到其他工厂的使用。
考虑到该系统已经进入开发中期，追加A工厂要望势必会增加成本和时间，你先估算一下然后后再决定是否实施。
乙方{小李}：好的，这就安排人去调查，有结果后电话再联系。
耗时40小时之后，{小李}把变更范围、成本、时间等相关信息告知了{小刘}。
=====================
有朋友很疑惑“这套路没问题呀，换做是谁都是这样做的。”
“没错，换做是我也会一样这么做，但是.........”
项目管理过程中，有一个不成为文的规定(15%原则) ：
→管理时间一般要占据项目工作总量的15%。
例如，{场景中}项目预估需要1000小时，那么分配给项目管理的时间大约是150小时，给客户报价的时候，整个项目将是1150小时。
→管理时间一般包括进度管理、QA管理、分配任务、有效沟通、风险管理等活动的时间，变更管理也在其中。
→15%原则的前提是假设项目管理都是一些常规、典型活动。当然了，这个百分比也不是一层不变。
项目经理处事风格不同，百分比也不同；项目本身复杂度不同，也会左右这个百分比。
比方说，项目计划很复杂、资源很难调配等因素，都有可能使这个百分比达到20%～25%，甚至是25%～30%。
从上面三点不难看出，管理时间已经预留了一些项目变更的所需时间。
所以多数管理者（包括我）都认为“{场景中}甲方依赖给乙方的调研、评估、报价是合情合理的，乙方花时间对应并将结果告知甲方也顺利成章的事，没什么不妥。”
{场景中}中{小李} 耗时40小时，把变更要件梳理成案，不觉得有一点点违背15%原则吗？
项目管理时间是包含项目变更管理时间不假，但这仅局限于花费少量时间去对应。像场景那样耗时近1/3的工时做一次项目变更请求的调研、评估、报价，不觉得有些奇怪吗？
项目所需1000小时，项目管理仅为150小时，仅仅一个A工厂特制机能追加的调研、评估、报价就耗时40小时，很明显管理时间不足以处理这件事。
{小李}不应该急于着手A工厂特制机能追加的调研、估算，而是:
▲判断是否能在项目管理时间内消化 (如果消化不了，需要估算出所耗时间)
▲调研价值 （甲乙双方合意）
▲项目影响 （乙双意见）
类似这样的事，一定要让项目发起人了解这个请求的特征，然后确定调研的价值是否抵得上对项目的影响。
如果发起人能够接受调研给项目造成的影响，他们在必要时应当延长进度、增加预算，因为正常分配的项目管理时间中没有包含对此次请求的调研。
上面我仅讲述了一个项目变更的例子，其实在项目管理过程中有很多侵占你15%管理时间的危机，只是你没有觉察到罢了。
想必有多数项目经理和{小李}一样，认为“甲乙双方的天平在签约那一刻起就已经倾斜了，乙方遵从甲方似乎是求生之道。甲方一个依赖，乙方应该无条件服从。”但你丝毫没有觉察到哪些是15%原则内？哪些是15%原则外？一个劲蛮干只会让你的管理时间越来越少。当你哭着喊着咆哮 “管理时间去哪儿”时，没人会同情你，因为没有人知道15%原则内的事，在他人眼里你做的一切都是你应该做的。
别问我是谁,我叫雷锋。
标签：style blog http color 使用 ar sp div 2014
原文地址：http://www.cnblogs.com/xiaohouchengzhangji/p/4008762.html
