这是一段非常难忘的经历，在产品诞生的过程中，我们在一起
一、需求
- 需求从哪里来？BD、运营、产品、BOSS，最终都是解决用户相关的问题
- 需求评估
这是一个综合性的评估过程，要确定：
- 做与不做
- 优先级 P0（高） ~ Pn（低）（业务需求、运营需求、管理需求）
- 影响因素：可行性 / BOSS最关心哪个
- 解决方案，逻辑可行性论证
- 确定需求在实现层面的解决方案。
没有解决方案的需求是没有执行效率的。
- 与相关平台的同学的沟通。
国内大的互联网公司，通常是首先和对接相关平台的产品，产品基本能够说清楚解决方案层面的绝大多数问题。如果有说不清楚的，也由产品经理牵头找到相应的技术同学说清楚。
- 解决方案至少有两个层面。
1） 逻辑是否可以走通。
2）与其他平台的交互是否可以满足业务需求？
需求，是一个不断回归本源过程。“要解决的是什么问题”
产品沟通的原则：
- 先聊清楚需求，实现方案是服务于需求的
- 关注用户体验，技术实现是服务于用户体验的
沟通的工具：
- 交互设计稿：最直观的说明了用户与产品交互体验、元素以及背后的需求。
- 业务逻辑：泳道图 或 时序图，清晰的说明业务背后的逻辑、平台之间的交互需求。
需求的明晰是由粗到细，由浅入深的过程
示例1：交互设计稿
交互设计稿建议包括：页面布局、基本元素、页面交互逻辑、一些必要的规则说明。
示例2：业务逻辑泳道图
泳道图可以说明各模块的内部逻辑以及模块之间的交互。能够清晰的说明全业务流程。一般泳道图只说明主业务逻辑，而不说明异常及边界逻辑。
示例3：时序图
时序图是可以在MarkDown文档中用“代码”的方式写出来的。目前在国内支持中文、Markdown标记、流程图、甘特图、时序图……比较好的是有道云笔记。
在有道云笔记中，“绘制”出上面的图，只需要下面的代码段，可读性很好。
前面的时序图就是用下面的代码生成的。
sequenceDiagram
停车平台->>ISV:authcode、car_ID
ISV->>支付宝授权网关:用authcode请求Token、UID
支付宝授权网关-->>ISV:Token
ISV->>停车平台:Token、car_ID
停车平台-->>ISV:车牌号
二、产品设计 = 说清楚需求 = 说清楚产品怎么做
- 业务逻辑，业务逻辑，业务逻辑！
业务逻辑必须是“通”的，可闭环的 - UI设计：交互逻辑、用户体验
产品设计输出的是PRD（Product Requirement Document 产品需求说明书），用来说明产品的各方面需求。
PRD（Product Requirement Document） = 业务背景 //在什么场景下？解决了什么问题？ 覆盖的用户？ 目标？
+ 业务需求框架 //对解决方案的全景描述
+ 业务逻辑 // 内部逻辑，与相关平台交互的逻辑
+ 异常处理逻辑 // 异常情况发生时的处理逻辑
+ 业务规则 // 处理规则、触发条件、边界
+ 交互设计 // 交互设计稿，页面之间的跳转逻辑【页面上的所有（至少是关键）行动点】
+ 页面元素、规则 //页面元素的格式、规则（数据展示、脱敏）、条件、下一步动作
+ 数据埋点 // 最容易忽视、轻视的部分，但运营数据的获取，产品的数据反馈都靠这个了
+ 性能需求 // 新产品不关键，后期优化的时候很关键，在初期有个大致的性能优化，会影响到架构设计
+ 安全性需求 ……………………
三、评审
架构设计师、开发工程师、测试工程师、项目经理、运营同学、BOSS对需求的一次检阅。
目的：
- 请所有人理解需求【非常重要】；
- 审核PRD描述的需求是否满足了本期的目标；
- 技术可行性的初步评估；
事先的“沟通”是PRD通过的保障。
视觉设计：在基本通过评审后，根据交互设计稿，出视觉稿。
四、技术同学开工了
如果开发不看PRD的原因是“PRD无法指导开发”，自己反省去吧。
- 架构设计：用例、模型、整体架构、技术架构、交互流程、接口
- 系分设计：应用系统依赖、数据模型、业务边界、接口逻辑、接口定义
- 测试分析：将业务流程拆解为测试点用测试用例说明、测试用例来覆盖产品需要验证的点。
以上三个设计都要有文档的输出，在文档的基础上组织评审，目标：
- 设计是否满足需求？
- 性能、扩展性是否满足需求？
评审完成后，给出项目计划。
自此开始，产品经理转换角色，成为项目经理（PM）
五、Coding & 需求合理吗？？
开发过程中，需求会被进一步的细化和被质疑。如何应对？
- 产品经理不会永远正确，也不是要证明谁正确。
- 重要的是：不断回归到需求的本源，来指导细化，分析不同意见对需求的影响。
- 积极在开发、测试与产品之间建立起“有效连接”
项目管理：在有限时间、有限资源的情况下，达成目标。
紧迫性、问题快速落地、立会……项目管理的内容太多，有兴趣的同学可以认真研习
控制需求
需求无止境，开发开始以后还有需求，要不要做？怎么判断？ 这是个非常复杂的问题，企业不同，风格不同。有时不是关于产品本身的问题。
- 条件是否成熟？
- 对需求本源目标是否有促进，程度如何？
- 来自BOSS，对项目有何影响？
技术上搞不定
技术方案不可行？【高度重视】 or 技术能力不行？【谁能搞定】
- 产品经理不懂技术，产品经理不懂技术，产品经理不懂技术
产品经理在开发同学面前，不要也没有必要号称对技术如何如何了解。产品经理即使懂一些代码，也没有必要“指导”开发同学。重要的是把握住需求，围绕需求讨论技术实现。
- 产品经理要了解技术，产品经理要了解技术，产品经理要了解技术
对产品经理而言，了解技术 的可行性、局限性、可扩展性。是非常必要的，就像建筑设计师不会砌砖，但应该了解建筑材料的用途和局限性。
六、测试、验收
单元测试 --> 整合测试 --> 测试同学测试 --> 产品验证
产品验证的关键点
- 产品的主逻辑是否满足需求；
- 异常处理逻辑是否正常；
- 边界情况下，是否ok？
- 页面元素、跳转关系是否ok？尤其是“返回”页面，容易被忽视。
- 交互体验ok？ //体验：速度、傻瓜程度、反人类、
- 请交互、视觉验证。
- 合作方业务流程
七、上线前夜
各种数据的配置，产品经理要确认的是需要上哪些业务，这些业务要配置的数据有哪些，涉及到图、文字的要确定下来文案。
发布后的验证
- 全业务流程，尤其是与其他平台的交互部分；
- 数据的完整性验证。
- 重点关注非生产环境（测试、预发）验证不了或验证不全面的问题。
八、运营、推广、数据
- 启动期
- 活动推广 ->营销需求 //拉动
- 数据是指路的明灯 --> 优化、用户体验、用户评价、活动评估……
运营中，各种需求还会不断的产生，重新回到“需求”，在把以上的过程重来以便。不断的重复，每次都有明确的、可行的需求，这就是快速迭代
产品成功的根源： 真实的、可行的、可持续发展的需求 //说起来容易，做起来难
附录： 对有志于产品经理同学的建议
- 用产品经理的思考方式做日常的工作。
用户的真实需求是什么？ 产品或服务的价值是什么？ 业务逻辑是怎样的？ 有优化的可能吗？ 如何提高效率？……
- 将思想形成文字，表达出来。
有文字的人类族群获得了比其他族群快得多的发展。这说明文字促进思考，在深度、完整性、逻辑性上帮我们走的更远。
- 做一个解决真实需求的产品，无论它是什么。
真实的需求可以首先来自自己。 做完全过程才会知道一个产品的诞生是多不易。同时才会明白如何做出来一个产品。
写在最后 多读书，尤其是非虚构类书籍。
