又说到需求（2）——范围解决之道

上月发了个关于需求的贴，见http://www.iteye.com/topic/407433 ，事情较多没有来得及跟上，今天晚上有了些空，打算对这个话题做更进一步的整理。

 

Tao，在软件从业人员当中变成了神圣的字眼，有了Tao，就好比抓住了一件东西的命门，其他引申或变化都可以迎刃而解。我在这里姑且套用一下，来阐发一下我认为的解决项目范围之道。

 

为什么不用“需求解决之道”而是用范围，理由是范围隶属于项目范畴，而需求则大凡用于软件工程领域，从项目角度去讨论这个话题更有针对性和系统性。

 

解决范围问题之道可以通过如下一图来形象表示：

 

 

 

在我看来，解决范围问题的核心是如何建立客户与开发方之间的互信，即甲乙双方。很多项目都遇到这样的情况，追着客户索要需求确认签字、对客户提出的变更左推右挡...这些都是缺乏互信的体现，而这类项目以失败见常。

 

无论什么项目，最终必须为客户提供或者创造价值，需求应该体现价值，当项目范围必须发生权衡抉择时（如为了进度砍掉某些需求），应该以价值作为导向。

 

在软件项目当中，开发方是主导方，主导方的专业程度决定了软件的价值，比如，对于需求模糊的客户，开发方可以利用原型驱动来诱导和捕获需求体现出的就是一种专业化。

 

沟通在范围管理当中尤其重要，客户和开发方之间的大多数沟通都是发生在需求和范围上，比如需求采集、范围变更，沟通有效与否很大程度决定了双方的互信。

 

期待项目范围不发生变化是一种非理性的奢望，理智的开发方应该把管理、技术的重心放在适应力上，比如小周期迭代、测试驱动、重构。

 

综合而论，解决范围之道在于价值、互信、专业、沟通、应变，价值是目标，专业是手段，应变是过程和能力，沟通是保证，互信是核心与基础，价值、专业、沟通、应变带来互信，反之，互信促进了价值的获取、专业的表现、沟通更有效、应变更自信，这就是范围之道。