本文探讨了PMO工作中“懂业务”的重要性，并认为PMO需要有一定的业务理解和技术知识，在助力业务推进的同时也能更好地与技术团队沟通。而PMO在工作中需要怎样定位？如何懂业务呢？让我们看看作者是怎么看的吧~
作者力求观点的通用性，但PMO工作经历主要积累自互联网企业，部分内容可能会略有偏颇，欢迎指正。
职能领域（HRBP、OD、战略）有很多“长盛不衰”的“天问”。PMO也不例外。
例如：
究其原因，核心在于这些领域本身就分化自企业/业务一把手的大脑，去解决难以量化又必须面对的，没有标准答案又需谨慎决策与魄力推进的，灵魂拷问。解铃终须系铃人。
近日在“Space X社群”的一场以HR职能为主要方向的“关于到底什么是懂业务的讨论”尤为精彩，群主总结的大意“不纠结什么叫懂业务，能不能解决老板的焦虑才是硬道理”甚是直击本质，也激起了我想要说两句的欲望。在此文聊表关于“懂业务”的PMO自己的浅见。
PMO要不要懂业务，要不要懂技术，坦率说这个问题也曾困扰过我一段时间。一方面这个问题的答案并不那么影响工作，另一方面这里“懂业务”的范围确实不知道如何谈起。但就在准备写这篇文章前，逐渐有了清晰的答案。
我肯定地认为PMO是必须要懂业务的。差别只是孰轻孰重，见深见浅而已。
关于如何评价一个PMO是否懂业务，或者应该懂到什么程度，陆续听到过各有千秋的不同思路：
站在PMO岗位的角度看，以上这样形式的表达是较有感召力的，非常形象也通俗易懂，但存在的一个问题就是大部分这样的回答是基于自己有限的组织环境来输出的。
我们不否定以上回答在局部的适用性，但这些表达都太过于具体以至于没有清晰的表达出本质，对于“何为懂业务的PMO”？
这个问题我认为较本质的回答是：
“具备了可以支撑PMO组织定位下职责有效完成的相应业务知识的PMO，就是懂业务的PMO”。
听起来像不像是一句“废话”？但或许就是因为它过于“废话”以至于大家都不屑于就其真正展开讨论，但却在“懂业务”这个方向上“越陷越深”。
既然是“废话”那接下来的部分我计划仅简单释义一下其中的几个关键点，而留下更多的时间，探讨一下这个观点背后那些更有趣的问题。
包括：
PMO不应该执着于为了“懂业务”而“懂业务”，也不需要为了改变身边合作伙伴口中的“不懂业务”去“懂业务”。但是要为了老板、高管口中的“不懂业务”去“懂业务”，细心的你会发现这不是唯上，而是老板及高管的要求、需求正是PMO“组织定位”的源泉。
因为管理职能的存在就是帮助高级管理层分担管理问题，要去解决解决老板的焦虑。这本质是一个To B的模式。
而老板评价“懂不懂业务”背后，评价的不是PMO懂业务到底有多深，而是自己期望PMO负责解决的问题是否得到了有效解决。
“不懂业务”往往是对解决方案或效果的不认可，也是给PMO的一个“台阶”。
回过头看，有效完成组织定位下的任务是本质，业务认知是手段。所以也就有了以上的答案：
PMO是否懂业务，是看他是否掌握了有效完成PMO定位下的任务所需要的业务知识。
例如研发效能提升：如果组织对PMO的定位是做产研效能优化，那PMO就不可能只懂得流程图5要素是什么？流程的三分法是什么？流程诊断怎么做？
还需要以效能提升为目标：
这里的五点其实就是在推进“产品研发”可能需要去懂的“业务”。但不需要PMO非得去了解整个产品族中各产品的交互逻辑，更不需要去了解Java语法本身。
例如项目管理体系搭建：首先PMO要去了解管理者对管理体系搭建背后的核心诉求和目的。最终可能决定围绕最基础的立项、监控、结项三个板块展开设计，重抓头尾及过程风险。
那PMO在熟悉业务上可能就要考虑：
这种情况下，PMO可能不需要花时间去理解每一个项目的目标以及策略是什么，也不需要去判断项目的收益测算是否靠谱。
PMO要做的工作是专业的设计流程及模板，并让核心问题及核心评审在合适的时间发生。这也是一件很了不起的事情。
但是如果你重点负责一个具体的项目交付，又或者老板对你的期望就是给予深刻的业务洞见或业务指导，那对业务的理解就需要深入到更深的一个层次。
但如果是后者，往往老板在招聘的时候就会按领域专家招，只是挂名PMO而非要求一个PMO上来去进行业务指导。这两者是有很大差异。
年轻的，快速发展的企业往往推崇不设界的文化，反对传统企业的教条主义。如果强调在定位底下懂业务是否会让人觉得PMO过于保守，没有主人翁意识？
对于这个问题我的理解是：在规划层以及文化层PMO应该有不设界的文化，但同时PMO也需要清晰的组织定位以确保有效支撑企业的战略。
怎么理解？
在规划层及文化层PMO应该有不设界的文化指的是：
但以上这些特殊情况都不应该否定PMO在组织上去校准自己“组织定位”的重要价值。
清晰PMO的组织定位指的是：PMO根据组织战略落地需要，根据业务生命周期，根据PMO的能力优势以及管理层的诉求去规划并与管理层校准对齐出PMO在组织的定位。
清晰的组织定位对PMO尤为重要，PMO在组织定位上较其他职能更有特点也更尴尬。大家都知道，很多企业原来是没有PMO职能的。
虽然没有经过很强的追根溯源，但经过一些行业沟通，还是可以推断很多公司因为发现PMO具备一些当下急迫的“管理痛点”解决能力，然后就开始组建起了PMO团队。
例如：
这些团队从0-1的成立，对问题的承接方向明确、成果肉眼可见。所以往往不太需要很系统的定位梳理，也不需要对岗位价值澄清就能顺利迈过第一个年头。
但随着时间的推移，业务阶段在变、战略在变、组织环境中的管理机制在变。PMO的能力在成长，管理者的思路也可能在变。
不同的力量推进着PMO往不同的方向发展。很容易会导致PMO的定位越来越不清晰，看似更好的融合进了业务，实则也没了重心。
而如果从一个团队成立的本质思考，一个团队背后承载的是一组能力，这组能力在支撑战略达成上是有其位置的。
如果这个位置模糊不清，也就讲不清对战略及对企业的价值，那这个团队便会变得岌岌可危。所以说清晰的组织定位是团队存在的立足点。
尤其PMO不像HR、财务团队，有较为“硬”的职责定位作为根基。更是要认真思考，探索，并与管理者就定位做好校准与对齐。
尽管我们的观点说PMO懂业务要基于“组织定位”，但仍然有很多噪音在牵引我们花大量的精力在焦虑自己“不懂业务”上。
因为我们身边经常会看到那些“懂业务”能和业务团队侃侃而谈的PMO更受组织的欢迎。
这是一个非常容易理解的事情，因为没有哪个业务团队和业务管理者会拒绝对其有帮助的业务洞见（只要你通过合适的方式传递信息）。
但对这个问题HR领域有一句话还是很有启发性，这句话是：“不缺位不越位”。“不越位”暂且不说，因为越位与否的评价标准有待商榷。但“不缺位”确是重点。
试问如果一个企业交予的定位（如项目交付，组织效能）没做好的PMO团队，即使业务再夸PMO懂业务，又何谈成功呢？
其实往往被夸“懂业务”的PMO，是那些本职工作做得比较好，在业务上又能给与洞见输出的人。而不是脱离本职只做洞见之人。
其实也可能会发生项目管理没做好，但是被组织夸赞“懂业务”的PMO。
这背后其实隐藏着一个更深层的需要探讨的问题是，这位同学为什么不直接作为业务团队的一员在更适合的岗位发挥自己的价值？
此处就这一话题不过多展开，但这确实是大部分成熟PMO团队需要去认真考虑的能力适配于能力溢出问题。
以业务为导向，或者更本质来说以客户为导向来工作是一个企业所有团队都必须追求的。但是：
以业务为导向工作≠需要事无巨细的学业务≠不需要学习业务
回到老板视角来看，老板肯定希望有一个能人能回答他所有的问题甚至业务业务决策。但现实中这是不可能的，因为人有一个最大的卡点就是“一天只有24小时”，精力是有限的。
那有限的时间里在企业工作中每个部分应该优先做什么呢？
必然是部门与老板对齐后组织定位里老板所要求的事情。
做职能、管理相关的工作并不代表就不业务导向，正是因为职能管理工作对业务的健康顺利发展起到重要支撑作用所以很多职能都已经成为企业的默认配置。
如果没有职能来分担业务管理者的精力，业务管理者就必须事必躬亲。不仅分散业务精力，也很难把职能相关领域做专，效率做起来。
职能团队把职能领域做专业，释放更多业务管理者的精力，甚至站在专业领域维度提出对业务发展的好的建议。这正是职能力度能发挥的ROI最高的以业务为导向的方式，这才是对企业全局ROI最高的业务导向。
例如HR团队，通常来说肯定要基于定位优先把“人力资源规划”、“人才招聘与配置”、“员工培训开发”及“绩效管理”等基本职能做好，再去说投入时间去帮助业务发现业务问题。相信没有哪个会老板招聘一个人力资源的人来去给他提供业务洞见。
即使存在这种情况，我认为这属于招聘一个业务助理临时挂在人力资源团队，仅此而已，不是真正意义上的HR。
又如PMO团队，“提供专业的项目管理能力”、“搭建高效的项目管理流程体系”、“系统性识别战略落地风险”、“促进跨部门协作”等则是PMO基于项目管理专业软硬技能所能赋予组织的能力。在适当的业务阶段介入业务，导入项目管理的能力、体系，正是基于业务导向的体现。
站在一个组织内，但又以脱离老板、组织期望的方式去贡献所谓的业务价值，实则是在耍流氓。
PMO的定位确实比大多数如HR、财务、战略等职能团队更难找。我所看到的有三方面原因：
1）需求零散
职能岗位以分担管理者管理精力为目的，而大部分可体系化解耦的课题已经有了较为成熟的学科。如人力资源、财务。
一个管理者的大部分管理问题可以被人力资源团队（现在更为精细化的还可以细拆到组织发展、人才发展、组织文化等等），财务团队，商业或经营分析团队以及这个老板自己的直接下属所承接。
剩余的管理诉求会较为分散，而很多时候团队的PMO就是在解决这些团队之外的管理问题。
2）需求多变
随着业务阶段不同，年度规划变化，业务对PMO的需求也不一样。快速扩张期可能需要PMO快速标准化SOP、剧本，以确定性项目交付的形式提供能力。
而到业务深水区，可能又需要PMO搭建一套适合业务深度假设验证及时纠偏的管理框架来助力业务迭代商业认知，有效竞争。
再到了后期，可能希望PMO充当效率提升的决策，通过导入流程化管理的思想，搭建流程框架，梳理流程来支撑基于流程的降本增效及业务优化。
3）组织/管理者敏感
PMO比其他职能部门要更“组织敏感”。一个企业的调整可能会突然弱化项目制，可能会突然取消项目管理会。但是不会不做人力资源管理，不会不做财务管理。PMO搭建的管理体系，更容易因管理者管理思路的变化而变化。
这些原因让PMO在不同公司，甚至不同公司内的不同团队呈现着百花齐放的形态。而正因为企业对PMO的需求如此多样，PMO才更应该在每次检测到变化发生时，积极去面对变化，以客户为导向去打磨校准自己的定位。
这是PMO岗位与其它只能比起来很不同的挑战。
如何找到组织定位并非本文的重点，但反复提到“组织定位”是评价“懂业务”与否的前提，却也是要把这个话题收一收。
“组织定位”是战略规划的输出，是目标制定的基础，大部分团队的组织定位可以随着企业或者业务的3-5年规划以及年度计划流程来完成。
所以基本上可以分为三大步，按照：PMO共创->管理层校准->按重大变更迭代。
指对内通过公司顶层战略、业务战略、上一级部门的输入；对外通过行业标杆（如向PMO优秀企业）、跨职能对标（如向HR）；对过去通过复盘PMO受到认可的过程、成果；对未来通过PMO团队对愿景的畅想。共同脑暴并收敛出PMO组织定位。
时间周期上，初创企业/业务可能以1~2年为考虑周期，大中型企业可以考虑得再长远一些围绕3~5年展开。
颗粒度上，组织定位核心是要表达团队在支撑战略中的主要位置、角色及职责。可以考虑分两级甚至多级设定。我所常见也觉得较为清晰的结构如下：
定位X：负责[关键职责X]的[角色A]
做什么：
不做什么：
例如定位1：负责[保障项目按时交付的]的[推土机]
做什么：
1. 项目启动、规划、执行、监控、收尾的推进，节奏把控及标准动作管理。
2. 项目风险、问题卡点、变更的识别及解决推进，必要时上升解决。
3. 项目负责人及骨干的项目管理Coach。
不做什么：
1. 不做项目业务方案内容的准备。
2. 可以参与但不作为业务流程的卡点环节。
3. 不做未经高管层确认的运营补位。
指经过PMO内部共创完成的内部终版与上一级管理层校准的过程。这个过程是吸收管理层建议并完善PMO定位的核心环节，前期再多的共创思考都要经过管理层确认才能成为团队真正的定位。
这一步通常有两种情况：
回到文初，为何提到“解铃终须系铃人”也在于此。PMO诞生于管理层的管理需求，自然也要植根于管理层的需求，而定位正是这个“根”。
脱离“定位”的“懂业务”就像是无本之源。
年度内PMO的定位一般不会轻易发生变化，但若有重大变更发生。例如流程管理团队解散并入PMO，又或者年终组织根据市场变化决定探索一个新业务，需要PMO构建探索类项目管理能力等，则需要PMO快速适应组织需要，对定位进行调整适配。
一般，组织定位都较为稳定，重大变更的概率也不会很大，变化的频次不会很高。
PMO常见的组织定位，如需要也可参考：互联网重新“定义”了PMO，内的“目前所能见到的PMO常见工作方向”部分。
强调“懂业务”背后其实是PMO对自己成长的一种追求。
趁着这个话题，也想说说几点自己近期关于PMO成长的思考，限定于互联网企业PMO领域，个人观点，欢迎交流切磋指正。
其实在、互联网重新“定义”了PMO里也表达过类似的观点。在互联网PMO领域工作至今的几年时光里，自己很切实地感受到互联网PMO来自四面八方的一些束缚。
我相信随着互联网的进一步发展，精细化管理能力的诉求一定会进一步提升。
但此时此刻，在这个尴尬的时间，PMO似乎暂时的进入了一个恶性循环。因为在职级、宽度、深度上都没有进一步的机会，所以也就只能停步于此，原地打转。
但其实真正把我们禁锢在这个循环里的，不是PMO定位本身，而是我们自己。
如果换一个思路，把PMO当作一个能力的标签。一个已经有了非常娴熟的项目管理领域技能的PMO，完全可以借着项目管理的经验以及自己的兴趣、特长与爱好去探索更广阔的天地。
不在乎自己叫不叫PMO，甚至自己去证明了PMO更多的可能性。
如果真的着迷于业务，而又积累了好的业务认知，完全可以不拘泥于Title去追求业务。而不是期望站在PMO岗位上去追求业务，这样不仅“累了”企业，也会累了自己。
在进行择业规划时，除了挑准赛道，结合经验，有一个很重要的参考其实是结合自身兴趣、特长。说实话，很长一段时间我都不是很笃定自己的兴趣和特长是什么。
最新找到了一个方法觉得简单又实用，其实就是两个很简单的引导问题：
与君共勉，希望有帮助。如果感兴趣，欢迎你也在评论区写下你对何为“懂业务”的PMO的思考。
本文由 @Talen 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。