管理好产品的需求.docVIP

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