优界网

首页 > 产品经理 > 需求管理:确认、跟踪、变更控制

需求管理:确认、跟踪、变更控制

94

0

0

2015-06-12 01:53:06

萤火

分享一下,又不会怀孕!

本作品为转载作品,版权为作品原作者所有,感谢上传者的分享!

1、需求确认(评审和承诺)

需求确认是指开发方和需求方共同对《产品需求规格说明书》进行评审,双方对需求达成共识后作出承诺。需求确认包含两个重要工作:“需求评审”和“需求承诺”。

2、需求评审面临的困难

需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味,也比较费脑子。刚开始评审时,大家都比较认真,越到后头越马虎。 需求评审涉及的人员可能比较多,有些时候让这么多人聚在一起花费比较长的时间开会并不容易(例如有些人可能出差在外,有些人可能事务缠身)。没有必要把所有事情挤在一块做,需求开发是循序渐进的过程,需求评审也可以分段进行。这样每次评审的时间比较短,参加评审的人员也少一些,组织会议就比较容易。 开评审会议时经常会“跑题”,导致评审效率很低。有时话匣子一打开后关不上,大家越扯越远,结果评审会议变成了聊天会议。主持人应当控制话题,避免大家讨论与主题无关的东西。

开评审会议时经常会发生争议。适当的争议有利于澄清问题,比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了,争吵不仅对评审工作没有好处,而且会无意中伤害同事们的感情。在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯:不要一棍子打死异己的观点,尝试着让自己站在他人的立场思考问题,这样你会找到比较满意的答案。

3、需求承诺

需求承诺是指开发方和需求方的责任人对通过了正式技术评审的《产品需求规格说明书》作出承诺,该承诺具有商业合同的效果。
需求承诺的“八股文”如下:本《产品需求规格说明书》建立在双方对需求的共同理解基础之上,我同意后续的开发工作根据该《产品需求规格说明书》开展。如果需求发生变化,我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。在作出承诺之前务必要认真阅读文档,一定要明白签字意味着什么。

4、需求跟踪

需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性,确保所有的工作成果符合用户需求。需求跟踪有两种方式:

正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵(即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系

5、需求变更控制

需求发生变更的起因主要有: 随着项目的进展,(包括开发方和客户方)对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足,因此要变更需求。市场发生了变化,原先的需求文档可能跟不上当前的市场需求,因此要变更需求。提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。对项目开发小组而言,变更需求意味着要调整资源、重新分配任务、修改前期工作成果等,开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话,这个项目也许永远不能按时完成。

需求变更控制的目的: 如果需求变更带来的好处大于坏处,那么允许变更,但必须按照已定义的变更规程执行,以免变更失去控制。 如果需求变更带来的坏处大于好处,那么拒绝变更。需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的,但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”:

开发方与需求方达成“事不过三”的约定(符合中国人的习惯),即允许变更三次需求;如果第四次变更需求,开发方有权拒绝,除非需求方愿意补偿开发方的损失。如果事先没有“游戏规则”的话,开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时再修改需求。

已有0人赞过

+1赞

认真评论的都成大咖了

还可输入1000个字

我要评论 我要评论
  • 刚刚
  • 登录优界网 ×