用新的技术。而这一切走向极端就会让研发陷入不可控制的地步。在我做物流和教育平台产品的时候，都遇到了这样的问题。架构师希望产品做得更大，满足更多的业务需求，同时又希望几乎每个业务模块组件化，具有更多的通用性，采用尽可能新的技术。最终造成计划的一拖再拖，让公司领导层丧失信心。第二种情况在一些规模较小的产品研发中也很常见。技术领导人在时间、资金或PM的压力下基本上放弃了软件品质的追求。他们只希望在规定的时间内尽快做出一个东西就行。他们基本上不太考虑组件性、扩展性等等。这样做出来的产品和项目也就差不多了，因为他的通用性、扩充性太差。可以看出，这两种情况都可能导致产品的失败。第一种总是想一口吃成一个胖子，他们忽略了软件开发的跌代性，软件总是在不断的跌代、更新中，螺旋式上升发展的。而第二种则是技术人员的悲哀，他们没有条件去追求软件的品质，只能寄希望于产品的下一个版本。事实上，没有前一个版本良好的框架，新的版本要想做好，几乎是重新开发。所以一个优秀的架构师，既要不放弃心中的完美主义的理想，又要对现实做一定程度的妥协，在这种平衡中，领导团队进行技术开发。事实上，在中国软件产业的现阶段，急功近利的公司太多了，他们不会提供更多的条件、更多的空间让架构师去实现一个优秀的产品。这是我们所有做软件技术人员的悲哀，这是所有想走向、或正在架构师岗位上的人员的悲哀。
在软件产品开发的这一阶段，除了以上的情况，还有许多问题同样会导致产品的失败。例如公司对软件工程的理解和掌握。软件工程强调使用过程来保证项目的成功，一般都会提出一整套的理论，如一些核心流程、步骤、方法、规则等等，例如RUP,XP。有很多项目经理、架构师和软件公司的高层都希望去使用这些方法，以保证项目、产品的成功。特别是公司的上层领导，他们只能通过这种方法来保证对项目的控制，所以特别热衷于实施这些方法。然而事实上呢?。大家都常有这样的经历：
为了文档而写文档，写出来的文档基本上可以扔进垃圾箱，没有任何作用了。我这样说，并不认为软件工程有什么不好，关键在于你怎么去使用它。软件工程是一门实践性很强的学科，需要我们根据不同的现实情况不断的调整、实施，而不是照本宣科的一些教条。最怕遇到这种情况：
一些领导或项目经理读了几本软件工程的书，自以为找到了灵丹妙药，就开始在项目中强力实施。比如制订一些步骤、计划，在什么什么时间，达到什么什么成果，要写什么什么样的文档等等。在我以前做教育软件产品中就充满了这种倾向。了在某为一时间交出架构设计文档，我们大部分时间不是去考虑、验证架构，而是为了写出这份文档。结果是，到我们要去实现时，发现根本行不通，整个架构存在严重的问题，到这个时候再回头重做设计，代价太大了。个人感觉是，要合理的使用一些软件工程理论，需要项目经理、架构师有丰富的实践经验，能够根据不同的产品研发情况，制订自己的一些确实可行的方法。软件工程是一些通用的理论，从来而且应该是可以灵活裁减的。四、其他步骤 如果说上面的步骤都很好的做到了，那产品应该说基本上成功了。有了一个合理的的架构设计，那么详细设计和编码应该不是一个问题，这只需要我们的软件工程师的努力就可以了。当然测试是很重要的，但基本上不会导致产品的研发失败。