软件工程之需求管理（好软件系列一）

软件工程之需求过程（好软件系列一）

---- 此文献给期望成长为软件大团队的项目经理

曾经在面试项目经理和需求人员的时候，我一般会问几个问题，请问如何做一个好需求？好需求的标准是什么？如何判断别人做需求的水平是好还是坏？有很多回答，但是最常见的是，需求做完后，通过客户的满意度来判断。我说如果是客户满意度来回答，岂非非得等到需求过程结束后，才能获悉？都需求结束了，判断出来了又有什么用？换句话来说，是否项目经理需要跟着需求人员做需求，才能知道需求做的好还是不好？那既然项目经理都跟着做了，那还要需求人员干什么？是否只要一个会帮着打打字的小姑娘就可以了？

很有意思的逻辑，貌似从这个逻辑中，我们可以推出目前项目经理做需求更好。貌似市场上也有很多公司招聘项目经理要求会做需求。但是真是这样的吗？如果项目经理做需求，那需求人员做什么！这是糟糕的角色定位，具体分析可以参考我写的“漫谈中国软件” 。那反过来推理，项目经理不做需求，项目经理就不应该陪着需求人员去做需求，那么项目经理如何才能判断出需求人员做的需求到底是一个好的需求还是坏的需求？这就是我开篇提的面试问题了。这些问题不是说需求具体应该怎么做，分几步，每步怎么弄？而是在讨论做好需求的标准是什么？或者说怎么判断出需求的质量。这其实属于软件工程范畴，因为它本身没有具体细化到需求细节，更多是以面来看整个需求过程的工艺如何。

平时在家有时会做饭，切菜工序是少不了的。太太打马虎说不喜欢，就只能我来做了。每次在切菜的时候，就想着快点。但因为菜是有各种形状，千差万别的，但总是快不起来。要不就是怕切到手指，要不就切的厚薄不匀，切切停停的。有一次看一个酒店师傅切菜，听他切菜的声音节奏感很强，就想这个师傅在切菜这个领域里很有造诣,不是非常人。果然师傅是专业切菜工，干了很多年切菜的活。看他切出的效果和声音效果一致,很享受。

这就是工艺，切菜的工艺。我们判断切菜的工艺水平，很简单，听，看就够了。可以想象的是，这工艺水平的菜，比较容易在锅里均衡受热，一起熟，口感各方面也会更好点。当然实际出菜的时候，客户的吃的口感，满意度才是最终的定论。我们是否可以借鉴一下，理解软件工程中需求过程的工艺水平呢？

参考CMMI中需求过程的说法，一个优秀的需求标准如下：

 此处较为学术化，我用另一个通俗维度结合我的经验来重点分享叙述。判断一个好的需求，可以从几方面入手。

一，关注需求的规划           

每一个系统都是要去解决相应某领域的问题。曾见过一个MIS管理系统A，里面把所有杂七杂八的功能都做 在一个系统里，这些功能都很简单。但是当某个系统B专业解决了一块问题的时候，就把A系统的某些功能覆盖掉了。这个时候A系统很尴尬，因为他不仅存在推广 浪费，功能白做的问题，还存在后续定位发展问题，系统的未来可能被替换掉。

还见过一个系统，项目一期和二期在规划上没有很好的衔接，出现二期做需求的时候，对一期项目的设计产生较大冲击，甚至严重到将一期大部分功能推到重来。这些也是没有规划的原因。

所以好的需求，一定有一条主线去贯穿整个系统,一定是在某个领域无可替代，有发展动力和生命力的。这也是CMMI中提到的完整性体现。

二，关注需求用户场景和需求变更列表分析

在CMMI中有用户需求和系统需求，用户需求表述的用户用自己的语言来描述当前对系统的一些期望。其实通俗点说用户需求最重要表达的是系统解决的用户场景问题。用例的表述需求方式的兴起也是基于场景来设计的。

曾讨论需求变更的源头分析，大多数需求变更基本是当时场景描述缺失。

比如：用户订餐，从功能上来说只是需要提交一个订单而已。但是从场景分析来看，用户订餐，会先去找餐厅，会先找常吃的菜，会分请情侣，商务宴请，请家人，请朋友各种场景，最后才是提交一个订单而已。我们会发现可能做一个订单提交功能，不一定是最重要的，可能客户重点是想解决一个请人吃饭的问题。如果这个时候把提交订单功能做的出神入化岂非本末倒置？

所以判断一个需求做的好不好，其实很简单，就是抽其中一段需求内容分析其所适用的场景和目标。如果能表述很清晰，就说明需求质量很高。这也是CMMI中正确性，可行性的的体现。

三，关注需求产出物齐全

所谓“燕过留痕，人过留迹”，优秀需求人员才能做出好的需求，而做事的方式一定会有个完整的套路，就象武功高手练的“降龙十八掌”，“六脉神剑”一样也是有套路的。所以判断需求做的好不好，在一些方面也能体现出来。结合经验，总结如下：

关注目标和进度：

需求范围SOW敲定 --- 判断与客户的沟通和需求范围的控制力

需求计划 --- 判断需求过程推进顺利的标准

需求工作量投入量估算 --- 判断需求过程的控制力

 

关注深度：

需求会议纪要 --- 判断需求过程交流达成共识产物

需求问题列表 --- 判断需求过程中双方交流的深度和水平

功能性和非功能性的需求覆盖 --- 判断需求过程中需求完整性

 

关注外部关联：

需求评审(关联设计，测试，UI)问题列表 --- 判断需求复杂度和知识传递的效果（可选）

需求跟踪矩阵--- 需求知识传递的保障（可选）

关注结果：

需求文档确认和高仿真原型的确认结果 --- 最终判断需求过程的结果

 

基本在需求产出物齐全这块包括了CMMI中优秀的需求剩下的其它特性体现。

 

所以一个好的需求工艺，也是靠“听”和“看”就可以了，不需要直接参与。而项目经理需要的是在这个过程中练习“听”和“看”的本领。需要关注当需求工艺某方面出现问题的时候，知道怎么解决它。例如：我们发现SOW范围没敲定下来，就开始推进需求讨论了，那么项目经理要能判断出什么问题,以及怎么解决它。或者需求知识传递效果不太好，怎么解决，等等之类。

 

总之，对于需求过程的把控是项目经理的职责，而对于需求的实施不需要项目经理。项目经理需要花更多时间在软件工程的整体把控和客户关系的梳理上。只有这样，才能发挥团队最大作用，做出一个好需求，做出一个好软件。