一个PMO的诞生--PMO组建与运营实例

很多企业对于项目的态度越来越多的从关注传统的项目的进度、质量、范围、成本，转向于关注项目所实现的价值。从而有计划的组建项目管理办公室（PMO），至于PMO是什么，应该包含什么样的职责，有很多很多的大神写过很多很多文章，在这里就不多赘述了，我主要说说，我们是怎么逐步组建PMO组织的。
我们的背景是一家高速发展的基于汽车行业的互联网公司，业务涵盖了车联网，汽车金融，汽车保险等汽车后市场服务，项目基本上是基于产品规划的多版本迭代项目。因为成立时间不长，然而业务发展非常迅速，从而造成市场需求及其的不稳定，使得研发团队苦不堪言，通常的情况是，昨天刚刚新版本上线，明天需求又改了，并且，在项目需求更改的情况下，一部分项目参与人员并不知道需求已经变更。在这件事情上，研发团队与产品团队逐渐的产生了隔阂。
于是在15年9月的一个早晨，决策层痛下决心，决定由我跟另外一个同志成立产品管理部——请注意，当时的名称还不是PMO。产品管理部的主要职责是要与产品部门对接，梳理项目需求，并协助产品经理编纂符合要求的项目规格说明书和PRD文档，必要的时候，要求产品部门绘制产品原型。从而首先解决了产品团队需求规格符合度的问题。但是原有的问题并没有得到彻底的解决，我们决定，将所有人员（其实加我本人就俩）下放到项目团队，跟踪团队的需求获取情况，惊讶的发现，多数项目需求来源惊人一致的不统一，有的是产品提出的，有的是客户提出的，甚至还有测试部门和UI部门提出的，更可怕的是竟然还有自己想出来的。学过PMP的同学都应该知道，这种东西叫项目镀金，对项目的健康状况有很大的影响。于是，经过充分授权，产品管理部制定并发布了一系列的需求管理规范，包含需求来源的唯一入口原则，需求变更的基本流程和信息一致原则等规范和流程。经过一段时间的运行和推广，基本解决了这一关键痛点，从而使得项目研发团队和产品团队和谐共赢发展，从专业技能、管理技能和整合程度上都有一定的促进作用，大家更像一个项目团队了。从而，我们定义的产品管理部，或者说PMO的第一个职能——需求管理和变更控制。
当我们深入到项目组，随着项目的逐渐演进，发现的问题不仅仅是需求范围这一个方面，我们还发现了更大的问题。我们公司其实对项目管理，或者是说叫项目管理的落地工作起步非常早，早在15年初，我们引入了著名的项目管理工具JIRA。但是从引入的那一天开始，此物就饱受非议，有人说这个工具太复杂不好用，有的说我们的项目不适合这个东西。但是事实上是，由于我们的项目组织比较松散，而且之前的管理规范大多数都是拿来主义，并不适合我们这个阶段和我们项目的特点。所以，首先我们对现行的组织级项目管理规范和流程与项目真实情况做了一个对比和梳理。发现，拿来的项目管理规范和流程并不能得到多数的项目经理和团队认可，于是，我们根据项目实际情况修订了一系列的项目管理规范和流程。并且对JIRA进行了流程定制和集中管理。做到了从需求、任务、测试用例、缺陷整条研发线路的通车，能够一站式的追踪、统计。从而，无论是从理论还是实操，得到了多数项目经理和项目团队的认可。并还在不断的接受新的意见和建议，不断的演进。2016年4月，正式更名为项目管理办公室（PMO），形成了我们的第二个职能——组织过程演进。
对于程序员来说，最不喜欢的事情是什么？答案会有很多，但是一定会包含的是改需求、写文档。对于一个高速发展的公司来说，业务和管理应是相辅相成的，但是对于我们来说，业务明显是跑在了管理前面，虽然我们有规范的流程。但是从执行层面来看，简直是一塌糊涂。我们想了个最笨也是最有效的办法——我们来帮着做。在规范推广的阶段，不管是程序员还是项目经理（其实我们的项目经理应该叫主程才对）都有一些不同的意见。于是PMO派遣专门的协调人员加入项目组，协助项目经理去做一些他们不愿意做的事情，我们管这个岗位叫项目助理。请注意，不是我们代劳，我们更像一个闹钟，到了什么时候该做什么事，我们去提醒项目经理，有必要的时候，还会对项目经理进行专业的指导。随着时间的推移，项目经理逐渐的能够对流程和制度深入了解，项目助理的工作范围基本包含了项目过程中非工程类的所有内容，包含但不限于风险识别和风险管理、沟通协调、配置管理、度量、组织评审等工作。这就是我们PMO的第三个职能——项目行政。
虽然从制度上，我们做到了尽可能的规范，从工作上我们尽可能的协助，但是由于发展速度太快，再加上多数项目经理都是程序员出身，最困难的事情就是如何转变程序员的思想，使之成为管理者。对于大多数程序出身的项目经理来说，有的是赶鸭子上架逼上管理岗位的，有的是主动转型成为管理者的，对于我们这个团队来说，前者占到了大多数。所以，大家对流程、文档等非生产类的东西还是持有一些不同的态度，只是知道要做，但是根本就不清楚为什么和怎样做的更好。我们PMO觉得有必要帮助他们完成角色转型。所以，在集团培训部门的帮助下，PMO针对项目经理，规划了一条自我提升的道路和相应的培训课程，并鼓励项目经理去报考比如软考高项、PMP等认证。并在人力部门的指导下，规划了项目经理技能等级，以及相应的晋升机制。至此形成了PMO的第四个职能——培训学习。
当一切都运行顺畅，另外一个问题又出现了。对项目如何评价呢？每个项目都是由项目奖金的，项目组的每个人都应该拿多少，A项目和B项目的复杂度、规模都不一样，应该怎么评价项目整体的好坏呢。这次要跟钱打交道了，PMO自己的力量是远远不够的。在公司和集团领导的支持下，我们组织各工种（UI、前端、程序、移动端、测试、产品等）大牛们，成立了专家评审委员会这么一个虚拟组织，由项目助理，通过项目过程和工程数据的度量，对项目的健康状况、过程执行情况、人员绩效、质量情况组织评价。通过评价结果，使用已定义的计算方法对真金白银进行计算，由人资专员统一进行分配。这个过程，使用的是非项目干系人，或者说是非项目直接参与者，更加客观，使用数据说话，由项目经理答辩，我们公平、公正、尽量公开，避免了项目间和项目组内的不少矛盾。这就是我们PMO的第五个职能——项目绩效。
至此，PMO发展不到3年的时间逐步形成了需求管理和变更控制、组织过程演进、项目行政、培训学习、项目绩效等五个关键职能，还有更多可以做的事情还在不断的尝试和摸索，所有的目的都是希望项目和产品线健康发展。能在项目价值和项目消耗之间找到平衡点，不仅仅是经济效益，还对团队演进、公司发展起到了一定的作用。将来，我们会更倾向于将流程和价值挂钩，保证自身发展的同事，更多去尝试一些管理方式和方法，让PMO和公司的所有项目组共同发展。
我认为，我们的PMO之所以能有现在的发展，有几个关键：
1、公司和集团领导的重视和扶持；
PMO从最初成立的2个人到发展到现在的16个正式成员，中间也不像我上文中表达的那样顺利。在PMO建设的这条路上，有领导的支持是首要的，因为你这样一个部门可以说是没有工作成果的，这就需要领导有一个长远的眼光和对发展的决心，虽然建立PMO组织是当今企业发展的必然趋势，但是要培养、建立这样的一个组织也是需要一个漫长的过程的
2.坚持正确的方式去做正确的事；
在很多的情况下，PMO是得不到大多数人认可的。有的人会认为你是不是故意来找我的麻烦，这就好像在本世纪初流行的软件企业都有QA的那个感觉差不多，当年我做为项目经理也骂哭过QA。现在再做这件事，我能够感同身受，在保证充分沟通、不违背原则的情况下，PMO的工作方式必须足够的灵活，这就是我们所谓的用正确的方式去做正确的事
3.充分建设自身的知识体系，保证理论基础，并落地实践；
打铁还需自身硬，这句话是一个PMO组织中所有成员都应该记住的一句谚语。没有理论基础就没有话语权，没有实践就没有真理。在组织项目管理过程中，都是摸着石头过河，PMO的成员在把自己建设好的前提下，才有机会通过实践摸索出一条适合本组织的项目管理体系。
4.创新并更新自身。
我们能看到白纸黑字的项目管理经验和最佳实践，我们也可以拿来主义直接照搬好的项目管理体系。但是我们没有这么做，我们做应该叫有公司特色的项目管理体系，我们PMO连续2年获得集团最佳创新团队奖。我们的每一个实践、每一条规范都是通过调查、问卷、试点等一系列过程才发布的，不合适那就忘掉她再重新来说。其实管理才是最需要创新的。
对于我们来说，PMO的职责可能不像书上写的那么规则，但是我们做了领导放心、团队基本满意，各部门合作共赢和谐发展。但是过程还是非常曲折的，有抱怨、有投诉、甚至有冲突一直在发生。但是我们相信在发展的道路上，我们PMO是必不可少的一个环节，所以我们一直在努力，一直在坚持。虽然不是适合所有的组织，但是我还是希望，这篇文章能够给看到的人一些启发。（本文首次发表于《中国项目管理最佳实践》，版权归属：中国国际人才交流基金会，转载来源于：懒人项目管理 作者：挨踢大懒）