工作流程
一、 贯穿始终的任务（非线性的）
1.1 需求收集
（1）描述：需求基本可分为两种：主动采集和被动采集。主动采集是指深入业务方工作环境，去发现流程的不合理、日常遇到的问题，将问题剖析后转为需求；被动采集则是指业务方在工作中遇到的问题，并且迫切希望解决的问题。需求收集过程中沟通的问题：
l 业务方过于强势，对于问题直接给了不太专业的解决方案，照做就完蛋了，也完全体现不出产品的价值，要学会提问，思考为什么他们希望以这种方式解决问题。
l 业务方回答不到点上，长篇大论，完全跑偏。这时候直接打断并非好方法，我习惯是耐心听取，提取有用的信息，并在恰当的时机与他们再次确认，适当得把话题掰回正轨。
l 业务方不够专业，不能清晰表达流程，沟通起来效率不高。可以索取业务原始数据和协助文档，从结果倒推流程，再找业务方确认。
（2）工具：
l 五why分析法：用于痛点挖掘（涉及多角色时需要分别梳理不同角色的痛点）；
l 用户故事：抽象业务，罗列痛点，一句话描述需求，一群什么样的用户在什么场景下想解决什么问题，解决过程碰到什么问题，最后用户怎么解决的。
（3）产出物：
l 需求背景：业务介绍，什么人在什么过程中遇到了什么问题，希望怎样。
l 涉及角色：参与具体业务的所有协作人
l 对接人：协助产品了解当前业务逻辑的人
1.2 需求整理排期
（1）描述：将需求入库后，需要定期整理，将已经不满足当前业务的需求出库，能合并的合为一个需求，有必要拆解的拆为多个需求。按照优先级得分、紧急状态去规划近3个迭代的需求（并非定死，迭代周期期间有可能穿插一些紧急的需求，按实际情况操作）
（2）工具：
l 需求打分表：按照需求类别、需求级别、优先级别等不同纬度打分，给排期提供数据上的支撑。
l 四象限法：同样用于评估哪些需求先满足，哪些可以先缓一缓。
（3）产出物：
l 近期三次迭代的需求规划
1.3 解决线上问题
（1）描述：产品经理的本质就是用合理的方式解决一个又一个难题。随着新版本迭代或者已有功能的使用中，业务人员常常会遇到系统出问题，有可能是系统bug、也有可能是功能流程问题、甚至仅仅是使用问题（无法理解怎么操作）等等。面对不同的问题，需要灵活处理，自己能解决的最好，不能解决的要及时调配资源辅助，特别是一些紧急的问题，耽搁少许可能就会导致严重的损失。
（2）工具：
l 强大的内心：遇事不慌，冷静得直面问题
l 积极主动的态度：客户、系统问题，产品都是首当其冲，你不冲在前方，也别指望在他人引领下走向光明。
l 责任心：事不关己，高高挂起的态度永远成为不了优秀的产品
l 良好的沟通力：高效、专业，当然也要适当注意言辞
（3）产出物：
l 修复好的系统bug
l 问题转需求
l 客观正视自己设计的需求方案（用户不会用，还得多想想自己的原因）
1.4 跨职能协作
（1）描述：产品经理需不需要懂业务？答曰：产品经理必须非常熟悉业务（尤其是B端产品）。要达到业务和软件系统的最佳融合，产品经理必须十分熟悉业务，在产品架构、功能迭代方向上，确保业务能够有效落地。解决方案上，并非要把系统设计的多么完美，要尽可能结合现实，考虑实际落地场景，承担部分项目经理的责任。
（2）工具：
l 业务数据分析
l 业务方向规划
（3）产出物：
l 跟随业务优化的系统优化
l 数据分析结论和应对方法
二、迭代任务（线性）
2.1 需求设计
（1）描述：需求设计是产品经理硬实力的体现，需求文档力求逻辑清晰、易读性高，以确保开发团队内协助高效。在设计过程中，基于需求背景、用户痛点、业务场景、业务角色等梳理需求目标，以目标为导向思考解决方案
（2）工具：
l 用户现场调研：深入业务方的日常行为及工作，发现根本问题
l HMW分析法：拓展问题解决的方向，发散思维寻求更多解决方案
l 竞品分析：了解其他相似功能或模块设计逻辑，体验产品的过程中，重点关注用户、使用场景、需求，吸取主流设计模式的优点。
（3）产出物：
l 需求概括：需求背景、目的、目标用户等，这些在需求收集阶段就要梳理出来，在需求设计阶段细化
l 业务流程图：涉及角色、交互的系统，梳理关键流程节点，前期厘清流程避免后期大面积返工，当然最终流程也需要跟业务方确认后再设计细节
l 功能流程图：包含主流程、详细子流程，考虑多线程流程、逆向流程等
l 功能架构：按照层级结构往下拓展，eg：端（管理后台、H5）->模块（商品管理、库存管理）->功能（新增、删除）->子功能（批量删除）
l 信息架构：每个子功能需要哪些信息支撑，由下至上梳理
l 页面结构和原型：页面间跳转逻辑，页面内组件交互备注说明、业务规则说明等。
l 其他：修订历史、简单核心用例
2.2 需求评审
（1）描述：需求评审，是每个产品经理必须经历的工作环节。在评审会议上，前端、后端、测试、UI、业务方、领导等不同角色都有可能参与，每个角色对于需求的关注点不同，目的有四：评估需求的价值（做还是不做）、评估需求方案的合理性、初步评估技术可行性、明确需求开发的事项。所以如何高效完成需求评审、让大家都能理解你做的方案，是一个产品经理的基本素养，和赢得团队信任的基础。
（2）评审流程：
l 首先是界定需求类别：需求本身可分为：功能优化、功能拓展、新功能。不同类别的需求描述着重点不同。
l 介绍需求背景：上来就讲功能点绝对是莫名其妙的，可能讲完了在场各位连你到底要做什么都还不知道。
l 描述当前业务流程：明确涉及的角色，描述当前关键业务节点，目的是让大家都了解业务逻辑，以便去判断方案是否存在大方向的偏差。
l 描述需求目标：根据背景和业务流明确此次方案的边界，要解决哪些问题，谁通过什么方式来解决。
l 描述方案/功能流程图：列出主要的功能模块/功能点，讲清楚需要哪些功能点来解决哪些对应的问题
l 细致描述页面流程：采用逻辑+模块的表达方式，功能流程图上每个关键节点都是一个产品模块，先讲清楚每个链上的产品模块，再讲模块的功能。上帝视角与用户视角结合，既要说明逻辑、模块、功能等概念，也会从一个具体配置人员的角度讲一讲他们该如何使用这个系统。
l 描述需求考核指标：此次需求设计的效果验证，最好能提供一些可量化的数据指标，即完成这个需求后能带来哪些数据的变动。
（3）产出物：
l 会议记录：在会上，在讲的同时也要把出现的问题记录下来，整理待解决的问题，并与大家确认无遗漏
l 问题解决方案：针对待解决的问题，给出其他更合适的解决方案，小问题发出确认即可，大问题还要约第二次评审，无论是大小问题，在修改需求文档时都需要记录修订时间、内容、修订人，同时通知相关人员
l 版本排期：最后一次评审会确定就要排期，这个可以跟相关部门的负责人沟通，比如技术经理，需要多久时间完成迭代任务，什么时候提测、什么时候可以上线
2.3 参与技术方案评审
（1）描述：需求通过评审后两天，技术人员在充分理解需求后，要过一遍技术方案，产品参与技术方案评审有两个目的：第一是听技术人员讲一遍需求，过一遍核心业务点，可以了解技术人员对需求的理解是否存在偏差，是否有遗漏；第二同时也是产品学习的一个过程，去充分理解技术实现的过程，在需求开发过程中可降低沟通成本。
2.4 参与测试用例评审
（1）描述：提测前两天，测试人员要细致得列出所有的功能的测试点，然后在会上一条一条过，产品参与测试用例评审目的有二：第一是辅助测试人员完善测试用例，需求细节在文档中没有描述清楚，在会上就是很好的纠错环节；第二是发现自己没有考虑到的点，逻辑上的不完整，异常页面缺失等，尽早发现问题，规避风险，同时也警醒产品在下一轮迭代设计中，尽可能考虑周全。
2.5 测试周验收需求
（1）描述：测试周中期阶段，测试人员基本已经把需求主流程跑通了，产品要参与实现效果验收。一切顺利的情况下，把控实现的细节；如果有部分功能子需求来不及实现了，需要记录下来并入库往后排期。
2.6 迭代培训
（1）参与人：本次迭代涉及到的业务方人员
（2）培训框架：
l 功能适用场景：描述需求背景、此次功能目的和要解决的问题，必须要提及本次迭代的功能界线。
l 适用的角色：即谁会用到这个功能
l 功能逻辑，流程：各角色之间是如何使用此功能协助的，需要特别注意哪些点
l 操作指引：在实际的线上系统，完整操作一遍作为演示。
（3）目的：推进功能的使用，降低用户作出改变的成本
2.7 跟踪上线的功能
（1）验证需求：根据需求设计时设定的验证方案，通过线上数据、用户反馈、使用者建议等评估此次需求是否达到预期，找出达不到预期效果的根本原因，思考下一步工作思路。
（2）收集新需求：对于新上线的功能，业务方在使用过程中的问题需要详细记录，必要时转为新需求，持续跟进已上线的功能，不断优化迭代，适应业务高速发展。
