产品生活流水账

这是一段非常难忘的经历，在产品诞生的过程中，我们在一起

一、需求

1. 需求从哪里来？BD、运营、产品、BOSS，最终都是解决用户相关的问题
2. 需求评估
   这是一个综合性的评估过程，要确定：

• 做与不做
• 优先级 P0（高） ~ Pn（低）（业务需求、运营需求、管理需求）
• 影响因素：可行性 / BOSS最关心哪个

3. 解决方案，逻辑可行性论证

• 确定需求在实现层面的解决方案。

没有解决方案的需求是没有执行效率的。

• 与相关平台的同学的沟通。

国内大的互联网公司，通常是首先和对接相关平台的产品，产品基本能够说清楚解决方案层面的绝大多数问题。如果有说不清楚的，也由产品经理牵头找到相应的技术同学说清楚。

• 解决方案至少有两个层面。
  1） 逻辑是否可以走通。
  2）与其他平台的交互是否可以满足业务需求？

需求，是一个不断回归本源过程。“要解决的是什么问题”

产品沟通的原则：

• 先聊清楚需求，实现方案是服务于需求的
• 关注用户体验，技术实现是服务于用户体验的

沟通的工具：

1. 交互设计稿：最直观的说明了用户与产品交互体验、元素以及背后的需求。
2. 业务逻辑：泳道图 或 时序图，清晰的说明业务背后的逻辑、平台之间的交互需求。

需求的明晰是由粗到细，由浅入深的过程

示例1：交互设计稿

交互设计图

交互设计稿建议包括：页面布局、基本元素、页面交互逻辑、一些必要的规则说明。

示例2：业务逻辑泳道图

泳道图

泳道图可以说明各模块的内部逻辑以及模块之间的交互。能够清晰的说明全业务流程。一般泳道图只说明主业务逻辑，而不说明异常及边界逻辑。

示例3：时序图

时序图

时序图是可以在MarkDown文档中用“代码”的方式写出来的。目前在国内支持中文、Markdown标记、流程图、甘特图、时序图……比较好的是有道云笔记。
在有道云笔记中，“绘制”出上面的图，只需要下面的代码段，可读性很好。
前面的时序图就是用下面的代码生成的。

sequenceDiagram
 停车平台->>ISV:authcode、car_ID
 ISV->>支付宝授权网关:用authcode请求Token、UID
 支付宝授权网关-->>ISV:Token
 ISV->>停车平台:Token、car_ID
 停车平台-->>ISV:车牌号

二、产品设计 = 说清楚需求 = 说清楚产品怎么做

1. 业务逻辑，业务逻辑，业务逻辑！
   业务逻辑必须是“通”的，可闭环的
2. UI设计：交互逻辑、用户体验

产品设计输出的是PRD（Product Requirement Document 产品需求说明书），用来说明产品的各方面需求。

PRD（Product Requirement Document） = 业务背景 //在什么场景下？解决了什么问题？ 覆盖的用户？ 目标？
+ 业务需求框架 //对解决方案的全景描述
+ 业务逻辑 // 内部逻辑，与相关平台交互的逻辑
+ 异常处理逻辑 // 异常情况发生时的处理逻辑
+ 业务规则 // 处理规则、触发条件、边界
+ 交互设计 // 交互设计稿，页面之间的跳转逻辑【页面上的所有（至少是关键）行动点】
+ 页面元素、规则  //页面元素的格式、规则（数据展示、脱敏）、条件、下一步动作
+ 数据埋点 // 最容易忽视、轻视的部分，但运营数据的获取，产品的数据反馈都靠这个了
+ 性能需求 // 新产品不关键，后期优化的时候很关键，在初期有个大致的性能优化，会影响到架构设计
+ 安全性需求 ……………………

三、评审

架构设计师、开发工程师、测试工程师、项目经理、运营同学、BOSS对需求的一次检阅。

目的：

1. 请所有人理解需求【非常重要】；
2. 审核PRD描述的需求是否满足了本期的目标；
3. 技术可行性的初步评估；

事先的“沟通”是PRD通过的保障。

视觉设计：在基本通过评审后，根据交互设计稿，出视觉稿。

四、技术同学开工了

如果开发不看PRD的原因是“PRD无法指导开发”，自己反省去吧。

1. 架构设计：用例、模型、整体架构、技术架构、交互流程、接口
2. 系分设计：应用系统依赖、数据模型、业务边界、接口逻辑、接口定义
3. 测试分析：将业务流程拆解为测试点用测试用例说明、测试用例来覆盖产品需要验证的点。

以上三个设计都要有文档的输出，在文档的基础上组织评审，目标：

1. 设计是否满足需求？
2. 性能、扩展性是否满足需求？

评审完成后，给出项目计划。
自此开始，产品经理转换角色，成为项目经理（PM）

开发进度计划

五、Coding & 需求合理吗？？

开发过程中，需求会被进一步的细化和被质疑。如何应对？

• 产品经理不会永远正确，也不是要证明谁正确。
• 重要的是：不断回归到需求的本源，来指导细化，分析不同意见对需求的影响。
• 积极在开发、测试与产品之间建立起“有效连接”

项目管理：在有限时间、有限资源的情况下，达成目标。

紧迫性、问题快速落地、立会……项目管理的内容太多，有兴趣的同学可以认真研习

控制需求
需求无止境，开发开始以后还有需求，要不要做？怎么判断？ 这是个非常复杂的问题，企业不同，风格不同。有时不是关于产品本身的问题。

• 条件是否成熟？
• 对需求本源目标是否有促进，程度如何？
• 来自BOSS，对项目有何影响？

技术上搞不定
技术方案不可行？【高度重视】 or 技术能力不行？【谁能搞定】

• 产品经理不懂技术，产品经理不懂技术，产品经理不懂技术

产品经理在开发同学面前，不要也没有必要号称对技术如何如何了解。产品经理即使懂一些代码，也没有必要“指导”开发同学。重要的是把握住需求，围绕需求讨论技术实现。

• 产品经理要了解技术，产品经理要了解技术，产品经理要了解技术

对产品经理而言，了解技术 的可行性、局限性、可扩展性。是非常必要的，就像建筑设计师不会砌砖，但应该了解建筑材料的用途和局限性。

六、测试、验收

单元测试 --> 整合测试 --> 测试同学测试 --> 产品验证

产品验证的关键点

1. 产品的主逻辑是否满足需求；
2. 异常处理逻辑是否正常；
3. 边界情况下，是否ok？
4. 页面元素、跳转关系是否ok？尤其是“返回”页面，容易被忽视。
5. 交互体验ok？ //体验：速度、傻瓜程度、反人类、
6. 请交互、视觉验证。
7. 合作方业务流程

七、上线前夜

各种数据的配置，产品经理要确认的是需要上哪些业务，这些业务要配置的数据有哪些，涉及到图、文字的要确定下来文案。

发布后的验证

1. 全业务流程，尤其是与其他平台的交互部分；
2. 数据的完整性验证。
3. 重点关注非生产环境（测试、预发）验证不了或验证不全面的问题。

八、运营、推广、数据

1. 启动期
2. 活动推广 ->营销需求 //拉动
3. 数据是指路的明灯 --> 优化、用户体验、用户评价、活动评估……

运营中，各种需求还会不断的产生，重新回到“需求”，在把以上的过程重来以便。不断的重复，每次都有明确的、可行的需求，这就是快速迭代

产品成功的根源： 真实的、可行的、可持续发展的需求 //说起来容易，做起来难

附录： 对有志于产品经理同学的建议

1. 用产品经理的思考方式做日常的工作。

用户的真实需求是什么？ 产品或服务的价值是什么？ 业务逻辑是怎样的？ 有优化的可能吗？ 如何提高效率？……

2. 将思想形成文字，表达出来。

有文字的人类族群获得了比其他族群快得多的发展。这说明文字促进思考，在深度、完整性、逻辑性上帮我们走的更远。

3. 做一个解决真实需求的产品，无论它是什么。

真实的需求可以首先来自自己。 做完全过程才会知道一个产品的诞生是多不易。同时才会明白如何做出来一个产品。

写在最后 多读书，尤其是非虚构类书籍。