产品设计与需求分析.ppt

产品与需求目目 录录由一个产品由一个产品由一个产品由一个产品UIUIUIUI说开去说开去说开去说开去由产品到需求由产品到需求由产品到需求由产品到需求沟通沟通沟通沟通业务业务业务业务分析与分析与分析与分析与表达表达表达表达12345技术技术开发、测开发、测试试产品产品需求、设计需求、设计博客博客商业商业市场、销售市场、销售6业务规划业务规划业务规划业务规划需求收集与管理需求收集与管理需求收集与管理需求收集与管理任务的目的是展示美国的几个城市在不同月份的平均降水量。UI演进举例产品需求确定后的表现差异体验设计要点贴心功能功能呈现信息展现交互感受辅助指引用户体验场景是核心重视情感需求场景下行为分析业务价值抽象目目 录录由一个产品由一个产品由一个产品由一个产品UIUIUIUI说开去说开去说开去说开去由产品到需求由产品到需求由产品到需求由产品到需求沟通沟通沟通沟通业务业务业务业务分析与分析与分析与分析与表达表达表达表达12345技术技术开发、测开发、测试试产品产品需求、设计需求、设计博客博客商业商业市场、销售市场、销售6业务规划业务规划业务规划业务规划需求收集与管理需求收集与管理需求收集与管理需求收集与管理目目 录录需求需求产品产品博客博客用户用户产品产品项目是定制的，个性化的，为了满足一个或一批特定的客户需求项目是定制的，个性化的，为了满足一个或一批特定的客户需求；而产品是服务一个用户群的，通用的。这就意味着，项目要服务好那个特定的客户；而产品不能为了个别用户的需求去定制，必须考虑用有限的资源去满足更多的、能有更多回报的用户。产品与项目的区别项目是相对短期的，较少后续工作的，可以结束的（称为“结项”）；产品是相对长期的，不存在所谓的“结束”，只能是“生命周期完结”。所以不可能有一个已经“完成”的产品，只存在不断完善中的产品，直到这个产品被新产品替代，已经没有存在的价值，它才会“生命周期完结”。为了避免把产品做成项目的集合体而臃肿不堪，我们需要细分市场，这时产品可能就要升级为“产品线”，按不同的细分市场，推出不同的产品。产品团队PMPDUIUEPM：产品经理。一个产品，首先由PM来进行商业上的规划，比如细分市场、目标客户、主要卖点等等，通常PD已经介入这个过程。在这个层面，商业问题、业务逻辑的流畅是思考的焦点。PD：产品设计师/产品规划师/需求分析师。PD侧重于做功能级的设计，在某个模块上，PD类似一个小产品经理。技术团队中的架构师/系统分析师/开发组长会与PD紧密合作，这时候开始考虑技术可行性，性价比，确定方案。UE：用户体验师/交互设计师/界面设计师。UE负责产品和用户交互方面的设计，这方面在技术部门的配合角色应该是前端工程师/客户端开发。PD与UE要充分沟通，UE必须要了解商业层面的内容，理解功能的商业价值。UI：界面设计师/视觉设计师/美工，与UE的界限模糊。到了UI层面，基本是界面的表现，是用户第一眼看到的效果，比如配色、页面结构、按钮形状、字体字号等等最基本的句式：解决了什么用户用户的什么需求需求？练习的时候，切忌求多，说一点即可，找到你感觉最贴切的那一种用户，和他最迫切的那一个需求。主要扩展有如下几种：产生需求的场合场合是什么？需求的应用场景，时间地点等，要有“故事感”，尽量找一个能让人会心一笑的。产品的主要功能功能有哪些？需求和功能的区别在于，前者是从用户角度说的，是一种希望，利益点，这时候还没有产品，后者是从产品属性上说的。产品定位规划练习技术基础是什么？主要考察产品的实现成本，从而评估性价比，是否值得做。没有这个产品的时候，用户是怎么解决问题的？帮助思考，这个产品是否是“不做会死人”的，我们尽量不要做有很多替代方案的产品。竞争对手是什么？这个问题不用局限，尽量展开了想，比上一个问题更广，可以考虑潜在的竞争对手。顺应了什么趋势？好的产品是顺势而为的，满足未来的某种根本需求是更进一步的基础，尝试预测未来。解决了什么用户的什么需求？产生需求的场合是什么？产品的主要功能有哪些？技术基础是什么？没有这个产品的时候，用户是怎么解决问题的？竞争对手是什么？顺应了什么趋势？方便面产品3+1思考法：测量产品/项目“靠谱程度”需求是从哪需求是从哪里来的？目里来的？目标客户是谁标客户是谁？有多少人有有多少人有这样的需求这样的需求？这个需求？这个需求紧迫吗？紧迫吗？他们的痛是什么他们的痛是什么？场景是什么？场景是什么？（用产品之前（用产品之前/之之后）后）解决之后在软件解决之后在软件数据上会有二次数据上会有二次挖掘价值吗？挖掘价值吗？目目 录录需求需求产品产品博客博客用户用户用户用户找到种子用户受要解决的问题困扰最深的人！l愿意配合l可以提供很多有价值的信息l可以忍受缺陷l乐意成为义务推销员除了最终用户外，还有Stakeholder分析Stakeholder列表：筹码量分析优先级Stakeholder档案：筹码付出关注点需求平衡与跟踪：冲突识别、实现跟踪123评价者运营者购买者不同层次的用户，其需求的价值不同业绩差距(问题)项目目标Stakeholder操作层要求机会差距(机会)Stakeholder列表Stakeholder关注点效率质量业务价值STAKEHOLDER分析影响度兴趣度高低低高保持沟通关键玩家尽力满足最小努力目目 录录需求需求产品产品博客博客用户用户需求需求产品设计是端到端的过程，端即用户，也就是从用户中来到用户中去，最最开始的源头就是“为为用户解决问题，满足其需求用户解决问题，满足其需求”。产品需求过程三步骤：产品设计中与需求相关的部分需求管理需求分析需求采集产品创意源于三新新技术新人群新业务技术创新带来的机会新业务模式带来的机会人群特点变化带来的机会手段特点模式产品灵感源于需求洞察产品现状预期预期现状预期现状预期现状预期现状问题机会需求的三层次WantNeedWin小张问店老板：你这小张问店老板：你这里有卖冲击钻吗？里有卖冲击钻吗？店主问：您为什么想店主问：您为什么想在墙上打个孔呢？在墙上打个孔呢？小张答：我想在墙上小张答：我想在墙上挂幅画。挂幅画。店主问：您为什么想店主问：您为什么想在墙上挂幅画呢？在墙上挂幅画呢？小张答：我下班回家，小张答：我下班回家，单身一人太冷清，挂单身一人太冷清，挂幅画热闹点。幅画热闹点。店主问：你想用冲击店主问：你想用冲击钻来解决什么问题呢钻来解决什么问题呢？小张答：想在墙上打小张答：想在墙上打个孔个孔店主答：对不起，我店主答：对不起，我们这没有冲击钻卖，们这没有冲击钻卖，你到别处看看。你到别处看看。暴食、贪婪、懒惰、嫉妒、骄傲、淫欲、愤怒暴食、贪婪、懒惰、嫉妒、骄傲、淫欲、愤怒意识：需求三要素业务背景：花盆种类、摆放位置解决方案：木制的小板凳问题：放花盆木桩什么形状，钉在什么位置？要几枚铁钉，多长多大？板多大、多宽、多厚？意识：需求三要素问题Why业务背景Context解决方案What1、澄清问题（问题表象+原因+范围与限定）2、了解业务背景（业务场景谁、什么时候、怎么做+业务术语+变化/约束/扩展）3、建议并确认解决方案（问题有效解决+成本合适）目目 录录由一个产品由一个产品由一个产品由一个产品UIUIUIUI说开去说开去说开去说开去由产品到需求由产品到需求由产品到需求由产品到需求沟通沟通沟通沟通业务业务业务业务分析与分析与分析与分析与表达表达表达表达12345技术技术开发、测开发、测试试产品产品需求、设计需求、设计博客博客商业商业市场、销售市场、销售6业务规划业务规划业务规划业务规划需求收集与管理需求收集与管理需求收集与管理需求收集与管理用户为什么说不清需求易于放大需求不讲需求背后的原因需求零散，思考不足问问WhyWhy结构化提问结构化提问马斯洛需求层级需求问题就是沟通问题沟通哲学产品产品做出来，还要卖出去。前者是做出来，还要卖出去。前者是“需求到功能需求到功能”，可以对应到，可以对应到“产品设计产品设计”的职能，后者是的职能，后者是“功能功能到卖点到卖点”，对应产品，对应产品运营。运营。从功能到卖点目标用户：人物；场景：时间、地点；碰到的问题：事情的起因，需求产生；产品/功能：事情的经过，我们如何解决了问题；用户收益：事情的结果，用了我们的产品以后，如何美好。成败案例分析(1)网上银行孰优孰劣？帐户管理基本交易网上支付借记卡信用卡基 金产品卖点需求全景右脑需求：感觉、情感、外观、设计右脑需求：感觉、情感、外观、设计左脑需求：实用、痛点、逻辑、功能左脑需求：实用、痛点、逻辑、功能（高层：解决问题（高层：解决问题/创造机会；中层：管理创造机会；中层：管理/控制）控制）关关键键需需求求详详细细需需求求吸引吸引购买购买业务子系统业务子系统/功功能域能域行为行为数据数据质量质量再次再次购买购买目目 录录由一个产品由一个产品由一个产品由一个产品UIUIUIUI说开去说开去说开去说开去由产品到需求由产品到需求由产品到需求由产品到需求沟通沟通沟通沟通业务分析与表达业务分析与表达业务分析与表达业务分析与表达12345技术技术开发、测开发、测试试产品产品需求、设计需求、设计博客博客商业商业市场、销售市场、销售6业务规划业务规划业务规划业务规划需求收集与管理需求收集与管理需求收集与管理需求收集与管理业务流程八要素分工活动规模规模风险风险专业专业协作并行串行异步产物关系分支审核异常规则业务流程分析选择合适的流程图描述方式标识流程中各参与角色梳理主流程梳理分支分析异常情况没有最好的图，只没有最好的图，只有最合适的的图，有最合适的的图，应根据流程逻辑特应根据流程逻辑特点选择点选择从服务请求到服务从服务请求到服务满足，整个过程涉满足，整个过程涉及哪些角色参与其及哪些角色参与其中中一切正常的处理流一切正常的处理流程是什么样的？需程是什么样的？需要相关的审核点吗要相关的审核点吗？在各个环节中会出在各个环节中会出现例外吗？针对这现例外吗？针对这些例外如何处理？些例外如何处理？有没有完全不能够有没有完全不能够按流程处理的情况按流程处理的情况？有没有出错的情？有没有出错的情况？况？业务流程 VS.业务功能最终用户管理者跨职能流程图视频侦缉描述流程：选择正确的工具 商业建模标准 复用性强 用户最容易接受 并行、异步支持差跨职能流程图活动图时序图数据流图 IDEF建模标准 强调数据流 未表示出谁执行 计费类系统最适用 UML建模标准 语义最丰富 强调行为流 强调活动内容 UML建模标准 强调行为流 强调协作 技术类系统更常用现场出图：流程分析加速器一听二问三读客户代表陈述不要中途打断绘出基本脉络为指引忽略细节草图演化具体的岗位分支与异常其他细节绘图者复述客户代表验证达成共识阅读用例图目目 录录由一个产品由一个产品由一个产品由一个产品UIUIUIUI说开去说开去说开去说开去由产品到需求由产品到需求由产品到需求由产品到需求沟通沟通沟通沟通业务分析与表达业务分析与表达业务分析与表达业务分析与表达12345技术技术开发、测开发、测试试产品产品需求、设计需求、设计博客博客商业商业市场、销售市场、销售6业务规划业务规划业务规划业务规划需求收集与管理需求收集与管理需求收集与管理需求收集与管理需求编号：需求编号：包含“采集时刻+采集者”信息需求类型：需求类型：（在进行评审时填写）功能需求、非功能需求来源（来源（Who）：）：（方便追根溯源）公司提供者：需求提供者的部门、联系方式产生需求的客户：用户需求的公司、部门、联系方式客户背景资料：受教育程度、岗位经验、其他与本单项需求相关经验场景（场景（Where、When）：）：产生该需求的用户活动特定的时间、地理、环境描述（描述（What）：）：用（主语+谓语+宾语）的语法结构，禁止使用修饰语句原因（原因（Why）：（保持怀疑的心，很多时候理由是假想出来的）：（保持怀疑的心，很多时候理由是假想出来的）验收标准（验收标准（How）：1.用量化的语言2.无法量化寻找标竿需求重要性权重（需求重要性权重（Howmuch）：）：满足后（1一般5非常高兴）未实现（1略感遗憾5非常懊恼）需求生命特征（需求生命特征（When）：）：1.需求的紧急度2.时间持续性需求关联（需求关联（Which）：）：1.人：需求关联的用户影响人物2.事：需求关联的用户业务与关联需求编号3.物：需求关联的客户系统、设备；需求关联的公司产品及版本参考材料：参考材料：在需求采集活动中的输入材料，仅仅输入援用的条目、章节竞争者对比：竞争者对比：（按照1分差10分好进行评估）1.竞争者对该需求的满足方式2.用户、客户对竞争者及公司在该需求的评价产品设计期需求目标用户目标用户：这件事，是为谁而做的，一旦售后填写这个就可以自己排除掉很多需求了；问题描述问题描述：目标用户碰到的痛点，只说“何时/何地，怎么难受”即可；严重程度严重程度：对问题严重程度的判断，“高/中/低”即可，具体的判断方法，可以根据用户重要程度，问题出现的次数、频率等因素考虑；现有方案现有方案：现在是如何解决此问题的。一般来说，一个值得解决的问题，通常已经有人着手想方案了，也一定已经有一些解决方案，而没有现有方案的问题，通常不严重；建议方案建议方案：建议的产品改进，催促售后换位思考，产品不一定采纳；价值描述价值描述：改进方案带来的额外价值，比如：省时间；能更精准的找到某某改进成本改进成本：建议方案的成本评估，“高/中/低”，同样，仅供参考。产品拿到一堆需求以后，主要根据性价比决定接下来做什么。性性价比价比=严重程度严重程度/改进成本，问题（用户需求）决定严重程度，解决方案（产品功能）决定改进成改进成本，问题（用户需求）决定严重程度，解决方案（产品功能）决定改进成本。本。售后/运营该如何提需求质量属性的常见误区定性描述全局描述盲目定量需求简单复制开发直接翻过需求写不出开发看不懂顾此失彼未能有效实现模块：模块：一般来说，每个模块下分310个子模块是合理的，否则要考虑重新划分。子模块：子模块：稍大一点的产品至少要给功能模块做二级分类了。功能功能：要给用户提供什么功能，功能名字。功能描述：功能描述：这里可以说具体一点。需求列表到功能列表商业价值描述：卖点是什么，可以给用户提供什么价值。商业属性：简单分为基本，扩展，增值。商业优先级：这块是整个Feature List工作中核心的部分，判断的准确直接影响着将来产品的方向。先基于自己对商业目标的理解，主观定级别，然后再PD团队pk，如有必要，再去客户处确认。开发量：一般由技术部门的项目经理或者系统分析师/架构师来确定。性价比：综合商业属性、优先级与开发量来确定一个合适产品的计算方法。备注：需求确认动态功能列表是对每个需求加上跟踪状态属性，能实时看到“何时做，谁来做，状态如何”。负责人：细分为需求提出者（备注原始需求）、需求负责人、开发负责人、测试负责人，属于哪个项目需求状态：通常有“待讨论”、“拒绝”、“暂缓”、“需求中”、“开发中”、“已完成”几个状态，可按实际情况增减。时间信息：提出时间、录入时间、发布时间采集产品干系人（广义用户）提出的各种需求，整整理理转化为产品需求转化为产品需求，即“需求转化需求转化”。“确定属性确定属性”即这个需求是属于产品的哪个模块？是基本/扩展/增值功能？是功能/性能/用户体验方面？等。属性的维度可按照产品的不同自由定义，原则是为了便于需求管理。需求管理feature list，每隔一段时间、或新需求积累到一定数量、或是由特别事件触发，进行“确定商业价值（产品内PK）”。会议上讨论所有状态为“待讨论”的功能点，需求状态一定要变化，进入“需求中”/“拒绝”/“暂缓”。拒绝的需求是被认为对产品的商业目的没有价值的，而暂缓的需求是“有价值，但是现在不做”的，通常要表明重启的条件。状态变为“需求中”的功能点，下一步就是初定工作量，只是简单的评估，和真实情况的匹配程度很取决于经验,要靠不断的实践来反复修正。有了每个功能点的商业价值和工作量，很自然的就能算出性价比，简单的说即“商业价值/开发工作量”，我们把feature list按照性价比从大到小排序，再对应考察每行评估出来的开发工作量，从上到下依次纳入项目，我们的可用工作量能做多少个功能点，一目了然。第二，需求依赖，功能点互相之间有依赖关系，只能先做某些功能，应在feature list里注明；功能点与人力资源之间的依赖关系也会经常存在，在这里评估工作量的时候不会考虑“谁来做”的问题，但是在后续立项，组建团队的时候需要注意。第三，功能点的粒度大小问题，商业价值很高的功能，如果细分的话，我们也会发现其中有价值相对低的部分，所以功能点的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内。第一，需求打包最好打类似的功能点，是否类似取决于需求的属性，“确定属性”这步做的事情起作用了，一般来说业务上有逻辑关系的需求才会包含一个项目里，否则就是一个纯粹修修补补的“小需求项目”了。需求发布流程目目 录录由一个产品由一个产品由一个产品由一个产品UIUIUIUI说开去说开去说开去说开去由产品到需求由产品到需求由产品到需求由产品到需求沟通沟通沟通沟通业务分析与表达业务分析与表达业务分析与表达业务分析与表达12345技术技术开发、测开发、测试试产品产品需求、设计需求、设计博客博客商业商业市场、销售市场、销售6业务规划业务规划业务规划业务规划需求收集与管理需求收集与管理需求收集与管理需求收集与管理业务规划-WHY？WHAT？HOW？可做的可做的事事想做的想做的事事能做的事能做的事一句话的业务一句话的业务定位定位一个商业一个商业模型模型几个几个个个业务关键点业务关键点资源资源保障保障计划计划安排安排效果预估效果预估业务规划业务规划HowHowWhatWhatWhyWhy首先，明确目的，最最重要，其实做一个会议和做一个产品也是一样的。不要试图在一个会议做一个会议和做一个产品也是一样的。不要试图在一个会议中解决所有的问题中解决所有的问题，就算你要连着召集两个参与人大部分相同的会议，我也建议你把它们分开，甚至，更好的做法，合理安排一个会议中的议题，可以让部分人早点走，或者晚点到。依据目的，类似的日常会议一般在15min2、3个小时不等。会议前，做好资源的确认：会议室、投影仪等；更要做好人员的确认：确认好“必选”的和“可选”的，不要漏人，也不要叫闲人，把握“大会决定小事，小会决定大事大会决定小事，小会决定大事”的原则。识别出会议的KP（KeyPerson，关键人物），通常是最大的一个或几个老板，提前当面或者电话知会一下，然后发出会议邀请。对于KP，争取提前与他讨论关键议题，达成一致，叫做“串供”，这会让会上省很多时间和精力。正所谓，要想让会议不流于形式，就要把会议本身变成走要想让会议不流于形式，就要把会议本身变成走走形式走形式。所有事情，尽量在会上取得共识，给出“会议决议”，实在不行的可以作为“遗留问题”。最后，牢记很实用的“所有人提供意见，少数人讨论，一个人拍板所有人提供意见，少数人讨论，一个人拍板”的民主集中原则。靠谱的会议回顾截至到上次会议结束时的信息回顾截至到上次会议结束时的信息1上次会议讨论的重点问题是什么？2关于这些问题我们达成了哪些一致意见？3上次会议中哪些问题由于缺乏信息考证，不确定性因素等原因而未能解决？4上次会议哪些执行计划被通过了？对于这些执行计划我们有哪些主要想法和设想？持续的战略规划会面对回顾信息，今天的重中之重8我们今天讨论的重点是什么？9你们提议的执行计划是什么？最初的设想和决定的理由？10我们怎样实践这些设想和减少潜在的不确定因素？11今天要讨论和做出的决定回顾上次会议结束到本次会议开始时间段5自上次讨论会议后外部发生了哪些主要变化？6自上次讨论会议后采取了哪些重要行动？以及这些执行对战略和财政上产生的影响？7上次会议后我们搜集了一些供参考的信息，对于执行计划是否要对当初的设想作些调整？“战略回顾”持续改进12从上一轮的战略回顾中我们学到什么？怎样在下一轮中学到更多？13怎样改进战略回顾会议和会议进行方式？谢谢！谢谢！