请大家来讨论下“会使软件开发误入歧途的10大错误”

在http://blog.csdn.net/turingbook/archive/2007/07/09/1683376.aspx文中谈到著名的IT市场研究公司Forrester近日发布了一份报告，列出了会使软件开发误入歧途的10大错误，这些错误包括：
   

1对项目的成功没有全心全意投入。Never committing to project success.
2在充分理解项目之前就定死进度和预算。Freezing the schedule and budget before a project is sufficiently understood.
3过分扩大某个解决方案的适用范围。Overscoping a solution.
4没有雇用专业的应用开发公司。Circumventing the application development organization altogether.（【按】此条翻译不够自信，请大家指教。）
5对问题的复杂性估计不足。Underestimating the complexity of a problem.
6缺乏领域专家，而专家的参与也不够。Being stingy with subject-matter experts, in which their participation is not sufficient.（【按】此条翻译不够自信，请大家指教。）
7项目的领导班子选择不当。Choosing the wrong project leadership.
8用人又疑。对已经委以任务的管理人员不信任。Distrusting managers who have had tasks delegated to them.
9未经足够研究，就进入开发阶段。Jumping into development without enough research.
10报喜不报忧，沟通不足。Suppressing bad news, in which dialogue is insufficient.

  在我现在效力的公司中，就存在类似的问题，比较突出的有：2在充分理解项目之前就定死进度和预算/3过分扩大某个解决方案的适用范围/5对问题的复杂性估计不足/9未经足够研究，就进入开发阶段
  不知大家对此有什么感想，不妨多讨论讨论

3有歧义，应该是不能控制方案的范围，或者说没有有效控制需求
“过分扩大某个解决方案的适用范围”很容易理解成技术适用性问题

我现在就只能说说我对这些内容的一些看法，可能有些钻牛角尖的感觉。而要知道这背后的答案，最起码是要看到报告的原文整体。
1.这点我很怀疑。本身究竟什么是成功，本身就有很多的分歧。一方面项目的相关人群会有不同的立场和角度，另外一个方面他们得到的信息大多数情况下也不可能是完全相同的。因此很多时候，存在着不同的以至于完全相背离的成功标准。而所谓的Committing，要说需要全心全意，则显然是不懂得投入和产出应该是成正比的浅显道理，看原文也看不到对应，只能说是想当然的翻译。
2.这点我就更加怀疑。虽然我是开口项目的热情支持者，但是我依然认为作为商业开发者，在项目进行之前将进度和预算进行限定是完全必要合理的做法。同时我还认为，如果要真正的理解一个项目，即使在项目已经死亡之后，很多后果还不是能够充分显现。关键其实还是在于，仅仅限定好进度和预算，恰恰是一种好的敏捷方式，实际上每一个迭代就是一个进度和预算完全限定的小段落。问题还是在于要能够根据实际情况去调节，需求和投入资源。
3.我觉得翻译为超出解决方案的适应范围。显然这里不仅仅是说技术问题。但是问题在于，解决方案是否真的提供了自己的适应范围了呢？而即使超出这个范围，并非就真的不可救药了。去看看GOF就明白了。
4.altogether这个词汇我怎么没有看到在翻译中显示出来。这里的问题在于，一个软件开发组织和一个application development organization的关系。显然SAP这样的组织是个例外。不过我认为，至少在国内除非是ERP这样的完全抛开原来的运营系统从新改造的项目之外，更多的情况信息系统还仅仅是原有项目的补充和加固，这个时候选择理解力强，更加贴近用户感受的公司更加有优势。而另外很多时候的项目产生，其实就是由于有了专业的面向企业应用进行开发的业务人士的启发（比如企业经营方面的顾问，生产管理方面的顾问），才产生的。我想国外的情况在这个方面也应该是类似的。
5.这个说法，我想没有针对性，因为你可以对任何组织和任何人在任何时候都这么说。
6.这个问题确实是个问题，国内国外我想都一样。
7.这个也认同。
8认同。
9.这个有低级的错误，研究就是开发过程的一个部分。我认为其大概意思可能是，没有经过充分的研究，就开始了设计或者编码。这点显然是对于敏捷开发不友好的。而同时即便是CASE爱好者，对这个说法也会很反感。
10认同。

两位朋友说得很好
对于：“3过分扩大某个解决方案的适用范围”
就我的理解，来举个例子：
我现在的公司前些年开发了一个OA系统，对于200人左右的单位，流程不是太复杂的情况下运行起来还是可以的，后来买到一个国家级的大型企业，这个项目已经实施了一年多，上个月勉强通过了初验收，目前的情况是平均每周DOWN一到两次机（低层算法考虑不周到 ）
其实10！和1000！在数学上是同质的，但在软件算法上是两个概念,把针对10！的解决方法用于1000！，肯定是出问题的