研发的需求管理,从前到后有五个步骤,分别是需求的搜集、分析、分配、实现和验证,其框架如图3-2所示。
企业研发的前端流程,除了进行市场分析、细分和战略定位外,实际上还包括搜集市场需求和客户需求,并对各种需求进行分析和分配,形成产品规划。事实上,前端流程和需求管理中的搜集、分析和分配等环节,是相互依赖,互为输入条件。充分的需求搜集、科学的需求分析和分配,可以更好的进行市场分析、产品规划等工作,而市场分析的过程中,通过研究行业、拜访客户等行为,能更充分的搜集需求。‘
需求搜集是需求管理的第一个环节,是企业产品研发的开始。需求搜集有两个来源,分别是外部来源和内部来源。
外部来源,包括来自客户的具体需求、对市场和行业的分析、对竞争对手的分析等,也包括来自对国家政策的解读、参加各种行业协会的交流获取的信息等。
其中来自客户的具体需求最为直接,也是最重要的,是一个企业立项进行产品开发的主要依据。
我们把来自具体客户的需求称为客户需求,而把来自对行业分析、对政策的解读以及对竞品分析得出的共性需求称为市场需求。
市场需求和客户需求最大的区别是市场需求更加共性,而客户需求更加个性。客户需求和市场需求大部分是重叠的,但是客户需求的个性化差异是企业进行产品研发最需要关注的需求。
内部来源,包括来自公司市场、研发、生产和服务等部门长期的经验积累以及对行业的理解,而增加的一些需求。这些需求一般是市场上还未表现出来,或者客户没有提出来,但是企业本身由于长期的积累而产生出来的。
内部需求也有一定的价值,比如它可以增加产品的竞争力,给客户超出预期的表现,也可以提醒客户,避免客户遗漏了一些重要的需求。
尽管需求有外部和内部来源,但企业进行产品研发,应以外部需求为主。所谓的以客户为中心,就是以外部需求为主,兼顾内部需求。切忌以企业自身的能力为主进行产品开发。
最后要说明的是,企业的需求搜集是一个持续的过程。
当企业通过市场分析和客户拜访等途径搜集到了大量的需求,接下来需要对需求进行分析。
由于不同客户对需求的描述和表达方式各有不同,使得有些看起来不同的需求,实际上经过分析之后是相同的需求,所以第一步需要把搜集到的需求进行过滤,它包括使用上文提到的$APPEALS模型进行统一语言描述,过滤掉一些重复的需求和无效的需求。
然后在此基础上对有效的需求进行进一步的分析,包括对需求的功能性能分类、客户分类、重要性排序、紧急性分类等。
需求分类是一件比较复杂但非常重要的工作,因为出现不合理的分类,可能会导致后续开发出的产品,即使开发过程非常顺利,也有可能出现销售不好的情况。
因此,需求分析这件工作对于分析人员的能力和组织方式要求很高,这部分内容在第二部分产品研发组织中有介绍。
虽然需求分析也是一个持续的过程,但是需求分析的工作可以通过制定机制定期进行,以提升效率。
在分析了搜集到的需求之后,下一步需要对这些需求进行分配。
所谓的分配,就是根据客户提出的需求,对这些需求的功能性能、紧急性和重要性等指标,把这些需求分配到不同的项目中去实现,以最大程度上满足客户的需求,使产品更有竞争力,但需求分配也可以针对当期正在进行的项目任务,根据需求的不同情况,分配给现在开发的各个项目。
例如,产品平均无故障时间MTBF指标需求,1万小时的需求可能分配到低端型号产品上,而2万小时的需求则会被分配到高端型号产品上。
同样,电动汽车电池的续航里程600公里的需求,可能分配到今年开发的产品型号上,但是800里甚至更长的续航里程需求,则被分配到2年后规划的产品上。需求分配也可以定期进行。
需求实现就是对已经立项的项目需求进行产品开发的过程,相当于产品开发V模型中的绝大部分过程,即从客户需求开始,到性能全面测试的全部环节,如图3-3所示。
当然在需求实现的过程中,客户和市场方面还有可能会出现新的需求,对正在进行开发的产品产生影响,这时候需要对需求进行变更,或增删需求,或者改变需求,这称为需求变更。需求变更需要机制、流程和组织来保障,否则容易导致需求跟丢、开发和市场脱节等问题。
对需求实现感兴趣的读者可以阅读作者即将出版的新书第四章“产品开发流程”,该章节有做详细的介绍。
需求验证是需求管理的最后一步,它表示在需求实现后,即将向客户交付的时候,站在客户的角度来验证产品是否满足客户的需求。
需求验证和产品研发内部的测试有区别,产品研发内部的测试,是站在研发的角度看研发工作是否达成了目标,而需求验证,是站在研发的外部,站在客户的角度,来验证客户的需求是否被满足了。
在有些企业,需求验证这个环节是缺失的,只要研发测试通过了就交付给客户。也有些企业,尽管有需求验证这个环节,但是需求验证的人员是研发人员,研发人员的角色决定了他们验证时更多的是站在研发角度看问题而忽视了客户的需求和关注点,容易导致验证不充分。
这两种情况都容易导致产品在交付给客户的时候出现各种问题。
事实上,需求验证较好的做法是,由市场人员或者售后维护人员而不是研发人员,站在客户的角度,根据市场或者客户原始需求,采用黑盒验证的方式进行充分的验证,所以有时我们也把需求验证称作企业代客户提前进行产品验收。
通信设备行业的一些标杆企业,其产品进行需求验证时,除了在企业内部有市场团队和售后团队对产品的原始需求进行验证,还会到客户(运营商)处开通实验局验证,这种实验局验证,完全模拟未来产品真实的应用场景,所以能比较好地实现需求的验证。
以上为需求管理流程的5个步骤,企业如果做好了这5个步骤,需求管理水平可以提升一个台阶。需求管理的5个步骤具体内容如图3-4所示。
针对需求管理常见的一些问题,该如何解决呢?
比如针对“搜集需求的随意性”这个问题,解决方法包括企业需要制定相应的制度,规定销售/市场等部门人员去拜访客户、参加各种会议后,在一定时间内,按照统一的模板提交搜集到的需求清单。有需求管理IT系统的企业,需要需求搜集人员按照固定格式往需求库系统中录入需求。同时企业需要有需求维护的角色人员,有的企业叫需求管理员,这个角色可全职也可兼职,取决于企业的规模。但需求搜集需要规定统一入口、统一格式,不能有多个需求入口、多种模板甚至没有模板随机填写,这样才能保持需求入口的科学性和规范性。通过这种规定统一需求入口的方式,也能解决上文中提到的“研发人员在实现时任意增删需求”的问题。由于有专门角色维护需求,大到企业层面,小到项目层面,不同层面都有对应角色来维护相应的需求,能有效避免多头管理等于没人管理的情况,也就解决了“需求容易跟丢”等问题。
再比如“客户的需求传递到研发人员,产生了重大偏差”这个问题,主要原因是有些企业的销售人员不懂技术,或者刚刚进入这个行业,在和客户交流时对于客户描述的需求理解出现较大的偏差,再经过多个环节,传递到研发这个环节,是完全可能出现重大偏差的,解决这个问题有几个方法,包括安排既懂市场又懂技术的专业人员和客户交流,或者安排研发人员和销售人员共同和客户交流等,这些方式能比较好的解决这个问题。
最后,需求管理流程中有一些过程文档和输出文档至关重要,比如过程文档中的《需求搜集表》,它规定了搜集到的需求按统一的格式进行填写。管理需求的需求库文件《需求管理库表格》则可以包括一个事业部甚至一个公司的需求。输出的文档《市场需求说明书》或者《客户需求说明书》,用来描述某个项目要实现的需求条目,以及这些条目对应的具体内容和解释等,是项目立项必不可少的一份文档,这份文档确定了项目开发的范围。
至此,需求管理的相关内容已更新完毕(若需阅读《需求管理 | 企业如何做好产品需求管理(1)》请点击左侧链接),完整的需求管理会比两篇文章所描述的复杂得多,这只有在咨询项目中才会体现出来。下一篇开始将介绍产品开发流程相关内容。