主题
03 技术术语（PM 需要了解的程度）
PM 不需要会写代码，但需要听得懂工程师在说什么、为什么这么说、以及这对产品意味着什么。
PM 为什么要了解技术术语？
你可能会想：「我是产品经理，又不是程序员，为什么要学技术？」
来看几个真实场景：
| 场景 | 如果你不懂技术术语... | 如果你懂... |
|---|---|---|
| 工程师说「这个需求要改后端接口和数据库表结构」 | 你不知道这意味着什么，无法判断合理性 | 你理解这涉及底层改动，开发周期会更长，可以提前调整排期 |
| 工程师说「加个缓存就能解决」 | 你不知道缓存是什么，也不知道这算不算一个好方案 | 你知道缓存能提升速度但可能带来数据不一致的问题，可以追问细节 |
| 上线后崩溃率飙升 | 你只能干着急，等工程师修 | 你能看懂崩溃报告的关键信息，参与优先级判断 |
| 老板问「为什么这个功能要做 3 周」 | 你只能说「工程师说要 3 周」 | 你能解释「因为需要前后端联调 + 接口改造 + 数据迁移」 |
PM 了解技术的目标不是写代码，而是：
- 能与工程师有效沟通（听懂方案、提出合理问题）
- 能判断技术方案的合理性（这个排期靠谱吗？有没有更简单的方案？）
- 能在产品设计中考虑技术约束（这个功能在技术上可行吗？性能影响大吗？）
术语详解
一、架构基础
前后端分离
| 项目 | 内容 |
|---|---|
| 是什么 | 将产品分为「前端」（用户看得见、摸得着的界面）和「后端」（用户看不到的服务器逻辑和数据处理）两部分，由不同的团队独立开发。 |
| 类比 | 餐厅的「前厅」和「后厨」分离。前厅负责接待客人、展示菜单、上菜（前端），后厨负责备料、烹饪、出餐（后端）。两者通过「出餐窗口」（API）沟通。 |
| PM 为什么要了解 | 当你提一个需求时，需要判断这个需求影响的是前端（改界面就行，相对快）还是后端（改数据逻辑，可能更复杂），或者前后端都要改（需要联调，时间更长）。 |
用户看到的 用户看不到的
┌─────────────────┐ ┌─────────────────┐
│ 前端 │ API 请求 │ 后端 │
│ (App / 网页) │ ──────────→ │ (服务器程序) │
│ │ │ │
│ · 页面布局 │ API 响应 │ · 业务逻辑 │
│ · 按钮交互 │ ←────────── │ · 数据处理 │
│ · 动画效果 │ │ · 用户验证 │
│ · 表单输入 │ │ · 数据库读写 │
└─────────────────┘ └─────────────────┘API -- 应用程序接口
| 项目 | 内容 |
|---|---|
| 英文全称 | Application Programming Interface |
| 是什么 | 不同系统之间沟通的「约定好的规则」。前端通过 API 告诉后端「我要什么数据」，后端按约定返回数据。也用于不同系统之间的对接。 |
| 类比 | API 就像餐厅的菜单。顾客（前端）不需要知道后厨怎么做菜，只需要看菜单（API 文档）点菜（发请求），后厨（后端）就会按菜单做好送上来（返回数据）。 |
| PM 为什么要了解 | (1) 与第三方合作时需要了解对方提供什么 API（如接入微信支付）；(2) 能看懂 API 文档有助于理解功能边界；(3) 当工程师说「这个 API 还没开发」，你知道前端就无法展示对应数据。 |
SDK -- 软件开发工具包
| 项目 | 内容 |
|---|---|
| 英文全称 | Software Development Kit |
| 是什么 | 封装好的工具包，让开发者不用从零开始做某个功能。通常由第三方提供，包含 API、文档、示例代码等。 |
| 类比 | 如果 API 是菜单，那 SDK 就是「预制菜套装」——不仅告诉你有什么菜（API），还把半成品食材、调料包、烹饪步骤（工具代码、示例、文档）都给你了，你只需要简单加工就能上桌。 |
| PM 为什么要了解 | 很多功能可以通过接入第三方 SDK 快速实现（如推送、支付、地图、数据分析），不需要自研。PM 需要评估「自研 vs 接入 SDK」的取舍（成本、时间、可控性）。 |
| 实际举例 | 想做消息推送？可以接入极光推送 SDK，3 天搞定。自研？可能需要 3 个月。但接入 SDK 意味着依赖第三方，如果对方服务挂了，你的推送也会挂。 |
数据库 (SQL / NoSQL)
| 项目 | 内容 |
|---|---|
| 是什么 | 存储和管理数据的系统。所有的用户信息、订单数据、商品信息等都存在数据库里。 |
| SQL 数据库 | 关系型数据库（如 MySQL、PostgreSQL），数据以表格形式存储，行列清晰，适合结构化数据。类比：Excel 表格，每一行是一条记录，每一列是一个字段。 |
| NoSQL 数据库 | 非关系型数据库（如 MongoDB、Redis），数据存储更灵活，适合非结构化数据、高并发场景。类比：文件夹里的文档，格式可以不统一。 |
| PM 为什么要了解 | (1) 当你要求「在列表页增加一个筛选条件」，工程师可能说「数据库没有这个字段，需要先加字段再迁移数据」，你需要理解这不是随便加的；(2) 数据库设计直接影响产品能力的扩展性。 |
简单对比：
| 对比项 | SQL（关系型） | NoSQL（非关系型） |
|---|---|---|
| 数据结构 | 固定表格，结构严格 | 灵活文档，结构自由 |
| 典型代表 | MySQL, PostgreSQL | MongoDB, Redis |
| 适合场景 | 用户信息、订单、财务 | 日志、聊天记录、推荐数据 |
| 类比 | Excel 表格 | JSON 文档/文件夹 |
微服务
| 项目 | 内容 |
|---|---|
| 英文 | Microservices |
| 是什么 | 将一个大型应用拆分为多个小型、独立的服务，每个服务负责一个特定功能，可以独立开发、部署和扩展。 |
| 类比 | 从一个「什么都做的大厨房」变成多个专业的「档口」：面档、烧烤档、饮品档...每个档口独立运营，互不影响。面档出问题了，不影响烧烤档继续出餐。 |
| PM 为什么要了解 | (1) 微服务架构下，一个功能可能涉及多个服务团队的协作，排期需要对齐；(2) 某个服务出问题不一定影响全局，PM 需要判断影响范围；(3) 新功能的技术方案可能涉及「新建一个微服务」的决策。 |
容器化
| 项目 | 内容 |
|---|---|
| 英文 | Containerization (Docker / Kubernetes) |
| 是什么 | 将应用程序及其运行环境打包成一个标准化的「容器」，可以在任何地方一致地运行。解决了「在我电脑上能跑，在服务器上就跑不了」的问题。 |
| 类比 | 集装箱运输。以前散装货物装卸麻烦，现在统一用集装箱，任何港口、任何船只都能装卸。容器就是软件的「集装箱」。 |
| PM 为什么要了解 | 了解即可。容器化提高了部署效率和环境一致性，使得频繁发版（如每日发版）成为可能。如果你的产品需要快速迭代，容器化是技术前提之一。 |
二、数据与监控
埋点
| 项目 | 内容 |
|---|---|
| 英文 | Event Tracking / Data Instrumentation |
| 是什么 | 在产品的关键位置「埋」入数据采集代码，记录用户的行为（点击了什么、浏览了多久、从哪里来）。是数据分析的基础，没有埋点就没有数据。 |
| PM 为什么要了解 | PM 通常是埋点需求的发起者。你需要规划：哪些页面需要埋点、记录哪些事件、需要采集什么参数。如果上线后发现「这个数据没有埋点」，就要等下次发版才能补上。 |
埋点设计示例：
| 事件名称 | 触发时机 | 需要记录的参数 | 分析用途 |
|---|---|---|---|
| page_view | 用户进入页面 | page_name, source, user_id | 统计各页面 PV/UV |
| button_click | 用户点击按钮 | button_name, page_name, position | 分析用户交互行为 |
| add_to_cart | 用户加购 | product_id, price, quantity | 购买漏斗分析 |
| payment_success | 支付完成 | order_id, amount, payment_method | 交易数据统计 |
数据上报
| 项目 | 内容 |
|---|---|
| 是什么 | 将客户端（App/网页）采集到的埋点数据发送到服务器端进行存储和分析的过程。 |
| PM 为什么要了解 | 数据上报可能因网络问题丢失，导致数据不完整。PM 看到数据异常时，要考虑是不是上报问题，而不是急于做产品判断。另外，过多的数据上报可能影响 App 性能和用户流量。 |
缓存
| 项目 | 内容 |
|---|---|
| 英文 | Cache |
| 是什么 | 将经常访问的数据临时存储在一个「更快的地方」，下次访问时直接从缓存读取，不需要再去数据库查询。大幅提升速度。 |
| 类比 | 你经常查某个电话号码，与其每次都翻通讯录（数据库），不如把它记在便利贴上贴在桌面（缓存）。下次直接看便利贴就行了。 |
| PM 为什么要了解 | (1) 缓存能加速页面加载，提升用户体验；(2) 但缓存可能导致「数据不是最新的」——比如用户改了头像，但缓存还是旧头像。PM 需要和工程师讨论哪些数据可以缓存、缓存多久。 |
CDN -- 内容分发网络
| 项目 | 内容 |
|---|---|
| 英文全称 | Content Delivery Network |
| 是什么 | 在全球各地部署服务器节点，将图片、视频等内容分发到离用户最近的节点。用户访问时从最近的节点获取内容，速度更快。 |
| 类比 | 总仓库在北京，但在上海、广州、成都都设了分仓。上海用户买东西从上海仓发货（CDN 节点），不需要从北京发，到货更快。 |
| PM 为什么要了解 | (1) 产品中大量使用图片/视频时，CDN 是必须的，否则加载会很慢；(2) CDN 有成本，图片越大、流量越高，费用越高。PM 需要在图片质量和成本之间取舍；(3) 海外用户访问中国服务器很慢，CDN 是国际化的技术前提。 |
三、工程实践
CI/CD -- 持续集成/持续交付
| 项目 | 内容 |
|---|---|
| 英文全称 | Continuous Integration / Continuous Delivery (或 Deployment) |
| 是什么 | CI：开发人员频繁地将代码合并到主分支，每次合并自动运行测试，确保代码质量。CD：代码通过测试后自动部署到生产环境，无需人工操作。 |
| 类比 | 工厂的流水线。以前做完一批产品才集中检测（容易发现大量问题），现在每做完一个就检测一个（CI），合格的立刻送去包装发货（CD）。 |
| PM 为什么要了解 | CI/CD 的成熟度直接决定了发版频率。有完善 CI/CD 的团队可以做到每天发版甚至一天多次，没有的话可能一个月才能发一版。这直接影响你的迭代速度和灰度策略。 |
Git -- 版本控制
| 项目 | 内容 |
|---|---|
| 是什么 | 代码版本管理工具，记录代码的每一次变更，支持多人协作、版本回退、分支管理等。几乎所有软件团队都在用 Git。 |
| 类比 | 写论文时的「修订历史」。你可以看到每一次修改了什么、谁修改的、什么时候修改的，还可以随时恢复到之前的任何一个版本。而且多人可以同时改不同部分，最后合并在一起。 |
| PM 为什么要了解 | (1) 了解分支模型有助于理解开发流程（为什么要建分支、为什么要 Code Review）；(2) 出现线上问题时，「回滚到上一个版本」是通过 Git 操作的；(3) 有时 PM 需要查看代码仓库来了解功能配置或文案。 |
灰度部署 / 蓝绿部署
| 项目 | 灰度部署 | 蓝绿部署 |
|---|---|---|
| 英文 | Canary Deployment | Blue-Green Deployment |
| 是什么 | 新版本先部署到一小部分服务器，少量用户先体验，观察无问题后再全量部署。 | 同时维护两套完全相同的生产环境（蓝和绿）。新版本部署到绿环境，测试通过后将流量切换到绿环境，蓝环境作为备份。 |
| 优点 | 风险小，可以逐步放量 | 切换快，秒级回滚 |
| PM 为什么要了解 | 这决定了上线策略。如果采用灰度部署，PM 需要规划放量节奏（1% → 10% → 50% → 100%）和观察指标。 |
负载均衡
| 项目 | 内容 |
|---|---|
| 英文 | Load Balancing |
| 是什么 | 将大量用户请求分散到多台服务器处理，避免单台服务器过载崩溃。 |
| 类比 | 银行大厅的叫号系统。不是所有人都排一个窗口，而是根据各窗口的忙碌程度，将客户分配到不同窗口。 |
| PM 为什么要了解 | (1) 大促活动（如双十一）需要提前做容量评估和负载均衡准备，PM 需要提前通知技术团队预期流量；(2) 如果出现「服务器扛不住」的情况，PM 需要理解原因并参与降级方案的制定。 |
四、性能指标
PM 需要关注的性能指标主要有以下几类：
前端性能指标
| 指标 | 英文全称 | 含义 | 健康标准 | PM 为什么关注 |
|---|---|---|---|---|
| FCP | First Contentful Paint | 首次内容绘制，用户第一次看到页面内容（文字/图片）的时间 | < 1.8 秒 | FCP 过长意味着用户打开 App/网页后「白屏」时间太长，可能流失 |
| LCP | Largest Contentful Paint | 最大内容绘制，页面主要内容（通常是最大的图片或文字块）加载完成的时间 | < 2.5 秒 | LCP 代表用户「感觉页面加载完了」的时间，是核心体验指标 |
| TTI | Time to Interactive | 可交互时间，页面完全可以响应用户操作（点击、输入等）的时间 | < 3.8 秒 | 有些页面看起来加载完了，但点击按钮没反应，就是 TTI 还没到。这会让用户感到卡顿和沮丧 |
页面加载时间线：
0s 1s 2s 3s 4s
│─────────│─────────│─────────│─────────│
│ │
├── 白屏 ──► FCP (1.2s) 首次看到内容 │
│ │
├──────────── LCP (2.1s) 主要内容加载完 │
│ │
├────────────────── TTI (3.2s) 可以交互 │
│ │
目标: FCP < 1.8s, LCP < 2.5s, TTI < 3.8s稳定性指标
| 指标 | 含义 | 健康标准 | PM 为什么关注 |
|---|---|---|---|
| 崩溃率 (Crash Rate) | App 发生崩溃（闪退）的比例，通常按会话（Session）计算 | < 0.1%（即千分之一） | 崩溃是最严重的体验问题。如果崩溃率超过 1%，应该停止新功能开发，优先修复稳定性问题 |
| ANR 率 (Android) | Application Not Responding，Android 系统中 App 无响应（卡死）的比例 | < 0.5% | 卡死和崩溃一样严重，用户可能直接卸载 |
| 响应时间 (Response Time) | 用户操作到系统响应之间的时间，通常指后端 API 的响应时间 | P95 < 500ms | API 响应慢会导致页面加载慢、操作卡顿。P95 意味着 95% 的请求在此时间内完成 |
指标与用户体验的关系
| 用户感受 | 对应的技术指标 | PM 应该做什么 |
|---|---|---|
| 「打开好慢，白屏好久」 | FCP、LCP 过高 | 和工程师讨论优化方案（图片压缩、预加载、CDN） |
| 「点了没反应」 | TTI 过高、响应时间过长 | 检查是否有性能瓶颈，考虑加载状态提示 |
| 「又闪退了！」 | 崩溃率过高 | 推动紧急修复，暂停新功能开发 |
| 「卡死了动不了」 | ANR 率过高 | 排查耗时操作，优化主线程任务 |
| 「图片加载不出来」 | CDN 问题或网络问题 | 确认图片规格和 CDN 配置 |
PM 不需要深入了解但可以知道的概念
以下是一些你可能在技术讨论中偶尔听到，不需要深入理解但知道是什么就好的概念：
| 术语 | 一句话解释 | 什么时候可能听到 |
|---|---|---|
| RESTful API | 一种常见的 API 设计规范，用 URL 表示资源、用 HTTP 方法表示操作 | 技术方案评审时 |
| WebSocket | 一种实时通信技术，服务器可以主动推送消息给客户端 | 做即时通讯、实时数据功能时 |
| OAuth | 一种授权协议，允许第三方应用访问用户数据（如「用微信登录」） | 接入第三方登录时 |
| HTTPS | 加密的网络传输协议，保证数据传输安全 | 讨论安全合规时 |
| DNS | 域名解析系统，把网址翻译成服务器地址 | 域名配置、网络排障时 |
| 消息队列 | 异步处理任务的中间件（如订单创建后异步发短信） | 讨论异步流程时 |
| 数据仓库/数据湖 | 专门用于数据分析的存储系统 | 讨论数据分析架构时 |
PM 与工程师沟通的实用技巧
| 场景 | 不好的沟通方式 | 好的沟通方式 |
|---|---|---|
| 讨论排期 | 「这个功能很简单，为什么要两周？」 | 「能帮我拆解一下技术方案吗？哪些步骤比较耗时？」 |
| 提需求 | 「我不管怎么实现，反正要做出来」 | 「我的目标是 XX，技术上有没有更高效的实现方式？」 |
| 出了 Bug | 「怎么又出 Bug 了！」 | 「这个问题影响了多少用户？复现步骤是什么？需要紧急修复吗？」 |
| 讨论方案 | 「我完全听不懂你在说什么」 | 「能用一个类比解释一下吗？这个方案的优缺点分别是什么？」 |
| 砍需求 | 「别和我讲技术困难，老板要求必须做」 | 「如果全量做确实排期紧张，我们能不能先做一个简化版本？」 |
常见面试问题
请解释什么是 API，PM 在工作中哪些场景会用到？
- 参考上文解释。常见场景：接入第三方服务（支付、地图）、和其他团队合作对接数据、理解前后端协作方式。
前后端分离对产品开发有什么影响？
- 优点：前后端可以并行开发，提高效率；缺点：需要联调时间，前后端需要先约定好 API 格式。
什么是埋点？PM 如何设计埋点方案？
- 明确分析目标 → 确定关键事件和页面 → 定义事件名称和参数 → 编写埋点需求文档 → 开发实施 → 数据验证。
如果线上出现大面积崩溃，你作为 PM 应该怎么做？
- 确认影响范围 → 通知相关人员 → 配合工程师排查（提供复现路径）→ 决策是否回滚 → 事后复盘。
LCP 是 4 秒，你觉得有没有问题？应该怎么推动优化？
- 有问题（标准是 < 2.5 秒）。先定位原因（图片太大？API 太慢？JS 阻塞？），然后和工程师制定优化方案，设定目标（如两周内降到 2.5 秒以下），跟踪数据变化。
小结
| 你想知道... | 看这个术语 |
|---|---|
| 产品界面和后台怎么分工的 | 前后端分离 |
| 系统之间怎么通信的 | API |
| 怎么快速接入第三方功能 | SDK |
| 用户数据存在哪里 | 数据库 (SQL/NoSQL) |
| 怎么收集用户行为数据 | 埋点 / 数据上报 |
| 怎么让页面加载更快 | 缓存、CDN |
| 大系统怎么拆分管理 | 微服务 |
| 代码怎么管理和发布 | Git、CI/CD |
| 新版本怎么安全上线 | 灰度部署、蓝绿部署 |
| 大流量怎么扛住 | 负载均衡、容器化 |
| 页面性能好不好 | FCP、LCP、TTI |
| App 稳定不稳定 | 崩溃率、ANR 率 |
| 后台响应快不快 | 响应时间 (P95) |
下一节： 04-design-terms.md -- 学习设计术语，和设计师高效协作。