新人工作心得与需求排序方法

　　转眼间已经工作4个月、1/3年，时间不长也不短，最近开始写博客园，想培养这样的习惯，因此将这几个月的工作总结作为开篇。                       ---开始写的原因

第一部分  工作中的处事原则

　　工作中始终记住并提醒自己的一句话是：凡事要闭环。其实闭环这个概念挺简单，通俗点讲就是有始有终，说的更详细就是：凡事有交代、件件有着落，事事有回音。

　　不要觉得“形式主义”没有用，工作中发现这些一听就明白的道理如果背会比简简单单读过就忘要有效得多，所以每天都提醒自己，是不是有工作消息没有交代清楚，是不是有未做完而搁浅的事情。

　    作为新人要勇于提出自己的不懂问题，千万不要不懂装懂，哪怕在项目会议上因为觉得丢脸而不敢问，下去也要自己百度或者请教弄明白。

        作为新人要多跟同事沟通，尤其是自己的上司，不然你们相互脱轨会让他产生困惑，不知道你的情况，涉及到工作的邮件最好抄送给他，同时对于解决不了的困难要及时向他提出，一般情况下他会给予支持。

第二部分 工作的流程

　　我前后大概花了两个月的时间，我才弄懂了自己整个工作流程，作为沟通最为频繁的产品，刚入职便接受了一个跨部门的需求，这个经历一方面挺考验人，另一方面也让我能更快的熟悉整个部门的业务流程，于是，我将整个的工作从输入到输出最终做了一个完整的流程图，如下图一。

图片1

　　从需求的提出到最后产品的上线，通过红框的方式标注了自己参与的部分并说明，当然这样的流程是最为理想的过程，在整个过程中会涉及到很多不同的问题需要灵活处理，在以后的总结中继续丰富工作流程。

第三部分 工作的方法之需求排序

  　  对于工作方法也大部分都是从网上习得的理论知识，目前了解到的主要是粗浅的、零碎的、不成系统的方法。

　　首先是需求排序的方法，这是工作的起始端，拿到需求以后，针对需求进行排序，目前了解到的是以下三个方法：SUD方法、RICE方法以及KANO模型。

        3.1 SUD方法

       该方法来源于网友海星的总结，觉得讲的清晰以及比较有道理因此记录下来，简单来说SUD为英文Strategy、User、Difficult三个单词的首字母，Strategy即为战略层，User即为用户影响层、Difficult即为技术难度层。

　　谈到Strategy，首先我们需要明白自己产品的战略层（产品定位与市场定位--来源《用户体验要素》点击可浏览本书简要框架），弄清楚自己产品的核心模式，明白现阶段产品的主要目标是什么，比如作为电商，我们最核心的目标就是GMV的提升，而GMV等于UV、转化率、客单价的乘积。这三个因素都与最终的GMV呈现正相关，但是每个阶段的核心目标也有所区分，比如最近的核心目标是拉新，则UV的优先级要高于另外两个因素，因此分享功能要比商详优化更为重要，针对近期的需求排出优先级S1、S2、S3。

　　谈到User即用户影响，首先这是一个十分宏大的课题，关于用户研究的书籍理论市面上可以找出一仓库，其实每一本书都有道理，这里不去具体的谈对用户影响的需求具体由那些，我们从两个维度去进行区分需求：重要程度、紧急层度，因此可以通过四象限发展及如下图二。

　　具体，判断重要程度按照以下原则（判断准则引用自刘飞在知乎的回答： 作为产品经理，你是如何分析和管理你的产品需求的？）

　　1 不做会造成严重的问题和恶劣的影响的

　　2 做了会产生巨大好处和极佳效果的

　　3 跟重要合作对象或投资人有关的

　　4 跟核心用户利益有关的

　　5 跟大部分用户权益有关的

　　6 跟效率或成本有关的

　　7 跟用户体验有关的

　　判断紧急程度按照以下原则：

　　1 不做错误会持续发生，造成严重影响

　　2 在一定时间内可控，但长期会有糟糕的影响

　　3 做了立刻能解决很多问题、产生正面的影响

　　4 做了在一段时间后可以有良好的效果

　　根据重要和紧急程度，给产品划出优先级排序U1，U2，U3。

　　谈到技术难度，则需要在拿到需求以后与研发同时沟通，了解开发的投入，重点确定以下三个方面的问题及：

1. 这个功能咱们能不能实现？
2. 能实现的话，需要多少人多长时间？
3. 有没有其他实现的建议或者方案？

　　从技术部门同事那里帮你判断了需求实现的容易程度：D1,D2,D3。

　　这样你就得到一张从三个维度判断需求优先级的表格了：

	S	U	D
需求1	S1	U2	D1
需求2	S2	U1	D2
需求3	S3	U1	D3

　　这样是不是需求的优先级就非常明确了呢

　　3.2 RICE方法

       

　　RICE 是评估每个项目的四个因素首字母缩写：Reach（接触数量），Impact（影响程度），Confidence（信心指数）和 Effort（投入精力）。

Reach（接触数量）

为避免因自己的使用习惯造成的偏差，请估计每个项目在一定时间段内会影响多少用户。对于我的团队来说，这意味着「一个季度内，有多少个用户会受到这个项目的影响」。

接触数量用每个时间段的用户数或事件数来衡量。这可能是「每季度客户数量」或「每月交易数量」。尽可能使用产品指标的实际测量结果，而不是随机去拍一个数。

举例：

• • 项目 1：500 个客户每月在注册漏斗中达到此点，30％ 选择此选项。每季度的接触数量是 500×30％×3 = 450 个客户。

  • 项目 2：每季度使用此功能的每个客户都将看到这一变化。每季度的接触数量是 2000 个客户。

  • 项目 3：这一变化将对 800 个现有客户产生一次性影响，而且没有持续的影响。每季度的接触数量是 800 个客户。

Impact（影响程度）

要专注于那些能对你的目标产生可观影响的项目，预估这个项目对个人产生的影响。对于我的团队来说，这就是「当客户遇到这个项目时，能够提高多少转换率？」。你的团队可能会用另一个目标，比如「提高采用率」，或者「最大化满意度」。

影响程度难以准确度量。因此，我设置了一些选项来衡量：3 为「巨大影响」，2 为「高」，1 为「中」，0.5 为「低」，最后 0.25 为「最低」。我们在计算最后 RICE 得分时会乘以这些数字来按比例放大/减小。

选择一个数字来预估影响程度看起来可能不太科学。但是别忘了它替代的是另一种估算方式：拍脑袋。

举例：

• • 项目 1：对于每个看到它的客户，这将产生很大的影响。影响程度是 3。

  • 项目 2：这将对每个客户产生较小的影响。影响程度是 1。

  • 项目 3：这在影响方面处于中间位置。影响程度是 2

Confidence（信心指数）

有些主意非常激动人心但是并不明确，为了遏制住马上去实践它们热情，在评估时请把信心指数考虑进去（我们认为这个功能能实现 R 和 I 的自信程度）。如果你认为一个项目可能会产生巨大的影响，但没有数据可以支撑，那么信心指数会让你更有掌控力。

信心指数是一个百分比，我设置了另一种选项来避免决策瘫痪。 100％ 是「高信心度」，80％ 是「中等」，50％ 是「低」。比这更低的信心指数都可以认为是「登月计划」。对自己诚实一点：你的预估真的可靠吗，有多少论据支撑呢？

举例：

• • 项目1：我们有定量指标来衡量接触数量，有用户研究来证明影响程度，还有工程预估会投入的精力。这个项目的信心指数是 100％。

  • 项目2：我有数据支撑接触数量和投入精力，但我不确定项目的影响会是什么程度。这个项目获的信心指数是 80％。

  • 项目3：这个项目的接触数量和影响程度可能低于预期，需要投入的精力则高于预期。这个项目的信心指数是 50％。

Effort（投入精力）

为了迅速行动并且事半功倍，请估算项目需要团队的所有成员（产品，设计和工程）的总时间。

投入精力的预估单位是「人/月」 ： 一个团队成员可以在一个月内做的工作。这里有很多未知数，所以我用整数来预估（一个月以下的任何事情都用 0.5 来预估）。不像其他的积极因素，需要投入更多的精力是一件「坏事」，它会作为整体影响力的分母。

举例：

• • 项目 1：这个项目需要约一周时间做计划，1- 2 周的设计和 2-4 周的研发时间。预估的精力投入是 2 人/月。

  • 项目 2：这个项目需要几周时间做计划，大量的设计时间和一个工程师至少两个月的时间。预估的精力投入是 4 人/月。

  • 项目 3：这只需要一个星期的计划，不需要新的设计，几周的工程时间。预估的精力投入是 1 人/月。

结合所有因素得到 RICE 分数

快速总结我们的四个因素：

• • R 接触数量：这个项目会影响多少用户？ （在限定的时间内估计）

  • I 影响程度：对每个用户的影响程度是怎样的？ （巨大影响 = 3x，高 = 2x，中 = 1x，低 = 0.5x，极低 = 0.25x。）

  • C 自信指数：你对自己的预估有多少信心？ （高 = 100％，中 = 80％，低 = 50％）。

  • E 投入精力：项目需要多少人/月？ （使用整数，最少为 0.5 人/月）

一旦你完成了这些因素的预估，把它们合并成一个单一的得分，这样你就能一目了然的比较不同项目的分数了。这是简单的公式：

一旦最初的评分完成，排序你的项目表单，并重新评估。有没有哪些项目的分数似乎太高或太低？如果是的话，重新考虑你的估算并做出调整，或者接受你的直觉可能是错误的。

在决定难以比较的项目想法时，RICE 可以提供极大的帮助。它迫使你思考为什么一个项目的想法会产生影响力，并且诚实地估计为达到目标所需的努力。

有效地使用 RICE

当然，RICE 分数不应该作为一个硬性规定。有很多原因可以让你先去做一个得分较低的项目上。一个项目可能是另一个项目的依赖项，所以它需要先发生，或者另一个项目可能是我们为了卖给某些用户的「赌注」。

有时你可能想要或者需要去做那些「无序」的项目。没关系！使用评分系统，你可以清楚地确定你什么时候可以做这些取舍。 ---rice部分转载自https://36kr.com/p/5140965.html

3.3 KANO模型

　　关于KANO模型的解释，以下这篇文章十分完整的解答了整个模型原理、使用方法以及局限性，点击衔接查看https://www.jianshu.com/p/131a947def2c