好像做PMO没有PMP不太说得过去。首先承认，PMP是个好东西，好处要留给培训机构去说，但是怎么去用，好像很难给你环境规规矩矩去用，就连裁剪完还得变个样。此处想引用两道曾经被面试的题，从PMO的角度说起
先说第一个，如何分解好一个WBS。
太多的教程，大同，很多都懒得小异了。说来很简单，一层层，一步步，但是这个真的是让项目经理最头疼，也是最手疼的事。绝大多数的项目经理都是根据一个项目的经验来做类似的项目分解，通过业务的相似性寻找WBS的通用性。国人的做事思维，这东西拼起来就是详细需求，具体化就是要做的任务，可以说谁有了这个东西，谁就可以去吃这条业务线的饭了。
我要说的，与其说是方法，不如说是我的一点感想和经验。和所有项目经理一样，我也为这个东西头疼许久，特别是开荒的项目，看着一篇需求脑袋能空白很久。16年有一个不大的智投项目，由于没有带队，所以我临时上任，只有一个看不出直接任务的详细需求和一个最终上线时间，还有两个有一点经验的组员，于是我和老板有这样一段对话，对话是从老板开始的。
“有什么看法”
“说不清”
“需要派人来帮你吗”
“我觉得先不用，这之前有件更重要的事情要做”
“是什么”
“我想自由发挥一下”
当时只想了一句话，就是最好的方法就是不要拆分原子任务，不要做规划，但是我没说，老板的想法是稳妥的，他绝对不允许一个极限编程的形式存在，何况是一个本职PMO的人员。
但是当时的做法也不止是因为我做不出来就大家一起做，只因为这个可能最后什么东西都出不来，是因为我先把详细需求发下去，迫使他们有自己的反应，找到他们有想法的部分，还有就是，任务之间的关联性很高，耦合性很强，尤其是研究性任务，结伴学习要来的更快，而且收益更大。就这样，大家草草列了个提纲，开始动工了，我们更多的是从职能上分工，而不是任务上，我们一起学习攻坚，他们负责将成果转化成交付物，我负责保障和检验效果，后来引入了一个测试人员帮助我们完成测试，从头至尾只有一份需求和一份测试报告。
听起来好像很敏捷，好像也无关WBS什么事情，也不在PMP的范围。我想说的是，从项目经理的角度来讲，看WBS无非是最底层的任务，任务是由人来完成的，那么人对于任务的看法是不一样的，根本原因是任务的大小是没有什么衡量指标，尤其是项目经理对需求的把控不那么好的时候（感觉就是老师问懂了吗，答不懂，老师问有什么问题，但是又问不出，此处先不考虑需求变更），不妨列几个大模块，大家依自己的想法先干活，边做边细化，做完再细化，也挺好的，如果你非要说细化任务是为了估算时间，那我们就不估时间了，上手的时候相信每个人心里都有个时间钟，并不是非要像定闹铃一样，如果你说那怎么保证总体时间，那么项目经理的时间钟就是保证，如果你说怎么衡量绩效，那么项目绩效不说了，个人绩效恕鄙人见识短浅，我见过的都是拍脑袋，当然你可能会说，每个项目都这样领导不是没法监控了，所以回到前提，当项目经理对需求把控不好的时候，以及，实施能力能不能大概cover住需求的时候。当然，关于可能的无用功和领导压力，项目经理要有自己的处理方法。
但从PMO的角度来讲，他会要求你细大不捐：我要看到最具体的，这样才有量化你的指标。现在想来我依然觉得，WBS这东西，可以边搭着服务器边写，边写着代码边改，很想说当时在PMO时每周去追踪项目组的WBS做报告，很蠢很无奈，因为到底怎么样，只有在项目一线的人最清楚。
而我当时是被从PMO借调，所以我给自己开了绿灯。
再看第二个，如何处理变更。
面对项目工期不合预期的询问，项目组最多的反馈就是需求有变动。学PMP时老师说牢记一句话，有变更、走流程，但是对于IT类项目经理，大多数的变更都自己私吞了，可能一方面要考虑工期，一个能做的变更经过了评审，最后很可能还是需求说的算，所以两人一拍这东西就做了，更和况很多公司连对变更的审核都没有，有个跟踪就是很好的事情了，另一方面项目经理要做个好人，能做我就尽量做了，两个人能定下来的事情按规章制度走，显得我太死板，撕破脸皮总是不好的，还有很多乙方项目经理，根本没什么话语权，低头干事就完了。
所以，PMO很多情况都不会预先知道需求要变，直到任务的截止日期出了问题，回头去核实，才知道需求已经变了。曾想过通过抓取流程工具的任务制作报表来做监管，但是我们不可能区分出任务是新增的还是拆分的还是由于需求或相关系统变动衍生的，区分不了就要核实，这个做法就显得很愚笨了。
但是，管还是要管，因为很可能因此从源头上就产生风险。
怎么管，我找到了我的靠山，测试。
思路是，一份修订过的需求，是需要同时分发给开发和测试的，而测试比开发更不希望有变更，因为他们更直接的面对生产。那么，联合测试，就形成一股强大的动员力量。首先，将需求管理工具与流程管理工具集成，避免需求私下交流，然后，对于项目经理的排期，测试具有否决权，并有权重新排布时间节点，或重新进行协定评审，由于背靠职能型的组织架构，测试的绩效是由测试团队考评，不能由项目组消化，时间节点就是重要的参考项，项目经理更希望中间时间点能灵活变化，而测试并不希望时间上出现偏差。
因此，测试便成了确定变更需不需要监控的关键一环，他们不止解决了系统功能上的风险问题，还解决了变更可能带来的风险，他们比PMO更加了解哪些变更需要监控（测试的业务能力往往比开发要强）。可能有人说是个项目经理什么模式下都会去找测试协商，但是如果项目经理全权组织需求变更的评定，那么对PMO来说，过程将不再透明，监控将变得困难。
以上是变更在流程上的的管理，需求变更为其中一例，还有一种是其他人拍脑门的。
有一个老生常谈的关于变更控制的方法，就是配置管理。近年来鼓吹了很多所谓devops一体化，开发运维不分家，老东家为此专门成立了运行管理部门来配合开发、运维、运营之间的协调，半年后宣告解散。我觉得大家的理解，一套UCM（统一变更管理）加一个自动化构建的工具，就是devops了，那这个东西还真没什么意思，至少我上学的时候就知道可以这么做了。后来工作中还讨论了怎么样处理关联系统的问题，我也没有在devops中看到此类描述。那么追溯根本，无论是自己手动还是全自动，依据的都是一个正确的版本和一个备份的版本。版本问题人尽皆知，办公室常出现以下交流：
“A功能有没有上测试环境”
“你们关联的X系统版本更新了吗”
“上生产的版本是M测试机上还是N测试机上的”
“准生产和运营环境版本是一样的吗”
走过几家银行，各个环境的管理都不相同，就说测试环境，有开发人员管，测试只管测的，有测试人员管，让开发上才能上的，还有专门的部门人员用来上测试环境的。貌似各有各的道理，又各有各的弊端。在刚做PMO时我就开始建设版本管理工作，不谈最优解（老东家的环境管理解决方案是PMO组最完美的工作项之一，方案加密），毕竟谁都能讲出自己的道理。
回归正题，版本上怎么来控制变更，主要解决的问题，很多开发人员直接在测试环境就改了东西加了东西，很皮。
有的人不承认这是变更，我觉得这是，确实是变了啊。有的人说这在理论上不合理，但是在我的工作中太过常见。
就是那个老气横秋的方法，自动化。如果做不到，那就避免用户界面。最廉价的jenkins-svn/git模型，应该依旧是风靡的自动化方式，如果可以，再集成进去流程管理，所有的管理就实现了一体化。
从需求到生产，整个过程其实就是一个流水化的生产线，一个角色做了一件事，交给下一个角色加工，再交给下一个，最终形成交付品。流水线的风险取决于其中的每个点会不会犯错，那么既然是流水线，就尽量不用人来做，监控的方法也很简单，由下一节点决定上一节点的质量，而最终质量收回到PMO手中，也就是只要保证所有节点都被实施过就可以了。例如，开发不能私自掺杂变更，在版本中会被测试发现，测试也不会直接修改生产的版本，因为在PMO手中有备案。
作为PMO，我在建设了自动化构建项目后就没有再去关注项目组版本的问题，我们当时的流程不再需要去做版本审计之类的事情，因为各个节点都有人在关注，我要做的，就是关注一下生产版本的基线与生产版本状态是否一致，是否发生回退等问题，也就是有没有上线成功，做最后的流程确认。
以上是从版本上减少变更风险，让人减少对版本移交的过程干预，可以避免私自变更及人工失误带来的风险，保证任务和版本的统一性。
一年工期，完善了自动化构建和流程管理，除了系统级维护，没有做过什么大的改动。
以上为一家之言，仅供参考。