在日活10亿的产品做TPM实习生是怎样的体验？

注：本文仅为个人分享，不代表企业观点；所有企业信息均已隐去或脱敏。

全文共9,566字，阅读需要18~20分钟

写在前面

这段实习经历，可能是不太幸运的2022年里最幸福的一件事。第一次接触到从前耳闻向往却不曾亲眼目睹的职业，这段体验极大程度地超出了我的预期，“成就他人”是贯穿我们行动的关键词。在这里，作为实习生，我也能得到充分的空间进行思考和行动。

实习生活走入尾声，回想起来既感动又欣喜，所以希望能用此文对我作为研发项目管理（aka TPM）的经历做一个简短的回顾，也与更多人分享我的体验和职业成就感。

项目管理：现代组织发展中的必需职能

“项目管理”最早帮助建筑、航天工程团队在质量、成本、时间的三角之间寻找可接受的制衡点。在今天，项目管理的应用范畴扩展至ICT、互联网产品等软硬件项目。

依据组织特点，满足组织管理需要，不同企业中的项目经理/PMO们会有各异的职能。但总之，都是帮助组织管理从混乱走向有序，项目信息从未知确定为已知，决策渐进明细。

项目管理是如同吃饭喝水，稀松平常而重要的能力

你可能不会意识到，自己的某个习惯已经是项目管理的行动。

计算机系的同学应该不会对图论中的“关键路径法”感到陌生，它引导我们把所有任务抽象为有向无环图，梳理依赖和开始/结束时间，找到决策中必须完成的最长路径和时间长度，以此计算决策最短时间/最优解。这个方法，最早便应用于项目管理中，也是我对于项目管理的启蒙。

常用于人员排期的甘特图，也是最早的项目管理工具之一。

把一个大目标（比如，复习一门课），拆分成互斥可执行的ToDo项（按考试章节复习），并确认优先级（按分数占比决定复习顺序），往往也是我们会做的事情。在项目管理中，这被称作“工作分解结构（Work Breakdown Structure / WBS）”。

为什么大型组织需要项目管理角色

假设这样一个情景，你是计算机系的学生小鸣，梦想是做家喻户晓的互联网产品。

1.马上要毕业了，你迎来大学四年里最重要的事情——毕业设计。你需要独立开发一个系统。你得独立完成需求调研、产品功能构思、交互逻辑设计、客户端/服务端系统设计、编码、测试，并糊上一层程序员审美的UI。为了实现这些目标，同时也向导师交差，你得给自己制定好计划，在某个时间点实现相应的功能，最后完美撒花。

2.你的毕业设计取得了一致好评，有其他程序员小伙伴认可你的产品价值，想和你搭伙，你也希望继续迭代。为了更高效的协作，减少互相干扰，你们分工为Web端、客户端、服务端、QA。同时，你们用Git处理代码冲突，用GitHub管理代码仓库，而你作为团队的核心也需要追踪大家的分工和进度。

3.有投资人看上了你的创意，大手一挥，你成为真正意义上的小老板，每次迭代的交付也需要更加正式。商场如战场，商机瞬息万变，你意识到你的产品研发要提效更要提质。有产品经理和设计师的加入，将产品逻辑改造得更加清晰，交互和视效更贴合用户的使用习惯；同时，研发资源开始不够用，研发和产品经理更谨慎地协商每一次迭代的新需求，尽量高效地利用资源。由于分身乏术，身为项目直接负责人的你不再投入大量的时间写代码，把更多时间花在产品战略构思和团队沟通中。

4.你的事业蒸蒸日上，招兵买马，走上商业化的正轨。酒香也怕巷子深，除了关注产品本身，你们开始投入人力到市场、运营中，商业合作洽谈也成为你的工作。团队沟通、项目实施、风险控制的任务，由一位项目经理替你分担。

5.若干年后，你终于实现了起初的愿望，做家喻户晓的产品，你的企业也成为大家口中的“大厂”。你的产品发展趋近成熟期，衍生出许多不同的业务线和价值链。早期服务于业务导向而赶工的工程开始爆出协作的隐患，需要自下而上逐步重构替代；各业务线有更专精的子团队进行设计和开发，如何将他们实现的产品功能价值跨团队串联是大体量产品无法回避的难题；随着人员的扩张，亟须科学的管理方法加以控制。项目管理办公室（PMO）的介入，为大团队的流程协作设立公认可接受的规范，并根据团队特点在实施中改进；有技术理解力的研发项目经理（TPM）从管理视角参与业务线成长，为跨团队软件工程项目提供支持，在项目中同步信息、协调资源、处理风险，并同时管理由若干项目组成的项目集，确保最大化交付业务线价值。

从以上的例子中可以看出，无论团队大小，“项目管理”的职能是贯穿始终的，区别在于越复杂的组织中越需要抽出专业的角色做专业的事。产品、研发如此，项目管理亦如此，团队越复杂，项目经理角色和部门的跨团队协作、管理的价值也就越不可取代。

成就他人，帮助团队正确地做事

上面的例子提到了TPM和PMO两种角色。而在我所处的语境中，更倾向于表示一种角色的两类职能，因技术导向较其他职能PMO更重，“产研PMO”更为贴切。根据团队成熟度和特点的不同，调整职能分配占比。

PMO：项目管理办公室，PMBOK对PMO的最新定义是“对项目相关的治理过程进行标准化，并促进资源、方法论、工具和技术共享的一个组织部门”。

我所在的PMO团队负责横向支持研发团队的通用流程设计与执行，通过度量方法和团队调研对流程进行改进优化，以达成尽量高的研发效率。

TPM：技术项目经理，管理某一研发业务线的项目集（Program）和项目（Project），保障重要专项的交付结果和交付质量，负责项目从启动到结束的端到端全生命周期管理。

TPM观察项目/项目集状态（图中横向），PMO关注整体流程效能（图中纵向）

一言以蔽之，我们是服务互联网产品研发团队，在跨团队协作中，围绕软件工程负责流程管理和专项交付的经理人。成就他人，正确地做事，是我们的使命。

IBM、CISCO是ICT行业最早一批引入项目管理的IT企业，随后国内的华为、UC、阿里巴巴陆续引入IT项目管理，并成立PMO团队。在微软、谷歌等公司，TPM已经是发展得比较成熟的职业，而国内TPM也在字节等头部企业野蛮生长中。

目前，美国项目管理学会PMI是全球最知名的项目管理专业组织机构，并推出项目管理知识体系指南（PMBoK），引申出PMP，ACP，PRINCE2等专业资格认证。

我是怎么转向TPM的

从产品经理到项目经理，几乎是原地急转弯的区别。坦白说，在此之前，我完全没在“项目管理”的赛道上做过专门的准备。但，最后这个选择能收获满满，既有运气的成分，也是意料之中。

恰到好处的运气

第一次接到了HR的电话，说在人才库看到了我的简历。第一次听到“你的简历很匹配，通过的概率很大”这样的承诺，心花怒放。十分感动，但还是因为漫长的雅思备考无法match上入职时间，主动拒绝了。

第二次是在临近雅思备考结束，在平台上看到了非常相似的职位。试探着点了投递，转头就忘了这件事，直到再次接到同一个电话。还有这么巧的事？想着还是试一试吧。

双向奔赴的诉求

虽然投递是巧合，但在此之前我就已经关注到TPM这个岗位。

我很清楚自己的职业愿望：开放交流，追求效率，共享最佳实践。帮助别人更快更好地达成目标，就是我的目标。

我很喜欢计算机科学，并且充分享受科学和工程带来的便利；热衷于自动化工具，喜欢折腾文档和笔记，写字和写代码是我浮躁内心难得的心流体验。我希望和更多人分享技术带来的便利，所以一开始想做技术导向的产品。

年初，在社交平台上刷到一位谷歌的TPM。以为是技术产品经理，浅聊一下，发现是技术项目经理。通俗地解释，产品经理负责一个产品的全生命周期，重需求策划与实现的从0到1；技术项目经理负责产品中多个项目的全生命周期，重产品规划中从1到100的能力组合与迭代。自那以后，开始在外网有意无意关注着。

至今还记得面试那天的情景。没有套路和技巧，我们交流了很多有意思的情景，计划、沟通、风险、复盘是关键词。我的紧张逐渐随交流缓解，有条不紊地解释想法和思路。

反问环节我问，“你们对实习生有什么期望吗”，面试官（也就是我的导师）花了10分钟结合TPM的职能对我分享；在二面，也从leader那得到更深入的补充。收到了至今为止最诚恳的回答。

这份职业热情打动了我。我希望利用好技术背景，帮助他人高效投入有价值的工作；研发项目管理需要我抱有成就他人的同理心，有结果导向的自驱力，也要有改变不合理的能力。

成长为“职业经理人”的种子，大概就是从这段时间起，扎根在心里。

作为TPM，你将会经历这些

成为TPM的第一课是PDCA。PDCA是一套循环式的质量管控流程，通过规划（Plan）、执行（Do）、查核（Check）、行动（Action/Adjust）四阶段，确保每次的目标都能达成。由美国学者爱德华兹·戴明提出，因此也称戴明环。PDCA形成的闭环，既是对单个项目的保障，也能从中总结经验，调整至下一次运转中，持续正向。

流程管理、专项交付、团队赋能，是我们最主要的职能。下面让我尝试以PDCA的思路，介绍TPM的一天：

流程管理：Develop a Process As a Product

另一个平行时空的小鸣，在做毕业设计之前，先来到一家科技公司做研发项目管理实习生。今天，他的任务是作为PMO，组织本周的需求流程管理。

小鸣所在的产品线，起初是只有十几个人的小组，团队项目管理可以相对容易地控制在一位项目经理手中。

随着业务增长，现在分离出几组不同的子业务，由各自的产研大组负责设计开发，总体规模成长为几百人的中型团队。由于产品还在快速增长期，子业务之间耦合频繁，一个需求常常要跨多条业务线配合。同时，也经常有外部团队提需合作。

总的来说，提出-设计-开发-测试-上线是最主要的需求流程。设想一下，如果没有公开认可的流程，中型团队的日常会是怎样的：

• 早晨十点，研发同学从待办需求里抽出被催促得最急的一项，拿着还没聊清楚的PRD开始写代码。刚进入状态，一条来自产品经理的加急打断了思路，又出现了一个紧急的需求，需要按照上线DDL倒排时间。没办法，他只能草草结束手上的需求，切换到下一项，却忘记把完成开发的分支交给QA做测试。
• 产品经理今天很愁，因为手上的几个需求又延期了。有些是因为研发资源被其他需求临时占用，有些是测试bug太多需要返工，甚至出现了线上事故被紧急下线。有的需求没确认细节就被赶进开发，最后的还原度不符合预期。白天忙于到处救火，只有深夜才能坐下来草草赶制PRD。
• 处于流程后置环节的QA同学总是很被动。前面待测试需求的开发逾期，导致后续的测试人员和排期也要被迫调整。要么就是因为逾期，压缩了测试的时间。匆匆赶工的代码质量，即使勉强能运行也会在测试环节被重新阻塞。到了封版集成的时间，加塞的需求给最后的版本发布又带来了新的风险。

DevOps神书，推荐阅读：《凤凰项目：一个IT运维的传奇故事》

为了提高资源利用率和承接/交付需求的能力，避免需求之间出现研发资源挤占或互相空等的情况，并且给内外部合作设立清晰的指引，PMO小组依据当前团队的特点（如 中型规模、耦合多、发版频繁），参照软件生命周期（SDLC），设计了需求开发通用流程，跟踪需求从创建至上线的全生命周期。

Plan：标准化工作流设计

前两天，某条业务线的QA组长找到小鸣，希望他在流程里加入“Showcase展示”这个步骤，在研发结束后展示需求效果，再开始测试。今天，小鸣拉着Ta，聊聊设置这个步骤的原因，和想要达成的预期效果。

访谈后，小明了解到，背后的诉求其实是QA觉得最近的研发代码质量把关不严，经常出现自测用例不通过就提交代码测试的情况，导致测试阶段出现的bug比以往更多，QA提bug单后需要等待更长的时间修复。和其他业务线交流后，小鸣发现这个问题之前在团队内普遍存在，而近期在这条业务线更频繁出现。

软件测试原则：尽早、不断进行软件测试，一个错误越早发现，改正它需要的改价就越小。

对比过多个解决方案（如，在各端测试前，分别设置准入条件）后，小鸣和QA组长还是觉得以Showcase展示通过作为准入卡点最合适，也能提前展示功能的主流程，帮助产品经理和研发同学尽早暴露可能存在的问题。

流程的改动不是拍脑袋想出来的。首先，要确认适用的范围和使用的方法，防止修改了却没人用得上。讨论后，小鸣决定先在这条业务线进行试点，测试负责人需要作为Showcase环节的直接责任人，做好把关和记录。测试负责人要在开发启动时，提供研发自测的用例，同时以自测100%通过率作为Showcase的准入条件。满足这个条件的需求代码，一般能保证基础的功能流转正常，不至于出现反复不通过的情况。

其次，在复杂流程中，改动需要和涉及的角色提前确认合理性，并通知流程上下游的影响。比如，该业务线的研发组长、QA组长负责安排项目计划和调整人力资源，在新增的步骤里都是最直接的干系人，要保证Ta们对新增改动的影响和收益可以接受。负责需求开发的研发、QA是执行者，需要让他们知道怎样做，确认流程可行。

Do：流程推动执行

万事俱备，准备开工。

上述提到的这些原则和条件，小鸣需要记录一份简易清晰的文档，作为流程指引。同时，更新原有的SOP（标准作业流程），避免口径不一。

项目管理工具往往是团队共建的数据空间。就像合作的代码仓库一样，一个小的修改就容易引发大的故障。在项目管理工具中配置完成后，小鸣还需要测试一下改动方式是否符合预期运转，并且将改动记录在团队统一的日志里，也便于其他的管理员查找和参考。

手持文档，小鸣可以在业务线研发团队中“布道”了，通过开会/私信/录屏的方式，确保流程的改动和使用方式周知业务方，宣贯到位。

最后，在流程试运行的时间里，小鸣需要作为“售后”，收集大家的使用体验，回答使用上的问题。

Check：研发效能度量

真金不怕火炼，好的成果需要数据和评价证明。

优化的目的是为了提高流程效率，改善研发质量。经统计，流程优化后的单位工时内bug数（即研发效能中的基础指标 bug估分比），有了显著的下降，大部分代码缺陷在自测阶段就以较低的代价被拦截或修复。

对于流程本身，设置是否有必要或具有通用性，得评估用户的使用习惯，在这里是“有多少需求能用上”。试运行期间，这个步骤被配置为可调整的开关，按需使用。有70%的需求打开了开关，其中绝大多数为有功能或UI改动的需求，属于高频使用流程。

用户的感受，需要访谈了解。小鸣和几位之前经常遇到代码质量问题的研发、QA聊了聊，大家都对流程的效果比较认可，使用上没有特别反直觉的体验，也反馈了一些改进建议。

注：研发效能度量的目的是，以尽可能少打扰的方式，衡量工程团队的研发效率与质量，在业界有成熟的指标体系和度量方法。

Action：流程迭代通用化

Showcase流程带来的收益得到了验证，不久后便推广到了全业务线有功能改动的需求中，成为必选项。小鸣根据大家的意见，细化了使用条件和相关角色，更符合团队当前工作流。

专项交付：每天起床第一句，今天项目On Track吗

小鸣的导师很看好他，决定交给他一个新任务——某业务线的跨线重保专项。这一次，小鸣需要作为主导方的TPM进行项目管理，并邀请合作的中台部门的TPM协助。

小鸣所在的业务线是需要快速迭代验证收益的C端产品，单周发版。作为业务方，依赖于公司内部中台提供的基础能力进行开发。中台产品需要综合考虑多类业务方的需求，进行通用化设计，同时复杂的内部系统也需要被划分为多个独立模块。因此，在时间上，中台产品需要更长的时间制定适配计划；在项目管理上，中台内部分工复杂，对业务方项目管理带来挑战和风险。

PMBOK认为项目全周期可以划分为五大过程组，主要包括项目启动、项目规划、项目执行、项目监控和项目收尾。PDCA循环是五大过程组的理论基础。

实际项目的管理中，会交付具体的文档，作为项目行动的成果，同时也是下一阶段的预备准入条件。

Plan：项目启动规划

业务方 <-> 中台过往的合作中，依赖关系复杂、项目计划有分歧、任务并发风险高，是主要的合作痛点。为有效解决这些问题，小鸣这次需要从项目启动阶段强跟进介入，开个好头，让大家在合作方式上达成一致。

小鸣先找到业务线的产品经理和研发负责人，确认业务方的预期目标。由于研发人力紧缺，协商后，项目会被拆分为优先级不一的多个阶段，陆续上线，便于验证收益。其中第一阶段是产品的MVP版本。通过让弱依赖的模块并行（比如，第一阶段的AB Test验证和第二阶段的方案设计一起开始），尽量在低风险的前提下，压缩项目时长。

带着初步的计划，小鸣和业务线同学拿着粗估的计划，和中台对接人在项目开始前做好前置沟通，预留充分的方案设计时间。最终，业务方和中台粗估产品方案和技术实现形式，两边预留人力，并一致确认项目的规划。随着细节逐渐确认，再渐进明细具体的项目计划和排期。

一鼓作气，再而衰，三而竭。作为项目的“誓师大会”，小鸣邀请双方的leader们和项目的所有参与者，参加kick-off 会（aka 项目启动会），在会上周知项目计划和预期，锁定资源，确认后续的“规范”，如沟通方式为每周开一次周会，需求变更需要全体同意并记录在文档中。最后各自抛出疑问统一回答。

Do：项目执行

中台提供的解决方案，可以被划分为不同模块中的feature，由不同的产品经理和研发负责，导致工作进度和干系人的管理都变得十分复杂。因此，中台侧会有统一的产品/研发对接人，在中台和业务方之间协调沟通，降低理解成本。小鸣也邀请了中台TPM，协助中台侧的进度管理和风险控制。

小鸣梳理出一张技术架构示意图，划分出业务方 / 中台方的代码改动范围，中台内部的模块和对应的待开发feature。两边研发工程师的ToDo，和feature之间的依赖关系，一目了然。在这个专项中，依据这个示意图拆解WBS，以模块和feature的粒度分配工作计划、追踪进展，会更清晰和易理解。

规划和执行期间，产品经理负责细化需求设计文档，研发工程师确定最终的技术方案。产品方案和技术方案都通过评审，确定任务优先级和人力分工，就可以准备进入开发。所有确定的信息和文档，被小鸣汇总到专项One Pager里，作为成员同步信息的中心。

Check：项目状态监控

“状态”，一般会被小鸣划分为“On Track / 正常”、“At Risk / 有风险”、“Pending / 暂缓”、“Delay / 延期”这几种。每周，小鸣负责组织项目周会，和项目组确认项目当前进度，检查是否符合当初设立的里程碑，抛出问题和风险。对于风险，需要尽快讨论清楚、确认对策和时间点。

每次周会结束，小鸣会对本周的项目进展做一次总结，发送到项目大群，作为公告。这样能让上级、组长等Sponsor（项目支持者）了解到项目的状态。

Action：项目收尾复盘

为了下一次做得更好，需要项目中的各方参与者（如产品、研发、QA）共同完成项目的总结复盘，讨论过程中做得好与不好的地方，有则改之无则加勉，同时也让项目成员对过程、结果达成一致。复盘中留下的待优化项，需要落实到具体的人和时间点，由小鸣跟进完成，为下一次合作打好基础。

团队赋能：人人都是项目经理

前面有提到，项目管理是非常普遍的职能，只是随组织所处阶段交由不同的角色执行。哪怕流程和工具做得再好，项目经理的单点人效是有上限的，能支持的规模有限。而需求的增长是无限的，更多的时候，需要项目的直接负责人（产品经理或研发）具有项目管理能力，对自己的需求或项目端到端跟进。

授人以鱼不如授人以渔。为了让团队内更多人掌握良好的项目管理能力，形成良性循环，解放人力，项目经理也会在团队建设方面花费不少的精力。我所在的团队，有“PMO学院”的共建知识库，分享项目管理的基础教程和工具模板，以标准化的形式辅导团队项目管理能力；同时，也会定期开设线上或线下的培训课程，根据指定的topic进行辅导。文档、教材和课程的沉淀，也有效减轻了项目经理和管理职能向下教育的成本，大家对标准、规范能够形成共同的认知。

真实体验：和优秀的人，做有挑战的事

“从被动执行到主动思考和理解业务，是60分到80分的区别。如果做到100分，更多的是靠热情。你真的很热爱一件事情，做完了特别有成就感，那这个是可遇而不可求的，就跟人有关。”

在坦诚开放，坚持问题导向的环境里做项目管理，是一件非常有爽感的事情。你需要有沟通协调的软素质和为人着想的同理心，但不再需要花费过多的精力在察言观色和应酬上；相反，同理心支持大家互相包容、善意假设，就事论事，一切为了结果负责。

相比产品、运营、研发，TPM在国内市场中没有特别大的需求。一是因为大型企业、复杂团队协作中，TPM才能发挥最大的价值，国内企业较少能达到这样的体量；二是TPM的需求和企业扩张的速度成正比，在降本增效的现况下，组织不再膨胀；三是国内企业的项目管理职能宽泛，很多企业内的PMO成熟度并不高，项目经理发展空间和上升渠道有限。

我所在的团队可能是少数能满足这些发展条件的地方：有扩张中且营收向好的国际化业务，PMO团队有成熟的工具和方法论培养项目经理。团队依旧在高速成长的阶段，对于新人，既有成熟项目需要迭代优化，可以积累经验，也有不少从0到1的建设，提供充足的发挥空间。哪怕是实习生，满足基础的专业素质后，同样有承接专项的机会。

对于我自己，计算机专业的学生从研发转向非研发，有一个漫长的探索过程。在过去的实习和经历里，我想找到一个位置，既能利用好专业背景，又能发挥软素质的优势，做好职能之间的桥梁，最大化自己的价值。作为TPM，技术基础帮助我无痛landing，跳过许多沟通的gap；而快速自学的能力和表达欲，支持我在短暂的时间里了解职能背景和业务概貌，在入职不久后就能介入项目跟进。

作为实习生，很幸运地能接受系统性的指导和培训，对于应届生的项目管理培养是国内天花板级的存在。很少有团队会培养校招PMO，更多的互联网企业会直接选择中高级产研转岗或社招高阶PMO的方式搭建人才梯队。

我的导师是一位充满职业热情与成就感的教练型PMO，乐于在团队内分享职业知识和传递价值。这种言传身授的方式，教给我许多项目管理的专业素质能力，清晰有力地指引我成长，以“职业经理人”的要求自居。在团队里，每个人的意见都会被充分交流和考虑，有这样一群优秀的人和你一起朝一个方向努力，真的很难不热血沸腾。

至今还清晰的记得面试时，导师反馈的“对实习生的期望”。我想不只是作为实习生，这样的要求也是我对自己未来职业发展的诉求。

个人职业理解：岗位间的异同

比较对象：研发项目管理 / 互联网产研PMO，负责产研业务线的流程管理和专项交付

说了这么多，我会继续做TPM吗

首先答案是，我的第一份工作不会以项目管理作为首选。这段经历在项目管理上的专业性对我后续的求职产生很积极的影响，让我重新选择我也还是会来；项目管理一定会是我的亮点，TPM大概率会是我的职业中期发展路径甚至终点。

一是个人职业发展的意愿，希望在职业起点更贴近业务，放大专业优势，积累产研经验。有项目管理能力的产品经理，在职业初期可能会比“有业务理解力的项目经理”更容易发挥优势。

二是因为项目管理的综合要求，很难通过“学习”达到成熟的水准，而是随亲身实践的产研项目经验积累的。考虑到作为低阶PMO，缺少实际产研经验显得有些局限，也很难有说服力。

三是项目管理本身需求量较少，以此作为校招首选很容易扑空。从就业准备的角度看，准备其他业务岗对项目管理方向的兼容性会更强。

因此，我还是希望体验其他的职业赛道，再在合适的时机调整方向。目前的考虑是，尝试做技术导向的产品策划或运营。比如，我对效率工具和开发者工具很感兴趣，希望可以借助好用的工具解放人效，创造价值。

• 知识管理：入职前，我就开始基于飞书搭建自己的内容管理体系。留学申请全程自助，用多维表管理信息并共享，用飞书文档和妙记自学语言，取得高于预期的香港科技大学offer，节省了3-4w的中介费和语言培训费。

• 数据管理：在职期间，多维表格帮助我灵活地完成了很多数据收集同步的功能，并实现了简单的数据管理系统。期间成了oncall群常客，记住了许多面孔。希望有机会深入开发多维表的玩法和基础能力建设。

• 项目管理：在团队学习了许多“流程管理之禅”。流程设计要满足当下的使用需求，尽可能通用化；要注意细节和规范，梳理权限、条件，让空间配置收敛得干净并可拓展。作为项目管理平台的超级管理员，在做配置的同时，也要思考“工具为什么是这样设计的”。（还有效能度量和计算公式配置，痛并快乐着）