做好需求工作的思考

 

      互联网产品发展迅速，不断更新换代，为了提升市场竞争力，我们需要具备快速响应产品需求、加快产品上线时间的能力。需求阶段工作质量对于项目的进程有着至关重要的作用，一方面需求阶段处在整个项目流程前期，如果需求工作做的不到位则会影响后续工作的进行，从而导致成本急剧增长和风险不确定提高；另一方面需求阶段参与的人员来自不同部门，从事不同工作职位，沟通成本大大增加。

 

         整个需求过程可以分为两块内容，分别是需求开发和需求管理。需求开发包括了需求获取、分析、编写文档和验证需求是否符合用户期望。需求管理主要包括变更控制、版本控制、需求跟踪和状态跟踪。

   

         这幅图示意了需求过程在项目中的位置（此处忽略测试阶段），需求分析主要处在项目的前期，而需求管理从项目立项一开始就进行，贯穿于整个项目，甚至在项目结束以后还需要进行需求管理工作。需求工作的重要性我们心知肚明，在过去的工作中也时常受其困扰，偶尔也深受其害，因为需求的模糊性、不确定性、易变化性使得需求工作难度加大。接下来将介绍需求过程中的一些可适用的方法，在日常中改进工作方式，提高工作效率和效果。

         需求获取是项目的第一步，也是非常关键的一环。

  

在互联网，业务方一般指销售、运营等最接近用户和市场的工作人员，他们最了解用户的需求，也是用户反馈问题的第一接手人，所以他们的需求代表着用户，但是一般都处于凌乱状态，不成体系。产品经理同样关注市场动态和产品发展趋势，接手业务方需求，对这些信息和需求进行统一处理，根据用户的需求和公司战略定位形成产品概念，产出PRD(Product Requirement Document 产品需求文档)。

 

实际上，此时的产品需求并不能直接用于开发，很多需求还不清晰，也不完整，可行性也不确定，只是定义了产品的大致模型，它告诉团队产品是用来做什么的，达到的商业目标是什么，但并没有涉及如何做。开发团队需要从事需求分析角色的人员参与到需求细化及可行性分析中。

 

与一般软件行业产品不同，因为需求已经经过业务方和产品经理过滤了，而且产品经理了解产品原理和技术，所以沟通起来没有那么费劲，一般采用开会的方式开始需求和确认需求，在这个过程中间非正式的需求沟通是最有效的，就是几个需求相关人比如业务方、产品经理和开发需分角色，在电脑前把关注到的问题点和建议，不断地讨论、求证，反复循环多次，最后确定当前项目的需求范围和优先级。

 

   

需求分析在需求阶段是重中之中，参与人员主要是开发团队需分角色人员（Requirement analysis RA），产品经理协助需求业务合理性，开发人员协助分析需求可行性。需求分析人员应该具备“五大力”，分别是沟通力、业务理解力、技术理解力、方案创新力和需求管理力。

 

沟通力是成功的基础，也是需求过程的核心能力。沟通力不能只简单地理解为能说会道，而是包括了肢体语言、心理、逻辑思维等软实力和技术理解力、业务理解力等硬实力，这些能力可以有效地帮助提高沟通效率和效果，只有具备了一定的业务、技术方面的实力，才有足够的条件寻找合适的方法和手段引导业务方清楚完整地描述需求内容，设计方案也具有更多的创造力，这是沟通的实质。对于一名需求分析人员来说，技术理解力和业务理解力往往是互相矛盾的，但两者相比较，业务理解力更重要，因为对业务理解地更深刻，对“创造用户价值”的理解把握地更精准。

 

在正确地理解业务之后，业务方与开发团队对于需求的大范围不会有太多的异议，更多争论的地方是一些小细节，而这些小细节往往容易造成项目进度推进停滞，甚至会导致不同团队之间矛盾的产生。业务的方向、产品的创意是无极限的，但是公司的资源、时间是有限的，在有限地资源、时间创造出更多有价值的业务产品才是项目团队所要一起努力的。那么在众多的各种需求中，我们必须做出选择，将所有需求功能点整理完成，并做必要地分析之后，对需求进行优先级排列。确定优先级可以考虑使用KANO模型的思想。

 

KANO模型定义了三个层次：基本型需求、期望型需求和兴奋型需求，这三类需求根据绩效指标分别对应为基本因素、绩效因素和激励因素。

• 基本型需求：业务方认为产品”必须有”的功能。但其功能不够强大时，业务方（代表着用户）就会不满意，抱怨产品的不足；但其功能够强大满足用户需求时，用户无所谓满意或者不满意，即不会抱怨产品。
  
  
• 期望性需求：这些需求功能看起来不是“必须”的，但用户是想要使用的。一个产品有更多的这种需求实现，那么用户就会越满意，否则顾客就不会对产品产生好感，充其量跟一般产品类似，则产品不具备足够的竞争力。
  
  
• 兴奋型需求：提供给用户一些完全出于意料的功能或服务，顾客将产生惊喜。用户对产品是否有此类需求并不在意，事实上也不清楚，如果这些功能能够帮助到用户使用，可以大大提高用户对产品的好感，如果这些功能影响了其他功能的使用，那么效果将适得其反。
  
  

这个模型在实际工作中划分需求优先级时可以作为参考，但具体还需要依靠业务、产品、技术的把握程度和经验。在实际工作中，尽管定义了需求优先级，但并不代表不实现，只有极少数需求推迟到二期或者项目发布之后，在开发正式介入之前，产品经理和开发往往在时间和资源上矛盾，产品经理在需求未搞明白之前就希望产品尽快上线，开发往往受困于需求实现方式、代码质量、资源有限等问题，无法完全满足产品经理的所有需求。这中间的博弈是很复杂的，个人认为要看个人的魅力、资历、经历，以及对产品需求、技术架构的熟知程度，才能够判断出正确的决定。一般情况下开发团队首先做出妥协，因为“给用户创造价值”最终会得到胜利，所以开发团队需要承担着各种风险高强度的工作。

         需求的验证是对上述工作的反馈和确认，一般只有需求工作的产出物PRD得到各方认可后，才会进入下一个工作步骤，即开发阶段，所以需求验证是必不可少的工作之一。在实际工作中，应用最为广泛的验证方式是需求评审和页面原型确认，这两者各有优势和适用的场景，有些产品需求会将两者结合一起适用。

 

         需求评审是必不可少的一个环节，参与人员包括了产品经理、需求分析人员、项目经理、开发技术人员、测试人员，业务方可选。需求评审是以会议的形式进行，根据经验，产品经理在评审前一到两天时间将PRD发送给相关人员，允许这些人员先较好的了解下需求内容，特别是开发和测试同学，因为他们是产品的实现者，前期又没有参与需求的讨论之中，所以这点是比较重要的，否则将会影响评审效果，进而影响后续开发、测试之间的需求讨论。

 

         此时PRD是需求的基线，开发工作量、项目范围都是以此为准，需求管理工作开始占据重要地位。通过需求管理的变更控制、跟踪可以有效地把握项目实施过程中紧紧围绕当初的产品目标，以避免需求的过分变更或扩大范围，使得项目进度和范围不可控。

 

         需求过程是产品项目非常复杂的一个阶段，必须将理论知识结合实际工作不断地磨练和摸索，以此不断地增加经验值，才能够做好产品需求分析的工作，结合自身工作写下这些记录，让我们工程师更能够从容面对需求，同时期望自己能够在以后的工作中会有所帮助，感悟更深。

 

参考资料

KANO模型：http://wiki.mbalib.com/wiki/KANO%E6%A8%A1%E5%9E%8B

 

文章引用：http://qxyqqxyq.blog.163.com/blog/static/12980220720115284244157/