一旦认识到试验性(其实，现在很多公司都在开始创建自己的研发队伍，不管技术在行业里难度如何，都希望有个某方面的突破。可就在管理实验性项目方面失败的很多。如果，没有对常规项目做好管理工作，我个人认为不要再做实验性项目，失败的多，成功的少。更何况从中得到成果更是难 )的系统必须被构建（很多技术人员喜欢这样做，但是构建之时没有理论上提高，只是有了实践的经验，重建未免得到更好的效果，有可能事倍工半 ）和丢弃（拿得起放得下，真是说对。但是，为放弃发生很多争端，有人不欢而散，有人搞恶作剧... ），具有变更思想的重新设计不可避免，从而直面整个变化现象（如果是一个项目正在做此工作，应该有心理辅导员、公司领导正确指导，重新认识新的任务。把各种心理转化成新事物的向往 ）是非常有用的。第一步是接受这样的事实：变化是与生俱来的，不是不合时宜和令人生厌的异常情况。Cosgrove很有洞察力地指出，开发人员交付的是用户满意程度（换位思考方式特别重要，让开发人员成为用户，站在用户的位置体验。其实很多地方说到这点，真正做到有几个呢？尤其是是开发人员对用户解释一个bug、new feature时，经常用技术化的语言表达，已经证明没有站在用户的位置上考虑问题了。如果说的话能用户化，80%应该站在用户位置上了 ），而不仅仅是实际的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
当然对于硬件产品而言，同样需要满足要求，例如新型汽车或者计算机。但物体的客观存在容纳和阶段化（量子化）了用户对变更的要求。软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒（如何对永恒做量子化呢？值得考虑！ ）的需求变更。
我从不建议（如何理解？指的是把用户的潜意识通过教育‘培训等手段转化成技术化因素？还是指让顾客接受技术基础建设条件的约束？ ）顾客目标和需求的所有变更必须、能够、或者应该整合到设计中。项目开始时建立的基准，肯定会随着开发的进行越来越高，甚至开发不出任何产品。
然而，目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免。抛弃原型概念本身（估计指形散神不散，形式可以多种多样 ）就是对事实的接受——随着学习的过程更改设计。
阅读《人月神话》批注http://peter9.iteye.com/