TD_博伟的博客

文章目录前言题目总结总结前言下边总结一些产品经理的面试题，和一些专业题。有的问题需要针对自己情况回答，有的涉及到专业知识，我将会附带参考答案，所有答案不唯一，如有问题可留言讨论。提示：后续还会不断的更新题目总结产品需求文档组成模块包括：版本信息，产品概述，功能需求，非功能需求。介绍自己（扬长避短）做过的项目，介绍下（扬长避短，尽量不要把自己带进沟里，一定要提前准备）你觉得产品经理应该具备哪些能力？• 编辑能力• 沟通能力• 文档能力• 学习能力• 项目管理能力和自我管理能力

系列文章目录上一篇 “Scrum与用户故事”如有问题请留言文章目录系列文章目录前言文章概览1. 处理非功能性需求2. 纸质还是软件3. 用户故事和用户界面4. 保留故事5. 缺陷的用户故事Finish前言讨论一些其他话题处理非功能性需求。团队应该使用纸质笔记卡还是软件工具。用户故事在用户界面方面的影响。在开发完成后，是否应该保留用户故事。缺陷报表和故事之间的关系。文章概览1. 处理非功能性需求常见的非功能性需求：性能准确性可移植性可重用性可维护性互

系列文章上一篇 “用户故事不良症兆一览”如有问题请留言文章目录系列文章前言文章概览1. Scrum是迭代和递增的2. Scrum基础3. Scrum 团队4. 产品 Backlog5. Sprint 计划会议6. Sprint 评审会议7. 每日Scrum 简会8. 在Scrum 中使用用户故事Finish前言如何把用户故事和另一种敏捷过程Scrum结合在一起？文章概览1. Scrum是迭代和递增的一轮迭代是一种持续改进的过程。例如：雕刻家会首先选择一块石头，画出大体轮廓

系列文章目录上一篇 “用户故事的优势”如有问题请留言文章目录系列文章目录前言文章概览1. 故事太小2. 故事互相依赖3. 镀金4. 细节太多5. 过早考虑用户界面细节6. 想的太远7. 故事划分太过频繁8. 客户很难为故事安排优先级9. 客户不愿意写故事，也不愿意为故事安排优先级。Finish前言故事的不良征兆预示着项目可能出现了一些问题。提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。文章概览1. 故事太小症状：经常调整估算2.

系列文章上一篇 “故事不是什么”如有问题请留言文章目录系列文章前言文章概览1. 口头沟通2. 用户故事更容易理解3. 用户故事的大小适合做计划4. 用户故事适合于迭代开发5. 用户故事鼓励延迟细节6. 用户故事支持随机应变的开发7. 用户故事鼓励参与性设计8. 用户故事传播隐性知识9. 用户故事的不足Finish前言用户故事带来的好处：• 用户故事强调口头沟通• 人人都可以理解用户故事• 用户故事的大小适合做计划• 用户故事适合迭代开发• 用户故事鼓励延迟细节• 用户故事支持随机

系列文章上一篇 “测量并测控速率”如有问题请留言文章目录系列文章前言文章概览1. 用户故事不是IEEE 8302. 用户故事不是用例3. 用户故事不是场景Finish前言为了更深入的了解用户故事，接下来了解下用户故事不是什么。如何区分用例，IEEE830软件需求规格和交互设计场景。提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。文章概览1. 用户故事不是IEEE 830IEEE 830 涵盖了如何整理需求规则文档，角色原型和良好需求的

系列文章上一篇 “迭代计划”如有问题请留言文章目录系列文章前言文章概览1. 测量速率2. 计划速率和实际速率3. 迭代燃尽图4. 迭代中的燃尽图Finish前言前言：我们将项目分解成一系列的迭代来做发布计划，每轮迭代中安排一定的故事点任务。一轮迭代完成的故事点就是迭代速率。为这个项目做计划时我们可以用已知的速率。速率非常重要，所以监控速率就变得同样重要。提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。文章概览1. 测量速率一轮迭代完成

系列文章目录上一篇 “发布计划”如有问题请留言文章目录系列文章目录前言文章概览1. 讨论故事2. 分解任务的原因3. 承担指责4. 估算并确认Finish前言利用发布计划，我们顺利地将粗粒度的故事分配到发布中的多轮迭代。迭代计划会议内容一般会包含以下几点：• 讨论故事• 从故事中分解出任务• 开发人员承担每个任务职责• 开发人员单独估计各自的任务提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。文章概览1. 讨论故事团队获得一

系列文章上一篇 “估算用户故事”如有问题请留言文章目录系列文章前言文章概览1. 我们想在什么时候发布？2. 希望在发布中包含哪些功能？3. 排列故事优先级4. 混合优先级5. 高风险故事6. 根据架构需要安排优先级7. 选择迭代长度8. 从故事点到预计工期9. 初始速率10. 创建发布计划Finish前言大部分软件项目都会有一个比较固定的发布周期，某些网站项目可能会很频繁。因此搜集新功能放到一个发布中是很好的。产品开发路线图可以帮助展示未来几个新发布中关注的重点。产品开发路线图可以很简单，可

系列文章目录上一篇 “优秀用户故事准则”如有问题请留言文章目录系列文章目录前言文章概览1. 故事点估算2. 以团队估算3. 估算4. 使用故事点5. 如果使用结对编程6. 使用故事点的一些提醒Finish前言没有一个项目会在启动很久之后才问“什么时候能完成？”估算故事最好的方法有如下特点：无论什么时候获得有关故事的新信息，都允许我们改变之前的想法适用于史诗故事和小故事不需要花很多时间提供进度和剩余工作的有用信息不太精确的估算也不会有太大问题可以用来制定发布计划提示：接下

系列文章 上一篇 用户故事验收测试如有问题请留言文章目录系列文章前言文章概览1. 从目标故事开始2. 切蛋糕3. 编写封闭的故事4. 不要过早的涉及用户界面5. 有些需求并不是故事6. 在故事里包括用户角色7. 只为一个用户编写8. 以主动语态编写9. 不要对故事卡进行编号10. 不要忘记意图总结前言了解了这么多的基础知识，接下来是一些额外的编写优秀故事的准则。提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。文章概览1. 从目标故事开始

如有问题请留言文章目录前言文章概览1. 测试是一个两步流程2. 写代码之前写测试3. 客户定义测试4. 测试是过程的一部分5. 多少测试才算多6. 测试类型（测试的是缺陷而不是覆盖率）总结前言写验收测试的好处有很多，其中之一就是很多客户和开发人员讨论的很多细节可以通过验收测试记录下来。接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。文章概览1. 测试是一个两步流程 a. 第一，将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录下来。

如有问题请留言文章目录前言文章概览1. 用户经理2. 开发经理3. 销售人员4. 领域专家5. 市场营销团队6. 以前用户7. 客户8. 培训师和技术支持9. 业务分析师和系统分析师10. 自己来可以吗？11. 设立客户团队总结前言对于一个项目来说，如果客户团队包含了一个或多个用户是非常好的。但是实际情况是客户团队很难包含用户。这时候我们就需要用户代理了。他们可能不是实际用户，但是这些人可以在项目里代替用户。提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜

如有错误或问题请留言文章目录前言文章概览1. 方法2. 画原型的过程中总结前言这篇文章将会记录如何与用户一起工作，如何通过沟通来发现故事。传统的需求收集方式要求在项目早期正确获取并写出所有需求。而敏捷项目则认为没有理想的方法能够在一个单一的阶段获取所有的用户故事。接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。文章概览1. 方法 a. 用户访谈 i. 这是许多团队使用的一种默认方法，这种方法的关键在于正确的访谈者。 ii. 而且只问客户需要

如有错误或问题请留言文章目录前言文章概览1. 用户角色2. 角色建模的步骤3. 额外的技术4. 如果有真实的用户在讨论现场，那么用户角色建模依然是必要步骤。总结前言以用户为中心的设计和交互设计的规则使我们懂得，在编写前识别用户角色和虚构人物有很多好处。这篇文章记录了用户角色，角色建模，角色映射和虚构人物并学习用这些条件编写更好的故事。接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。文章概览1. 用户角色 a. 首先要明白用户角色并不是一个具体的用

提示：如有问题或错误请留言文章目录前言文章概览1. 一个优秀的故事2. 独立的3. 可讨论的4. 对用户或客户有价值的5. 可估计的6. 小的故事7. 分割故事8. 合并故事9. 可测试的，故事必须是可测试的总结前言前面提到了故事，那么什么是故事，又该如何使用和编写呢？编写故事又该注意哪些问题呢？这篇笔记将记录这些要点。接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。文章概览1. 一个优秀的故事应该包含以下特点（《探索极限编程》和《重构手册》的作者

提示：文章如有错误请留言文章目录前言一、概览1. 什么是用户故事？2. 细节在哪里？3. 必须多长时间完成？4. 客户团队5. 使用故事的过程6. 规划发布和迭代7. 什么是验收8. 用户故事的优点总结前言《用户故事与敏捷方法》这一书初读之下感觉给了我不少的启发，为此记录下我学到的知识点。下边让我用书中一个有意思的例子开始我的文章：一个三岁小孩子，她用脚趾头试了下水温，并告诉父亲：“水要暖点”。父亲把手放入水中，惊奇的发现水并不冷，水已经比她女儿习惯的水温更热了。父亲思考了一下女儿的要求，发现他

提示：主要记录产品经理常用的名词和缩写文章目录前言一、产品经理常用的方法1.竞品分析常用方法：二、常用术语（不分 toB 和 toC）1.投资回报率（Return On Investment，ROI）3.跳失率4.跳出率5.页面浏览量（PV）6.DNU（Daily New Users）7.AU（Active Users）8.PU ( Paying User）9.APA（Active Payment Account）10.ARPU(Average Revenue Per User)11.ARPPU (Av