第1个回答 2022-07-21
以斐波那契数列为例，介绍需求 工作量的估算。
案例：以斐波那契数列估算需求工作量
1.选定参照物
选择一个中等工作量的功能或需求作为参照物，视为数字5、这里以微博的登录功能为例，功能主要有账户与密码的验证，记住登录状态，取回密码的功能，登录功能的工作量视为数字5，这个数字5是工作量的参照数字，以它作为基准。
2.团队成员定义工作量
以5-7人组成团队，每个人用菲波那契数列的数字1、2、3、5、8、 13 、21、...定义当前需求或功能的工作量，当然是基于当前需求或功能的工作量，当然是基于与参照物数字5的对比。如果登录功能的工作量是5，那么发布微博的功能工作量有多大，5位团队成员分别给出数字答案：34、55 、89 、144 、 233 。可以看出，5位成员给出的答案分歧很大。
3.进一步明确需求
如果团队成员的分歧很大，需要澄清和进一步明确需求。分歧很大的原因是没有明确发布微博到底有哪些主要功能，这与在实际的产品工作中遇到的问题是一样的，只说产品要做某个功能，大概说了一下，就询问研发人员的工作量有多大，研发人员也估算不出来，因为需求不明确，所以当成员之间的数字分歧比较大时，需要相关人员明确到底有哪些功能，比如发布微博的主要功能有：发布有140个字文本的微博、发布一张图片微博、发布音乐、视频、话题和投票微博，需要有敏感词过滤功能，一段时间内不能发布相同的微博，账号被封的用户发布不了微博。明确主要功能之后，成员再次给出估算数字，这一次大家的答案是：34、 55 、55 、55 、89。从答案可以看出，这一次团队成员的分歧不是很大。
4.确定结果
如果团队成员的分歧不大，使用较高的那个数字作为需求或功能的工作量，或者使用出现次数较多的数字作为工作量。选取55作为发布微博功能的工作量，因为这个数字出现了3次。
按照上述方法逐条对需求定义其数字。通过这种方法，我们还可以估算转发、评论、私信等功能的工作量。
需求变更
产生需求变更在实际的产品工作中是正常的，没有需求变更是不正常的。导致需求变更的主要原因有产品经理自己都没有想清楚，需求文档有逻辑漏洞，不细致，不准确；也有产品经理的“完美主义”情结在作怪；再有就是技术能力和资源的问题，要对变更的需求进行评估，需要评估影响的范围有多大，是否有必要进行变更，确定需要变更时，是一定要在当前这个迭代变更，还是可以放到下个迭代进行变更，哪怕是进行一个小的迭代也行。在需求已经通过评审并进入项目环节时，尽量减少不必要的需求变更。
一旦确定需求需要变更，通常要以口头和书面文档形式通知相关人员。一下是需求变更表。这些内容要方便相关人员都能及时获取。
需求管理工具
需求管理起源于需求获取，终结于需求的关闭，产品经理需要跟踪需求的进展和状态。需求获取指的是需求采集表。需求管理的过程与终结如表。
具体内容描述如下。
编号：需求的唯一数字标识，便于统计。
提交人：负责录入和解释需求。
版本：所属的版本号。
模块：产品的功能模块。
名称：简要概括需求的主体特征。
描述：需求的主要描述。
任务类型：新增功能、功能改进、体验提升、Bug修复、内部需求等。
Ticket编号：需求或Bug对应在Trac、Jira等管理工具上的编号。
需求评审完成时间：需求文档经过评审，获得通过的时间。
技术评审完成时间：技术人员接收到需求之后，设计技术方案完成并通过评审的时间。
技术提测开始时间：编码完成，可以提交给测试人员开始测试的时间。
需求优先级：商业价值，即重要性+紧急性，5点度量，从1到5,5最高。
研发优先级：投入产出比，商业价值/工作量，5点度量，从1到5,5最高。
状态：需求生命周期，包括待讨论、暂缓、拒绝、需求中、开发中、设计中、测试中、已发布等。
负责PM：状态进入“需求中”后确定。
UED设计师：状态进入“设计中”后确定。
开发工程师：状态进入“开发中”后确定。
测试工程师：状态进入“测试中”后确定
发布时间：需求的发布时间。
备注：其他信息，如被拒绝的理由、被暂缓的理由和重启条件、其他等。