项目管理之需求工作篇

需求工作相关的词

1. 需求开发
2. 需求分析
3. 需求调研
4. 需求管理

关于CMMI

CMMI通过对多个（Process Area）过程域来描述对软件研发各个方面的要求。

• 其中有两个过程域与需求工作直接相关：

• Requirements Development(需求开发)
• Requirements Management(需求管理)

• 每个过程域通过Doals（目标）来描述该方面的总体要求。

需求开发

三个目标：

需求开发三个目标

总结：

需求开发是一个由粗需求到持续驱动到细需求的过程，并且需要持续的确认需求。

需求管理

目标： 需求被管理，并且需要识别项目计划及工作产品中与需求不一致的地方。

理解：
管理需求： 管理需求的确认和签署，变更。
通过需求驱动工作

• 用需求指导计划、设计编码、测试、实施等工作。
• 不做或少做与需求无关的事情

关于需求分析的实用过程

可以从大战略分为几步：
1.搞清楚大boss的想法

2. 搞清楚小boss想法（这两者基本是用户需求）
   3.思考软件还需要什么样的功能（这属于软件需求）

关于需求工作过程中的实用法则

关于需求分析、需求调研、需求确认这些工作中的十大实用法则：

一、什么都可以省，需求工作不能省

需求工作少投入1小时，将来工作量将会增加100+小时。
需求工作量占整个项目工作量的20%+

二、法则二：搞清楚需要

12306网站用户需要

需要搞清楚客户的需要,但是因为我们主要是涉及软件开发的，所以很多客户的需要会跟软件的需要挂钩起来。比如上面客户的需要是可以回家过年而已。A、B其实是软件需求，不是用户需求。我们应该通过用户需要，来反过来思考软件的需求应该怎么做？？

三、法则三 明确限制的条件

客户的想要的基本都是自助餐心态？
要吃好、吃的够多，还要省钱，省时间，马上上菜？？对照我们的项目。

我们这时候就需要明确限制的条件.

常见的限制条件

• 工期、预算、于第三方系统对接的要求、关系等
• 项目组自己要明确限制条件
• 同时需要让上面的boss知道限制条件。

法则四： 先做加法，在做减法

把该项目有利益影响的人、单位都列举出来。然后列举出这些相关单位的需求，对项目的

我的做法：

1. 头脑风暴，角色分析（加法）
2. 考虑限制条件进行取舍（减法），工期、预算、边界限制、第三方系统限制等等，排序优先级，大boss的想法是最重要的。

不同角色之前的需求有冲突，需要取舍以及求取平衡。

好处:

1. 让项目团队思路清晰
2. 充分考虑和平衡各角色需求
3. 不会漏掉最重要的、基本的诉求。

法则五： 持续确认需求

---需求文档基本几十页甚至上几百页的需求规则说明书，如何让客户进行确认？

真实情况应该是这样，需要一遍编写一遍跟客户反复确认需求文档的内容，让客户持续跟进，而不是自己闭门造车后，再一次性跟客户确认。

需求调研的过程就是持续确认需求的过程。

法则六： 避免“二手需求”

提需求

假设有这样的情况，某官府部门，要做一个项目，发起部门为IT部门，IT部门提出要做某某项目，但是该系统最终使用部门为业务部门，项目组来做需求收集的时候，被IT部门挡住了，变成了IT部门来提需求，做出了系统。

这时候，系统上线后，部署给各业务部门来使用，业务部门又提出了新的需求，跟原来IT部门提出的不一样。这时候就犯了个错误了。

需求的提出，应该是谁使用，就由谁来提出需求。

在内部的时候，也可能会存在这样的情况，比如需求负责人提出需求给开发人员，开发人员又对接给测试人员。对测试人员来说，这也是二手需求。

一句话就是说: 需求的提出应该是谁用谁提出，而不是经过第二手提出。

法则七： 成为业务专家

• 现实中经常会遇到这样的问题
  -- 客户总是抱怨软件不好用
  -- 我们反复改，客户还是说不好用。

• 需求分析的几种档次：

• 落后的模式： 客户说啥，我们去实现什么？
• 先进的模式： 成为业务专家，给客户提供最大价值。

比如客户提出一个需求，我一般会按照以下步骤思考：
1.先思考客户这样需要这样需求的本质是要达到什么目的。（该目的是否合法合理，是否有必要）
2.通过自己判断以及确认沟通，弄清楚目的之后，考虑该需求是否有必要实现。

3. 思考该实现是否能满足客户想要达到的目的以及有没有更好的业务实现。
   4.最后才是去思考怎么转化成系统需求，如何设计、实现的可行性、是否会导致其他问题等等。

同时提出自己的业务思考跟设计的同时，也可以跟产品进行讨论，取经为什么这样设计会比较好，如何考虑的。自己也慢慢提升自己的业务思考以及思维。

法则八： 需求是"设计"出来的

ps：需求分析其实就是找出合适的软件配方

客户提出具体的软件需求时，我们应该怎么办？

根据大Boss以及小Boss的想法，思考软件需要什么功能，这是高技术含量的活！让最简洁的实现来满足客户最重要的需求是最好的。

法则九： 团队作战效果更好

• 需求评审的常见问题

  1. 需求文档检查表

• 需求工作必须解决的两个难点

  • 全面准确地捕获需求。
  • 将需求准确无误地传递给其他项目成员。

• 团队作战的基本策略，告别单独整理

• 需求负责人： 搞定用户需求、大小boss需求
• 其他成员： 导出软件需求

• 让项目组成功工作更爽！

• 知道自己干什么！
• 提升技能！

单干的话：

细节部分可能没法完全把控，
开发人员没有足够熟悉需求的话，可能有时候自以为理解很清楚，但实现出来会偏差非常大。
在上线后，可能很多项目成员会在过后很久才能理解需求。

如何解决，团队作战:
按上面的基本策略

法则十 七分需求分析，三分需求管理（七分原因，精力放在需求分析工作，剩下三分放在需求管理）

• 错将需求分析的问题归咎于需求管理的问题

• 客户的需求变更，不从自身找原因，一位归咎责任给客户
• 大部分问题产生的根源是我们需求分析工作不到位

原因：
反省是否我们的需求分析不到位，没有满足大小boss的需求，没有做好软件需求之间的取舍，没有一开始较好的设计软件工作。
忘记了"双赢"的原则

客户与我们都能赢
-要让客户赢，客户才能让我们也赢

• 绝大部分客户并不是追求单赢。与我们产生矛盾主要是我们没能满足客户的“温饱”级别的需要。

• 良好的需求分析工作作为基础，加上合适的需求管理，很多问题就能迎刃而解。

关于需求篇，暂时就总结到这里了。