产品需求

凡事“预则立，不预则费”。即使你有丰富的产品经验，在面试那种紧张的环境下要面试好也不是一件易事，因为在那种环境下，你要对面试官提出的问题快速反映，快速组织语言，而你又没有经常训练这种能力，想回答好还是很不容易的，如果你经常背一些产品经理的面试题，那你回答的时候就流畅多了，下面将一些常见的产品经理面试题整理下来，需要的小伙伴拿去。 下面我们先看看都有什么问题吧 以下是上面的问题的具体解析，可能不全面，欢迎大家补充 1、介绍一下你自己 介绍一下自己的姓名，年龄、毕业院校，工作经历。简单的介绍，保持在三分钟以内，给面试官问问题的时间。 工作经历主要讲一些你牛逼的工作经历，例如：你加入XX公司以后，销售额增加了多少、用户翻了多少倍…这样一些。有些人工作经历比较多，3年跳了好几家公司，建议你合并一下，不然面试官会觉得你这个人没有定力，在其他家公司干的时间都不长，在我公司能干多久？ 至于你的毕业院校牛逼的肯定要说出来，如果觉得学校不好，不好意思说那就不说吧。 总的原则就是扬长避短，把自己的经历简单介绍下，然后留给面试官发问的时间。 2、做过的项目有哪些，简单的介绍一下 主要想考察你做的项目有哪些，以及你在项目中的贡献，你可以说说你做的项目流程，你在项目中的角色，你的项目周期是多久，你的项目解决了什么问题，你的项目给你们的产品带来那些改变？例如：用户增加了，留存率提高了多少等

项目交接小总结 稿源：wangxuntian.com ** 撤稿纠错 最近被项目交接的事搞得很焦躁，总也完不了的感觉。影响现在的工作进度不说，还弄得老大颇为不满，以为我藏着掖着不愿意讲，委屈又窝火。希望能总结一下，以后改进，也希望众人多提议，让我赶紧脱离这个苦海。 简单分成了文档&业务逻辑两个部分： 文档已能涵盖几乎所有的内容，但因数量较多且层次不分明，往往需要花费大量的时间阅读，对新接手的人来说，是了解项目最全面最精细也是最慢的方式。所以，为了交接的效率，会辅以会议和串讲，说明核心逻辑和业务需求，还有各方联系人。也会安排答疑，保证项目的平稳过渡。 别看我说得头头是道，做起来完全是疯掉了…… 首先，文档不全，除了提交并评审过的版本，其他的严重残缺，还有些项目做了升级文档却没空update 。另外，各类文档的版本号命名规则不同，很难有序的组织起来。想了想，就按照时间顺序，弄了个 文档版本历史 ，简要说明了功能点。 这部分主要靠个人习惯，有没有定期整理，是否坚持更新，有没有发在wiki或者组内的工作平台中共享。 总之秉承着“有什么就发什么，捡重要的发”这个原则就行。 然后是业务逻辑，“业务”这个词的概念太宽泛，几乎产品的各个方面都能纳进去，内容有以下几点： \1. 基本模型、基本结构、基本流程（各种模型&流程图） \2. 已上线的功能 \3. 需求方 \4. 需求汇总、分析 \5.

1 背景概述 在软件行业飞速发展的今天，我们可以将软件公司分大体分为两类，一类是使用框架进行开发的软件公司，另一类是套装软件产品的提供商，前者公司多数定位是项目类公司，后者则可以称为产品类公司。但做产品与做项目有哪些区别，大多数的人面对这个问题还是较为模糊的，甚至简单认为两者是没有区别的，均是程序开发而已。但事实并非如此，做产品与做项目两者之间既存在本质的区别，也存在着紧密的联系，今天笔者在这里将自己理解与大家分享。 2 定义及周期 2.1 项目定义 项目： 是指在一定的约束条件下（主要是限定时间、限定资源），具有明确目标的工作任务。 软件项目： 是指为企业开发或者部署实施一套专用的系统，或在特定的行业领域做一些系统之间的集成，在进入项目之前必须与用户进行具体的交流和讨论，了解清楚用户心目中的产品或项目预期是什么样子，然后招投标、签订合同、实施交付。 2.2 项目周期 软件项目的生命周期是软件的产生直到报废的过程，包括项目的启动、需求调研、功能设计、业务开发、项目测试、项目验收交付给用户，项目结项后项目生存周期结束。随着时间的推移以及发展，为满足当前发展的需求项目通常会重新定义开发。软件项目的生命周期图如下： 2.3 产品定义 产品： 是指能够提供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。 软件产品：

软件 软件是计算机系统中与硬件相互依存的部分，它是包括程序、数据及相关文档的完整集合。 软件危机 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 软件工程 软件工程是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。 软件生存周期 软件生存周期是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程，一般包括计划、分析、设计、实现、测试、集成、交付、维护等阶段。 软件复用 软件复用就是利用某些已开发的、对建立新系统有用的软件元素来生成新的软件系统。 质量 质量是产品或服务满足明确或隐含需求能力的特性和特征的集合。在合同环境下，需求是明确的；在其他环境下，隐含的需求需要识别和定义。 质量策划 质量策划包括产品策划、管理和作业策划，以及质量计划的编制和质量改进的准备工作。 质量改进 质量改进是以最求最高的效益和效率为目标的持续性活动。 质量控制 质量控制是对流程和产品的符合性的评估，独立分析不足并予以更正使得产品与需求相符。 质量保证 质量保证是有计划的和系统性的活动，它对部件或产品满足确定的技术需求提供足够的信心。 软件质量 软件质量是指明确声明的功能和性能需求、明确文档化的开发标准、以及专业人员开发的软件所具有的所有隐含特征都得到满足。 正式技术复审

在使用脑图进行用例设计的实践中，首先需要先出来两个中心： “需求分析”和“模块用例分析” 。 对于明确需求，主要参考指标总结如下几点： 软件开发合同 项目开发计划 系统/子系统设计文档 软件需求规格说明书（含接口需求规格说明） 用户需求说明书 软件设计说明 对于 继承需求 ，主要是该项目或产品的上游内容已有需求或指标，而这一块儿往往是最容易忽略的地方，所以单独拿出来统计分析。正如在做该项目之前，已经有过一个版本存在，并经过了大量的测试与实践，也进行了各种修改以及需求的完善，那么在设计本项目需求分析属性时，就应该继承上一版本的可用需求或指标，避免只是针对本项目的明确需求分析不到位，导致项目质量不过关。 所以，对于继承需求的参考指标，总结如下几点： 相关产品或上一版本的软件需求说明书 相关产品或上一版本的测试需求或测试报告 相关产品或上一版本在使用过程中遇到并且需要解决的问题汇总 隐含需求 的指标需要十分有经验的测试设计人员的思考，要对项目或产品非常熟悉，甚至对该产品所属行业清晰明了。 主要的参考内容如： 有关产品使用场景的梳理数据 该产品相关的行业标准 非专业人士不清楚的特性指标（如六性要求、稳定性要求） 安装性测试与易安装性方面的质量子特性（可移植性）相对应。 安装性测试有两个目的： 第一个目的是确保该软件在正常情况和异常情况的不同条件下可以正常安装: 例如，进行首次安装、升级

问题 “一云多端”成为趋势，终端类型越来越多。比如，现在PC Web网站的产品已经有了，现在想扩展APP，小 程序... ...怎么办？一个直接能想到的方法就是在原来的基础上，为APP等增加API接口，如下图所示： image.png image.png 这样做是可以的，然而一旦遇到修改，那么要同时修改几个端的代码，很麻烦，不是很完美。 “前后端分离”成为趋势。一开始的PC Web网站，大多是采用服务端渲染的前后端一体化的模式。随着技术的发展，前后端分离，前端渲染逐渐成为趋势。相应地，前端开发人员也从后端团队中独立出来。 最近兴起的APP，小程序等，天生就是前后端分离的。 前端，APP，小程序等各自独立成专门的团队，当然可以满足这种趋势。 相应地服务端需要为每一个前端部门提供服务，在实践中常常发现，重复的内容很多，有没有办法增加复用？或者说后端能否只对接一个“大前端”部门，剩下的“大前端”部门内部自己解决？ image.png 服务端设计的API接口，面向通用服务，还是面向UI？各个端对数据的显示要求不同，给一个公共的API还是分别给不同的API？ 比如，时间显示，PC端可能要求“2018-6-11”的格式，而APP端可能要求“2018/6/11”的格式，接口怎么给？ 再比如，相同功能的一个接口，PC Web端需要20个字段，已经做好了。现在APP端因为屏幕小，只要10个字段就够了

title: 敏捷软件需求管理 date: 2017-10-23 10:29:39 tags: 需求管理 严格的来讲，这个标题的说法并不是很严肃，这篇文章的目的不是建立一个敏捷软件需求管理的流程，而是去探索一种需求管理的实践，解决现在工作中遇到的困惑和困难。为了将问题解释的更清楚，我需要先从流程定义说起。 流程定义  上面这个图是一个典型的IPD（集成产品开发）流程图，从大的视角来看，这就是一个典型的瀑布模型，需要有前一个阶段的成果作为后一阶段的输入，后一阶段的工作才能开展，这样当然没有错，不过有时候会显得低效和无法满足项目的需求。 同样，我也拿出我们研发层的各阶段的定义，进而进一步探讨。  从图和表中点后可以看到，需求分析集中在项目的前期的阶段，理所当然，需求就要作为后续工作的输入，因此需求很重要，这都知道，所以在图中也设置了需求的技术评审，但需求的技术评审并不能保证全部的质量。 总结来说，需求很重要，但需求又大多数集中于前端部分，不好管控，怎么保证需求高质量的分析，发现和实现都是比较困难的事情。 需求层次 产品开发规程中，对需求层次的定义是： op=>operation: 用户需求 op1=>operation: 产品需求 op2=>operation: 软件（子系统）需求 op(right)->op1(right)->op2 用户需求是顶层需求，直接反应用户的需要

引言 笔者 2012 年做为敏捷教练入职百度，到 2018 年年底一直做为敏捷教练，在百度内部进行敏捷开发的推广，DevOps 实施工作。在工作过程中，我被频繁的问到以下几个问题: 敏捷/DevOps 教练是做什么的？你能帮我写代码/带项目/做测试么？ 你看我产品线的现状，适合做 DevOps/敏捷转型么？ 我的产品线做了敏捷/DevOps/精益，到底能带来什么收益？ 回到具体的实施，我们应该从哪里开始着手？ 相信这些问题也是很多企业的 IT 主管，DevOps 推动者想问的问题。今天我就根据我自己的工作经历来为大家分享一下我的理解和实践: I.什么是敏捷教练？在百度做敏捷教练是种什么体验？ 对于敏捷教练，好像很难有一个统一的定义。引用 CIO.COM 上一位博主的原话: "Agile coaches help train corporate teams on the agile methodology and oversee the development of agile teams to ensure effective outcomes for the organization. They are responsible for guiding teams through the implementation process and are tasked with

敏捷软件开发与传统软件开发的对比 最早了解敏捷开发是通过大二的一次博雅课堂，一位在百度工作的北航学长跟我们分享了他近年来从事敏捷开发的经历。印象最深的一句话是一个延迟3个月交付100%功能的软件和一个按时交付75%核心功能的软件，敏捷软件开发者更愿意选择后者。本学期的软件工程基础课又向我们讲授了传统软件开发，经过课上和课后的学习，对于敏捷软件开发和传统软件开发有了浅显的认识和理解。由于课上学习的重点是传统软件开发，所以课下对敏捷软件开发进行了更多的涉猎，本文以敏捷软件开发为主体，来分析其与传统软件开发的对比。 敏捷软件开发与传统开发方法相比具有很大的不同，其特点是适应性而不是预测性，强调沟通和反馈，开发团队不仅包括开发人员，还包括管理人员和客户。它鼓励团队成员的相互交流通过反馈机制尽早纠正软件中的错误，提高开发效率，同时为需求的调整提供更多机会，保证软件向正确的方向发展。 传统软件开发如瀑布模型强调预见性，严格遵循计划、分析、设计、编码、测试和维护等几个阶段。瀑布模型开发各阶段间具有严格的顺序性和依赖性，必须等到前一阶段的工作结束后才能开始下一阶段的工作，前一阶段的输出文档是后一阶段的输入文档，只有前一阶段的输出文档完全正确，后一阶段才能获得正确的结果。 对敏捷联盟宣言的理解 1.个体和交互胜过过程和工具，强调软件开发必须发挥人的积极性和创造性，更看重人的沟通和团队的力量； 2

讲师：360可视门铃产品负责人 100多年前，福特公司的创始人亨利·福特先生到处跑去问客户：“您需要一个什么样的更好的交通工具？”几乎所有人的答案都是：“我要一匹更快的马”。很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。 福特：“你为什么需要一匹更快的马？” 客户：“因为可以跑得更快！” 福特：“你为什么需要跑得更快？” 客户：“因为这样我就可以更早的到达目的地。” 福特：“所以，你要一匹更快的马的真正用意是？” 客户：“用更短的时间、更快地到达目的地！” 于是，福特并没有往马场跑去，而是选择了制造汽车去满足客户的需求。 2005年，贝恩咨询为362家企业所做的一项调查中，有95%的企业认为自己关注了客户，80%的企业认为自己向客户提供了优秀的体验。而在这些被调查的企业的客户中，只有8%的客户这样认为。为什么产生如此大的反差？时隔六年，这样的尴尬局面依然没有得到解决 1、每个产品都需要有一个豪华需求池 编号、需求名称、需求类型、需求状态、需求提出时间、需求部门、需求背景概述、需求目标、业务逻辑、期望上线时间、优先级、产品负责人 2、需求收集 内部： 外部： 3、需求分析 短期目标： 连问6个为什么？ 工具1-典型用户场景上板 6W2H用户用这个的目的是什么？在什么时间用这个？什么场景下用这个？具体的操作时什么