产品设计与需求分析PPT格式课件下载.pptx

产品设计与需求分析PPT格式课件下载.pptx

《产品设计与需求分析PPT格式课件下载.pptx》由会员分享，可在线阅读，更多相关《产品设计与需求分析PPT格式课件下载.pptx（53页珍藏版）》请在冰豆网上搜索。

PD侧重于做功能级的设计，在某个模块上，PD类似一个小产品经理。

技术团队中的架构师/系统分析师/开发组长会与PD紧密合作，这时候开始考虑技术可行性，性价比，确定方案。

UE：

用户体验师/交互设计师/界面设计师。

UE负责产品和用户交互方面的设计，这方面在技术部门的配合角色应该是前端工程师/客户端开发。

PD与UE要充分沟通，UE必须要了解商业层面的内容，理解功能的商业价值。

UI：

界面设计师/视觉设计师/美工，与UE的界限模糊。

到了UI层面，基本是界面的表现，是用户第一眼看到的效果，比如配色、页面结构、按钮形状、字体字号等等,最基本的句式：

解决了什么用户的什么需求？

练习的时候，切忌求多，说一点即可，找到你感觉最贴切的那一种用户，和他最迫切的那一个需求。

主要扩展有如下几种：

产生需求的场合是什么？

需求的应用场景，时间地点等，要有“故事感”，尽量找一个能让人会心一笑的。

产品的主要功能有哪些？

需求和功能的区别在于，前者是从用户角度说的，是一种希望，利益点，这时候还没有产品，后者是从产品属性上说的。

产品定位规划练习,技术基础是什么？

主要考察产品的实现成本，从而评估性价比，是否值得做。

没有这个产品的时候，用户是怎么解决问题的？

帮助思考，这个产品是否是“不做会死人”的，我们尽量不要做有很多替代方案的产品。

竞争对手是什么？

这个问题不用局限，尽量展开了想，比上一个问题更广，可以考虑潜在的竞争对手。

顺应了什么趋势？

好的产品是顺势而为的，满足未来的某种根本需求是更进一步的基础，尝试预测未来。

解决了什么用户的什么需求？

技术基础是什么？

方便面产品,3+1思考法：

测量产品/项目“靠谱程度”,需求是从哪里来的？

目标客户是谁？

有多少人有这样的需求？

这个需求紧迫吗？

他们的痛是什么？

场景是什么？

（用产品之前/之后）,解决之后在软件数据上会有二次挖掘价值吗？

目录,找到种子用户,受要解决的问题困扰最深的人！

愿意配合可以提供很多有价值的信息可以忍受缺陷乐意成为义务推销员,除了最终用户外，还有,Stakeholder分析,Stakeholder列表：

筹码量分析优先级,Stakeholder档案：

筹码付出关注点,需求平衡与跟踪：

冲突识别、实现跟踪,评价者,运营者,购买者,不同层次的用户，其需求的价值不同,业绩差距（问题）,项目目标,Stakeholder,操作层要求,机会差距（机会）,Stakeholder列表,Stakeholder关注点,效率,质量,业务价值,Stakeholder分析,影响度,兴趣度,高,低,低,高,保持沟通,关键玩家,尽力满足,最小努力,目录,产品设计是端到端的过程，端即用户，也就是从用户中来到用户中去，最最开始的源头就是“为用户解决问题，满足其需求”。

产品需求过程三步骤：

产品设计中与需求相关的部分,需求管理,需求分析,需求采集,产品创意源于三新,新技术,新人群,新业务,技术创新带来的机会,新业务模式带来的机会,人群特点变化带来的机会,手段,特点,模式,产品灵感源于需求洞察,产品,现状,预期,预期,现状,预期,现状,预期,现状,预期,现状,问题,机会,需求的三层次,小张问店老板：

你这里有卖冲击钻吗？

店主问：

您为什么想在墙上打个孔呢？

小张答：

我想在墙上挂幅画。

您为什么想在墙上挂幅画呢？

我下班回家，单身一人太冷清，挂幅画热闹点。

你想用冲击钻来解决什么问题呢？

想在墙上打个孔,店主答：

对不起，我们这没有冲击钻卖，你到别处看看。

暴食、贪婪、懒惰、嫉妒、骄傲、淫欲、愤怒,意识：

需求三要素,意识：

需求三要素,问题Why,业务背景Context,解决方案What,1、澄清问题（问题表象+原因+范围与限定）2、了解业务背景（业务场景谁、什么时候、怎么做+业务术语+变化/约束/扩展）3、建议并确认解决方案（问题有效解决+成本合适）,目录,由一个产品UI说开去,由产品到需求,沟通,业务分析与表达,1,2,3,4,5,6,业务规划,需求收集与管理,用户为什么说不清需求,问Why,结构化提问,马斯洛需求层级,需求问题就是沟通问题,沟通哲学,产品做出来，还要卖出去。

前者是“需求到功能”，可以对应到“产品设计”的职能，后者是“功能到卖点”，对应产品运营。

从功能到卖点,目标用户：

人物；

场景：

时间、地点；

碰到的问题：

事情的起因，需求产生；

产品/功能：

事情的经过，我们如何解决了问题；

用户收益：

事情的结果，用了我们的产品以后，如何美好。

成败案例分析

（1）,产品卖点需求全景,右脑需求：

感觉、情感、外观、设计,左脑需求：

实用、痛点、逻辑、功能（高层：

解决问题/创造机会；

中层：

管理/控制）,关键需求,详细需求,吸引,购买,再次购买,目录,由一个产品UI说开去,由产品到需求,沟通,业务分析与表达,1,2,3,4,5,6,业务规划,需求收集与管理,业务流程八要素,分工,活动,规模,风险,专业,协作并行串行异步,产物关系,分支,审核,异常,规则,业务流程分析,没有最好的图，只有最合适的的图，应根据流程逻辑特点选择,从服务请求到服务满足，整个过程涉及哪些角色参与其中,一切正常的处理流程是什么样的？

需要相关的审核点吗？

在各个环节中会出现例外吗？

针对这些例外如何处理？

有没有完全不能够按流程处理的情况？

有没有出错的情况？

业务流程vs.业务功能,最终用户,管理者,跨职能流程图视频侦缉,描述流程：

选择正确的工具,现场出图：

流程分析加速器,一听,二问,三读,客户代表陈述,不要中途打断,绘出基本脉络,为指引,具体的岗位,分支与异常,其他细节,绘图者复述,客户代表验证,达成共识,阅读用例图,目录,由一个产品UI说开去,由产品到需求,沟通,业务分析与表达,1,2,3,4,5,6,业务规划,需求收集与管理,产品设计期需求,目标用户：

这件事，是为谁而做的，一旦售后填写这个就可以自己排除掉很多需求了；

问题描述：

目标用户碰到的痛点，只说“何时/何地，怎么难受”即可；

严重程度：

对问题严重程度的判断，“高/中/低”即可，具体的判断方法，可以根据用户重要程度，问题出现的次数、频率等因素考虑；

现有方案：

现在是如何解决此问题的。

一般来说，一个值得解决的问题，通常已经有人着手想方案了，也一定已经有一些解决方案，而没有现有方案的问题，通常不严重；

建议方案：

建议的产品改进，催促售后换位思考，产品不一定采纳；

价值描述：

改进方案带来的额外价值，比如：

省时间；

能更精准的找到某某改进成本：

建议方案的成本评估，“高/中/低”，同样，仅供参考。

产品拿到一堆需求以后，主要根据性价比决定接下来做什么。

性价比=严重程度/改进成本，问题（用户需求）决定严重程度，解决方案（产品功能）决定改进成本。

售后/运营该如何提需求,质量属性的常见误区,定性描述,普遍重视不足,全局描述,盲目定量,需求简单复制开发直接翻过,需求写不出开发看不懂,顾此失彼未能有效实现,模块：

一般来说，每个模块下分310个子模块是合理的，否则要考虑重新划分。

子模块：

稍大一点的产品至少要给功能模块做二级分类了。

功能：

要给用户提供什么功能，功能名字。

功能描述：

这里可以说具体一点。

需求列表到功能列表,商业价值描述：

卖点是什么，可以给用户提供什么价值。

商业属性：

简单分为基本，扩展，增值。

商业优先级：

这块是整个FeatureList工作中核心的部分，判断的准确直接影响着将来产品的方向。

先基于自己对商业目标的理解，主观定级别，然后再PD团队pk，如有必要，再去客户处确认。

开发量：

一般由技术部门的项目经理或者系统分析师/架构师来确定。

性价比：

综合商业属性、优先级与开发量来确定一个合适产品的计算方法。

备注：

需求确认,动态功能列表是对每个需求加上跟踪状态属性，能实时看到“何时做，谁来做，状态如何”。

负责人：

细分为需求提出者（备注原始需求）、需求负责人、开发负责人、测试负责人，属于哪个项目需求状态：

通常有“待讨论”、“拒绝”、“暂缓”、“需求中”、“开发中”、“已完成”几个状态，可按实际情况增减。

时间信息：

提出时间、录入时间、发布时间,采集产品干系人（广义用户）提出的各种需求，整理转化为产品需求，即“需求转化”。

“确定属性”即这个需求是属于产品的哪个模块？

是基本/扩展/增值功能？

是功能/性能/用户体验方面？

等。

属性的维度可按照产品的不同自由定义，原则是为了便于需求管理。

需求管理,featurelist，每隔一段时间、或新需求积累到一定数量、或是由特别事件触发，进行“确定商业价值（产品内PK）”。

会议上讨论所有状态为“待讨论”的功能点，需求状态一定要变化，进入“需求中”/“拒绝”/“暂缓”。

拒绝的需求是被认为对产品的商业目的没有价值的，而暂缓的需求是“有价值，但是现在不做”的，通常要表明重启的条件。

状态变为“需求中”的功能点，下一步就是初定工作量，只是简单的评估，和真实情况的匹配程度很取决于经验,要靠不断的实践来反复修正。

有了每个功能点的商业价值和工作量，很自然的就能算出性价比，简单的说即“商业价值/开发工作量”，我们把featurelist按照性价比从大到小排序，再对应考察每行评估出来的开发工作量，从上到下依次纳入项目，我们的可用工作量能做多少个功能点，一目了然。

第二，需求依赖，功能点互相之间有依赖关系，只能先做某些功能，应在featurelist里注明；

功能点与人力资源之间的依赖关系也会经常存在，在这里评估工作量的时候不会考虑“谁来做”的问题，但是在后续立项，组建团队的时候需要注意。

第三，功能点的粒度大小问题，商业价值很高的功能，如果细分的话，我们也会发现其中有价值相对低的部分，所以功能点的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内。

第一，需求打包最好打类似的功能点，是否类似取决于需求的属性，“确定属性”这步做的事情起作用了，一般来说业务上有逻辑关系的需求才会包含一个项目里，否则就是一个纯粹修修补补的“小需求项目”了。

需求发布流程,目录,由一个产品UI说开去,由产品到需求,沟通,业务分析与表达,1,2,3,4,5,6,业务规划,需求收集与管理,业务规划-Why？

What？

How？

可做的事想做的事能做的事,一句话的业务定位一个商业模型几个个业务关键点,资源保障计划安排效果预估,业务规划,How,What,Why,首先，明确目的，最最重要，其实做一个会议和做一个产品也是一样的。

不要试图在一个会议中解决所有的问题，就