| 编辑推荐: |
本文主要介绍了基于IPD的需求管理流程相关内容,希望对您的学习有所帮助。
文章来自于微信公众号企业管理杂志,由火龙果软件Alice推荐。 |
|
IPD是一种面向客户需求,将贯穿产品生命周期的活动及时协同的产品开发方法。早期IPD框架中,需求明确作为框架的输入部分,可见IPD体系中需求管理的重要性,新产品设计为了满足客户需求,需求是新产品开发的源头。
需求管理流程框架
需求管理过程始于客户需求,终于客户满意。合理的需求管理流程能够及时准确地从目标客户群获取需求信息,结合企业的营销环境和营销计划转化为市场需求,并进一步转化为对产品或服务的需求。企业基于自身实力将需求转化为具体产品实现方案,在客户需要的时间,以客户能够承担的价格和可以接受的质量,提供产品和服务,最终让客户满意。
基于需求管理的工作可展开为三个层次:一是战略层面的定位管理,企业基于技术和市场趋势寻找机会点,提前进行产业布局,属于企业级需求管理;二是策略层面规划管理,基于产业布局进行业务规划,即在年度规划中明确重点方向、产品及时间节点,指导产品开发,属于业务级需求管理;三是执行层面的开发管理,针对细分市场客户群的需求进行产品开发,通过技术和管理手段满足客户需求,属于产品级或项目级的需求管理。
IPD流程是业务层面的研发管理,超越了项目级别,因此基于IPD的需求管理需要从业务层面整体考虑,由临时性工作转变为日常工作的一部分,从时间、客户群、产品等维度,持续、综合、全面、全过程进行管理。基于IPD构建满足研发需求的管理流程,需要与IPD中的其他子流程及相应团队匹配,明确工作内容和负责人。
需求管理流程由五个步骤构成:需求收集、需求分析与排序、需求分配、需求实现和需求验证。这五个步骤只是需求管理系统的框架,企业需要结合具体情况进行细化。
需求收集以市场为导向
需求收集过程以公司产品愿景、产品战略为指导,全面了解目标市场、目标客户群需求情况,其目的在于以市场为导向,为后续需求分析、需求筛选及产品规划与开发提供输入,从而保证技术研究方向、资源投入与客户需求的一致性,以及产品在市场上的竞争力。
企业若想全面、准确、及时收集客户的需求信息,需要建立广泛的渠道,保证信息不遗漏。需求从来源上大致可以分为外部来源和内部来源。外部来源包括客户反馈、竞品分析、社交媒体、产品及用户相关行业分析等。内部来源包括产品战略、项目发起人、客服人员、运营人员、市场营销人员、销售人员、产品用户行为分析等。
一般情况下,战略部门负责宏观、共性、趋势性的需求收集管理,用于指导战略制定及战略项目确定;业务部门负责具体业务范围内目标客户群共性、趋势性的需求收集管理,用于指导业务部门的组合规划、产品线设计、技术规划等;产品经理负责具体产品或产品线所对应目标客户群的需求收集管理,用于指导具体产品或产品线的新品开发或产品升级工作。
需求分析与排序
需求分析是对收集到的客户需求信息进行加工处理,排除错误并弥补不足,将用户非形式的需求表述转化为完整、正式的需求定义,形成产品规划或产品开发所需信息的过程,最终输出需求排序表,为需求分配做好准备。
需求分析过程可分为四个步骤:需求解释、需求过滤、需求分类和需求排序。
需求解释指将客户对需求的描述转化为企业内部规划和开发人员之间的常用规范描述,并且对客户的原始需求查缺补漏。
需求过滤是对转化后的需求结合业务情况进行筛选的过程,需要综合考虑客户需求是否和业务紧密相关、是否与产品战略一致、是否给企业带来更高的价值、是否已经提交、是否在现有产品中已经满足等,剔除冗余、重复、不相关或不符合业务趋势的需求,形成业务需要的正式需求池,为下一步分类工作做好准备。
需求分类针对正式需求,按照一定的规则,比如按紧迫程度、承载项目类型、涉及产品范围等进行分类,以便后续分类处理。
需求排序指针对分类后的需求进行优先级排序的过程。客户需求众多,企业资源有限,要在时间、资源、战略要求等众多约束条件下,优先安排等级较高的需求开发,这要求企业必须对需求排序,排序往往针对同一类需求进行,不同类别的需求无法直接比较。对于需求自定准则比较,可采用价值工程法、Delphi方法或AHP(层次分析法);对于方案型需求需要从多个维度分析比较,可采用$APPEALS法(价格、可获得性、包装、性能、易用性、保证程度、生命周期成本、社会接受程度),这种方法需要综合Delphi方法、AHP以及雷达图分析。
需求排序一般是由业务单元的产品规划部门牵头,细分市场的营销、研发、服务、质量等部门人员参与,并邀请各方面专家,以团队形式共同完成需求排序工作。
按紧急程度进行需求分配
需求分配指将已经获得批准、将要纳入业务的需求,按照紧急程度(即需求实现的时间点)分配到不同开发计划中,以便在开发计划指导下,合理协调资源,实现需求有序开发。由于企业业务类型、管理流程的差异,在需求分配的操作细节上可能有一些差异,但大方向基本一致。本文以联想公司为例,分析需求分配的路径。
联想作为IT企业,产品更新换代节奏很快,客户需求变化也比较快,因此企业采用的需求分配方式有以下几种。
第一,长期需求。分配到年度业务规划中,2年以上的需求为长期需求。战略级的长期需求一般指定公司一级研发部门负责,由业务单元配合,为后续在产品中的实现做好准备。产品应用层面的相关需求会落实在年度业务规划中,并用来指导技术/产品平台预研,这些需求可以凭借业务单元的技术力量,由业务单元战略部门牵头,产品规划、技术规划、市场营销等部门配合,由总经理最后决策。
第二,中期需求。分配到产品路线图中,3~24个月的需求为中期需求。相关需求根据客户群或市场区域划分落实到对应产品线中,并每月滚动检查需求的变化情况。该工作由产品规划部门牵头,技术规划、市场营销部门配合,最后由IPMT(集成组合管理团队)决策。
第三,短期需求。3个月内或处于概念前阶段的需求为短期需求,直接在项目任务书中体现。该工作由产品经理具体负责,产品核心团队配合支持,最后由IPMT决策。
第四,紧急需求。直接分配到项目任务书或通过产品变更形式加入项目任务书。在项目正式启动后到产品发布期间的需求为紧急需求,在计划阶段结束前,可由PDT(产品开发团队)直接加入项目任务书,经IPMT决策后即可落实;在计划阶段结束后,项目范围基线已经确定,需求的加入需要由PDT提出变更申请并经IPMT审批通过后加入项目任务书。
第五,其他需求。指在产品生命周期管理期间需要通过产品升级满足的需求,可分为两类:一是临时需求,需要通过临时产品升级实现;二是根据技术发展或业务运营需要,通过提前计划好的升级满足的需求,这些需求往往按照一定节奏分批落实,工作由生命周期管理团队(LMT)或PDT负责,由生命周期管理委员会(PLMC)或IPMT做最后决策。联想公司需求分配流程如图1所示。
在需求分配管理工作中,要尽量减少进入开发验证阶段的紧急需求和生命周期管理期间的临时需求,这些需求往往需要临时增加资源,会打乱产品开发或运营节奏,给企业带来不可知的风险。
需求实现是广义概念
需求实现指将客户需要以功能的形式落实到产品或服务中,并完成开发工作的过程。但如果仅按客户需求开发产品并不能真正满足客户需要,也不能很好符合市场要求。客户通常理解的产品指具有某种特定物质形状和用途的物品,是看得见、摸得着的东西,客户需求通常也基于此来描述,而市场营销学认为,广义的产品指人们通过购买而获得的能够满足某种需求和欲望的物品总和,既包括具有物质形态的产品实体,又包括非物质形态的利益,这就是“产品整体概念”。
如果期望通过开发过程交付一个客户满意的产品整体并能够使企业获益,就需要综合考虑顾客需求、技术需求、DFX(面向产品生命周期各环节的设计)需求、质量需求、设计规范需求、测试需求、生产制造需求、服务需求、目标市场的法律法规需求、开发过程中内部客户需求、市场竞争需求等,在此基础上形成一个完整的产品方案。
方案需求是功能和服务层面的描述,无法直接用于指导开发工作,这时还需要将其细化为对软件、硬件、服务、生产制造等各方面的技术、操作要求,并进一步细化为对子系统、模块的技术要求,再和企业各种技术规范相结合,形成最终指导开发实现的文件,如系统规格书、部件规格书、软件规格书、测试方案等。
还以联想为例,其采用MRD(市场需求文档)进行方案需求的总体描述,由产品经理负责。在该文档中,要分析支撑方案需求的相关市场趋势和机遇,明确市场与客户细分模型,识别目标客户的痛点和相应需求,并对竞争对手深入分析,在此基础上形成产品/解决方案概念,并细化为方案软硬件定义、部件定义等。MRD文档是IPD流程中实现把项目当作投资管理的关键一步,在该文档中需要对项目的投入产出、营销策略进行全方位分析,并给出解决方案,从而确保达成项目技术及经济目标。
需求验证四阶段
测试验证是确认产品能否让客户满意的关键环节,一个新产品的开发,从收集内外部客户的问题开始,包括业务问题、产品问题、产品规划问题、细分市场客户群调研获得的问题、企业内部DFX问题等,然后将收集的问题转化为原始需求描述,经过需求分析规整形成产品初始需求。
将筛选排序后的初始需求按照市场定位分解到相应产品,并以客户可体验或可见的产品系统功能服务的形式描述,就构成了系统特性。
PDT团队在综合考虑系统特性、内部需求的基础上形成对产品全面交付需求,即系统需求,系统需求只能回答产品做成什么样的问题,但无法回答要做到什么程度的问题,也并不能直接用于指导开发工作,因此还需要基于系统需求进行系统设计,即综合运用各有关学科的知识、技术和经验,通过总体研究和详细设计等环节,设计出约束条件下能最大限度满足系统需求、整体最优的新系统,该过程的输出一般称为系统设计规格书,主要说明系统架构、各子系统或模块的功能及彼此之间的配合关系等内容。
子系统需求、部件/模块需求的拆分并不是需求管理所需要的,更多是基于产品开发、技术管理以及专业配合角度进行拆分,与其相对应的产品实现文件为子系统设计规格书、部件/模块设计规格书,是基于系统设计,对子系统、部件/模块的技术实现的详细描述,此层面的文档已经足以支撑具体产品、部件的开发工作。
产品开发V字模型如图2所示,产品的测试验证是与需求的分解逐层相对应的,按倒序进行的增量过程,包含了模块验证、子系统验证、系统验证、客户验证几个阶段。
在IPD流程中,为了保证新开发的产品方案能够满足客户需求,可构建四阶段增量集成测试流程,用于指导新产品开发中测试工作。
基于IPD流程的增量集成测试内容与V字模型中的测试内容有一定的对应关系,但又不完全相同,因为IPD中的测试流程还要考虑生产过程的需求,其对应关系如下。
第一,模块需求,对应测试验证为BBFV(构建模块功能验证),由设计人员主导,测试人员协助,验证模块级功能设计是否达到预定目标,此阶段一般采用白盒测试法。
第二,子系统需求,对应测试验证为SDV(系统设计验证),子系统或模块级测试,包括基本功能、性能的常规测试,以及各种可靠性类测试。SDV工作通常以测试人员为主,设计人员参与。
第三,系统需求,对应测试验证为SIT(系统集成测试)产品整机测试,测试内容与SDV大致相同,但增加模拟用户的可用性测试、可维护性测试和包装测试。SIT在开发阶段后期,由测试人员负责完成。
第四,生产需求,对应测试验证是SVT(系统验证测试),是在小批量试生产情况下的测试,测试内容与SDV大致相同,但强调从试制生产线随机抽检,关注产品质量一致性,SVT必须在SIT完成后的验证阶段完成。SVT工作由试生产人员(有时被称作新品导入NPI)主导,研发人员、测试人员参加即可。
产品开发V字模型通过增量式的开发方式,将工作分解到可以独立验证的部件或功能,通过异步开发保证开发的进度和需求满足。
需求管理是IPD的根基,是贯穿IPD全流程的核心引擎,它为 IPD 提供市场与用户导向的源头动力。企业只有做好需求管理,才能开发出满足市场需求且具备商业价值的产品。 |