以下内容六牙四皂小姐可以看看，至于看的懂看不懂不负责。

程序届有个说法，只有你想不到的，没有我做不到的。当然，程序是基于数学的。如果违反了数学的基础理论，程序还是无法实现的。可程序又不同于数学。说穿了，程序有一个时间，成本和环境的限制，有的时候还有法律问题。理论上说，任何一个水平足够的人都可以写一个windows出来。但是，首先是一个人写需要多少时间。其次是这些时间，还有其他投资(例如电脑)所造成的成本。然后是这个windows所能运用的环境。当然windows也许没有这个问题，可如果是程序就必须考虑适用系统(Windows,*nix)，字长(32bits,64bits)等等限制。最后，一个和windows一样的系统是否会侵犯了微软的版权？

对于程序员来说，可能这些都不是问题。程序员面对的是明确的目标，环境，解决方法和框架。他们要解决的是按照构思来实现功能，并且按照算法来构建代码。例如一个播放器，对程序员来说可能就是一个确定的接口，向里面写入固定格式的数据。或者引用某种算法读取压缩数据，解压为通用数据进行播放。或者是实现解码器的注册和管理。这些都是已经被严格确定了的目标。程序员有一个固定的环境，一个统一的框架。解决方法或者是被说明的，或者是不言而喻的。

可是由一个抽象的需求来获得一个明确的目标，并且确定环境和实现方法由谁来做呢？一般这些人被称为需求分析师和系统构架师。需求分析师的工作在于帮助用户确定需求，分析需求的可能性产出(例如播放器中是否需要一个屏保屏蔽功能)，分析系统的目标环境。这些任务更多的是出于用户角度考虑的，主要是我需要做什么(what,

why)。系统构架师则是一个对称的职务。其主要职能在于确定如何使用目标环境中的各种技术实现目标需求，使用这些技术完成目标需要多少时间，多少成本，是否引发法律问题。等等等等。这些问题更倾向于从程序员角度考虑，主要是怎么做(how,

when)。

当然可能没有这种职位，但不可能没有这种职能。有的时候分析和构架是由项目经理兼任的，有的时候是由客户驱动的(尤其是外包的时候)。至于完全没有的时候，就只有将需求分解为零散的问题，对问题求工具了。理论上说这是一种很好的方法，强大的bash语言体系其实就是由一堆解决细节问题的工具组成的。问题是，这种情况下，对于工具的使用者就提出了很高要求。往往会把工具的使用者变成另外门语言的使用者。例如我们看电影，一般用户只是点开就看而已。如果是针对问题求解，可能我们会出现一个播放容器，一个编码分析器，一个视频解码管理系统，一个音频解码管理系统。最后还需要一个注册器来关联适当属性的播放容器和某种文件类型。从软件结构角度，这样的软件有利于构架和编写。可从用户的角度，这是最差劲的播放器。事实上，mplayer就属于这种播放器。我们用起来觉得简单是因为一些高手制作了一些预先设定的包，将所有组件关联起来。

我们回到原本的问题上来。如果用户驱动了系统的构架，那问题自然不大。只需要制作方评估系统规模，然后按照规模给出成本和时间。双方讨论一个可以接受的成本和时间，东西就可以做了。至于客户变更了系统，那自然有相关的人员会重新评价，给出新的成本和时间。问题是如果约定不清晰，可能会造成比较大的麻烦。例如客户认为他们给出的解决中必须实现某个东西，而程序这里认为是最好实现某个东西。那就扯不清楚了。因此一般建议编程人员向客户要求一份详细的制式计划书，然后双方签字确认。根据合同法规定，如果制式合同中出现纠纷，应当被解读为不利于提供方的方式。倒过来显然是不行的，既不能指望编程人员提供计划书，也不能指望客户不会对计划书随便解释。

如果是由非客户的分析和构架人员来做系统构架，那么情况就复杂了。问题实质上其实变成了五方会谈。客户方，代表客户方的需求分析师，制作方，代表制作方的系统构架师，还有程序员。看起来有点重复，但是其中都有利害关系的。客户方希望需求分析师提出尽可能多的需求，因为这样才能产生好用的软件。系统构架师则希望需求分析师提出尽可能少的需求，这个才容易制作和维护软件。制作方希望系统构架师提出尽可能高的成本和时间预算。这样有充裕的时间制作，不会制作失败，还可以多赚钱。但是客户方不会喜欢很高的成本和迟到的软件。程序员希望系统构架师给出的解决方案足够清晰，而且改动少。系统分析师总喜欢在程序员的失败中改进方案，因为简单啊。客户方希望程序员给出完整的文档和后期维护，但是程序员都不喜欢写那东西。

所以需求分析师往往会提出一堆怪怪的功能，即使这东西一般人八辈子用不到。系统构架师往往会提出高的吓人的成本和时间预算。和股指差不多吧，没几个有脑子的相信。真正的成本和时间就会在客户和制作的吵架声中被确定，并且往往成本高出正常值，时间低于正常值。程序员就在一次次的咒骂声中修改系统，并且经常忘记跟着修改文档。客户拿到手的往往是一个延期了再延期的系统。它们十有八九跑的起来，刚好可以完成预定目标。只是往往会有一些Bug，并且只有不同步的文档。系统就会在客户的抱怨声中被退回，而且客户还会追加两个需求，加上句“钱不是问题”。制作方看在孔方兄的面子上，往往也会说“保证完成任务”。系统修改的结果往往是Bug越改越多，文档越改越老，系统越改越奇怪。最后系统分析员往往会找到一个下家而跳槽，客户往往会因为钱是问题而拖帐，制作方往往会保证完不成任务，程序员往往会抱怨天天加班，唯一没问题的需求分析师往往是客户亲戚兼任的。

到底是哪里出的问题？