在前文中，笔者比较鲜明的提出了“不重视文化建设的PMO没有灵魂”这个观点。
那么为什么PMO需要特别关注文化建设？PMO应该如何接地气的开展相关工作呢？
我们今天就来探讨一下两个问题。
为什么PMO需要关注文化建设
我们还是从PMO的本源--“项目管理”的角度来入题。
我想任何一位项目经理除了要运用PMBOK中关于项目时间、范围、成本等等一系列的专业技巧来达成项目目标之外，一定不会忽视一个PMBOK中没提到的因素：团队“士气”。
注：最新版的PMBOK 7 中也大幅增加了有关于团队的内容，说明PMBOK也意识到这个“无法名状”的领域的重要性。
士气是什么？士气说白一点就是团队用一种什么状态把事情干了。
士气是“楚虽三户，亡秦必楚”，士气是“宜将剩勇追穷寇”，士气是“一而鼓，再而衰，三而竭”.....士气的高低，往往会对事件的最终走向起到决定性的影响。
而士气又是“看得见，摸不着的”。
为什么这么说它“看得见”？以笔者的经验，即便作为一个项目组的“外人”，你是能够通过与项目团队的一次讨论，一次会议，或者一次发布协同，就能够切切实实的感觉到团队的“士气”是高是低。
那为什么“又是摸不着”的呢？因为你很难准确的确定做哪些事情可以提升“士气”，更不用说具体可以提升“多少”士气......
基于此，虽然每个项目经理的做法可能都不尽相同（比如聚餐，小型庆祝仪式，打鸡血，真金白银或者“画饼”等......），但关注和保持“团队士气”一定会成为项目经理工作计划中的必然选项。
以此类推，我们说项目经理需要关注项目团队“士气”的话，那么作为PMO，就必须要关注整个研发团队文化建设。
“且慢！”一些思维逻辑缜密的同学发言了。“我同意研发团队文化建设非常重要，但一定需要PMO来么？差点被你带节奏！我们一般印象中的文化建设，不是应该由HR（或者时下比较流行的HRBP）去做么？”
但笔者的看法则不同。
文化建设一定是“润物细无声”的，而并非是轰轰烈烈的运动，所以需要在日常工作中与研发团队紧密配合的角色来开展更为合适。
因为研发人员工作的特质，你很难想象一个人啥事不干就在程序员写代码的时候就那么待着，所以HRBP的工作根本进！不！去！更不用说是在“局内”有着各种“爱恨情仇”的产品、开发、测试等角色了。
正因为PMO与各角色的配合比较紧密，也相对更加中立，是进行“团队文化”建设的最佳选择！
我们了解了PMO为什么要关注文化建设之后，接下来跟大家聊聊怎么做。
总体上说，PMO可以从“一虚一实”两个方向开展文化建设工作。
树立“工程师文化”
研发PMO服务于研发团队，文化建设的工作目标是帮助研发团队树立一个健康的“工程师”文化。
简单来讲，就是：我们提倡什么，反对什么；奖励什么，批判什么......用最简洁的方式从感性的角度给团队定个调。这......果然很虚呀！
还是以我加入创业公司的心路历程跟大家打个样，供大家参考吧。
记得当初加入创业团队在Wiki上写的第一个网页不是什么流程制度，联系方式什么的，而是这么一句话和这么一张图：
Our Tag ：“严谨，积极，创新，分享” ；我们是攻无不克，战无不胜的攻城狮！
“攻城狮”和图片多少有些打鸡血的意味，但那八个字却是我们研发团队“工程师文化”的雏形。
以前我对于企业搞什么“企业文化建设”总是觉得难以理解：花了不人力物力，实际上到底有什么收益？难道就是停留在员工手册、宣传海报、员工脑子里的几句话么？“我要这铁棒有何用~”
随着自己PMO工作经验的增加，特别是加入到创业公司以后的观察发现，才发现“文化”其实无论对于企业还是员工都是一种更加有效率的“工具”：其一用于组建团队；其二用于日常工作决策。
组建团队
拿我们提出的八个字（当然你的团队完全可以是别的）来举例：我们需要严谨的人，不需要随意的人；我们需要积极的人，不需要坐等安排的人；我们需要有创新能力的人，不需要循规蹈矩的人；我们需要乐于分享的人，不需要故步自封，搞小圈子的人......
当然以上的一切可以通过更加细化的所谓“能力模型描述”来对应到更加可以实操的层面：如怎么定义“严谨”、“积极”等等，但在这一切都还没有的时候，以上几个看似感性的定义就足够了。退一万步讲，即便以后组织规模变大了，有非常多的维度来衡量团队成员，我也会在“套用完一系列工具之后”，去繁存简，用这几个简单的词来支撑最终的用人判断。
大家也许听过一句话：“读书要先读厚，再读薄”。我们设计一个流程，去执行一个过程，又何尝不是如此呢？
日常工作决策
笔者非常认同一个对于“文化”的定义：对某种价值和秩序有所坚持，对破坏这种价值和秩序的行为有所抵抗，是为文化。
一个公司或者说一个组织的规章制度不可能完全细化到每一个场景应该如何处理，基层员工最基础“条件反射”，靠的就是“文化”。
比如，这段代码虽然就改了几个字，没经过测试就发布，严谨么？
这有一个明显的Bug，但跟我手头的任务没啥关系，多一事不如少一事，积极么？
反复搭建测试环境又无聊又低效，但大家都这么干，我为啥要起头开始“自动化”，创新了么？
这个第三方库还真好用，告诉别人那我不就没那么牛B了，分享了么？
......
同时，这个定义也告诉了大家要想在组织/公司里生存和发展的“密码”。
如果你自己能够在组织里对某种秩序和价值有所坚持，即能做到到“严谨、积极、创新、分享”，那在组织里生存无虞；如果你不仅仅自己能做到，还能够对于“不严谨，不积极、不创新、不分享”的行为说不，让周围的小伙伴都做到“严谨、积极、创新、分享”，那你一定能够在组织里得到更好的发展，承担更多的组织责任。
一个“空降”的项目经理要开展工作，一开始最需要注意的因素其实不是别的，恰恰是“企业环境因素”；
同理，一个PMO要开展工作，一开始最需要注意的就是研发团队的“文化”。
综上，PMO应该首先了解研发团队的“工程师文化”，如果没有？那就输出一个！
然后呢？
PMO在日常的工作中可以身体力行，宣导和践行这种文化。
项目这个载体基本可以涵盖研发领域的绝大数事件了，我们可以通过一个个的项目实施，让这几个字不单单印入研发团队“脑髓”，而是深深植入研发团队的“骨髓”。就像提到“不抛弃不放弃”一定会第一时间想到“钢七连”一样。
打造“技术品牌”
聊完了虚的，下面我们聊聊实的部分。
笔者认为，PMO对于文化建设可衡量的输出物就是对于研发“技术品牌”的打造。
这个工作又可以从“对内”和“对外”两个方向分别展开。
对内：
一个有影响力的“技术品牌”，自身的技术实力一定是过硬的，内部运作一定是高效的，工作氛围一定是工程师们喜爱的......
如何能够做到？解法本身就涵盖了非常多的本身PMO的工作范畴。
比如，是否有稳定的技术产品输出，研发流程/研发工具是否高效这本身就PMO的工作重心，其核心就是如何衡量以及不断提升“研发效能”；
是否使用先进技术，拓展先进技术的实际应用场景，这也可以通过控制“创新性项目”投入（创新性项目立项比例或者项目中创新性任务比例）来平衡和落地；
至于工作氛围，其实项目也是一个重要的抓手，项目结项（或者Retro）时对于项目参与满意度的了解是更为全面和实时的反馈，这比半年度发起一个全员调研，获取一个偏感性的评价要靠谱的多......
至于表现形式，相关流程/工具的引入和落地，优秀项目/技术奖项的表彰，技术社区的建设（内部定期分享机制），工程师文化氛围活动的组织等（如Scrum Hero ，“1024节”，Hackthon等），每一个都是PMO可以立马着手行动的“文化建设项目”。
对外：
对外的工作简单说来就是对外宣传，让更多的人知道。常见的方法有：公众号的运营，行业大会的参与，开源项目等等。
技术品牌的建设一定是由内及外的。如果没有花一定时间和精力有意识的去内部沉淀，对外的工作一定是无源之水，无本之木。
比如，如果平时没有例行的分享机制，让一些有技术能力的小伙伴上台锻炼，你面对几十人的场子都手发抖，嘴发干，那有朝一日让你去几百上千人的“大场面”你如何能hold得住?
如果没有平时在项目进行中把一些技术经验和心得及时总结，那公众号的内容难道都放其他公司的？
如果日常代码非常随意，你好意思开源出去“走两步”？
还有一个小点，比如专例的申请也是一个看似不起眼却挺重要的事情。当然这是技术品牌一个比较硬的指标，除此之外就是可以争取到非常多的政策补贴，对于企业来说也确实是真金白银。笔者经常笑称，我们项目集经理干的累死累活，还不如我们申请专例的同学ROI高......
对外的工作做的扎实，又可以反过来促进内部的工作：优秀的团队总是能够吸引更多优秀的人才；如果我们不能一贯/全员做到我们所“宣传”的那样，一定是一件特别“没有成就感”的事情......
以上种种，无法一一细数，我想这就是文化建设相对困难的地方。但可以肯定的是，它就在你的研发团队中发挥着不可忽视的作用，默默改变着每一个人。
所以，笔者所在的PMO做了很多看上去跟“项目管理不搭界”的事情：比如“新闻站会”（站会利用很短的时间对于一些内外部新闻的解读，比如“收购”与“被收购”，竞对又放了什么“大招”），每周技术分享组织，技术社区的组织，月度生日会等等......
综上，因为PMO与研发团队的工作更为密切，同时PMO理应比项目经理更加关注组织长期发展，自然是进行研发团队文化建设的最佳选择，PMO应当有意识的去主导研发团队文化建设。
PMO应该洞察有关研发团队的一切，因为都有可能是PMO下一步的工作方向。瞅准了方向之后，持续的输出，日拱一卒，PMO最应该坚持的就是“长期主义”。
写在最后
如果我们把管理解构一下，会发现所谓管理无外乎是“事”和“人”两个因素。
回到项目管理这个细分领域，无论是项目经理还是PMO的工作都始终围绕着这两个因素展开。
“事”是“人”干的，“人”是通过“事”产生联系的。
项目经理因为项目的“短暂性”，更倾向于“用人做事”，目的是把项目干成了；
PMO更注重组织的长期发展，更突出于“借事修人”，落脚点在人。PMO通过项目这个“工具”，目的是打造一个卓越的组织。
无论你如何架构PMO，都不应该背离这个初衷。在研发领域，更是如此。
唯有如此，PMO才能在的日常工作当中多一些理解，把身段变得柔软，真正和研发团队打成一片；
唯有如此，PMO才能在日常工作中多一些耐心，给团队时间，跟随团队一起成长；
也唯有如此，才能将PMO真正“架构”在研发团队每一个人的心中：
无论碰到任何困难，都会第一时间来找PMO；
无论碰到任何解决不了的难题，都会第一时刻想起：PMO，Always by your side！
347
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
