从航运互联网创业公司的运营经理、到医疗供应链软件产品再到独角兽的PMO。尽管同属互联网产业，却无论从具体行业到职能都发生了很大变化。

如何让自己更快的进入角色，最小化自己的“青涩”，最大化公司的“收益”，是我在每一次转折中都要考问自己的话题。

幸运的是，三次转型在我心中都算得上是成功的，这份成功不是来自于自己的收入或成长，而更多的是可以看到自己在不断成长中被委以的重任，以及在每一次沟通中所能感受到的一起拼搏的同事的认可。感谢在成长路上，不吝指点和认可的每一位伙伴：）

一、从实践到理论的四个阶段：“ACES”

不知是不是因为年龄渐长的原因，越来越放不下面子，对自己的每一个决策、每一个问题的回答的要求都变得越来越高。即使有的事情有前辈的经验，和细致的考虑后，决定先行，但在执行的过程中也会不断想要找寻做事背后的逻辑、原理和体系。

小时候学习解应用题，老师首先会教我们基础的加减乘除，然后是教会我们解答一道应用题，接着引导我们学会解一整类应用题（如鸡兔同笼），再最后为了应对更为复杂的考试，他还要教会我们如何判断题型，选择解法，系统解决各类应用题。

细心的你会发现：

1. 运算加减
2. 解一道题
3. 解一类题
4. 解各类题

是我们学会系统解题的四个不同阶段。并且在许多实践认知过程都有类似的体现。按照易记且“流行”的方式，我给这四个维度冠以英文缩写形成“ACES”。

对于“解应用题”这样一个知识领域，我们通过举例映射一下ACES里的四个阶段：

1. 动作阶段：根据指导，进行加减乘除，或者列/解方程式动作解题。
2. 案例阶段：学会独立，解一道具体的应用题（这时候还做不到举一反三）。
3. 经验阶段：举一反三，解一类应用题（如鸡兔同笼问题）。
4. 体系阶段：系统分析判断，解决各种应用题，甚至提出创新型解法。

然后我们用“厨师炒菜”再举一个例子：

1. 动作阶段：一步一步根据师傅指导，切菜、点火、下油、下料、下菜、出菜、摆盘。
2. 案例阶段：学会独立，制作一道固定的菜如糖醋鱼。
3. 经验阶段：举一反三，掌握糖醋类基本做饭，搞得订糖醋鱼、糖醋排骨等糖醋大类。
4. 体系阶段：系统掌握厨艺，蒸、焖、炸、炒体系贯通，甚至可以开创新式菜系。

当然实际案例比以上均要复杂得多，好的学生除了会应用题，还要会证明题。好厨师除了会烹制手段，还要学会食材挑选，体系是否完备决定了掌握的变量是否充分。充分的变量不仅给解决问题带来更多手段，也为创新和突破带来更多可能。

1. ACES不是模型，是思维

花了这么多文字引出ACES，那ACES对我来说有什么用呢？于我而言，ACES的价值不是用来分析问题的模型，而是一个让自己变得更专业的思维和路径。

以下是一些对我自己颇有意义的思维总结，每一个点可能都可以用一个完整篇幅来展开，但是为了节约篇幅量，不再展开。如果你有产生共鸣，欢迎慢下脚步：）

• ACES帮助我看清自己在某个知识领域的段位。
• ACES帮助我快速预估和定位实现目标我需要付出的努力（越向经验和体系，要求越高）。
• 想成为真正的高手要有体系有套路，勤练习、多积累。
• 实践的重要，聆听的价值，以及经验总结的必要性。
• 一个问题可能多个解法、前人的经验也不一定是最好的，如果想要系统性回答、解决和创新性解决问题，我们需要体系化领域知识。
• ACES并没有约束成长路径，如果你的目标是成为领域专家，早一些开始体系化（但不能过早）的工作可能会对经验积累事半功倍。
• 每件事情都可以精益求精，但时间有限，培养体系是一件费时费力的事情，请选择性培养重要的体系，而有的事情仅仅做到动作到位就已经足够。有舍才有得。

2. ACES对应的四个关键动作

ACES的四个阶段，对应着四个关键动作，是领域知识阶段升级的关键。

关键动作一：“识别”（Action → Case）

别把工作当指令，转换角色，在工作中“识别”出“事业”。

在老师指导下解应用题时，如果你没有把做一系列加减乘除与应用题联系，你的心里是没有应用题的，只是在执行计算指令。

在师傅知道做菜时，如果你没有把切菜、下锅、下料、拼盘着一系列动作与完成一道菜联系，你的心里是没有这道菜的，只是在执行一系列动作。

这样在这个过程里，你只可能积累到计算的经验，缺无法积累解题的经验；你只能积累切菜、下锅..的经验，无法沉淀做出一道菜的经验。

所以在如果想要成为某一个领域的专家，积累某一个领域的体系，先决条件是需要我们先“识别”（无论是自己识别出来，或者从他处习得）出这个领域，把它当成一回“事”，而不是机械的执行指令。

在产品领域的运用示例：这个过程其实可以对应到产品工作的各个层面来运用，

• 小到运用Axure时你要识别出某个组件或者某个功能，有时你会发现就一个新识别的技巧就可能让你的设计瞬间提高一个层次的“逼格”。
• 中到一个产品的设计，你可能识别出用户操作安全是需要着重考虑得设计要素。
• 大到在B端大型系统解决方案中，你发现客户前期参与竟是如此重要，并加入到今后工作计划中。

这些看似微小的每一次“识别”正是高手与新手差距的起点。

关键动作二：“萃取”（Case → Experience）

案例只是说来好听，萃取出的经验却真的好用。

没有Case就有没经验，那么有了Case就一定有经验了么？答案是No！

如果想要积累经验，需要一个主动的“萃取”过程（直觉上、单一动作上的经验除外）。大部分领域的资深员工或者专家都经历了很丰富的案例，无形中相较于新员工他们处理某一个具体事情往往更得心应手而且容易拿到好结果。这中间的差距是什么的？除了影响力以外，大部分的应该还要归功于经验。而当我们刻意去问这些专家或者资深前辈他们的经验是什么时，他们却常常说不出口，亦或者反问一句“难道不应该这么做么”？而无法沉淀的经验又何以更好的指导工作呢？

“萃取”的动作就是帮助这些专家或者你自己把这些说不出口的经验转化成说得出口的“经验”的过程。它需要我们通过思考，甚至借助一些系统化的方法（“知识萃取”本身有一些系统化方法）挖掘沉淀我们的经验，让其更系统和工具化地被更大范围的复用起来。另外经验系统化的过程也可以为之后的知识体系化沉淀基础。

在产品领域的运用示例：接续识别时提到的Case

• 小到提炼自己产出某一次Axure设计的设计过程，运用技巧。
• 中到根据自己经验，梳理一份自己的产品设计自检表，并把安全考虑要素融入其中。
• 大到总结产品“用户成功”技巧，将销售、实施、实施后各个需要关注的细节梳理成文，甚至成为制度。

看似仅仅是把隐形知识显性化的“萃取”，其实是知识传播的起点，也是知识得以系统化升级的起点。许多人可能停步于此。

关键动作三：“系统化”（Experience → System）

超越经验，让自己站的更高，看得更远更清楚。

如果要问识别、萃取和系统化，这三个关键动作中那部分最难的，我认为要数系统化。

原因很简单，因为识别虽然是意识问题，但是很多工作已经被很好的识别，很多理论书籍和研究人员也在不断帮助我们识别问题，通过阅读就可以获得很多“识别”。

而经验萃取，本身也有一定程度的方法论得以引导和支撑，是可以由专门的萃取师帮助完成的。但系统化却不一样。

当下市场环节变化循序，技术发展迅猛，跨学科需求越来越多。不像“识别”有这么多前人的沉淀，不像“萃取”有他人可以帮助完成，一个较新领域的“系统化”工作，可能只有靠我们自己，或者邀请到志趣相投的同道中人一起才可能完成。这当中对知识的深度和广度和实践的要求都有很大的挑战。

后续第二大部分文章将介绍在我脑海中系统化的知识的样子。

在产品领域的运用示例：系统化是大量萃取沉淀，经过思考后的升华

• 系统化后的Axure认知，你可以很清晰知道Axure能做什么，不能做什么。看到一个设计后，你可以快速判断Axure是否能做，用哪些组件，流程大致如何。一切都在你掌控之中，只差动手。
• 系统化后的产品设计经验，你就像有了自己的“用户体验要素模型”，所有与产品设计的Topic都不太可能超出你的思考范围，你可以自如的与人探讨产品设计领域的话题，快速形成理解与洞察。
• 系统化后的解决方案设计，或者“用户成功”方法，不仅帮助你成功，还能帮你认知别人的流程，你将可能用你的系统化知识成为顾问，辅导他人。

系统化并不容易，系统化后的经验可以有的放矢的存储，提取，传授，与人交流，解释现象，甚至给人“洗脑”（开个玩笑），这时的你，在这个领域至少也是个初出茅庐的专家（前提是你的系统化足够深邃）。

关键动作四：“指导”（System → Action）

没有指导意义的理论，都是空理论。

很容易理解的部分，实践沉淀理论，理论指导实践，闭环循环，日益改进。不在赘述。

确保“识别”、“萃取”、“系统化”和“指导”四个关键动作的有效发生，可以促进我们一步一步实现知识体系化的升级。而接下来我们重点介绍这四步里最“难”的一步，关于领域知识的系统化。

二、我用的职能领域知识系统化5T模型V1.0

文章标题我提到了三次职能转变，上一章我介绍了领域知识的四个阶段。铺了这么长的垫，四阶段和三次转变有什么关系呢？

反观我的三次转型，我认为我能顺利切入新职能的关键就在于以“系统化”领域知识为目标，不断磨练，思考，积累经验，并不断对经验进行系统化尝试，同时积极用“系统化”知识指导工作，刻意地练习。目标管理领域提到，如果希望目标具有牵引力，目标就需要足够的具体，那么将领域知识“系统化”这个目标，具体形式是什么呢？

结合我自己在三次职能切换时所沉淀的框架，外加对三个职能体系阅历和经历的总结，我导出了以下领域知识系统化的一个5T模型。它也既是我对自己三次职能转换“经验”，的“系统化”。

5T模型：5T模型是一个对职能领域知识进行系统化管理的模型，它将一个职能（如产品经理、运营经理、项目经理等）的领域知识划分为5个组成部分，分别是：主题框架、理论知识、思维、技能和工具。

1. 5T组成部分的概念及示例

主题框架：是一个与职能匹配、逻辑清晰、完整的理论知识索引。

主题框架是这个职能体系的高阶方法论，无论在指引自己工作亦或者对外交流时用于拉齐认知的核心框架。

• 示例1-对产品经理可能采用“用户体验要素：战略层-范围层-结构层-框架层-表现层”
• 示例2-对运营经理可能采用“海盗模型：AARRR”
• 示例3-对商业分析师可能采用“商业模式画布：9要素”

理论知识：是一系列与职能匹配的理论知识点，它们被分类承载在主题框架之下。

理论知识是所能收集到的出色完成职能工作的基础至高阶的所有所需理论知识的集合。

• 示例1-对所有职能的高阶工作岗位来说：战略管理、目标管理、组织行为学等都是所需理论知识。
• 示例2-对产品经理来说：设计心理学、用户行为学等书所需的理论知识。

思维：是前人、业内或自己总结的指导工作的思维。

思维往往是业内、企业内或个人最佳实践的凝练，思维的行程和积累帮助缩小决策范围，加快思路行程，通过思维的传播和拉齐也能减少不必要的讨论，提升决策。

示例-行业思维如：MVP、数据驱动；企业思维如：破局思维；个人思维如：结果导向。

技能：是完成职能工作或出色完成职能工作所需要具备的基础和高阶技能。技能与理论知识有时可能会有重合的地方，区分它们的关键在于熟练度是否能显而易见影响工作质量，技能往往更为明显。

示例-PS之于设计，Axure之于产品，数据分析之于运营，引导术之于项目经理。

工具：是前人、业内或自己总结的提升工作效率、可复用可传播的模板、流程、使用指南。

示例-项目管理的会议设计模板、产品管理的设计自检规范。

2. 我是如何在知识上完成职能转变的？

上图5个组成的排布顺序其实蕴含了一些小心思，把我在实际职能切换中对这五个组成部分的重点积累顺序体现其中。在切入新职能过程中，我一般：

1. 先学习理论知识保证自己能看懂、听懂；
2. 然后学习技能保证快速产出价值；
3. 接着学习和积累工具确保产出效率和质量；
4. 最后是积累思维和建立框架，让自己有见解，会决策，具备通盘考虑和创新的基础能力。

在没有动手实操即将转变至的实际工作前，阅读是最重要的提升手段，阅读的来源包括，但不限于：

• 行业网站/论坛/高品质问答
• 行业书籍入门/实战/深度/理论
• 行业公众号

另外考取认证可以用于辅助提升专业度和自信，动手完成技能“Hello World”是对职能责任心的最基本体现。所切换至的职能一般也都是自己感兴趣的方向，所以理论、人证、技能甚至思维应该都有机会事先积累或涉猎。但自己独特思维以及系统性的框架，唯有通过不断的实战和思考才能逐渐搭建起来。

为了帮助大家感受一下这五个组成要素的内容及覆盖的完整度，下面罗列一些我获取知识的小例子。

每个人阅历、知识体系不一样，对同一本书或文章的吸收也不一样，但迄今为止我所沉淀的职能领域知识基本上都可以划归入以上提到的五个部分（主题-理论-技能-思维-工具）。如：

《精益创业》-让我在创业与产品思维上获得如MVP这样的概念。

《用户体验要素》-让我在产品管理主题框架上获得5层体验要素的概念。

《启示录》-让我获得了丰富的产品思维。

《PMBOK》-让我获得了主体框架、部分理论知识还有一部分框架的内容。

《增长黑客》-让我获得Growth Hacker思维。

《商业模式新生代》-让我获得创业知识体系的主题框架。

“人人都是产品经理”网站-让我获得很多综合的思维、技能、甚至他人的框架用于完善自己的框架

“知乎”网站-让我看见对理论属于或职能的“百家见解”丰富了我对职能概念的理解深度

“李叫兽”公众号-让我获得许多营销、文案、思考相关的技能和思维，实在受益匪浅。

…

3. 我目前的互联网PMO知识体系V0.8

虽然我在切入领域过程中5个组成部分的积累先后顺序基本Follow：

“理论知识 → 技能 → 工具 → 思维 → 主题框架”

这样一个顺序。

但在体系逐渐梳理处理后，它们的逻辑更像是从：【主题框架】导出【理论知识】，【技能】、【工具】和【思维】三部分支撑主题出色完成这样一个逻辑。

以下以我还在梳理中的“互联网PMO知识体系V0.8”的例子，展示一下在我处梳理后的5T模型大致的样子：

————————————————
版权声明：

遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：http://www.woshipm.com/zhichang/2674042.html