产品设计与需求分析PPT课件

产品与需求 目录 由一个产品UI说开去 由产品到需求 沟通 业务分析与表达 1 2 3 4 5 6 业务规划 需求收集与管理 任务的目的是展示美国的几个城市在不同月份的平均降水量 UI演进举例 产品需求确定后的表现差异 体验设计要点 用户体验 场景是核心重视情感需求 场景下行为分析 业务价值抽象 目录 由一个产品UI说开去 由产品到需求 沟通 业务分析与表达 1 2 3 4 5 6 业务规划 需求收集与管理 目录 项目是定制的 个性化的 为了满足一个或一批特定的客户需求 而产品是服务一个用户群的 通用的 这就意味着 项目要服务好那个特定的客户 而产品不能为了个别用户的需求去定制 必须考虑用有限的资源去满足更多的 能有更多回报的用户 产品与项目的区别 项目是相对短期的 较少后续工作的 可以结束的 称为 结项 产品是相对长期的 不存在所谓的 结束 只能是 生命周期完结 所以不可能有一个已经 完成 的产品 只存在不断完善中的产品 直到这个产品被新产品替代 已经没有存在的价值 它才会 生命周期完结 为了避免把产品做成项目的集合体而臃肿不堪 我们需要细分市场 这时产品可能就要升级为 产品线 按不同的细分市场 推出不同的产品 产品团队 PM 产品经理 一个产品 首先由PM来进行商业上的规划 比如细分市场 目标客户 主要卖点等等 通常PD已经介入这个过程 在这个层面 商业问题 业务逻辑的流畅是思考的焦点 PD 产品设计师 产品规划师 需求分析师 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 业务规划 需求收集与管理 用户为什么说不清需求 马斯洛需求层级 需求问题就是沟通问题 沟通哲学 产品做出来 还要卖出去 前者是 需求到功能 可以对应到 产品设计 的职能 后者是 功能到卖点 对应产品运营 从功能到卖点 目标用户 人物 场景 时间 地点 碰到的问题 事情的起因 需求产生 产品 功能 事情的经过 我们如何解决了问题 用户收益 事情的结果 用了我们的产品以后 如何美好 成败案例分析 1 产品卖点需求全景 右脑需求 感觉 情感 外观 设计 左脑需求 实用 痛点 逻辑 功能 高层 解决问题 创造机会 中层 管理 控制 关键需求 详细需求 吸引 购买 再次购买 目录 由一个产品UI说开去 由产品到需求 沟通 业务分析与表达 1 2 3 4 5 6 业务规划 需求收集与管理 业务流程八要素 分工 活动 规模 风险 专业 协作并行串行异步 产物关系 分支 审核 异常 规则 业务流程分析 没有最好的图 只有最合适的的图 应根据流程逻辑特点选择 从服务请求到服务满足 整个过程涉及哪些角色参与其中 一切正常的处理流程是什么样的 需要相关的审核点吗 在各个环节中会出现例外吗 针对这些例外如何处理 有没有完全不能够按流程处理的情况 有没有出错的情况 业务流程vs 业务功能 最终用户 管理者 跨职能流程图 视频侦缉 描述流程 选择正确的工具 现场出图 流程分析加速器 一听 二问 三读 客户代表陈述 不要中途打断 绘出基本脉络 为指引 具体的岗位 分支与异常 其他细节 绘图者复述 客户代表验证 达成共识 阅读用例图 目录 由一个产品UI说开去 由产品到需求 沟通 业务分析与表达 1 2 3 4 5 6 业务规划 需求收集与管理 产品设计期需求 目标用户 这件事 是为谁而做的 一旦售后填写这个就可以自己排除掉很多需求了 问题描述 目标用户碰到的痛点 只说 何时 何地 怎么难受 即可 严重程度 对问题严重程度的判断 高 中 低 即可 具体的判断方法 可以根据用户重要程度 问题出现的次数 频率等因素考虑 现有方案 现在是如何解决此问题的 一般来说 一个值得解决的问题 通常已经有人着手想方案了 也一定已经有一些解决方案 而没有现有方案的问题 通常不严重 建议方案 建议的产品改进 催促售后换位思考 产品不一定采纳 价值描述 改进方案带来的额外价值 比如 省时间 能更精准的找到某某 改进成本 建议方案的成本评估 高 中 低 同样 仅供参考 产品拿到一堆需求以后 主要根据性价比决定接下来做什么 性价比 严重程度 改进成本 问题 用户需求 决定严重程度 解决方案 产品功能 决定改进成本 售后 运营该如何提需求 质量属性的常见误区 定性描述 普遍重视不足 全局描述 盲目定量 需求简单复制开发直接翻过 需求写不出开发看不懂 顾此失彼未能有效实现 模块 一般来说 每个模块下分3 10个子模块是合理的 否则要考虑重新划分 子模块 稍大一点的产品至少要给功能模块做二级分类了 功能 要给用户提供什么功能 功能名字 功能描述 这里可以说具体一点 需求列表到功能列表 商业价值描述 卖点是什么 可以给用户提供什么价值 商业属性 简单分为基本 扩展 增值 商业优先级 这块是整个FeatureList工作中核心的部分 判断的准确直接影响着将来产品的方向 先基于自己对商业目标的理解 主观定级别 然后再PD团队pk 如有必要 再去客户处确认 开发量 一般由技术部门的项目经理或者系统分析师 架构师来确定 性价比 综合商业属性 优先级与开发量来确定一个合适产品的计算方法 备注 需求确认 动态功能列表是对每个需求加上跟踪状态属性 能实时看到 何时做 谁来做 状态如何 负责人 细分为需求提出者 备注原始需求 需求负责人 开发负责人 测试负责人 属于哪个项目 需求状态 通常有 待讨论 拒绝 暂缓 需求中 开发中 已完成 几个状态 可按实际情况增减 时间信息 提出时间 录入时间 发布时间 采集产品干系人 广义用户 提出的各种需求 整理转化为产品需求 即 需求转化 确定属性 即这个需求是属于产品的哪个模块 是基本 扩展 增值功能 是功能 性能 用户体验方面 等 属性的维度可按照产品的不同自由定义 原则是为了便于需求管理 需求管理 featurelist 每隔一段时间 或新需求积累到一定数量 或是由特别事件触发 进行 确定商业价值 产品内PK 会议上讨论所有状态为 待讨论 的功能点 需求状态一定要变化 进入 需求中 拒绝 暂缓 拒绝的需求是被认为对产品的商业目的没有价值的 而暂缓的需求是 有价值 但是现在不做 的 通常要表明重启的条件 状态变为 需求中 的功能点 下一步就是初定工作量 只是简单的评估 和真实情况的匹配程度很取决于经验 要靠不断的实践来反复修正 有了每个功能点的商业价值和工作量 很自然的就能算出性价比 简单的说即 商业价值 开发工作量 我们把featurelist按照性价比从大到小排序 再对应考察每行评估出来的开发工作量 从上到下依次纳入项目 我们的可用工作量能做多少个功能点 一目了然 第二 需求依赖 功能点互相之间有依赖关系 只能先做某些功能 应在featurelist里注明 功能点与人力资源之间的依赖关系也会经常存在 在这里评估工作量的时候不会考虑 谁来做 的问题 但是在后续立项 组建团队的时候需要注意 第三 功能点的粒度大小问题 商业价值很高的功能 如果细分的话 我们也会发现其中有价值相对低的部分 所以功能点的粒度应该尽量细 前提是细化引起的管理成本上升在可接受的范围内 第一 需求打包最好打类似的功能点 是否类似取决于需求的属性 确定属性 这步做的事情起作用了 一般来说业务上有逻辑关系的需求才会包含一个项目里 否则就是一个纯粹修修补补的 小需求项目 了 需求发布流程 目录 由一个产品UI说开去 由产品到需求 沟通 业务分析与表达 1 2 3 4 5 6 业务规划 需求收集与管理 业务规划 Why What How 可做的事想做的事能做的事 一句话的业务定位一个商业模型几个个业务关键点 资源保障计划安排效果预估 业务规划 How What Why 首先 明确目的 最最重要 其实做一个会议和做一个产品也是一样的 不要试图在一个会议中解决所有的问题 就算你要连着召集两个参与人大部分相同的会议 我也建议你把它们分开 甚至 更好的做法 合理安排一个会议中的议题 可以让部分人早点走 或者晚点到 依据目的 类似的日常会议一般在15min 2 3个小时不等 会议前 做好资源的确认 会议室 投影仪等 更要做好人员的确认 确认好 必选 的和 可选 的 不要漏人 也不要叫闲人 把握 大会决定小事 小会决定大事 的原则 识别出会议的KP KeyPerson 关键人物 通常是最大的一个或几个老板 提前当面或者电话知会一下 然后发出会议邀请 对于KP 争取提前与他讨论关键议题 达成一致 叫做 串供 这会让会上省很多时间和精力 正所谓 要想让会议不流于形式 就要把会议本身变成走走形式 所有事情 尽量在会上取得共识 给出 会议决议 实在不行的可以作为 遗留问题 最后 牢记很实用的 所有人提供意见 少数人讨论 一个人拍板 的民主集中原则 靠谱的会议 回顾截至到上次会议结束时的信息1 上次会议讨论的重点问题是什么 2 关于这些问题我们达成了哪些一致意见 3 上次会议中哪些问题由于缺乏信息考证 不确定性因素等原因而未能解决 4 上次会议哪些执行计划被通过了 对于这些执行计划我们有哪些主要想法和设想 持续的战略规划会 面对回顾信息 今天的重中之重8 我们今天讨论的重点是什么 9 你们提议