一个需求从诞生到上线的完整流程.ppt

时间 部门名称 一个需求从诞生到上线的完整流程 2010.12.22 ——谈谈产品经理如何降低决策风险 1 2 产品经理的角色 产品设计的完整流程 3 QA 1 产品经理的角色 产品经理是做什么的? 1.你是用户 2.战略决策 1.产品设计方法论 2.产品设计流程 1.项目管理(？） 2. 产品质量管理 数据统计与分析 产品经理=产品的老板=我们对一切负责=没有我们不管的事 Ownership!!!! 产品经理是老板,ownership很重要 不管有没有授权,都必须认为自己有这个权利管所有事情 首先要有这个气魄,有这个自我认识和要求 否则你不可能成为当家的,只能成为童养媳 2 决策 产品经理是做什么的？ 为什么要做？ 用户需要吗？ 要不要这个功能？ 链接放什么位置？ 需求要变更吗？ Bug一定修复吗？ 成功还是失败？ 为什么click下降？ 做决策，做判断 3 决策风险 做出好的决策 = 一个好的产品经理 什么是好的决策？ 在没有结果之前，谁也不知道决策好不好。没有最好的决策，只有风险相对较低的决策。 有很多方法论可以帮助避免错误决策。 好的流程能很好帮助一群臭皮匠做出诸葛亮的决策。 做出连续的好的决策 并贯彻出结果 = 一个NB的产品经理 降低决策风险= 权威，信任，影响力 1 2 产品经理的角色 产品设计的完整流程 3 QA 1 产品设计完整流程 2 产品设计-Featurelist 在之前的需求准备阶段，我们就应该准备了充分的论据，来证明这个事情要做 对于大的版本或者战略决策，不是在这个环节讨论的。MRD要前置。 沟通成本：4 因为，我们一定要说服项目组成员，这些功能点必须做。 文档成本：1 因为，要做什么，一定是可以简单明了的说清楚的。否则一定没有想清楚。一个简单的excel就是Featurelist. ”这个能不能做？“ ”为了达到这个目的，可行的方案是怎样的？“ 3 产品设计-wireframes wireframes（线框图）是一个PM的基本功，我们最好学会使用fireworks，axcure，mockups……中的某一个。PS过于复杂不是很利于提高效率。 在这个环节，不需要考虑细节，关键是产品的大概设计，基本流程和主要逻辑。 和PM讨论问题，应该是开放而轻松的，应该获得成长和享受，所以沟通成本为2. ”没有wireframes就讨论？” “不和周围的PM讨论，苦思冥想，闭门造车？” ”不仔细对比同一功能2个以上竞争对手的设计？“ 不遵循相似功能的常规做法，老想着“亮点”？ 完全只关注前端设计，不考虑后端逻辑？ 4 产品设计-PRD 第一部分：PRD的撰写 PRD撰写的水平 = PM产品设计能力的书面凭证 PRD=Featurelist + 详细的wireframes + 清晰的逻辑流程描述。也就是定义清晰，结构清晰，描述清晰。就是RD和QA容易看得懂，无歧义。 你思考了90%，PRD只写其中最重要的60%。剩下的30%靠评审+沟通。 ”wireframe非常粗略，连展示什么内容都画错！“ “不重视分支流程，只有一个主流程，甚至没有流程！” “逻辑考虑非常表面和简单！让工程师笑掉大牙！” 我们一定要努力做到严谨严谨再严谨，每次思考都多严谨一点。 但文档成本一定要控制，不是什么都需要写，更重要的是沟通。 5 产品设计-PRD 第二部分：PRD评审 PRD评审是一个严肃的场合，我们必须做好万全的准备。每一次评审，都是PM作为个人，作为集体，对整个项目组树立权威/信任/影响力的时刻。 PRD评审严格的说不是需求评审，不是要不要做，而是到底具体做什么。 会前一定要邮件发出PRD，并敦促负责RD事前详细阅读，最好有批注。 控制会议进程，针对PRD每一点进行详细的充分的讨论，务必达成结论。做好会议纪要，会后迅速发出，并迅速的修改需求。 不一定需要多次评审，但一定需要反复的非正式沟通。 对于工程师的问题，我们必须有预见性和理解力。请不要显得惊慌失措甚至鸡同鸭讲。当然这需要一个学习的过程，谁不是呢？ 对于工程师提出的需求建议，请本着开放的心态共同讨论，会受益良多。 需求评审应该是一个严谨而又适度开放的过程，即验证了需求，又优化了需求，如果我们有能力控制过程，会很享受。 我们一定要努力做到凡事都想在工程师的前面，哪怕是当场学习和补缺，最不济也得装成这样………… 6 产品设计s 交互设计师应该是我们的好帮手，但是我们必须有强大的判断能力。PRD中的wireframes应该尽可能的考虑到所有交互细节，自己不考虑，不可能产生判断能力。 在设计过程与设计师保持高密度的沟通，push对方与自己高效的输出。 有争论的时候，尽可能寻找