【题记】作为一只“冠冕堂皇”的产品狗，总是少不了在各种情形下（包括，拉出业务主流程就行、2个小时之内、不考虑技术实现等等）被要求产出各种规格、版本、形式的需求文档，那么也就少不了将文档提交给业务的上下游环节，或者在各种正式和非正式的场合进行各种名目的评审，那么也就免不了担心就着需求被人指指点点，在众人面前因为各种小细节的遗漏、逻辑的模糊被挑战。虽然，在考虑问题的时候难免在细节上可能会出现遗漏，这也是需求评审的重要意义之一，但是，对于自己需求的自我检查，能够更好地家加强自己的信心，也能够在业务上下游环节树立自己更美好、更专业的产品狗形象。
事实上，每次在需求提交前进行一次需求文档的梳理有助于自己对于需求整体和细节的把握，能够在一定程度上通过情景再造详实需求细节，也便于加强自己对于需求的熟悉程度，以在需求评审时能够快速、敏锐的阐述自己产品设计的出发点和对于业务实现及客户体验的考量。那么，问题来了——需求检查从何做起，要怎么开始？
【其实，方法很简单】进行需求检查的方法，实际上和我们在进行产品设计的方法是一致的，即“可用性”检查的方法，也就是通过设定：用户在特定条件下完成指定任务。从这个角度来解释需求文档，就是，用户在特定条件下完成指定任务的实现指南；继续延伸下来，对于需求文档的检查，就是对于用户、特定条件和指定任务的逐层分解后进行业务流程的演进，进而通过任务完成的过程检查各节点在需求中的映射，发现逻辑遗漏或者流程细节中的缺失。
【示例】以我们常见和经常使用的移动购物APP为例，在完成主要的业务流程和结构功能的构建之后，在进行需求检查时，对用户、特定条件和指定任务进行逐层的拆解，我们可以得到以下内容：
用 户： 按照用户类型进行拆解得到：游客、注册用户、第三方账户登录用户
按照用户级别进行拆解得到：普通用户、VIP用户
按照用户角色进行拆解得到：操作用户、管理员用户
按照用户状态进行拆解得到：新建用户、历史用户
特定条件： 按照登录状态进行拆解得到：登录状态、未登录状态
按照网络状态进行拆解得到：在线状态（WI-FI、3G）、离线状态
按照数据状态进行拆解得到：空白状态、存量历史数据状态（A/B，一条/多条）
按照预设条件是否满足进行拆解：满足状态（条件1/2）、不满足状态（原因1/2）
指定任务：指定任务按照业务流程的节点进行拆解和定义。
各个流程节点的任务都可以归结为“表单记录”式操作：增、删、改、查
按照指定任务为查看商品详情进行拆解得到：查看新商品、查看购物车/订单商品
按照指定任务为收藏商品进行拆解得到：收藏新商品、二次收藏商品
以上拆解并非是完整展示，而且在拆解之后所要进行的更为重要的步骤是交叉组合，将拆解得到的内容组合后还原成”可用性“检查的内容模式：不同的用户在不同的特定条件下完成不同指定任务的实现指南。只要通过逐层的拆解和组合，就能够在构建完成的主业务流程需求的主干上，不断的细化、丰富、完善需求内容。随着拆分的细致程度的不断提升，检查的深入程度也会不断的加深，相应的需求的质量也会得到不断的强化，也将实现我们之前所讨论的目的：一步到位，拒绝别人对你的需求说三道四。
网友评论