昨天听了曹大的产品经理入门课程，今天做个总结。
一、产品经理的职责
不同企业的工作范畴不同，存在不同的定义。其共性可以概括为：产品需求设计、与研发的沟通协调。其他外延，包括产品需求设计之前的市场调研分析、产品上线之后的运营决策支持及反馈。
本文仅讨论 与研发的沟通协调
二、产品经理在与研发沟通沟通中常见问题
- 需求提出之后，研发做出来了，但是与需求有很大出入
- 提出一个简单需求，研发表示需要很长时间，甚至做不到
- 研发做出了合适的需求，但故障频发
三、解决方案
1. 一致性原则
确保老板与自己、你与研发，对产品的理解、定义、用户目标、运营目标有相对一致的认识。了解产品背后真正的目标、诉求。
不要假装研发知道你懂的背景常识，如产品的意义、价值，产品的核心目标用户群，产品的对标市场，产品的运营特点、涵盖范围等。如果研发对这些常识认识不足，或者产生误解，很容易产生的问题：
- 如果产品文档不规范，研发自由发挥的空间很大，可能做出来的东西跟你想要的完全不是一回事
- 如果文档规范，研发做出的功能可以按需求完全实现，但存在一些认知上的问题可能导致的结果：
- 研发基于自己对产品目标、产品运营做结构上、性能上的准备，可能做大量的无用功，从而导致研发效率低
- 仅仅满足功能需求，该做的准备没做，导致性能考虑不足，运营支持度考虑不足
因此，在 功能诉求 之前，尽可能让技术理解产品的真实目的、目标用户群、业务诉求、运营途径、推广途径，对产品的涵盖范围有清晰的认识和了解；功能诉求要有整体大纲，让系统整体构成一目了然；指定业务边界，减少无用功；适当允许和鼓励研发参与产品讨论和功能规划。
此外，在沟通技巧上，要与研发在产品目标上进行确认，并且定期回述目标（让对方按他的理解，重述项目背景和目标，减少双方理解上的歧义、偏差），发现问题。
2. 产品文档规范
把东西说清楚，让研发理解透。
- 列出总纲，总体目标定义。描述 产品需求定义 ，用户目标定义、产品目标定义、相关边界定义，描述 产品构成 ，功能视图清单、基本操作流程、角色构成、数据构成。
- 根据角色、终端、功能项的视图描述。
- 页面布局
- 元素（图标、图案、文案，信息和数据、交互操作项）
- 逻辑（数据逻辑、交互操作逻辑、异常和容错性说明）
研发拿到产品文档，一方面通过总纲，对系统总体流程、产品目标、角色构成、运营策略以及各个视图间的关联关系有一个完整性的认识；另一方面通过视图，对各个模块、功能点有具体、细致的认识。
3. 测试与反馈
测试与反馈是非常重要的产品与研发沟通的范畴。参与测试，就测试给出研发合理的反馈，这样可以更好的进一步协调确保产品的质量和进度。
- 单元测试：每个模块、每个独立的功能特性理论上都可以测试。明确测试目标、测试角色、测试流程、测试用例。（产品必须和研发协调进行单元测试，单元测试的目的是有效保障研发效率，以及尽早发现和确认研发中的问题，如果为了测试，而打乱了正常的开发节奏，延误了正常的开发周期，是得不偿失的。）
- 整体测试：又分发测试环境测试和线上环境测试。
- 测试用例
- 正常流程测试：测试完成度、可用性
- 反流程测试：用户按预期流程操作产品导致的问题处理
- 限制性测试：超长字符、频繁出错的密码等，对错误输入的提示、容错性，是否符合预期、是否符合产品目标
- 数据规模、并发压力测试
- 安全性测试
对测试出的问题进行分类（可用性问题、体验问题、运营支持问题、安全问题等），列好严重程度、优先级。
4. 需求边界
技术有研发成本，同一个功能，同一个数据逻辑，面对的不同的用户诉求边界，实现成本、效率差异很大。明确用户诉求边界，可以在很大程度上减少无用功，提升研发效率。（取巧）
- 数据精确度边界
- 数据覆盖率边界
- 功能性边界
在目标一致性原则之下，考虑对需求边界的 容忍度 范围。
研发三境界
- 简陋。对性能、风险、安全隐患、系统扩展性一无所知，功能完成，但上线后千仓百孔，问题层出不穷。
- 繁冗。明白了什么是性能瓶颈、什么是业务风险、安全隐患、什么是架构扩展，然后在架构上、代码上做各种补丁、防范，其中大部分是想太多、无用功，导致大量的时间、精力消耗。
- 简单，返璞归真。已经清楚各种风险，可以用最低的成本最低的代价尽可能多的对风险进行覆盖、对未来可能的扩展进行保留。举重若轻，大巧若拙，代码越写短，架构越做越轻。
5. 产品人员建议了解的技术常识
- 性能
- 数据规模
- 每秒相应频次（操作即完成，非持续性请求）
- 最大并发诉求（保持实时在线的，如 1000 个请求，平均一个请求 10 秒完成释放链接，并发为 10,000）
性能瓶颈可能出现在客户端、网络端（传输/带宽）、服务器（脚本/缓存/数据库）。核心业务系统单服务器下，在百万甚至千万的数据记录下查询，每秒能达到 1000 次的响应能力，算是一个比较合格的技术指标。
- 安全
- SQL 注入
- XSS（跨站脚本）
- 上传漏掉
- 源代码泄露
- 防撞库设计
- cc 攻击
- 架构
系统考虑产品的整体实现，好的架构首先可以满足更多的业务诉求（如 运营诉求、新增的产品需求）；其次能满足业务激增的情况下快速扩充响应能力，同时保证成本可控；最后是团队开发中更好的质量和安全控制。架构主要考虑的问题：- 扩展性问题：业务扩展、性能扩展
- 工作协同问题
- 安全问题：在架构层屏蔽一些安全隐患
核心原则是 低耦合 ，每个模块只关心输入、输出，内部逻辑与其他模块无关。（低耦合，高复用，是所谓优秀架构的标准，但不要过高拔高这个标准，举个例子，php可以理解为就是从 c 语言基础上，做出的一个低耦合，高复用架构。你把低耦合，高复用做到极致，能做的过一门编程语言么。）低耦合、高复用是所谓优秀架构的标准，但都需要考虑一个 度 的问题。
分层模型：请求、分发（又有一些策略，如先查缓存）、响应
- 提升响应处理能力。有些请求可以合并处理，有些请求可以通过缓存处理，此外请求可以分布式处理
- 提升业务扩展能力。比如做一些通用的标准接口，业务层面自由组合诉求
- 提升安全性。中间层可以对业务数据做过滤，防止改写后端程序逻辑。
但分层结构同理，适度就好，不能搞得过于复杂，过于繁冗。另外，切忌为了分层而分层，为了结构而结构，一切以目标为导向。
四、总结
最核心的还是，多沟通，多交流，多换位思考，不要认为你知道的别人都知道，也尽量理解研发的顾虑和思考的过程。沟通一定要主动！
