pmo行业趋势（互联网重新定义）

四两清风 2022-12-17 18:51:55

编辑导语：互联网的产品经理们，对于PMO这个职能应该不陌生。互联网PMO区别于传统的PMO有了不同的工作侧重点。作者从十一个方面分享了自己对于PMO方面的一些工作感悟与思考，希望对你有所帮助。

互联网的产品经理们，对PMO这个职能通常不会感到陌生。甚至我们还会看到一部分PM尝试转型成PMO来一探在产品解决方案设计之外的管理解决方案的“快乐”。你是如何理解PMO的？他是会议组织者？进度的Pusher？抑或是复盘会上那个用心在带领大家一起发现问题的人？

以下是我在自己公众号上首发的一篇结合PMO小几年工作经验的一些感悟与思考，在做PMO之前，我也是一位产品，而且我很喜欢做产品，甚至在做PMO时我把自己，把自己设计的每一次会议每一个机制，每一个管理解决方案都当作产品来设计，来“销售”。

希望这篇文章可以帮助产品同行们更Open的了解PMO。

当然也请当心，我在本文所表达的开放流派的PMO是非常开放的，看起来非常有趣，但是实际到了企业里可能会有种种束缚，PMO的定位很多时候是需要自己打出来的。千万别误导了大家以为哪里的PMO都很“开放”，在我看来，还不是。
一、背景
在互联网工作偶尔还是会被问到PMO的缩写是什么，更不用说“PMO到底是做什么的”这个问题的提及率了。

对互联网老人来说可能都已经习惯成自然了，每个人心中可能都有一个PMO的“模样”。但大家可能不知道的是，就连成立了若干年的PMO团队都也还在不停的在进行自我认知迭代。而以下是我这一段时间来，在PMO工作岗位上积累的思考。
二、目录
“官方”的PMO定义
“传统”PMO在做什么
“互联网”PMO在做什么
我所理解的，被互联网重新“定义”的PMO
和其他管理职能的区别与联系
互联网里PMO得以存在的根本原因（之我见）
“千团千面”的PMO
互联网“定义”下的PMO的几个核心工作方向
互联网PMO从业者未来职业方向的小展望
两点收获感悟
“开放流派”
三、“官方”的PMO定义

PMO一般指项目管理办公室。项目管理办公室是企业设立的一个职能机构名称，也有的称作项目管理部、项目办公室或项目管理中心等，英文为：Project Management Office ，缩写简称：PMO。PMO是在组织内部将实践、过程、运作形式化和标准化的部门，是提高组织管理成熟度的核心部门，它根据业界最佳实践和公认的项目管理知识体系，并结合企业自身的业务和行业特点，以此确保项目成功率的提高和组织战略的有效贯彻执行。

——百度百科

从定义中其实我们不难拆解出三个核心要素（本质、抓手、目标）：
首先在这个定义里，PMO本质是一个部门；
其次PMO通过抓手：“将实践、过程、运作形式化和标准化”，“运用业界最佳实践和公认的项目管理体系”并“结合企业自身的业务和行业特点”；
最终实现目标：确保项目成功率和提高组织战略的有效贯彻执行。

以上的定义看似简单，然而在没有深入企业管理领域的情况下它背后所隐含的概念还是不那么容易理解的。

例如：
“战略”是什么？长什么样子？在实际工作中是什么内容？怎么落地？
“项目管理体系”是什么？长什么样子？在实际工作中是什么内容？
不同业务和行业都有哪些特点需要考虑？哪些在什么情况下是关键要素？
怎么样算是战略有效贯彻执行了？

我想也正是这每一个看似简单实则深邃的词汇背后的不同理解以及环境的差异铸就了当下在不同行业甚至不同企业百花齐放的PMO团队。
四、“传统”的PMO在做什么
让我们先来看看相对“传统”（中性词）的PMO一般都在做些什么？这些内容来自于与同行就“传统”PMO定位的交流以及自己在外企、传统民企工作经验的整合。当然从知乎和一些历史悠久的外企的招聘JD上相信大家也都能看到类似的表述。

在传统定位下的PMO通常有异于项目经理。PMO更像是HR三角（COE/BP/SSC）里的COE，而项目经理更像是BP（弱/平衡矩阵结构里），甚至业务负责人（强矩阵结构里）。

在这样的体系里，项目经理通常掌握一定程度的管理钱和人的权力，有相对明确的职责界定，是项目成败的首要责任人。而PMO则主要制定标准、进行培训、认证体系以及进行集中管控与治理等工作。

乍一看起来，有异于项目经理的PMO好像特别厉害的样子，但如果PMO一直高高“在上”，脱离一线和业务，尤其如果资历还非常年轻，那势必容易受到项目经理的挑战。

而在我所听闻到的情况也是如此，尤其在一部分相对强调个人主义的企业或者地域文化下，真正厉害的项目经理反而有着更强的能力和影响力。
项目经理与PMO岗位区别化；
项目经理职责界定清晰（通常偏交付）；
PMO偏项目管理体系搭建、集中管控、治理及人才培养。

以上三点便是我能深刻体会到的，也是本文所指的“传统”的PMO定位的关键特点。
五、“互联网”的PMO做干什么
我毕业之后的第一份工作是在外企做技术工作，在外企的工作环境里给我一个最深印象就是体系完善、职责明确、协作清晰。公司有比较完善的支撑体系，让你可以把精力集中自己应该做的事情上，任何不是自己分内的工作基本都可以快速找到责任方和协作方法。

除了外企的技术，我还有幸在创业民企从事过偏运营和产品的工作，在创业企业可不像外企这么幸运，分工并没有想象中明确，甚至一人兼任多职，同时也可能经历非常快速的组织调整变化。

在进入互联网做PMO之前我以为创业企业的组织环境可能就已经是最糟糕的了。可当我真正在互联网做起PMO之后我才发现，之前那些遭遇可能都已经算不上什么大事了。

为什么呢？因为在互联网从事PMO岗位，除了要应对变化极快的市场环境和组织变化，更困难的是可能没有人能说得清PMO的职责到底是什么。综合这些年的面试和JD阅读，归纳出其中最常见的有以下五类PMO类型：

这五类PMO在工作内容上并没有特别严格的区分，都可能要做项目交付、也有可能需要理解业务（下文会讲到常见的六个工作方向），但是通常他们工作的最直接出发点是不太一样的。这五种类型的名称也因此得名。

产研型PMO-通常聚焦于关注产研效能和重点产研项目交付，产品研发的质量与效率通常是第一要务。

业务型PMO-通常关注业务效能和重点业务项目交付，业务目标的达成是第一要务。

交付型PMO-区别于产研和业务型一般的内部交付，这里指的交付型PMO是对外交付，例如SaaS类互联网公司的系统交付与部署，项目的顺利部署与交付，拿下合同拿到回款是第一要务。

助理型PMO-扮演的是Leader助理的角色，又区分为行政助理和业务助理两种（此处不再进一步定义助理的工作内容，我理解这类PMO的存在，某种原因来自于Leader不好意思配置助理title的下属）。

战略/组织型PMO-这类PMO通常关注战略的落地和组织建设，提升战略落地的确定性和效率以及提升组织效能是第一要务。

番外猜想：说到这里你有没有发现，一大部分互联网的PMO做的事情就是我们所说的项目经理（Project Manager）在做的事。那么为什么互联网很少听到项目经理这个词而，PMO却越来越多的出现呢？

我的一个简单粗暴的猜想，就是互联网还有一个非常流程的岗位叫“产品经理”的简写业务PM，为了区分这两个PM（Project Manager / Product Manager）最终组织选择了PMO来对互联网项目经理进行“称呼”。

很高兴的是就在最近和一位同事聊天时，他也表达了在某个公司的某条业务线里确实有着类似的缘由。
六、我所理解的，被互联网重新“定义”的PMO
从上面五种互联网常见的PMO类型不知道大家有没有看出来，PMO在互联网似乎是一个能“上天入地”的职能。能管业务、产研，能做战略、组织，还能做助理。那么他和其他管理职能的区别和联系又是什么？PMO存在的原因和意义又是什么呢？

“互联网里的PMO是？”这个问题，如果用我的语言表达，互联网的PMO是：

“以项目管理为基础，以提高组织战略落地确定性和效能为目标的，管理痛点杀手。”

这个定义的范畴其实很大，甚至打破了对PMO的常规认知。它只限定了PMO的出发点（“以项目管理为基础”），却不去约束PMO将要使用和践行的管理领域知识。

越来越多的互联网PMO应该已经意识到在企业里，一个项目的成败不仅仅取决于项目管理本身，还可能因外部环境或者受组织内部的项目驱动因素变化所影响。后一种我理解正是项目管理领域的组织级项目管理层面所希望研究和影响的范畴。

我并没有刻意的想去拔高PMO的意思，因为在我所曾服务的企业里，我是真正在尝试践行这样一个定义的。
为了支撑业务战略的有效落地，我们可能需要去实践业务流程管理范畴。
为了减少战略落地的折损，我们可能会扮演战略或者目标拆解引导师的角色引导业务或组织战略的制定和拆解。
甚至为了团队人才能力的建设，我们会去研究胜任力模型并深入一线进行专家经验萃取。

但凡我们发现一个管理问题很重要，如果解决了对企业的ROI很高，而且在没有更直接专业的资源可以去解决时，我们就要成为那个“痛点”的杀手。
七、和其他管理职能的区别与联系是什么？
管理学科四通八达，为了解决某一个学科或者职能遇到的问题通常需要引入或者涉猎另外一个学科的知识。例如作为战略管理专家为了促进战略落地，可能需要组织结构设计甚至绩效设计能力；再例如作为组织变革专家为了有效管理组织变革，可能需要项目集管理能力来协调多方并行参与和转型。

尤其在鼓励学科跨界产生创新的这个时代，管理职能的边界更越来越模糊了。这是我理解管理职能间区别与关系的大背景。而在这之下从PMO与其他管理职能的关系上，我总结了以下三大常见的关系，这三个关系并不一定独立存在，通常是混合出现在一个企业里。

1. 平行关系

平行关系指在一项工作/动作上，PMO的管理范畴和动作与另一个管理职能职责清晰，职责清晰。例如交付型项目的进度管理通常就很明确是互联网PMO的范畴，而绩效薪酬设计很明确是HR团队的范畴。
2. 战友关系

战友关系指在一项工作/动作上，PMO的管理范畴和动作与另一个管理职能职责相对清晰，但需要相互合作。例如在一个组织结构计划由职能型向矩阵型转型的项目过程里，PMO和HR团队通过密切的合作来联合设计结构、激励和治理体系。

聊到这，不得不提到来自“续华老师”的一篇文章，文章里提到PMO是“联接者”、“助推者”和“践行者”，尤其针在“践行者”部分提到以下：

践行者：从点（项目中的具体问题解决）到线（长效优化机制建立）到面（变革管理）的践行者

引用自：https://www.sohu.com/a/396868515_100126021

我读到这篇文章的感受是，就连建设了多年管理体系的企业，PMO一样有如此强的灵活性和空间来推动管理变革，相信在互联网的PMO，有更多的机会在企业需要时提供多种多样的价值。
3. “补位”关系

补位关系指在一项工作/动作上，PMO的管理范畴和动作可能属于大家公认的另一个管理职能的范畴，但实际与该管理职能的工作并无重复造轮子的情况。

这种情况下PMO在扮演的更多的补位角色，弥补该管理职能的资源或精力不足。例如人才的“选”“用”“育”“留”一般属于人力资源范畴。可是千万别小看这四个字的范围与深度。

单纯拿”选”来说，HR团队可能要花精力做战略分析、组织设计、人才盘点、胜任力模型构建，进而才能让人才的选择更精准的适配战略与组织需要。而”育”也是，一个团队可能需要专业技能建设、领导力建设、领导梯队的建设等等，这一系列如果想要做得专业和规范，是需要耗费大量的精力和时间的。

但作为PMO你可能会发现一个项目的成败有时候真的有可能来自于人或者组织的能力不匹配。那怎么办？保障重大项目交付或者管理体系建设之余，PMO也还可能参与到团队培养项目中，与HR一同参谋人才胜任力模型，甚至作为项目管理的讲师参与到培训计划中。

除此之外，PMO还可以作为战略引导师推动战略制定，作为团队复盘引导扮演OD的角色陪伴团队发现问题找到解法，推动组织效能提升。这些看似PMO“分外”之事，都是PMO可能做的为团队和业务好的事情。

在这些工作上，如果天然有HR团队或者战略团队存在，那PMO与该团队的关系就是补位关系。

在我的经历里，平行、战友和补位关系都遇到过，这个过程中也曾担心过自己是否有“越界”的情况。但如果过程中大家协作良好，最后也拿到了对公司和彼此有益的结果。那本身不就是价值吗？

这也是为什么在我看来，PMO应该是管理痛点杀手，而不仅仅局限于解决狭义的项目管理范畴内的问题。
八、互联网里PMO得以存在的原因（之我见）
从事PMO的同事同行时常会用一些自嘲的话来相互调侃。如：

PMO不在核心价值链上，好像有和没有都没啥关系。作为PMO你能说出你在项目里的独特价值吗？

很多公司PMO干了几年把公司项目管理能力培养起来，自己就黄了。

在我的观点里，我承认PMO不在核心价值链上，也承认没有PMO业务一样能够转得起来。甚至我的观点是越能让一个团队离开PMO之后可以高效自运转的团队，越是一个好的PMO。那如此回过头来看，PMO得以存在的根本原因到底是什么呢？

在我看来PMO得以存在的根本原因是：企业内管理精力的不足。

而PMO是在互联网领域，除了各类管理BP角色外重要的管理精力出口。因此PMO有了存在的重要根基和价值。

那么为什么企业会存在管理精力不足的情况呢？在我看来至少有以下几个原因：
1. 管理者天然精力不足

管理者的一天其实一点都不简单，要开各类周会，面试高阶人才，收集战略信息，做慎重的业务规划和决策，接受上级和各职能部门的建议和沟通，差旅谈合作，应对突发的重要卡点和部门冲突，甚至为必要的项目或者下属站台…

幸亏有财务、战略、人力BP、PMO同事协助管理者来做好各类支撑工作，否则管理者可能一天24小时都不用休息了。
2. 管理职能精力不足

除了管理者，管理职能的同事（例如战略BP、HRBR）一样忙得不可开交。这一点在之前讲PMO与其它职能团队的互补关系时其实也有提到。

随着各管理职能学科的精细化以及专业化，我相信如果想做好一个管理职能所需要花费的精力会越来越多，只不过大家一直在做平衡与取舍。
3. 互联网高灵活性的业务要求

互联网高灵活性的业务要求，通常引发了两个常见的组织特征：

①扁平化结构

②重协作轻流程，而这两点恰恰加重了管理精力的消耗。

本质上它是一种用人的管理精力来替代重结构和强规则管控，最终支撑业务灵活性的一种模式。这种模式下，势必对管理精力会有极大的消耗。很直观的一个现象就是流程虽然少了，但是会议多了。

所以暂且不说PMO在项目管理领域的专业性，单从战略落地过程中的各种管理问题上，PMO都可以替管理者和团队分担许多管理精力，以此为团队带来价值。

并且在我肉眼可见的当下互联网的管理模式下，仍然还会继续催生强大的管理精力需求，PMO确实是目前所能看到的快速补足并相对灵活适配这一精力需求的职能。
九、千团千面的PMO
正因为PMO存在的根本原因是管理精力的不足，所以PMO的主要核心目标就是在管理精力上的补足上。但这么说起来还是太抽象，PMO的工作应该长什么样子呢？

我的理解是，互联网的PMO没有绝对的定式，是“千团千面的PMO”。

原因在于不同的管理团队在某个时刻下所需要的，以及PMO所能投入的切入点是不一样的。因此在做PMO工作规划时我们要结合不同的因素来加以识别和考量。以下几个维度是我常用的重要考量点：

其中1、2是基础，3、4是关键。

1. 业务特征

业务在不同的生命周期和市场环境下要解决的核心矛盾的不同的。

美国最有影响力的管理学者之一爱迪斯提出了企业生命周期的十个阶段，进一步提炼后可以大致划分为创业阶段、成长阶段、成熟阶段和衰退阶段（我认为还可以加上“再创业期”）。这其实就是指导我们分析PMO管理切入点的一个常见视角。举两个容易理解的例子：

第一，在创业阶段的业务，一般来说灵活应变快速试错是核心，那么管理精力通常重在商业模式的探索及快速的能力与资源获取。这个时候的企业通常不需要正式的PMO，即使需要也是更多需要投入到商业模式的探索中，而非流程机制体系搭建。

第二，在成熟阶段的业务，一般来说业务趋于稳定，通过管理创新来降本增效是核心，管理精力通常放在降本增效上。这时候PMO能做的事情可能就很多了，核心是找到那个当下最要紧的管理痛点。

组织结构是否需要矩阵化？项目管理体系是否需要规范化？流程机制是否需要加固、改进或者信息化？PMO通常可以从组织级项目项目管理诊断或者OD组织诊断出发去为组织发现并解决问题。

除了企业内在的生命周期，市场外部的环境一样重要。用户是To B还是To C，竞争是激烈亦或平静，行业的发展周期是起步还是衰退，对应技术更迭是否迅猛。这些外部因素往往通过影响组织战略进而影响组织和配套管理方式。是我们做管理选择所要关注的“势”。
2. 团队特征

团队也一样，我们要去关注在不同的组织结构，文化和职能属性上在某一时刻需要解决的核心矛盾是什么，它们通常也会有所不同。

例如在组织结构上，业务团队的核心矛盾通常可能是如何适应快速变化的市场环境，而开发团队通常关注的是如果高质量高效率高氛围的保交付，这就导致PMO在支持不同组织时需要关注的点不同。

在文化层面也是如此，进一步介绍前给大家安利一个我比较喜欢的对立价值观模型（Competing Values Framework）。

该模型有两个维度：一个维度的两个方向为“强调灵活、动态性” VS “强调有序、稳定性”，如阿里巴巴等互联网类企业，其组织形式和产品组合富于变化，而一般的政府组织就偏向于稳定。

另外一个维度的两个方向为“内部导向，强调整合统一”VS“外部导向，强调差异和竞争”。如丰田等组织全球化过程中会因为不同区域的从差异采用不同的特征，而IBM内部的管理模式则高度统一。

引用自：https://www.sohu.com/a/378771720_300134

这两个维度通过2×2矩阵可以将组织划分成4种类型（具体见上链接），针对不同类型的组织文化，我们会发现它们有着不同的导向、价值驱动因素和有效性理论（更多见以上外部链接）。这些内容都可以成为PMO进行管理切入点的参考。

例如关注内部和整合，同时强调稳定和控制的文化下，有可能流程管理和体系建设就是PMO的一个管理切入点。

但是在适配文化进行管理的时候有一点是需要强调的。我认为，一个组织的文化应该去适配它的发展阶段和业务，因此在考虑组织文化去落地管理手段前需要我们去判断这个组织文化是适配业务发展的。

如果文化本身不适配组织发展，那么我们的着力点甚至有可能是通过项目管理去协助HR团队一同调整组织文化。无论是把文化调整融入到项目管理体系设计里，还是甚至作为组织变革项目的经理进入到组织变革的核心团队。

业务特征和团队特征共同决定了当前管理精力所应该投入的重点，而PMO作为管理精力承担职能之一，如果不能帮组织解决核心矛盾，就很难体现出价值，也容易缺乏成就感。所以说对业务和团队特征的思考是PMO寻找工作方向的基础。
3. 管理者&自我特征

其次，除了找到组织的核心管理矛盾，自身具备能力以及管理者的理解与认可也是PMO寻找工作方向时的关键。因为工作阅历原因，每一个管理者对于PMO的定位和理解通常是不尽相同的，每个PMO身上所具备的管理经验和知识也是不尽相同的。

有了业务特征和团队特征的需要作为工作基础之后，还要解决自身能力以及所支持管理者理解与信任的问题，基于管理者的理解和信任去帮助他解决核心的管理矛盾。

业务、团队、管理者、个人特征，一直是我思考PMO工作的四个重要考量点。
十、目前所能见到的PMO常见工作方向
做完一大轮发散，就像做会议引导一样，习惯性的总想要收敛点什么。虽然看似PMO可能性如此之大，但是PMO工作方向这个事，是一个PMO、组织、企业/业务管理者成长共同决定的事情，基于某个时刻多多少少还是能有迹可循。

结合我自己所见所闻，总结了以下几个常见的工作方向，试图抛砖引玉，听见更多可能性。以下六个工作方向与之前提到的五种PMO类型并不冲突，只是视角不同。

五种PMO类型是从工作目标或者出发点出发去看PMO，它通常被用于称呼。而以下六个常见工作方向是从工作内容出发，它通常被用于PMO工作的规划和详细内容的分类。
项目交付-如单项目、项目集、项目组合交付保障
流程管理-这里的流程主要指业务流程，包括梳理，规划和优化等
战略衔接-如战略解码，目标管理体系（其实属于4的子集，但重要）
体系建设-如项目管理体系建设，知识管理体系
组织建设-如矩阵型组织变革，项目文化培育，组织效能诊断
业务创新-如跨业务线横向创新探索

（以上3理论上是4的一个子集，但较为重要，单列一项以突显）

这里有项目、有流程、有战略、有体系、有组织也有业务，看似超出项目管理，但其实并没有乱入。只要回归到对互联网PMO的全新理解：

“以项目管理为基础，以提高组织战略落地确定性和效能为目标的，管理痛点杀手” 你就会发现，以上这些都是PMO的可能性。

而其实除了这些可以考虑写进规划的方向，在PMO的价值输出上，我们还能见到一些专业软技能的输出对组织帮助一样巨大。例如引导技术在战略规划、组织/业务复盘上的使用。如果细心，你就会看得见许多PMO同事围绕着组织，在做着很多默默而伟大的事情。
十一、互联网PMO从业者未来职业方向的小展望
时而会和同事同行一起聊到未来展望，有的朋友对PMO岗位持有略微消极的态度，因为发现做着支持型的事情，尽管初期可以相对容易晋升和成长，但到了中后期却往往会遇到成长天花板。

以上观点我觉得对也不对。对是因为根据企业内PMO的组织架构、汇报层级和文化，有的企业里PMO确实不那么容易争取到很高的空间，甚至组织层级越做越低。

但是如果回到能力视角，PMO身上带的是一系列随着经历成长的管理能力。但凡PMO始终在高ROI的管理支点上历练，我相信大概率成长起来的还是社会上互联网当下相对炙手可热的管理能力。具备这样的能力，用心去追寻还是很有可能探索到自己在企业和社会里的一席之地的。

虽然PMO职业出口肯定有无数种可能性，但我所能见或能想到的几个通道有：
管理通道：PMO总监
高管通道：CIO
咨询/培训通道：管理咨询/培训专家
业务通道：业务/产品负责人
跨职能通道：战略/OD/HR

这里面有些路趟的人多了，路径非常清晰。而有的路走的人还不多。但我始终相信有能力傍身，加上不断的接触，路就大概率会趟出来。

十二、两点收获感悟
1. 做合伙人

特别谢谢我在PMO岗位上的第一位Leader，在我入职2个月的时候用最简洁的一个词帮我深刻的领悟了互联网的PMO。在那段对话里，她问我觉得PMO是做什么的？

我用一大段话似懂非懂的解释完PMO的定位后，她告诉我（大概的意思是）在她看来PMO就是管理者和业务的“合伙人”。这句话当时在我内心中回荡了很久。也成为了引导我打开视野，放开膀子，探索管理领域的钥匙。
2. 跳出“PMO”

在和部分PMO Leader或者同事交流时，大家有时会表达出来对边界冲突的担忧。担心自己在做的一个事情是否跨了管理边界。这个事情该想，但是我更倾向于非常开放的向更多可能性去思考。

例如当PMO在项目管理过程中发现组织架构有问题时，向内的做法是不言或少言，向外的直接做法是做为PMO角色推动组织架构调整。

但在我看来，其实还有另外一种跳出“PMO”的可能性就是，我不做PMO了，我转做HR去做组织架构调整。在我看来对于高管来说，真正重要的是胜任力而非Title，这就是为什么高管之间通常会进行轮换。

我觉得PMO也可能如此，只要我们不断磨练身上的能力，不需要拘泥于真正的Title，真正需要的其实是被企业发现，争取自身能力为企业做贡献的机会。

特别希望组织管理者可以用能力视角来看PMO，这无论对PMO或者组织都是大有裨益的。甚至在我心中PMO岗位或许有一天还能成为中层管理者的“黄埔军校”，让新晋管理者在做“组织管理痛点杀手”，长出更强的综合管理能力，为组织迎接更为复杂的挑战做准备。
3. “开放流派”

管理领域对一个概念或者方向历来有很多不同的观点或者视角，单独看都可能有自己的道理，只不过因时代、业务、受众经历的不同接受程度也各不相同。我相信本文中对于PMO的观点也是一样，这可能算是PMO的“开放流派”吧：）

如有激进之处，还请跨职能的读者多多理解，回归到源头来说，还是希望不同管理职能打开事业去解决企业管理问题，要么平行、要么并肩、要么彼此互补着陪企业迈向未知的未来。

本文由 @ Talen 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议
,