(产品管理)管理好产品的需求.pdfVIP

（产品管理）管理好产品的 需求 管理好产品的需求 最近的壹系列事情开始教育我，如果不能做好需求管理的工作，产品人员疲于应付不断变化 的需求，导致无法正常开展产品的设计和管理工作。结果就是交付给开发人员的需求文档不 断变动，开发人员也不知道自己究竟该做什么，项目进度越拖越慢。最后到了规定好的交付 时间，因为拿不出需要的产出物，部门之间开始互相推诿、埋怨。 思考良久，需求的变动固然是造成这种结果的主要原因，另壹个不能忽视的因素则是需求没 有表述清楚，开发人员面对表述模糊的需求文档，更加无法完成既定的开发工作。 如何表述清楚需求 ?我们需要尽可能做好俩件事情： 1. 完整建立产品的 usercase; 2. 于需求文档中力争做到明确、完整、壹致和可测试四点。那么对于产品、开发的工作影响 就能降到最小，你的项目也越能于规定的时间内完成。 如何建立产品的 UserCaseDiagram UserCaseDiagram 也叫用例图，基于面向对象的思想和用户视角来设计。如下图就是壹种 非常简单的用例图，它有点类似创建产品的用户角色，你需要能从使用的角度描述出用户是 如何壹步步操作这个产品的。 用例这种通过讲故事来把需求描述清楚的办法很有点黑盒的概念，很容易被用户和开发者理 解 ;但缺陷于于无法描述清楚该如何实现， 也很少涉及内部的信息。 壹旦我们遇到无法理解产 品实现机制或者内部流程架构的情况时，就必须借助其他的方法来理解需求，这个过程能够 理解为打开黑盒。 这样通过不断地观察黑盒， 打开黑盒、 分析黑盒， 然后再打开黑盒的过程， 我们就能做到对整个产品的需求有比较准确的把握。互联网的壹些事 用例图就是这样壹种能帮助我们了解需求的方式，当然如果指望让程序员见完了用例图就能 把程序做出来，那是相当地扯淡…… 因为用例图本身只是用来阐述用户的需求，很难准确对产品的功能、架构赋予严谨的描述和 定义。因此，我们仍需要另外壹份交付物，来清楚表达产品的功能、流程和架构，比如说产 品需求文档。 产品需求文档应有的几个基本要素： 对应的产品不同，需求的标准也不尽相同，不过有壹些通用的要素，仍然是能够借鉴的： 明确： 很多撰写需求文档的人且没有学习过形式化语言，因此我们见到的需求文档很多均是 采用自然语言写出来的。这对需求分析带来的最大弊病就是它的二义性。因此需要我们对文 档的表述进行壹些限制，例如尽可能只用主谓宾的基本表达方式，避免修饰句，避免容易令 人产生误解的表达方式。 比如我们是做壹个社保卡系统，你能够这样描述需求：每张公交 IC 卡只能属于壹个用户， 社保卡有卡号和金额数。社保卡能够于医院使用，能够用来支付医药费。 完整： 既不要于提需求时说仍有壹些需求没有确认，也不要开发接近完成了提出来有壹些需 求遗漏了。需求的不完整是导致开发返工的最直接因素，也是令人发指的行为。 需求的完整需要产品人员有很好的产品管理技能，也需要对已有产品的架构有清晰的了解， 很多时候产品人员面对的均是拍脑袋或者临时决定提出来的需求，很难第壹时间提炼出完整 的需求，怎么办 ? 问! 问自己，问客户，问开发。于你无法确认出完整需求或者起码的核心需 求之前，任何交付给开发的行为注定是不负责任的。互联网的壹些事 壹致： 需求简单来说能够分成业务需求、用户需求和开发需求三个方面。用户需求需要能和 业务需求壹致，开发需求需要能和用户需求壹致，这且不是于说废话，而是三种需求之间的 继承关系。 否则， 辛苦开发出来的东西很可能会偏离当初的实现目标。 于具象的实现过程中， 这种壹致性也必须细化。往往用户需求于整个过程中不断变化，产生所谓的”需求变动” ， 这种变化不应该超出先前既定的范围，至少不应该超出最初的业务目标。 可测试： 很多人认为项目、产品的测试应该从写完代码输出测试产品时开始算起或者说开发 们于写代码的时候就该开始履行测试的职责了，这样理解有它的道理。但实际上，和完整性 的要求壹样，测试的过程应该从需求壹开始分析的时候就要开始。 作为测试的输入输入和参照物，需求分析应该是可测试的。比如我们说“设计壹个网站，能 让用户第壹时间了解车票的行情” 。这个需求是可测试的么