产品经理入门

昨天听了曹大的产品经理入门课程，今天做个总结。

一、产品经理的职责

不同企业的工作范畴不同，存在不同的定义。其共性可以概括为：产品需求设计、与研发的沟通协调。其他外延，包括产品需求设计之前的市场调研分析、产品上线之后的运营决策支持及反馈。
本文仅讨论 与研发的沟通协调

产品经理的职责

二、产品经理在与研发沟通沟通中常见问题

• 需求提出之后，研发做出来了，但是与需求有很大出入
• 提出一个简单需求，研发表示需要很长时间，甚至做不到
• 研发做出了合适的需求，但故障频发

三、解决方案

产品经理与研发的沟通协调

1. 一致性原则

确保老板与自己、你与研发，对产品的理解、定义、用户目标、运营目标有相对一致的认识。了解产品背后真正的目标、诉求。
不要假装研发知道你懂的背景常识，如产品的意义、价值，产品的核心目标用户群，产品的对标市场，产品的运营特点、涵盖范围等。如果研发对这些常识认识不足，或者产生误解，很容易产生的问题：

• 如果产品文档不规范，研发自由发挥的空间很大，可能做出来的东西跟你想要的完全不是一回事
• 如果文档规范，研发做出的功能可以按需求完全实现，但存在一些认知上的问题可能导致的结果：
  • 研发基于自己对产品目标、产品运营做结构上、性能上的准备，可能做大量的无用功，从而导致研发效率低
  • 仅仅满足功能需求，该做的准备没做，导致性能考虑不足，运营支持度考虑不足

因此，在 功能诉求 之前，尽可能让技术理解产品的真实目的、目标用户群、业务诉求、运营途径、推广途径，对产品的涵盖范围有清晰的认识和了解；功能诉求要有整体大纲，让系统整体构成一目了然；指定业务边界，减少无用功；适当允许和鼓励研发参与产品讨论和功能规划。
此外，在沟通技巧上，要与研发在产品目标上进行确认，并且定期回述目标（让对方按他的理解，重述项目背景和目标，减少双方理解上的歧义、偏差），发现问题。

2. 产品文档规范

把东西说清楚，让研发理解透。

• 列出总纲，总体目标定义。描述 产品需求定义 ，用户目标定义、产品目标定义、相关边界定义，描述 产品构成 ，功能视图清单、基本操作流程、角色构成、数据构成。
• 根据角色、终端、功能项的视图描述。
  • 页面布局
  • 元素（图标、图案、文案，信息和数据、交互操作项）
  • 逻辑（数据逻辑、交互操作逻辑、异常和容错性说明）

研发拿到产品文档，一方面通过总纲，对系统总体流程、产品目标、角色构成、运营策略以及各个视图间的关联关系有一个完整性的认识；另一方面通过视图，对各个模块、功能点有具体、细致的认识。

3. 测试与反馈

测试与反馈是非常重要的产品与研发沟通的范畴。参与测试，就测试给出研发合理的反馈，这样可以更好的进一步协调确保产品的质量和进度。

• 单元测试：每个模块、每个独立的功能特性理论上都可以测试。明确测试目标、测试角色、测试流程、测试用例。（产品必须和研发协调进行单元测试，单元测试的目的是有效保障研发效率，以及尽早发现和确认研发中的问题，如果为了测试，而打乱了正常的开发节奏，延误了正常的开发周期，是得不偿失的。）
• 整体测试：又分发测试环境测试和线上环境测试。
• 测试用例
  • 正常流程测试：测试完成度、可用性
  • 反流程测试：用户按预期流程操作产品导致的问题处理
  • 限制性测试：超长字符、频繁出错的密码等，对错误输入的提示、容错性，是否符合预期、是否符合产品目标
  • 数据规模、并发压力测试
  • 安全性测试

对测试出的问题进行分类（可用性问题、体验问题、运营支持问题、安全问题等），列好严重程度、优先级。

4. 需求边界

技术有研发成本，同一个功能，同一个数据逻辑，面对的不同的用户诉求边界，实现成本、效率差异很大。明确用户诉求边界，可以在很大程度上减少无用功，提升研发效率。（取巧）

• 数据精确度边界
• 数据覆盖率边界
• 功能性边界

在目标一致性原则之下，考虑对需求边界的 容忍度 范围。

研发三境界

• 简陋。对性能、风险、安全隐患、系统扩展性一无所知，功能完成，但上线后千仓百孔，问题层出不穷。
• 繁冗。明白了什么是性能瓶颈、什么是业务风险、安全隐患、什么是架构扩展，然后在架构上、代码上做各种补丁、防范，其中大部分是想太多、无用功，导致大量的时间、精力消耗。
• 简单，返璞归真。已经清楚各种风险，可以用最低的成本最低的代价尽可能多的对风险进行覆盖、对未来可能的扩展进行保留。举重若轻，大巧若拙，代码越写短，架构越做越轻。

5. 产品人员建议了解的技术常识

• 性能
  • 数据规模
  • 每秒相应频次（操作即完成，非持续性请求）
  • 最大并发诉求（保持实时在线的，如 1000 个请求，平均一个请求 10 秒完成释放链接，并发为 10,000）

性能瓶颈可能出现在客户端、网络端（传输/带宽）、服务器（脚本/缓存/数据库）。核心业务系统单服务器下，在百万甚至千万的数据记录下查询，每秒能达到 1000 次的响应能力，算是一个比较合格的技术指标。

• 安全
  • SQL 注入
  • XSS（跨站脚本）
  • 上传漏掉
  • 源代码泄露
  • 防撞库设计
  • cc 攻击
• 架构
  系统考虑产品的整体实现，好的架构首先可以满足更多的业务诉求（如 运营诉求、新增的产品需求）；其次能满足业务激增的情况下快速扩充响应能力，同时保证成本可控；最后是团队开发中更好的质量和安全控制。架构主要考虑的问题：
  • 扩展性问题：业务扩展、性能扩展
  • 工作协同问题
  • 安全问题：在架构层屏蔽一些安全隐患

核心原则是 低耦合 ，每个模块只关心输入、输出，内部逻辑与其他模块无关。（低耦合，高复用，是所谓优秀架构的标准，但不要过高拔高这个标准，举个例子，php可以理解为就是从 c 语言基础上，做出的一个低耦合，高复用架构。你把低耦合，高复用做到极致，能做的过一门编程语言么。）低耦合、高复用是所谓优秀架构的标准，但都需要考虑一个 度 的问题。

分层模型：请求、分发（又有一些策略，如先查缓存）、响应

• 提升响应处理能力。有些请求可以合并处理，有些请求可以通过缓存处理，此外请求可以分布式处理
• 提升业务扩展能力。比如做一些通用的标准接口，业务层面自由组合诉求
• 提升安全性。中间层可以对业务数据做过滤，防止改写后端程序逻辑。

但分层结构同理，适度就好，不能搞得过于复杂，过于繁冗。另外，切忌为了分层而分层，为了结构而结构，一切以目标为导向。

四、总结

最核心的还是，多沟通，多交流，多换位思考，不要认为你知道的别人都知道，也尽量理解研发的顾虑和思考的过程。沟通一定要主动！