电子商务网站建设课设心得体会,营销策划与运营方案怎么写,石油化工建设网站,网站在线建站产品项目在进行时经常会有一些需求需要实现#xff0c;需求是产品更新迭代的动力#xff0c;需求也是从用户诉求转化而来#xff1b;在做需求管理时#xff0c;我们需要判断一个需求的优先级等方面#xff0c;对产品进行优化#xff1b; 目录#xff1a;
一、 为什么要… 产品项目在进行时经常会有一些需求需要实现需求是产品更新迭代的动力需求也是从用户诉求转化而来在做需求管理时我们需要判断一个需求的优先级等方面对产品进行优化 目录
一、 为什么要管理需求二、 什么是需求需要与需求、从功能性划分需求分类、需求的层次三、 需求的来源调研、用户反馈、公司战略、产品研究、政策与标准要求四、 需求收集记录五、 需求管理给需求分类、确定需求优先级六、 需求变更需求变更的原因、如何应对需求变更、需求变更的流程控制七、 需求的反馈八、 需求的后续处理。
需求对于产品的重要性相当于一日三餐对于人的重要性需求是我们产品不断迭代的动力之源本文所指需求主要针对企业服务企业服务产品的需求项目型需求和C端产品需求的处理会有差异仅供大家参考。
一、为什么要管理需求
需求的来源多样重要性、紧迫性也不一样如何处理好纷繁复杂的需求对于产品发展至关重要。
如果处理不好无法辨别出需求的范围、重要性无法合理安排需求的优先级等都可能将产品方向“带偏”浪费公司资源错失发展时机失去产品竞争力严重的将会将丢掉市场和客户相反如果能够识别关键需求、紧急需求、紧跟市场需求处理及时得当将有助于提高产品竞争力。
二、什么是需求
在上一篇文章中介绍到需求预期-现状这是一个简单的描述大家对于需求有一个形象的了解。
在不同的领域对于需求有不同的定义在产品中我理解需求是与具体产品有相关性的、为解决具体问题而提出的、尚未满足的要求。
1. 需要与需求
需要与需求两个词语相似词义相近但在产品中这两个词有比较大的差异。
需要往往为用户提出的诉求希望满足某一个要求而需求是与产品有相关性并且一般为可设计、可实现的要求。
用户“需要”一般经过提炼、转化后才能成为“需求”而有些需要受制于客观限制是不能转化为需求的。
2. 从功能性划分需求分类
需求一般分为功能性需求和非功能性需求
功能性需求是那些用以处理产品所必须满足用户需求的功能特性功能型需求是最基础也最核心的用户需求功能型需求有时也被称为业务需求。非功能性需求包括可用性需求、性能需求、可靠性需求和安全需求等这类需求在系统建设早期重视度往往不高当用户量上升产品越来越重要时非功能性需求的重要性越来越突出。
3. 需求的层次
提到需求的层次一般绕不开马斯洛需求理论虽然这是基于个体的需求理论但企业需求场景仍然具有借鉴意义毕竟B端的产品使用对象也是一个个鲜活的个体。
但总体上企业服务产品更多注重实用性和效率提升对于美观性和心里满足的要求相对较弱但这是由行业现状导致的从长远来看企业服务产品应吸纳借鉴C端产品设计的一些优秀特点。
企业服务产品需求有自身的特点比如
企业服务产品面向企业或组织帮助其解决企业经营或管理问题对于组织来说需要企业服务产品提供基于管理场景的功能无法简单的通过马斯洛模型来定义描述企业服务产品的使用对象也需要关注业务用户而业务用户的需求动机同马斯洛需求模型有一定的交叉但并非完全适用企业服务产品作为业务管理或协同系统除了承载业务目标还需要考虑软件架构设计、体系构建、生态构建等问题C端产品的后台同样存在类似的问题因此需求分析管理中对于软件产品本身还需要有足够的关注度。
基于此企业服务产品也可分为几个层面的需求
1业务需求
业务需求实际上为满足企业某一使用场景和目的必须实现的功能主要体现在满足业务规则、管理制度、业务流程等方面。
比如开具一张发票需要有发票数据相关字段的录入功能添加一张凭证必须录入一些摘要、科目、借贷方等信息再比如一些工作审批流程功能没有流程的相关处理就没法完成业务的流转。
2用户需求
企业服务产品的使用对象是一个个有情感的人在满足业务需求后产品是否好用会成为评判产品优劣的重要指标。
产品页面表达是否清晰、操作是否便捷、反馈是否准确、效率能否提升都是用户体验相关的重要因素。
我们在一些项目型需求中经常会专注于满足业务需求但在SaaS、PaaS等平台型产品中仅满足于业务需求是远远不够的产品在具备良好的产品体验后才会真正具备一定的市场竞争力。
3产品需求
产品需求一般是由产品团队自发提出的基于公司战略及产品战略满足企业持续发展的需要如用户中心、消息中心、订单中心、账户中心、短信服务、邮件服务、认证中心等服务建设。
解决产品发展的重复建设问题搭建技术中台服务满足产品生态建设建设代理、运营管理平台建设合作伙伴开放平台等等都可以归类于产品需求——产品需求在一定阶段又会转化为业务需求和用户用户。
业务需求是企业服务产品的需求基石需求功能的健全程度决定企业用户是否能够使用产品用户需求解决企业服务产品体验的问题是企业服务产品具备竞争力的主要产品因素满足用户更好的使用产品的诉求产品需求基于集团战略及产品战略的规划而提出为企业服务产品的可持续发展及最终成功提供产品支持。
三、需求的来源
1. 调研
需求调研有多种方式有行业调研、用户访谈、需求沟通会等等其中
行业调研包括行业研究、竞品分析、典型用户分析等用户访谈与用户的电话会议、跟踪用户工作场景、访谈等方式获取需求需求会议与相关方开展会议收集用户需求组织头脑风暴会议激发大家的观点碰撞。
需求调研的方式多样在产品的不同阶段、产品所在的不同行业、不同场景需要选择不同的调研方式需求调研的每一种方式方法都可以作为专题来研究。
2. 用户反馈
1测试反馈
测试人员在测试系统的过程中实际是在模拟用户的操作在这个过程中可以发现一些系统问题提出比较好的需求建议特别是用户体验相关的建议。
2客户反馈
实际用户在使用过程中会发现一些系统提供的功能同实际操作需要之间不匹配的一些功能点如果沟通渠道通畅也会收集到一些用户反馈的需求。
3运营反馈
在一些有运营支撑部门的公司运营团队会代表用户向产品团队提出使用反馈的需求以帮助产品改进。
用户反馈和需求调研的差异主要在于是主动还是被动的收集需求。
3. 公司战略
公司会根据发展需要推出一些新的发展方向或者提出新的产品方向对这些公司战略的分解与分析形成产品需求。
公司战略形成的需求有些可能不是真实的用户需求有些是在创造用户需求这些都需要产品同学花费更多的精力去研究对产品有更好的预判能力避免产品掉入“伪创新”的泥坑。
4. 产品研究
产品同学可基于对行业的理解、用户的研究规划产品设计对产品进行优化迭代产品研究一般更侧重产品宏观发展和产品内在管理逻辑的实现。
5. 政策与标准要求
在一些国家监管或者存在行业管理标准的行业中企业服务产品需要满足国家的政策、文件及行业标准的要求为此需要设计相关的功能、流程、管理机制确保产品本身合法规范。
此类需求需要产品同学或者公司反馈机制去查找相关的政策、文件、标准并确保产品及时更新在要求的时限内完成或尽快完成产品改造满足监管要求。
四、需求收集记录
通过多种渠道获取需求后一定要对需求进行记录我总结需求记录一般遵循以下原则
需求来源可追溯一般需要对需求来源记录清楚当有些需求问题存在不确定性或需要对异常流程进行补充处理时可以再次进行沟通。
需求场景可还原需求记录要能够清晰的描述用户实际场景需要看到需求记录的相关描述要能够明白用户的实际需要是什么尽量不要产生歧义避免难以理解的需求记录。
需求分析可实现需求记录的问题应该是经过一定的过滤比如重复问题、与系统无关的问题等这些问题需要在更靠前的环节解决掉需求记录的问题应该是可实现或理论可实现的需求。
需求推进可持续有时会存在需求后续推进过程中提需求的人我们已经找不到或者无法确认这种情况时有发生。一个后续无法获取反馈的需求上线后无人使用会浪费团队大量的精力我们在需求收集阶段就需要开始辨别此类风险。
需求采集表一般需要体现出如下信息比如需求来源比如客户、企业员工等、提出人、提交时间、企业客户名称、客户联系人、客户联系方式、需求描述、涉及系统、功能节点等也可以根据产品的实际情况调整需求记录的项目。
五、需求管理
1. 给需求分类
做需求管理时我们需要先弄清楚几个问题这个需求是否为个性化需求覆盖的用户范围有多大带来的价值有多高紧迫度有多高如果对需求工作量有一定的判断经验可以初步评估实现的难易度和工作量。
需求影响力指需求能够影响的用户范围对用户影响范围越大得分需要越高反之越低例如分值可以为5、4、3、2、1、0其中5代表最大范围0代表无影响范围。
需求复杂度评估需求影响产品范围,可通过数值来标识可以通过判断影响功能范围、复杂度高低进行评分用于评估后续的实现难易程度影响功能范围越大复杂度越高实现难易度就越困难反之越容易可用数值进行标识例如分值可以为5、4、3、2、1其中5代表实现最简单1代表实现最复杂。
需求紧急度可跟提交需求的伙伴沟通优先级了解紧急程序也需要根据产品同学的经验进行判断对于业务需求、阻断流程需求、政策性需求可给与较高的紧急程度例如分值可以设定为5、4、3、2、1,5代表最紧急、1代表不紧急。
需求价值需求价值可区分为经济价值和产品价值没有想到特别好的命名。
需求经济价值是指这个需求的满足是否能够直接带来经济价值在企业服务SaaS产品中会有客户愿意为某一定制化功能买单对于SaaS产品来说需要慎重评估经济价值和需求影响力之间的关系例如分值可以设定为5、4、3、2、1进行评估。
需求产品价值可通过典型的KANO模型进行分类KANO模型将需求分为五类。
必备需求当优化此需求用户满意度不会提升当不提供此需求用户满意度会大幅降低期望需求当提供此需求用户满意度会提升当不提供此需求用户满意度会降低魅力需求用户意想不到的如果不提供此需求用户满意度不会降低但当提供此需求用户满意度会有很大提升此类需求处理得当可以很快提升产品竞争力。无差异需求无论提供或不提供此需求用户满意度都不会有改变用户根本不在意反向需求用户根本都没有此需求提供后用户满意度反而会下降。
一般来说可以分别使用3、2、1、-1、-2来分别代表必备需求、期望需求、魅力需求、无差异需求、反向需求。
需求价值可以通过需求经济价值需求产品价值来表达。
2. 确定需求优先级
处理需求的过程中很重要的事情就是确定需求优先级优先级的确定可以参考使用ICE方法。
ICE是将需求分为影响范围、自信程度、实现难易3个层面进行评估
影响范围是指需求的影响力自信程度是指用户对需求实现能够带来好的反馈的程度实现难易是指技术实现需求的难易程度。
在上个章节中我们将需求进行分类打标签我们对需求分类标签的目的是希望通过对需求进行客观的分析以数值的方式记录评估然后对需求的总得分比较排序尽量避免用拍脑袋的方式定义分值让使用ICE方法时更加合理。
影响范围可以用需求影响力*需求产品价值来表达自信程度可以使用紧急程度需求价值来表达实现难易可以通过需求复杂度的分值来表达
最终将每个需求的ICE三个分值相加根据得分顺序排列需求优先级。
对于每一个需求的归类和分值定义可以在实际的操作过程中进行调整摸索出一套适合自己产品的方法。我们在对外沟通的过程中也可以将确定优先级的方法作为一套标准争取各环节共识各环节能够理解并达成一致后有助于产品推进。
六、需求变更
需求变更是难以避免的。
有人说唯一不变的就是变——我深以为然变更对于产品来说可能是好事也可能是坏事所以我们需要做好需求变更的控制——对需求变更的管理不是为了杜绝变更而是降低需求变更对产品的负面影响让产品向更好的方向发展。
在PMP的知识体系中对于需求变更非常重视在传统的瀑布式项目开发过程中需求变更意味着项目计划的调整、资源投入的调整实际情况是大多数情况都会导致项目进度延期或者增加资源投入。
在产品迭代常采用敏捷开发的方式过程中我们对于需求变更的控制力度或流程管控力度有所降低迭代开发模式追求快速上线、快速试错、快速调整本身也容易导致需求变更的发生。
1. 需求变更的原因
前期需求不够明确我们在一些产品早期或者功能早期建设过程中有时会缺少参照需要进行一些产品创新此时对于需求的评估还不够精准用户研究也不够透彻上线往往需要根据用户反馈调整产品设计。
业务场景不够了解我们在分析客户的使用场景的过程中由于自身专业知识水平和行业经验的限制对业务的使用场景不够了解对用户的需求描述仅看到表面问题没有分析到本质问题设计出来的产品往往不能满足客户的真实完整需要。
业务形态发生变化当公司的商业形态或者业务运营逻辑发生变化时我们也需要根据情况进行调整这类问题在业务主导型公司经常发生产品团队作为提供服务方往往会比较被动。
2. 如何应对需求变更
在管理的过程中我们需要根据造成需求变更的原因有针对性的进行管理在有些产品中多种情况可能会同时出现。
对于需求不够明确的情况我们需要控制需求量避免一次投入过多的工作量采用小步快跑的模式减少资源的浪费。
因为业务场景了解不够导致的需求变更问题在设计产品前需要产品人员多方面、深入、客观的了解业务需求增强自身对业务场景的认知了解需求的真正痛点不要浮于表面。产品设计过程中多考虑新需求的相关性有助于发现更多的场景问题在产品评审时需要仔细跟用户讨论确认有条件的情况下让用户帮助评估是否符合业务场景对于客户的疑虑或不解多追问、多了解。
当业务形态发生变化时需要评估影响范围和紧迫度比如公司战略调整就需要尽快全面响应需求变更。
当业务管理部门的频繁变动或业务规则频繁调整时我们需要适当降低需求的优先级在设计产品的过程中针对这类频繁变更的需求产品同学需要注意总结需求变更前后的特点找到规则通过可配置的产品设计实现需求让用户自行配置保持产品功能的灵活性减少需求的变更。
在实际的需求管理过程中需求变更的原因是比较复杂的有产品自身的原因、有业务的原因、公司管理的问题我们需要根据具体情况具体分析当遇到较大的需求变更风险时应及时反馈到上级。
3. 需求变更的流程控制
在产品迭代过程中变更的需求往往被作为新需求进行处理这是目前一些公司的现状产品同学可根据自己所在公司的情况选择需求变更的控制流程。
但总体来说遇到需求变更时需要提升对变更需求的风险关注度。
我们可以总结出相对通用的需求变更控制流程作为参考
变更申请如果用户需要变更需求最好提出《需求变更申请》经客户方和服务方共同确认后发送内容给产品需求对接人。变更分析产品人对接人收到变更需求时将问题录入到需求收集表标识问题类型接下来组织团队分析需求变更影响、紧急度、需求价值等。变更决策团队相关人员进行内部变更评估、审核决定哪些变更无法修改并说明原因哪些变更需要修改和什么时候修改。变更实施需求变更通过后确定开发时间和纳入的版本制定开发计划变更验收对于需求变更而进行的版本更新需交付相应的《版本更新说明》。
七、需求的反馈
我们在确定大致的需求优先级后根据项目团队的初步评估确定上线周期及时同各方做好需求的反馈工作。
新产品和处于迭代中的产品在处理需求的过程中会有一些差异。
新产品一般需要经过立项过程其需求来源相对简单沟通反馈过程也相对简单而迭代中的产品可能会出现部分需求重要但没有马上给出排期计划的情况需要分别对待。
一般在沟通需求反馈时需要对需求受理状态、解决方案、解决时间等给出响应。
八、需求的后续处理
在需求管理完成后后续还有很多工作需要处理比如产品设计、产品评审、UI设计评审、研发过程跟进、配合测试评审、产品验收、产品发布、收集反馈意见等这些内容我们会在后续章节继续探讨。
