转自同事H的项目总结中关于工作量的自身经历和思考，并且提出自己的建议，供读者思考。
————————————————————————————————————————————
场景：
这里讨论的不是项目立项前的工作量，而是项目立项完毕、总体工作量既定情况下，变更工作量可能会遇到的问题。项目经理H，经历了项目A这个有关工作量变更的项目。按照原有需求，功能完成后系统已经投入正常使用。但无论是界面还是功能逻辑方面，客户希望做一些修改，并愿意接受变更的工作量。项目经理H就针对需求变更内容，具体到功能点，剖析了每项任务各个阶段需要的工作量。如下图，是其中一个模块的工作量清单。
（暂时由于博客图片的系统错误，等系统正常后补图）
项目经理H整理了所有需求变更内容，总工作量是120人日。商务人员L就拿着这些整理的文档跟客户进行沟通。业主代表G看到了功能点和工作量清单，认为清单里面有些“水分”，跟商务人员L要求在总工作量上减少15人日。该业主代表G跟项目经理H和商务人员L所在的开发商公司不仅一个项目的来往，有比较紧密的合作关系。出于这方面考虑，商务人员L就和项目经理H商量，是否可以把这15人日的工作量“和谐”掉。虽然项目经理H认为自己列出的工作量清单已经很清晰和合理，但无奈也得接受工作量被“和谐”的结局。最终，三方面人员达成共识，按客户代表G的意见，总工作量减少为105人日。
思考：
针对上述项目A，不能不让我们进行反思，有关项目总工作量外的其它工作量的处理问题。
站在项目经理的角度，是不希望把自己项目的工作量拖延到下一个、或者是其它项目里面，因为那样处理的不可控性比较大。当然更不希望项目工作量被无情地“和谐”掉。
商务人员的立场，也希望项目组的工作量得到承认、取得应得的回报。但往往是工作量不大的情况下，为了处理好跟客户的关系，才不得已接受“和谐”工作量的做法。
业主客户方的角度，一般情况下也不会为了贪图一点工作量而厚着脸皮去跟商务人员、项目经理在周旋着。一般导致他们希望采取“和谐”措施的，有两方面的原因：一是因为要执行需求变更的操作性，就要重新向上申请走一些变更流程。而在他们角度是不希望一个项目走几次这些向上级申请的流程的，无论从手续、从工作效率方、可操作性方面，他们都希望避免的。二是客户认为项目经理提出的工作量含有“水分”，并不是真实的工作量。
因此，针对以上三方面角色的考虑，在现有项目的处理流程、处理方式上，是不可避免地会再出现客户希望“和谐”工作量的情况。
建议：
1、签订项目合同的时候，开发商和用户方达成共识，预留一定的工作量，作为以后项目可能需要变更时候的工作量。如果项目完成得很理想，就不需要花费那部分工作量，对双方都没影响；而一旦有发生工作量，则可以用那部分工作量来处理，也不至于出现为一点工作量争执的情况。
当然，关于预留工作量，最大的受益者应该是开发商方面，因为预留工作量保障了项目额外花费的工作量得到回报。而对用户方，主要受益是避免了要走变更流程、重新申请工作量的情况。所以，一般情况下作为开发商的我们，应该尽量引导用户方，让他们知道预留工作量对他们、对我们的意义所在，尽量减少项目由于工作量而引起的争议。
2、项目经理在处理工作量的时候，必须清晰、明确、趋向真实和合理。例如在某个模块要变更的时候，必须明确列出模块的功能点，以及分解每个功能点需要的工作量。在处理每个需求点的工作量的时候要不断质疑自己，客户是否会对这个需求点提出质疑，自己是否能给出支撑的依据。先过得了自己的质疑，再去接受客户的质疑。
愿望总是美好的。具体的实施就需要业务人员和项目经理的共同努力，让用户方理解并且接受预留工作量的措施；项目经理应该努力做到工作量的分解清晰和合理，让客户坦然接受。虽然如今要建设“和谐”社会，但不应该把项目组努力的工作量也“和谐”掉的。