在软件项目中经常会遇到以下几个方面的问题：

　　需求不充分同时经常变更;

　　缺乏与客户的沟通;

　　团队内部沟通不畅;

　　不必要的复杂度;

　　团队工作缺乏效率;

　　上面的第1条好理解，因为这是软件项目成败的基础，还软件是用来干什么的都没搞清楚，那么怎么可能指望它能得到客户的满意呢?为什么会出现需求不充分这种情况呢?主要有两点原因：其一是客户常常自己不能明确地了解自已的需求;其二是就算客户有能力了解一个复杂系统需求的所有细节，他也可能不知道如何有效地组织需求文档。同时就算是在项目开发将近结束的时候，仍会发现新的需求或是要进行需求更改。比如随着程序开发过程的深入，客户对亿们需要什么有了更清楚的了解;客户认识到最初的需求无法满足他们的需要;客户在需求阶段可能提出了一些他们并不真正需要的需求，然后在开发过程中又不想要了;客户需求的改变;客户方的职员或经理发生变更，由于想法不一致，导致需求的改变等等。

　　第2条也比较容易理解，因为要准确定义需求是一项困难的工作，因此，与客户保持开放和有建设性的交流是很重要的，那样做可以确保你所做的工作正是客户想得到的。一定要通过与客户的交互来完成需求分析。另外，每个项目都是从一些不完善的信息开始的，对于项目将如何进展也是处于一系列设想之中的。通常在随着项目进度的展开，这些设想将不得不进行调整，你和客户将分担这些调整所带来的影响，因此交流的结果最终必须达成协议。

　　第3条主要是当开发人员增多时，每个开发人员也相应地要与更多的人进行同步，根据《人月神话》这本书上所指到的那样，开发人员的增长，会导致团队里用于沟通的信息量呈二次级数增长。不畅的沟通有两种：太少或太多，太少会导致不能消除系统分歧，太多则浪费太多时间在协调而非代码开发上。

　　第4条的复杂度增加会占用大量资源和时间进行开发、维护和扩展，从而导致团队工作越来越繁杂且收效甚微。当一个程序规模扩大，内部交互增多时，就会使出错的机会增大，且这些漏洞在开发过程中难以发现。同时复杂性还会导致代码的难以理解。一个项目一般包含很多组件，当构件数目增加时，就会增加每个组件与更多组件交互的机会。当交互数量大大增加时，就不太容易理解程序正在做什么，也使得没有人能够修改或扩展这个程序了。

　　第5条是在开发中很常见的，因为没有哪个程序员是通过培训成为团队成员的，学校里也不会教学生如何参与团队系统的开发。作为团队成员，沟通、协作和建立共识的技能比个人的编程技能要重要得多，这对于学校出来的程序员来说是认识不到的，他们通常认为自己能写出没有毛病的代码，同时觉得别人的代码都不够完美或严谨。沟通、协作和建立共识是花时间且没必要的，他们崇敬的不是杰出的团队成员，也不是什么团队领导，而是个别有创造力的程序员。而结果是他们的代码难以理解并潜伏着错误，同时带来的问题就是开发时间的延长。

　　本文出自 “野火兔的窝” 博客，请务必保留此出http://firehare.blog.51cto.com/809276/588061