项目需求工作如何开展
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
客户有时提的是“方案”而不是“需求”，我们要理解其“表面需求”背后 的“真正需要”
法则3：明确限制条件
客户的“自助餐”心态 -- 我要吃好、吃多! 你要告诉他： 没有龙虾! 没有鲍鱼!只能吃半小时!
常见限制条件： ➢ 工期、预算、与三方系统的关系
项目组要明确限制条件，同时也要让客户和Boss们知道限制条件。
需求调研的过程就是持续确认需求的过程!
法则6：避免“二手需求”
业务部门 <----> IT部门 <-----> 项目组 需求负责人 <----> 开发人员 <-----> 测试人员 避免项目组内的“二手”甚至“多手”需求!
法则7：成为业务专家
是否遇到过这样的问题? 客户总是抱怨产品不好用; 反复修改，客户仍然说不好用!
这些需求会影响到产品的技术架构、后台处理方式、数据库设计等内容， 需要提前与开发、运维人员协调，确保技术可行性
需求确认技巧
➢ 需求分析的过程就是与客户持续确认理解的过程，确认不是最后才进行的。 （确认方式有: 1、需求调研表，客户签字。2、会议记录，与会者签字。3、邮件确 . 认。4、中间文件的确认）
➢ 项目组应主动与客户确认，可用各种非正式的确认方式。 如：某次口头沟通后，对某些问题达成一致，可将这些内容Email给客户确认 如：确认某业务概念或流程后，将图打出来再次与客户确认，让客户签字。
➢ 从谁那里获取需求，就向谁确认。 ➢ 向客户澄清 ： 项目组也需要签字，签字不代表不可 以 变化，而是表示到签字这
(6) 避免“二手需求” (7) 成为业务专家 (8) 团队作战效果更好 (9) 七分需求分析，三分需求管理
(5) 持续确认需求
02 需求分析
需求分析全过程 需求确认技巧
非功能性需求
需求分析过程（一）
需求分析过程（二）
非功能性需求
➢ 性能 ➢ 安全性 ➢ 可维护性、可扩展性 ➢ 易用性 ➢ 兼容性 ➢ 容量 ➢ 网络环境
法则4：先做“加法”再做“减法”
对应做法： ➢ 头脑风暴法、角色分析(加法) ➢ 根据限制条件进行取舍(减法)
好处： 1、让项目团队思路清晰 2、充分思考和平衡角色诉求 3、不会遗漏重要的和最基础的需求
法则5：持续确认需求
常见问题： 几十页甚至上百页的需求规格说明书，如何让客户确认?
思考： 这几十上百页的需求文档是闭门造车写了N天后，才给客户确认的吗?对于 客户来说，该文档是从天而降，他之前没有见过其中任何的内容吗?
发生需求变更时，应对步骤是怎样?
Step0：做好需求变更预防工作 . Step1：看项目当前所处的阶段
Step2：确定引起需求变更的原因 Step3：各方沟通，评估对项目成本的影响 Step4：决定应对策略
一看阶段，二看原因，三看影响，四定策略
需求排期
（1）需求拆解 ---- WBS工作分解结构 . （2）人员安排 ---- 项目成员技能矩阵
（3）工时估算 ---- 三点估算法 （4）优化总工期 ---- 关键路径法
需求跟进与验收
1、解答开发人员的疑问
.
2、随着开发的深入，及时优化和调整不合理的需求 3、跟进需求完成情况 4、对需求变更的控制 5、确认设计稿 6、产品功能验收
需求变更管理
变更 原因
>
管理 目标
>
应对 策略
>
应对 步骤
需求变更概述
范围 镀金
项目团队超出范围定义，主动增加额外的工作而得不到任何经济补偿 的行为。
范围 蔓延
被动的未经变更程序批准的增加功能。
➢ 如何避免：在未获变更批准前不做该工作。 ➢ PMI理念：永远不要做额外工作
需求变更管理的目标
需求变更有哪些应对策略？
➢ 需求工作少投入1小时，将来工作量可能会增加数倍 ➢ 作为项目范围基准，需求变更可谓：“牵一发而动全身” ➢ 需求工作量占项目工作量20%+
法则2：理解清楚真正需要
春运期间关于铁路乘客的需要，哪个合适? A、我需要网上订票功能 B、可以查询班次，可以网上支付，能记住我的使用习惯，最好不 用登录(因为我经常忘记密码)，系统不会挂掉… C、我希望可以方便地买到票 D、我希望可以回家过年 E、我希望过年时能和家人在一起
需求分析的两种层次: ➢ 落后模式：客户说啥，我们做啥 ➢ 先进模式：成为业务专家，给客户带来价值!
法则8：团队作战效果更好
一、需求工作必须解决的两个难点： ➢ 全面准确地捕获需求 ➢ 将需求准确无误地传递给其他项目成员
二、团队作战基本策略 ➢ 需求负责人：搞定用户需求 ➢ 其他成员：导出软件需求
需求 管理
对需求的实现、变化进行追踪，确保开发的产品满足需求。
需求工作的实用法则
1、需求工作不能节省 2、理解清楚真正需要 3、明确限制条件 4、先做“加法”再做“减法” 5、持续确认需求 6、避免“二手需求” 7、成为业务专家 8、团队作战效果更好 9、七分需求分析，三分需求管理
法则1：需求工作不能节省
刻为止，咱们双方达成的一致理解。
03 需求管理
需求日常管理
需求变更控制
需求日常管理
需求池
>
优先级
>
需求 排期
>
跟进与 验收
需求优先级--MVP法
MVP(最小可用产品) . （1）罗列出预期的方案
（2）从最不重要的功能开始砍掉 （3）直到再砍下去，流程就无法正常运转起来，产品无法正常使用 为止 两个原则： 1、所有的环节，能省则省; 2、每个环节上，能省则省，只保留最核心的用户故事。
法则9：七分需求分析，三分需求管理
错将需求分析的问题归咎为需求管理的问题 ➢ 不首先从自身找原因，一味归责客户。 ➢ 大部分问题产生的根源是我们需求分析工作不到位。 忘记了“双赢”原则。 “双赢”是指客户和我们都能“赢”! ➢ 要让客户能“赢”，客户才可能让我们“赢”! ➢ 绝大部分客户并不是只追求“单赢”的，与我们产生矛盾的主要原
因是我们没能满足客户的“温饱”级别的需要。
有好的需求分析基础，才有好的需求管理
回顾
1、理解需求工作：
➢ 需求工作不是客户叫你做啥你就做啥;
➢ 我们是专业人士，给客户带来(创造)价值才是我们需求工作的核心
本质!
2、需求工作的九大法则：
(1) 需求工作不能节省 (2) 理解清楚真正需要 (3) 明确限制条件 (4) 先做“加法”再做“减法”
项目需求工作如何开展
分享人：XXX
引言
项目成功的基本要素： ➢ 时间 ➢ 成本 ➢ 质量
项目管理的目标：平衡三者之间的关系，使之达到最佳效果
目
01 理解需求工作
录
02 需求分析
03 需求理
01 理解需求工作
需求工作概述 实用法则
需求工作包括：
需求 分析
需求的收集、分析、整理、验证、编写，最终形成需求规格说明书。
法则3：明确限制条件
客户的“自助餐”心态 -- 我要吃好、吃多! 你要告诉他： 没有龙虾! 没有鲍鱼!只能吃半小时!
常见限制条件： ➢ 工期、预算、与三方系统的关系
项目组要明确限制条件，同时也要让客户和Boss们知道限制条件。
需求调研的过程就是持续确认需求的过程!
法则6：避免“二手需求”
业务部门 <----> IT部门 <-----> 项目组 需求负责人 <----> 开发人员 <-----> 测试人员 避免项目组内的“二手”甚至“多手”需求!
法则7：成为业务专家
是否遇到过这样的问题? 客户总是抱怨产品不好用; 反复修改，客户仍然说不好用!
这些需求会影响到产品的技术架构、后台处理方式、数据库设计等内容， 需要提前与开发、运维人员协调，确保技术可行性
需求确认技巧
➢ 需求分析的过程就是与客户持续确认理解的过程，确认不是最后才进行的。 （确认方式有: 1、需求调研表，客户签字。2、会议记录，与会者签字。3、邮件确 . 认。4、中间文件的确认）
➢ 项目组应主动与客户确认，可用各种非正式的确认方式。 如：某次口头沟通后，对某些问题达成一致，可将这些内容Email给客户确认 如：确认某业务概念或流程后，将图打出来再次与客户确认，让客户签字。
➢ 从谁那里获取需求，就向谁确认。 ➢ 向客户澄清 ： 项目组也需要签字，签字不代表不可 以 变化，而是表示到签字这
(6) 避免“二手需求” (7) 成为业务专家 (8) 团队作战效果更好 (9) 七分需求分析，三分需求管理
(5) 持续确认需求
02 需求分析
需求分析全过程 需求确认技巧
非功能性需求
需求分析过程（一）
需求分析过程（二）
非功能性需求
➢ 性能 ➢ 安全性 ➢ 可维护性、可扩展性 ➢ 易用性 ➢ 兼容性 ➢ 容量 ➢ 网络环境
法则4：先做“加法”再做“减法”
对应做法： ➢ 头脑风暴法、角色分析(加法) ➢ 根据限制条件进行取舍(减法)
好处： 1、让项目团队思路清晰 2、充分思考和平衡角色诉求 3、不会遗漏重要的和最基础的需求
法则5：持续确认需求
常见问题： 几十页甚至上百页的需求规格说明书，如何让客户确认?
思考： 这几十上百页的需求文档是闭门造车写了N天后，才给客户确认的吗?对于 客户来说，该文档是从天而降，他之前没有见过其中任何的内容吗?
发生需求变更时，应对步骤是怎样?
Step0：做好需求变更预防工作 . Step1：看项目当前所处的阶段
Step2：确定引起需求变更的原因 Step3：各方沟通，评估对项目成本的影响 Step4：决定应对策略
一看阶段，二看原因，三看影响，四定策略
需求排期
（1）需求拆解 ---- WBS工作分解结构 . （2）人员安排 ---- 项目成员技能矩阵
（3）工时估算 ---- 三点估算法 （4）优化总工期 ---- 关键路径法
需求跟进与验收
1、解答开发人员的疑问
.
2、随着开发的深入，及时优化和调整不合理的需求 3、跟进需求完成情况 4、对需求变更的控制 5、确认设计稿 6、产品功能验收
需求变更管理
变更 原因
>
管理 目标
>
应对 策略
>
应对 步骤
需求变更概述
范围 镀金
项目团队超出范围定义，主动增加额外的工作而得不到任何经济补偿 的行为。
范围 蔓延
被动的未经变更程序批准的增加功能。
➢ 如何避免：在未获变更批准前不做该工作。 ➢ PMI理念：永远不要做额外工作
需求变更管理的目标
需求变更有哪些应对策略？
➢ 需求工作少投入1小时，将来工作量可能会增加数倍 ➢ 作为项目范围基准，需求变更可谓：“牵一发而动全身” ➢ 需求工作量占项目工作量20%+
法则2：理解清楚真正需要
春运期间关于铁路乘客的需要，哪个合适? A、我需要网上订票功能 B、可以查询班次，可以网上支付，能记住我的使用习惯，最好不 用登录(因为我经常忘记密码)，系统不会挂掉… C、我希望可以方便地买到票 D、我希望可以回家过年 E、我希望过年时能和家人在一起
需求分析的两种层次: ➢ 落后模式：客户说啥，我们做啥 ➢ 先进模式：成为业务专家，给客户带来价值!
法则8：团队作战效果更好
一、需求工作必须解决的两个难点： ➢ 全面准确地捕获需求 ➢ 将需求准确无误地传递给其他项目成员
二、团队作战基本策略 ➢ 需求负责人：搞定用户需求 ➢ 其他成员：导出软件需求
需求 管理
对需求的实现、变化进行追踪，确保开发的产品满足需求。
需求工作的实用法则
1、需求工作不能节省 2、理解清楚真正需要 3、明确限制条件 4、先做“加法”再做“减法” 5、持续确认需求 6、避免“二手需求” 7、成为业务专家 8、团队作战效果更好 9、七分需求分析，三分需求管理
法则1：需求工作不能节省
刻为止，咱们双方达成的一致理解。
03 需求管理
需求日常管理
需求变更控制
需求日常管理
需求池
>
优先级
>
需求 排期
>
跟进与 验收
需求优先级--MVP法
MVP(最小可用产品) . （1）罗列出预期的方案
（2）从最不重要的功能开始砍掉 （3）直到再砍下去，流程就无法正常运转起来，产品无法正常使用 为止 两个原则： 1、所有的环节，能省则省; 2、每个环节上，能省则省，只保留最核心的用户故事。
法则9：七分需求分析，三分需求管理
错将需求分析的问题归咎为需求管理的问题 ➢ 不首先从自身找原因，一味归责客户。 ➢ 大部分问题产生的根源是我们需求分析工作不到位。 忘记了“双赢”原则。 “双赢”是指客户和我们都能“赢”! ➢ 要让客户能“赢”，客户才可能让我们“赢”! ➢ 绝大部分客户并不是只追求“单赢”的，与我们产生矛盾的主要原
因是我们没能满足客户的“温饱”级别的需要。
有好的需求分析基础，才有好的需求管理
回顾
1、理解需求工作：
➢ 需求工作不是客户叫你做啥你就做啥;
➢ 我们是专业人士，给客户带来(创造)价值才是我们需求工作的核心
本质!
2、需求工作的九大法则：
(1) 需求工作不能节省 (2) 理解清楚真正需要 (3) 明确限制条件 (4) 先做“加法”再做“减法”
项目需求工作如何开展
分享人：XXX
引言
项目成功的基本要素： ➢ 时间 ➢ 成本 ➢ 质量
项目管理的目标：平衡三者之间的关系，使之达到最佳效果
目
01 理解需求工作
录
02 需求分析
03 需求理
01 理解需求工作
需求工作概述 实用法则
需求工作包括：
需求 分析
需求的收集、分析、整理、验证、编写，最终形成需求规格说明书。