精华内容
下载资源
问答
  • EDITED BY CHENYU * 移动互联网产品设计 移动互联网产品设计课程 Mobile Internet Product Design 主讲...03 金字塔模型法 优先级判断原则四象限法则和kano模型结合 需求优先级评估 重要 不重要 紧急 重要且紧急基本型
  • 需求优先级划分技巧

    千次阅读 2018-12-11 14:01:16
    01 优先级 开场语 假设需求梳理会议上,团队确定本迭代的待办事项有n个,假若等到两周迭代开发快结束的时候,还有2个未完成,在这种情况下,是否按照约定准时发布? 按敏捷的思想,答案非常明确:按时进入测试和...

    01 优先级

    开场语

    • 假设需求梳理会议上,团队确定本迭代的待办事项有n个,假若等到两周迭代开发快结束的时候,还有2个未完成,在这种情况下,是否按照约定准时发布?
    • 按敏捷的思想,答案非常明确:按时进入测试和修改Bug阶段,并且只测试已经完成的n-2个需求,剩下2个没有完成的需求放在下一个迭代。
    • 但这时候可能会有人跳出来:用户最看重的就是这两个需求,少了这两需求客户会很不满意!
    • 根本原因:需求优先级划分不合理。

    优先级排列方法     

    • 是否有定性或定量的排列需求优先级的方法哪?
    • 当你决定是否开发这个需求时,最先考虑的因素有哪些?
    • 我们先从需求的两个最显而易见的属性考虑:
      • 产品价值
      • 技术成本

    • 从产品价值和技术成本两个角度分析,可以将产品划分为小而美、小而更美、大而美、大而丑四个象限
    • 取舍线以上的为可纳入产品开发范围的需求,取舍线下的为淘汰的需求,不同开发团队的取舍线斜度不一样
    • 如何判断产品价值?
      • 用户更喜欢哪个?
      • 对盈收有什么影响?
      • 不做是否会产生潜在的负面影响?
      • ……
    • T-shirt Size 估算
    • 假设销售估算: L可以带来100万收益或给100万用户受益,M是50万,S是5万。
    • 研发团队评估:L要三个月,M一个月,S一周。
    • 两边对比,如果价值比较高,而且技术成本比较低,这就是小而美;如果反过来,研发要花好大的力气,价值又不高,那就坚定不移地砍掉;如果两个都是 L,可以考虑再拆分。

    上图是个比较形象的比喻

    练习:

    • 请将卡片中的需求从价值和技术成本角度,划分出类型
      • 小而美、小而更美、大而美、大而丑

    • 影响优先级的其他因素
      • 风险和不确定性
      • 时间关键性/延期交付成本
    • 风险/不确定性
      • 如果需求具有不确定性,比如:在一定条件下这个需求会引爆市场,但是这个条件何时到来还不知道,那就降低优先级,推迟决策。早做浪费,晚做白做!
      • 如果需求的实现有风险,比如:需求对老代码模块的逻辑架构有重大冲击,如果决定必须做,就要早做,直面风险!
    • 时间关键性/延期交付成本
      • 加急类:是否用户急缺的功能?
      • 固定日期类:是否是固定交付日期类型的需求?
      • 普通类:没有特定的截止日期,早交付早产生影响
      • 投资类:不直接产生价值,但是会提升团队效率从而间接产生价值;或者如果一直不做,长期累积,会产生经济损失,比如清偿技术债。

    综合考虑

    几个注意事项:

    • 优先级是相对的!
    • 建议不要划分太多级别,3-5个较合适。
    • 可以先排列出Backlog顶部的需求优先级。
    • 团队的交付节奏越密集、交付速度越快,花在排序上的时间就可以越少。
    • 比决定优先级更重要的是决定做与不做!

    02 迭代计划

    • 划分需求优先级后,切忌过于强调高优先级的需求,在同一个迭代周期内安排太多高优先级的需求!

    • 迭代计划必须考虑:依赖性!
      • 低优先级的需求可以依赖高优先级的需求,但要避免高优先级需求对低优先级需求的反向依赖。
      • 错开节奏!尤其依赖的用户故事由其他团队交付的情况,进度不受自己控制,更需要错开节奏。

    • 迭代需求金字塔

    • 迭代计划还必须满足MVP
      • MVP (Minimum Viable Product, )最小化可行产品,《精益创业》 一书中提出的理念,其核心思想是,开发产品时先做出一个简单的原型——然后通过测试并收集用户的反馈,快速迭代,不断修正产品,最终适应市场的需求
      • 这也是Scrum的输出件要求:潜在可交付产品

    03 迭代交付

    • 做好迭代计划后,是否就能高枕无忧了?
    • 实际开发过程中,我们不仅需要召开各种会议,还要通过电话、邮件和当面沟通的方式反复确认:
      • 产品经理下周一能够准时输出需求文档吗?
      • 公共库下周一版本能够准时输出吗?
      • 开发能准时解决…问题吗?
      • ……
    • 大部分确认的共同目的都是:确保进度和交付。     
    • 无论事前做了多少工作,团队成员之间仍然会充满不信任。以往的经验也告诉大家——盲目的相信承诺付出的代价会更高
    • 如何破解?
    • 时间盒,刚性交付

    时间盒

    • 每个角色都恪守自己的承诺,在时间盒燃尽前交付自己的任务,若无法完成也应主动反馈。团队成员之间不需要花太多的成本互相确认进度,一切都按照迭代运行模式图中的计划进行。
    • 固定时间点开始,固定时间点结束!
    • 刚性交付!

     

     

    地铁 VS 公交

    迭代地铁

    • 不管地铁是否有人乘坐、是否挤满了人,地铁永远是按照时刻表运行,出现晚点的概率极低。
    • 把每一趟地铁比喻成一次迭代,每一位乘客就是一个需求:
      • 需求要不要上车,都是需求决定的,并不是迭代决定的,迭代只确保上了车的需求准时发布。
      • 如果迭代的地铁里太拥挤,无法容纳更多的需求,唯一的选择就是搭乘下一趟迭代地铁。
    • 正是因为这样的运行规定,迭代的地铁才可以保证每天海量的需求可以准时交付,运行效率远高于公交。

    总结

    • 项目中只有每个角色做到刚性交付,团队内部才可以减少内耗,让大家逐步建立信任机制,减少沟通时间,每个角色可以腾出更多的精力完成自己的任务。
    • 这样才能逐渐形成一个良性循环,整个团队慢慢向好的方向发展,否则大家仍然会陷入无尽的进度跟踪,无法自拔!

     

    展开全文
  • 如何进行需求优先级管理?

    千次阅读 2019-09-11 18:17:43
    需求优先级管理四步走 需求优先级的管理,其实是为了帮助我们确定先做哪个需求后做哪个需求,从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理,或者更直接来说是优先级顺序管理,我们需要做到...

    需求优先级管理四步走

    需求优先级的管理,其实是为了帮助我们确定先做哪个需求后做哪个需求,从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理,或者更直接来说是优先级顺序管理,我们需要做到如下几件事情:

    1. 确定优先级模型:优先级看起来像是一个简单直接的值,但实际上它是一个基于多种因素进行综合判断之后得出的一个值,这些因素和判断原则,就是我们所说的优先级模型;
    2. 排定需求优先级顺序:将需求代入优先级模型进行计算,得出每个需求的优先级顺序;
    3. 调整需求优先级顺序;
    4. 改进优先级模型:如果经常发生需要调整需求优先级顺序的情况,那么最好是对这些情况进行一定的复盘分析,如有必要,修正或改进当前的优先级模型,让它可以适应实际情况,以避免调整优先级顺序的情况反复发生;另外就是需求可能已经交付或发布上线,但是该功能的实际用量或价值不吻合预期,则需要反思我们对这些需求的分析和判断,究竟是分析判断有误还是优先级模型有误,并进行相应的调整;

    一,确定优先级模型

    成本收益分析就是最简单的一种优先级模型,重要/紧急的四象限也是一种优先级模型,Kano模型也是一种优先级模型,它们都可以帮助我们去确定需求的优先级顺序。模型可以简单也可以复杂,根据企业实际需要来确定即可。

    务必切记优先级模型不应追求完美,以避免模型过于复杂,导致优先级管理的管理开销过高,喧宾夺主,反而影响了需求的开发和交付。如果较为简单的模型就可以满足需要,就应该首选使用较简单的模型。企业可以从简单开始,逐渐完善,不需要也不应该在一开始就追求过于复杂的模型。

    • 简单可以体现在考虑的要素更少,比如成本收益分析只考虑两个要素,就比考虑更多要素的模型简单;
    • 简单还可以体现在要素的取值范围更窄或精度要求更低,比如预计利润只要求评估高//低,就比要求以万元为单位评估预计利润更简单;

    优先级模型确定后,可以进行存档管理,注意该模型宜供所有人或相关人员查阅学习,比如录入到Wiki知识管理系统就是一个很好的做法,如下图:

    二,排定需求优先级顺序

    比如成本收益分析,可以是把预期市场收入作为收益值,把预期研发投入作为成本值,计算差值,或计算ROI均可。假设需求A预计收益为10万元,研发投入按人天折算预计3万元,那么预计利润就是7万元,预计ROI 233%;需求B预计收益为5万元,研发投入折算预计4万元,那么预计利润1万元,预计ROI 25%。那么需求A的优先级顺序就要比需求B更靠前。这种相差悬殊的情况往往不难判断,我们假设还有需求C预计利润也是7万元、预计ROI50%,以及需求D是预计利润1万元、预计ROI500%。那么ABCD这四个需求的具体顺序怎么排定呢?

    如果真的出现这种情况,那就更复杂一些了,需要考虑引入权重,然后计算出一个综合值,这个值按照某种规则(例如从大到小)排列出来就是最终的优先级顺序,比如:


     

    预计收入(万元)

    预计成本(万元)

    预计利润(万元)

    利润权重

    利润加权值

    ROI%

    ROI权重

    ROI加权值

    综合值

    优先级顺序

    需求A

    10

    3

    7

    0.1

    0.7

    233%

    1

    2.33

    3.03

    2

    需求B

    5

    4

    1

    0.1

    0.1

    25%

    1

    0.25

    0.35

    4

    需求C

    21

    14

    7

    0.1

    0.7

    50%

    1

    0.5

    1.2

    3

    需求D

    2

    1

    1

    0.1

    0.1

    500%

    1

    5.0

    5.1

    1

    根据上述表格中所得出的结果,我们就应该依序将需求D、需求A、需求C、需求B排入开发计划。优先级顺序,在DevCloud中,可以使用工作项的优先级顺序字段来实现,该字段取值范围1-100,如下图所示。

    三,调整需求优先级顺序

    调整顺序本身非常简单,只要在DevCloud中重新设定该需求的优先级顺序字段的值就可以。但重要的是,需要将优先级顺序调整这件事情记录下来,包括为什么要调整、具体如何调整的、调整背后的具体考虑等信息都记录下来,同样,建议记录在Wiki知识管理系统中。用于后续的复盘回顾中作为参考信息,比如每个Sprint/迭代结束时的回顾会议上拿出来进行探讨。

    四,改进优先级模型

    市场在变化,用户在变化,产品在变化,优先级模型自然也必须跟随着发生变化。我们可以定期或不定期的安排对需求优先级模型进行复盘分析,找出可以改进或优化的点,并跟进落实。可以是定期开展,例如每个月进行一次复盘,把这个月所涉及的需求都拿出来审视,或者是其中有调整过优先级顺序或者出现过问题的需求拿出来审视均可;也可以是不定期,以问题驱动的方式,比如某天进行了大量需求优先级的调整,那么当天或第二天就可以临时召集一次复盘会议,分析为什么会发生这种情况。

    复盘要有好的效果,就必须尽可能的复原问题发生当时的情况,所以前面提到的Wiki记录就变得非常重要。复盘会议应提供尽可能多的相关信息以便参会人员了解情况,充分探讨。

    复盘过程中,我们要定位出正确的根因,是模型本身设计有问题(例如要素和尺度),还是取值、加权有问题(比如某类需求的预计收入就是非常难估算),还是过程管理的问题(比如过早进行估算,因为缺乏必要信息,导致估算得出的优先级顺序不准确),并进行针对性地改进。

    参考附录

    相关文章

    1. 维基百科上的Kano模型词条:https://en.wikipedia.org/wiki/Kano_model

    相关书籍

    1. 杰拉尔德·温伯格:《成为技术领导者》
    2. 邱昭良:《复盘+:把经验转化为能力》

     

    展开全文
  • 产品需求优先级评估

    万次阅读 2016-07-26 11:19:16
    本文介绍几种常用的需求优先级的评估方法。 一、数字排序法(三分法) 需求可分为强制型(Mandatory),满意的(Desirable),非必要的(Inessential)三种类型。 假设有需求R1、R2、R3、R4、dR5、R6。 假设参与需求...
      产品需求的优先级评估是一个颇有难度的工作,其实也是也是颇有技术性的活。本文介绍几种常用的需求优先级的评估方法。
    

    一、数字排序法(三分法)

    需求可分为强制型(Mandatory),满意的(Desirable),非必要的(Inessential)三种类型。

    假设有需求R1、R2、R3、R4、dR5、R6。

    假设参与需求评估的用户为A和B。强制需求赋值为3,满意需求赋值为2,非必要需求赋值为1。

    lip_image001.png

    结论:最终优先级为:R1>R3=R4=R5>R2>R6

     此方案优点:简单易行

    缺点:每个用户给出评估值的逻辑可能不一致,最终结果可信度不高。

     

    二、KANO模型

    受行为科学家赫兹伯格双因素理论的启发,东京理工大学教授狩野纪昭(Noriaki Kano)和他的同事Fumio Takahashi于1979年10月发表了《质量的保健因素和激励因素》(Motivator and Hygiene Factor in Quality)一文,第一次将满意与不满意标准引入质量管理领域。

    KANO模型定义了三个层次的顾客需求:基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素

    基本型需求是顾客认为产品“必须有”的属性或功能。当其特性不充足(不满足顾客需求)时,顾客很不满意;当其特性充足(满足顾客需求)时,无所谓满意不满意,顾客充其量是满意。

    期望型需求要求提供的产品或服务比较优秀,但并不是“必须”的产品属性或服务行为有些期望型需求连顾客都不太清楚,但是是他们希望得到的。在市场调查中,顾客谈论的通常是期望型需求,期望型需求在产品中实现的越多,顾客就越满意;当没有满意这些需求时,顾客就不满意。

    兴奋型需求要求提供给顾客一些完全出乎意料的产品属性或服务行为,使顾客产生惊喜。当其特性不充足时,并且是无关紧要的特性,则顾客无所谓,当产品提供了这类需求中的服务时,顾客就会对产品非常满意,从而提高顾客的忠诚度。

     lip_image002.png

     


    M代表Must-have,是基本型需求;L代表Linear,是期望型需求;E代表Exciter,是兴奋型需求;R代表Reverse,是相反的需求;Q代表Questionable,是可疑的结果;I代表Indifferent,是无关紧要的。

    cano1.pngcano2.png


    1. 第二、第三象限:表示一旦实现了一定数量的必需功能,就无法再通过增加这类功能来提高用户的满意度了。无论增加多少必需功能,用户满意度都不会超过中点以上。
    2. 第一、第四象限:表示只要实现一部分兴奋点,就可以明显提升用户满意度,苹果的产品在这方面是典型代表。
    3. 第一、第三象限:表示期望型需求的增加和用户满意度呈线性增长,所以这类需求越多越好。
    4. 时间的衰减:用户的需求类型是随着时间变化的,也许期望型需求变成了基本型需求,兴奋型需求变成了期望型需求,需要重新挖掘用户的兴奋型需求。

    通过以上分析不难得出,对于必须完成的需求,在产品发布时需要完成,但并不是要求在第一次迭代时就开发完成;完成尽可能多的期望型需求;如果时间允许,至少应该确定少量的兴奋点需求优先级,进入研发和发布计划;及时跟进用户的需求状态和类型,不断挖掘用户新的兴奋型需求。

     

    三、维格斯法(WIEGERS’ Method)

    维格斯法分为四个纬度进行评估:

    1. 实现需求给客户带来收益(Benefit)
    2. 不实现需求给客户带来的损害(Penalty)
    3. 实现需求所需要耗费的成本(Cost)
    4. 实现需求的风险(Risk)

    其中收益和损害是从客户角度出发,而成本和风险则从实现角度出发。

    优先级算法:

    lip_image006.png

    例如:

     

    lip_image007.png

    假设Wbenefit =Wpenalty = Wcost =Wrisk=0.5,推算结果如下

     lip_image008.png


    此方案优点:每个用户都是通过四个纬度的分析,逻辑清晰

    缺点:有效性缺乏验证,结果仍不够可信

     

    1. 层次分析法Analytic Hierarchy Process (AHP)

     

    美国运筹学家Saaty于二十世纪70年代提出的一种实用的多方案或多目标的决策方法,它合理地将定性与定量的决策结合起来,按照思维、心理的规律把决策过程层次化、数量化,是一种定性和定量相结合的、系统化的、层次化的分析方法。

    根据层次分析法,需要设置”目标“,两个”准则“(价值和成本),若干”解决方案“(需求项目R1…)

    层次分析法.png

    在比较过程中,需要用到判别矩阵,矩阵中数字填写行列两项之间的重要想比较结果,重要性判断的原则如下:

    ip_image011.jpeg

    例如:

    VALUE维度的评价结果

    lip_image012.png

    COST维度的评价结果

    lip_image013.png

     

    最终结果

    X轴表示成本,Y轴表示价值。落入“成本低、价值高”区域的需求优先级最高。

    xy.png

     

     

     

     

    李春雷

    2015/12/18

    展开全文
  • 在实际工作中,经常遇到需求堆积、开发资源有限的情况,要想在这种情况下合理的安排需求,实现价值最大化,对需求进行优先级管理异常重要。 首先,需求重要性的判断标准:用户基数、使用次数和类别重要性。类别重要...

    在实际工作中,经常遇到需求堆积、开发资源有限的情况,要想在这种情况下合理的安排需求,实现价值最大化,对需求进行优先级管理异常重要。

    首先,需求重要性的判断标准:用户基数、使用次数和类别重要性。类别重要性分成基本型、期望型和兴奋行需求三类。

    对于基本型需求,比如产品的性能、安全、浏览器兼容等方面,一旦出现问题,用户不能访问使用产品的情况,应该立马放下手头的工作,利用一切的资源尽快解决这方面的问题,在有的公司成为“911bug”,属于最高级别的bug,优先级最高。比如说网站被黑了,或者使用起来非常慢,用户快崩溃了,这个时候应该想方设法尽快解决,拖的时间越久,用户越容易流失,这基本是一个常识。

    排除上述bug情况,其他需求的优先级排序,有四种依据:频率、开发难度和效果、产品价值、对用户熟悉程度。

    1.看影响面

    采用四象限看用户量和发生频率

    优先解决大量用户的高频问题,基础体验

    最乎解决少量用户的低频问题,超好体验

    2.看开发难度和效果

    采用四象限看开发难度和效果

    优先见效快且开发难度不大的,这就是迭代

    最后做很费劲而且见效慢的,这可能是未来的机会

    3.看产品价值

    这里的价值分为用户价值、商业价值、公司价值三个方面,在判断每一种价值时,考虑”满足了有什么好处,不满足有什么损失“,以此来做出综合判断。

    用户价值,就是这个需求实现了,能够影响多少用户,能够让多少用户更多实用产品。如果有数据指标,如果做了,数据能提升10%。而如果不做,数据导致一定比例的数据减少,长此以往必定流失用户。

    商业价值,对于有商业变现的产品来说,就是这个需求实现了,能带来多少收入。或者如果不做,会损失多少。比如对于内容产品来说,比如站酷网的增加广告新形态需求,基本有单子就一定会做。而对于商业化产品,通常就是那些能刺激用户的各种促销手段。

    公司价值,这里主要指对公司战略目标的影响,通常是产品目标,基本可以量化,比如日活翻番,如果某个需求实现能进一步实现目标,他的重要性和紧急性相对较高。

    通常产品价值综合以上评估,通常以公司价值为主,兼顾考虑用户价值和商业价值。

    4.看你对目标群体的熟悉程度

    你是否深入了解用户使用场景?你对用户群体的理解是否足够了解?如果不熟悉,应该立马想办法去熟悉它。了解清楚以后做决策时更为理性而非拍脑袋。

    基本了解以上4个依据以后,通常需先考虑产品价值,然后根据影响面和开发成本来考虑需求的优先级。

    展开全文
  • 需求优先级该怎么定

    2020-05-18 12:27:50
    一般情况下,我们可能会对接多个需求方的需求,但是他们都说自己的需求紧急程度是 P0,最后汇总到我们这边的需求也都是 P0,此时我们该如何处理? 二、解决方案 可以根据《高效能人士的七个习惯》中的四象限法则,来...
  • 需求优先级管理四步走 需求优先级的管理,其实是为了帮助我们确定先做哪个需求后做哪个需求,从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理,或者更直接来说是优先级顺序管理,我们需要做到...
  • 需求分析 1. 什么是需求分析 1.1 需求类型 1) 任务型需求 - 来自上级的安排,上级通常会参考公司的短期战略规划,制定出近期要完成的任务 - 拿到这个需求,不必和领导讨论这个需求的必要性 - 首先,考虑如何实现,保...
  • 总得有先有后,优先级高的需求优先研发,优先级低的需求延后研发,这样的话就涉及到需求优先级定义的标准了,在产品实践中,很多产品经理都是拍脑门决定先做哪些需求,后做哪些需求,要么就是老板拍脑门决定
  • 从定义需求的优先级也能看出产品经理的能力。在前面已经详细阐述了...这就会涉及需求优先级定义的标准。在产品实践中,很多产品经理都是拍脑门决定先做哪些需求,后做哪些需求,要么就是老板拍脑门决定需求的优先级...
  • 一章中专门介绍了这个模型,这个模型可以作为我们确定需求优先级的一个参考。KANO模型定义了三个层次的顾客需求:基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素...
  • 可是团队资源有限,面对需求池中如此多的需求,如何确定优先级呢?这是很多产品新人面对的困扰。通过和产品组同事一起小圆桌交流讨论,结合自己实际项目经验总结,现将其沉淀下来,并方法论化。  1. 为什么需要...
  • 因为我这边对接的需求方是好几个相对独立的方向,这就导致在每一个需求方眼里,自己的需求都是P0优先级,而最后汇总到我这边时,就会出现所有需求优先级都是高优,需求排期中的优先级因素基本相当于无效。...
  • 在很多时候我们会遇到优先级的问题,比如:1、今天,时间管理,将待办事项根据紧急和重要程度排列优先级,然后根据情况灵活执行。2、今年,我要做一个年度计划,选择些可执行且可量化的事情按照实现...
  • 一、C端需求和B端需求的管理差异 1. 相同点 1)需求管理的目的相同 都是为了集中当下优势资源为服务对象提供有客户价值的需求,对内提高资源利用率,保证产品开发团队良性运营;对外通过提供切实的服务,满足市场...
  • 本节书摘来自异步社区出版社《软件开发践行录——...2.4 理清需求优先级 在频繁上线的项目中,其中一个重要的实践是确定需求的优先级,使得重要的功能能够先得以开发出来投入使用,以便及时收集用户反馈。一般的...
  • 我的主管经常对我们说:产品经理最重要的能力就是判断优先级,不然就不叫产品经理,而是需求经理。以前我听了总是不以为然,觉得判断优先级就是优先做紧急的和实现成本低的需求,毫无技术含量;而设计师需要从用户的...
  • 也许你会要求业务方直接给出需求优先级列表,把任务分为P0到P5,这样的划分除了按需求本质的优先级还同时考虑了开发资源、开发难度等问题。毫不夸张地说,我曾经拿到一张全是P0级别的需求清单,如果一切任务都是高
  • 如果选择了模式一的划分方法,需求分析人员只需要把需求优先级分为高、中、低就可以了。这种方法简便易行,但是划分结果一定要取得的客户的认同。 但是这种方法是不精确的,因此,所涉及到的每个人必须在每种类别的...
  • 一般来说,软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷来源、缺陷原因等。 软件缺陷的主要类型: (1)设计不合理; (2)功能、特性没有实现或部分实现; (3)运行出错...
  • 如何评定产品需求优先级

    千次阅读 2017-10-21 14:41:54
    即使你真的去判断哪些是“必需”,哪些又是“应有”、“可以有”的,但哪些又是“必需功能”必须有的特征呢?哪些功能是你应该放在首要的呢?无论你是否正在进行功能优先级排序,这四个排序方法都值得你一试。 ...
  • 需求优先级排序-迭代期内无变更-团队承诺 是这个生态的主线之一。 让我们重新看一下前面变与不变的例子。 简单粗暴的方法包括“一个强制性的变更或不变更制度”。即在高层领导的支持下(如果他们不支持,大家就放弃...
  • 作为产品经理,平时的工作中会遇到各种各样的需求,如何整理这些需求,以及确定哪些需求是需要马上做的,哪些是可以 推迟实施的,这是一个很重要的点需要产品经理去分配,那么应该如何分配呢? 今天介绍一下KANO模型...
  • 敏捷估计与规划中对优先级进行了描述,优先级由以下四点因素来确定。 获得这些功能带来的经济价值 开发(可能包含支持)新功能所需的成本 开发新功能所产生的学习和知识的量及重要性 开发这些功能所减少的风险...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 73,015
精华内容 29,206
关键字:

判断需求优先级