软件项目总会出现需求变迁，同时这种变动在需求者看来是天经地义的并轻而易举的，这是令开发者最头痛的地方；需求需要变动，也就是软件的软字的由来。有一位前辈的话最具代表性："软件项目就象是建筑工程，在大型建筑工程中，象建一座桥，在差不多完工后要求桥转90度的情况需求既不会在实际中发生，也不会被人看作是合理的；而原来的需求是公路桥，变动为铁路桥，也会被看作是两个不同的项目。但在软件中，尽管要重复完成的工作是同样的，但要求把桥转九十度，或者由独木桥转眼变成金门大桥的需求变动，却是屡见不鲜的。用户并不明白，在既定的项目时间和投资中，实现这样的变动是不可能的。"另一段教科书中的话也很有代表性："大多数情况下，用户并不知道他们需要什么，他们只是知道某些东西新奇，但并不知道自已是不是真的需要它；直到他看见自已不需要的东西，倒是可以很快拿定主意."
这两句话可以说是软件项目中最具代表性的描述了。项件中的项目管理，实际上开发中的技术工程管理尽管复杂，但真正是关系全局的，却是需求的管理；它意味着整个软件项目工作是否具有实质性的意义。我不明白XP编程中声称不需求管理，需求可以随机变动是什么意思；如果没有详细的描述和可靠的广泛项目成功证明；我认为那只不过是一个夸大其词的喙头，它没有说明可以承受的变动范围和适应动动的措施，以及变动后对时间/人力/金钱预算的变动的影响，所以等同于一句空话。
从项目经验的总结中可以发现，需求变动并不完全来自于业务方，而有一定程度是来自于技术实现方。后者的出现是由于技术实现方在很多情况下不得不承担部分业务成败的责任的原因。在中国，由业务方完全承担业务成败责任，并提出清晰明确的产品需求供技术实现的情况非常少；原因在于中国软件产业还是处于非常原始的阶段，缺乏第三方的软件项目咨询公司/专业人员，市场机制不健全，也令标准的产品研发-》技术实现-》市场销售的流程难以兑现。在象微软（美国）这样的大公司在推出产品时主要由产品规划部提出完整的规划，微软还实现了先收用户的钱，然后与用户共同开发使用产品的销售机制；在这个环境中，公司销售环节非常强大，技术部门仅仅是一个可以外协（象交给印度公司）实现的不算太重要的部门。
在中国，市场机制和实际上不存在技术销售市场，造成了要么技术部门是为已经签署的业务单完成技术开发，象许多政府电子政务的项目，这是擦屁股项目，最重要的是令合同找不出破绽，让当事人不至于因为收了回扣吃亏；所以实现越简单越好，这时侯技术人员的责任也是比较轻的，因为天蹋下来收了钱的人会替你顶着，这是中国大部分软件项目的实现方式，也因此形成了中国以单打独斗占主流的擦屁股高手的广泛存在。另一种可能性，是由技术人员和业务人员合力造出一样东西，由业务人员完成销售。在这种环境下，由于纯业务人员缺乏必要的技术理解，要么提出的是不可能实现的，但在业务人员看来是唯有如此才能完成销售的产品需求；（象手机上放高晰度电影，远程高清晰传晰医疗图像完成手术这类）；要么是纯技术人员造出完全与市场脱节的产品。对于这种项目，如果不是由稍通技术而精通市场的业务人员主持（一般是改行做销售的技术人员），或者就是由稍通市场精通技术的人员主导项目，才有成功的可能性。无论是那一种，主持这个项目的人从技术角度上看都有着自已变动需求的倾向，因为他要对此负责。
技术方提出需求变动的另一种可能性是对未来的考虑。软件实现在我看来是人类智力因素最浓集的领域，每一个软件人的大脑都是一台能够完成高速虚拟现实仿真的超级计算机，这令软件设计者在考虑当前需求实现方式时会更多的预见到与未来工作的冲突。如果这些工作大概是由其他人去完成，软件人没有必要在当前加以过多的考虑，（这是需求要素优先级的制定，钱？时间？人员？维护工作量？），但如果预计在未来这些工作仍是自已和自已部门承担的话，就不会不加以考虑。如果当前付多一倍的精力，但未来可以减少三分之二，通常比例还要大得多，的工作量的话，所有软件工程师都会选择更周详的方式实现，而不会死搬XP编程中说的用最简单的办法实现，没有细节说明，那是一句空话。
技术实现方提出需求变动的又一种情形是对基础实现方式的重视，所谓对底层和组件的重视。这与XP编程是完全相同的，它体现了一种质量观念，以及高质量的基础可以大幅度减轻维护成本。维护成本并不一定是交付用户使用后的维护才见维护成本，合续项目工作也是对前期的一种维护，大部分软件项目实际上没有办法最后完成的重要原因，就是前期基础打不好，令后续项目实现成本无限延伸造成的。这个控制后续项目成本，令整个项目可以控制可以最终完成，也是令软件技术发现出函数方法，发展对象，发展出分层技术，发现出组件包装的前进动力。所以当技术方发现前期实现方式不妥，象适于组件实现（以后还需要广泛重用）的环节使用了零散代码的临时实现方式，一般情况下是会回到前一步把这个基础打好。所以回到XP编程上，如果前面是用简单方法实现，通常就意味着后面回来重新打基础的情形大幅度增加，这同时意味着重新测试和回归测试的成本，因为，组件耦合度变化了。而如果一开始就以组件形式实现，是不存在回归测试的需要的。什么时侯什么地方适宜于可重用组件形式实现同时控制时间和成本，是系统分析员和普通工程师的工作水平差别表现的重要方面。要知道，可重用组件的开发成本是不可重用代码简单实现的两到三倍。
最后，由于在这种项目开发中软件负责人实际上已经不是闭门造车的开发者了，而是面向市场的产品创造者，随着对产品市场的进一步了解，一般情况下总是伴随着对自已产品质量档次水平的同步提高，这也构成了软件项目需求的在实现过程中的变化。而且，是非常主要的一种变化形式。因为技术实现毕竟是为了市场需求，而不是面子亮光的。但是对于一个项目来说，时间和预算由于业务的强烈请求，总是被打到极限线以下；正如前文所提，业务方并不理解独木桥和金门大桥，反正都是桥；小平房和金茂大夏有什么区别，反正都是房；更不知道金茂大厦和金茂大厦的照片（模型）和成本有什么区别，反正看上去都是一个方体。这样，就变成了技术实现方成为整个项目的压力焦点所在，如果对需求的控制是不坚决的，估计项目最终必然是以失败告终。
坚决控制项目需求，不妨打高一点项目实现的时间和风险成本，是技术实现者中一个有效的项目措施。对于这种项目，实际情况是纯业务方提出的只是需求建议，他们本身不用对这种需求负责，负责的是技术实现方，所以如果实现失败，不能归咎于业务方需求不合理不明确，他们也会以自已是不懂的为理由（不懂又不愿意懂，还要提需求，就只能是一种建议了），而应该认为是技术实现方对需求斟别不合理。所以套用无条件实现客户需求作为项目指导，是愚蠢，也是项目管理能力不足的表现。
