首页  思维导图  详情

需求管理【方法与实践】

2024-05-17 09:35:50   1  举报





AI智能生成

软件项目需求管理方法与实践

软件工程

软件项目

需求管理

作者其他创作

大纲/内容

需求管理的过程

需求调研（收集需求）

形成需求调研大纲

确定需求调研方法

注意时间、地点和人物

需求分析（定义范围）

Want or Need

强需求 or 弱需求

高频率 or 低频率

定义好对应的可交付成果

需求确认（形成基准）

可视化、可量化

形成书面文件

需求跟踪矩阵（全程跟踪）

正向跟踪

逆向跟踪

需求变更（规范和策略）

规范的流程

多样的策略

需求不要省事，实际中很多项目经理对需求比较马虎，多数从招标文件里面抄，然后马上设计开始开发

需求调研（收集需求）

调研大纲【做好之后发甲方项目经理】

做好之后可以发甲方项目经理，以便用户或甲方就调研所需的资源（如业务人员按时间安排会议室、相关资料）

调研大纲应包含如下内容

调研内容

调研对象

有决定权的领导

业务骨干

最终用户

调研方法

确定你去调研需求要用什么样的形式

需求调研的常用方法

访谈

提出“预设”或“即兴的问题”

头脑风暴

【对客户要慎用，业务人员头脑风暴出100个天马行空的需求，我们都不做，业务人员会骂我们，我们自己也坑了自己】

焦点小组

组织相关方和同职能的主题专家

我们的能力往往组织不起来焦点小组讨论，需要借力甲方项目经理

引导式研讨会

JAD或者用户故事

跨部门之间的需求需要引导客户

谨慎使用这个方法，当客户内部不一致时我们往往由甲方项目经理出面，因为客户内部的矛盾点，如果我们参与过多可能会被当枪使，满足一个部门的需求往往得罪另一个部门，因此谨慎使用

观察法

当客户没时间理我们的时候我们可以观察客户的业务

原型法

手绘->低保真->高保真

分支主题

调研注意事项【参考麦肯锡方法】

事先梳理

事先梳理相关需求，提出建议的解决方案，引导为主

统一接口

甲方最好能统一对接出口，避免甲方各个部门提出矛盾的需求，更不要陷入甲方内部斗争

平等合作

乙方是来与甲方探讨问题的，既不是来接受问题的，也不是来指导工作的

术语标准

学习和使用相关术语和标准，以便能够准确的理解客户

深挖需求

调研阶段主要弄清楚Why，而不是着急去明确how

复述总结

调研结束后，最好复述一下相关内容，避免理解的偏差

【需求调研只收集需求，收集完了抓紧确认，不要把需求和设计混在一起】

需求分析（定义范围）

一定要问：为什么要做这个需求

我们要区分多种客户提出需求的真实情况

福特：为什么要一匹更快的马？

客户：因为可以跑得更快！

福特：你为什么要跑得更快？

客户：因为我要尽早的目的地

福特：所以你要一匹快马的目的是？

客户：用更短的时间到达目的地

真实需求和伪需求

强需求和弱需求

强需求：必须要有

弱需求：要是要，但是优先级不高

高频需求和低频需求

高频需求：使用的次数很多，不一定优先级很高，但是平时用的很多，比如登录这样的功能

低频需求：比如注册功能，做一次就不再做了

相关方需求和解决方案需求

客户是真正的要解决问题？还是客户借着新需求的名义难为我们？

MoSCoW法【需求优先级排序】

MoSCoW法

Must

必须要完成的需求

必须要做的功能

一般是强需求或高频次需求

Should

应该做的需求，但是可进行协商，或者考虑其他备选方案，一般是弱需求

Could

不太需要的，或者很少用到的，有了更好，一般是低频次需求

Would Not

不应该做的需求，通常是不切实际的，范围外的或者是伪需求

【需求优先级排序，做都要做，但是怎么做？要抓重点，通过排需求优先级便于我们以后管理进度，进度管理的原则就是”要事第一“】

有和没有，好和不好是两码事，先保证有东西让业务转起来，做的好不好再优化，可以给客户说我们做了第一版，后面还可以再优化，但是如果什么都没有没发给客户解释【完成比完美重要！】

需求确认（形成基准）

需求文档【需求规格说明书】（有模板）

创建

定稿

评审

确认

如果允许让客户签字确认，最好是要签字

需要谁签字？

甲方项目经理

业务部门

乙方项目经理

当我们需要客户签字，但是客户不签字怎么办？

首先考虑客户为什么不签字

需求没搞清楚

怕承担责任

用什么办法让客户签字

需求没搞清楚

面对面聊直到清楚

怕承担责任

打消顾虑：需求经过双方努力形成了基准，后续可通过变更流程增加新需求

实在没辙找甲方项目经理或者甲方业务领导，但是不是去告状，可以说成”我们和业务部门需求已经定下来了，这个项目我们公司还很重视，您看是不是有时间和我们一起过一遍帮我们把把关“。开完这个会，立马打出来会议纪要签字【可以诉诉苦：我们公司对重点项目的文档和标准管的很严，对于这些文档我们都需要提交上去，不然会考核我们（把锅甩给公司，因为客户不可能去公司核实）】

找要政绩的那个领导

规规矩矩的开评审会【除非我们特别需要这个文档】

尽快定下来需求规格说明【基准】，有了基准的需求变化叫变更可以走流程、没有则不算，因此要尽快

控制范围

控制范围的常见策略

推二期

如果可以放到二期去做的，尽量放到二期，甚至可以配合客户进行相关申报

做交换

如果有优先级比较高的需求，可以牺牲cloud，在必要的时候可牺牲should【做事情不要迂腐】

谈弱化

如果不能牺牲低优先级的需求，可以尝试弱化一些功能，降低期望，最终达成一致

查人品