项目管理的价值体现在：

1，从问题空间到目标空间的narrow化。目标空间是问题空间中的一个极小的“点”。问题空间是一个由多个维度组成的极大的逻辑空间。如一个软件项目可能由可用性，功能性，稳定性，可靠性，可维护性，及时响应性，用户友好性，数据的独立性，安全性。。。等等，许许多多的维度组成。如果不对所有这些属性实施项目管理的话，那么项目最终达到目标空间的可能性几乎为零；

2，没有办法自动化的结果。项目由人组成。不是每一件工作都可以由机器完成。很多工作只能由人完成。而只有人才能管理人。这是项目管理的价值所在。项目管理的很大一部分其实是对人的管理。如果所有的东西都可以由机器完成，我不觉得还有实行项目管理的必要。因为那样的话，所谓的项目管理必将最后被转化为以其它形式存在的知识。

原型化方法是最愚蠢的一种需求分析的方法。

因为它并不是一种真正的“需求分析”方法。

原型化事实上是一种将真正的用户需求使用软件形式进行表达然后希望通过这样的表达得到真正的用户需求的尝试。但是从弄清用户真正需求的角度出发，需求分析不应该被当成任何形式上的用户需求向软件需求的转化。这种对需求的形式上的转化其实是软件行业扭曲用户需求的第一步。

只有在放弃所有的扭曲用户需求的尝试以后，才能回到真正的对“用户需求”的分析。用户需求是极其捉摸不定的东西。需要的其实是一种捕捉用户心理的能力。我们做软件的，大部分的从业人员都不具有那方面的能力。更何况即使具有那样的能力，它也不是一个已经完成所有或大部分研究的领域，我们没有必要也没有时间去做那样的事情。

我们能做的首先是：不要扭曲用户的需求。这要求：

第一，将对用户需求的表达形式停留在自然语言的层次。不要尝试对用户的需求进行任何形式上的表达。因为那是扭曲。

第二，对用户的“需求”描述进行领域回归即概念澄清。千万不要顺着用户的思维往下走。那是错误的。应该要顺着用户的思维往上走。这才是抓住用户需求的最重要的一步。因为用户自己对需求的描述其本身已经是对原始需求的扭曲。如果再顺着这样的扭曲走下去，必然是离用户最原始的需求越走越远的。。。。什么叫“揣摩用户的心思”？揣摩的意思就在这里------不要把用户说的东西搞得太严肃。用户说的东西不一定是他要的东西。即使“是”，你也不能确定你正确地捕捉到了他的表述。那要怎么揣摩他们的真正意图呢？。。。Use your brain! 大脑是你唯一的工具。使用原型当然可能在一定程度上排除掉你对用户的误解，但并不能保证或最佳地捕捉到用户的需求。

正确地捕捉用户需求，应该从一些最稳定的东西开始。用户的思维分成几个层次：

1，意志层；

2，概念层；

3，概念关系层；

4，表述层。

其中的第4层是最不稳定的。原型通过将问题给具体化，的确拥有在分析阶段去除一定的用户误解或思维回归的作用，但它不是一种根本性的方法。所以最终必然MISS掉很多在用户大脑中（或不在用户大脑中----这是一个更大的挑战。即使使用揣摩的方法也无法捕捉到这样的东西---单纯的揣摩是不够的）非常根本的东西。

而第1层以现在的技术是不可能达到的。所以一个比较现实的目标是第2层。但是即使是这一层，也要求非常强的对用户需求的抽象化能力。因为即使是这样的层次，它仍然不是一个平坦的层次。它可能是一个错综复杂的结构体系。而如何对这么复杂的系统建模，则是系统设计的问题。现阶段的目标则是如何尽量捕捉到这个系统。因为只有在捕捉到了这个系统以后，才可能在最终的系统中保留同样的概念。而只有在最终的系统保留了同样的概念的情况下，才可能在最终的系统中建立起一个正确的逻辑结构。

否则就只有看你的运气了。因为关系或结构它本身是个扑朔迷离的东西。我们可以往一个结构上面放置各种不同的语义。也就是说，因为它本身是没有语义的所以它拥有极强的语义承载能力。但那是在你的语义结构恰好能被你最终构建的形式结构完整地支持的情况下。否则就只有天才能“保佑”你了。

不然，我们要那么多数学家干什么？。。。数学家在结构上花了几个世纪的时间，至今仍只能在局部上有一些进展而未能形成全局性的理论或方法。范畴论在大多数情况下仍然只能做一些描述性的工作。

语义与结构的关系是一个巨大的挑战。

我不想尝试迎接那样的挑战。所以我将采用最傻瓜的方法。即对用户的需求尽量诚实化也即尽量保留原始的用户概念结构而不是去尝试建立另一种结构然后在完成以后忐忑地祈求它最终能够“幸运地”正确。那是弱者的行为。

诚实者不是弱者。诚实是一种美德。诚实使得事物的本来面目得以保存。