乐虎网IT需求管理流程

汇银 管理

原则

需求管理流程原则是增加需求列表透明度，消除领导、需求方、技术之间的信息不对称，做出最终决策和取舍。

1 讲故事

    一个故事就是描述谁，在什么情况下，想做什么事，为什么想这么做。每个人都可以随时随地向产品经理讲述，也可以在讨论会上讲述。

1.1 故事例子：

• 我是品管，昨天有个订单仓库没货了，所以一直没审核，后来也不知道什么时候有货，这个订单就被遗忘了，我想要能及时发现这个问题，比如仓库有货了给我发个通知。
• 我是用户，我的评论列表里有些发错的内容，我想删掉一些，但是我怕误删，应该在删之前给我弹个提示。

1.2 注意：

    故事只描述情景和问题，涉及的改进建议仅供参考。比如上例用户描述：我想要一个消息提醒，仓库有货了给我弹消息。我要删评论之前需要个提示。仅供参考，不能全盘照做。
    如何解决问题，是产品经理要全面考虑的，而不是头痛医头脚痛医脚，用户说要什么就照做，具体见需求。
    产品经理听完，想完，整理。在进一步分析前不向需求方反馈结论，定方案，做计划。

2 提需求

    正式需求由产品经理提出，通过各种故事收集整理以后，产品经理要与讲述人进一步交流，充分深入了解、思考和讨论问题的解决办法。

2.1 对问题的解决方案例子：

1. 品管可以将订单设置为库存暂缺状态，可以通过该状态条件搜索订单，该状态下可以进行审核，库存到货再通过审核，理由：提醒只起辅助作用，能随时找出这类问题订单更重要。
2. 对超出时限仍未到货的商品高亮及站内信提醒。时限要可以设置。

3. 增加评论回收站，删掉的评论可以从回收站找回来，删除之前不需要做提示，理由：提示被熟视无睹后基本没用，误删只是少数情况，全部做提示影响体验。

   以上为产品经理经过思考后得出的解决方案，将用于整理需求明细表。
   

2.2 注意：

    有的需求是产品经理对故事进行了提炼而产生的，还有的需求是通过自身思考，数据分析以后提出来的。
    并不是一个故事对一个需求，有可能几个故事用一个需求解决，也有可能一个故事要分好几个需求解决。
    需求方案出来以后要征求原始需求方的意见，同意才确定需求。

3 需求分解评估

    产品经理对需求进行细分，征求技术人员意见，整理出需求明细表。

3.1 需求明细表例子

...
这张表要给需求原始提出方确认，以及给技术人员评估开发量。

4 需求评审

    对整理出来的需求，进行几个重要指标的评估，包括重要性、紧急程度、持续时间、商业价值。

4.1 需求指标

• 重要性，代表这个功能对系统整体有多重要，比如订单审核功能就比库存暂缺提醒的重要性高，因为前者是订单流程必不可少的一环。
• 紧急程度，代表功能的完成时间需求，下周要进行抽奖活动，要开发抽奖功能，就比下个月有双十一，要开发双十一专题频道要紧急。
• 持续时间，这个功能的有效使用期，比如抽奖是长期活动，双十一专题是一次性活动，有效期大约一周（明年双十一未必会再这么干）。
• 商业价值，前三个指标，都是用来评估商业价值的参考项，经过评审会充分讨论后，站在公司利益角度，主观判定的一个需求的商业价值，可以用数值表示。

4.2 评审表例子：

这张表用来开评审会议，会前填满除了商业价值以外的所有项，商业价值会上讨论后定。

4.3 注意：

    重要性指标由产品经理根据功能必要性来判断，时间要求和持续性由原始需求方提出，开发周期由技术人员评估，这几项在完成需求细化过程中就填写完毕。
    商业价值在需求评审会上经过充分讨论后，由与会的最高决策者决定，有异议的需求可以表决。

4 需求拍板立项

    需求评审表完全完成以后，将商业价值确定，交由大领导最后拍板优先级，如无特别理由基本参照商业价值。
    得到最终优先级以后，技术团队按顺序消化需求，将当前可用人手资源排满，得出一个计划时间表，立项结束。
    无合适技术人员的需求，将被延后，可能因为开发人员对系统熟悉度，及专业领域不同，导致部分高优先需求被排到低优先需求后面。

4.1 待办需求表

这张表是领导最终签字拍板的结果。

4.1 技术计划安排原则

• 优先级最高的先安排开发资源
• 下一个需求当前已经没有足够开发资源时跳过，再看更下一个需求是否能做
• 在剩余开发资源已无法满足时间要求时，安排评审协商是前面的需求让路，还是跳过，看下一个需求

5 需求进度汇报

    每周需求评审会例程包括需求进度汇报

5.1 需求进度表