我的理解，项目，是为达成一个或多个目标，在某些条件的限制下，做出的计划和工作。
从理论上讲，目标、条件都是客观的因素，只要把握客观因素，在分析达成的可行性后，目标就一定会达成。但是，事实上却并非如此。
因为，客户对于目标的理解、与项目人员对于目标的理解，以及项目成员间对于目标的理解，存在或多或少的偏差。而对于存在的条件限制，由于条件比目标往往来得更加隐蔽（人总是喜欢好的东西），就导致了更多的不同的理解。
客户对于自身业务，通常情况下是比较熟悉的，那么客户对于目标和条件的理解，就取决与这个客户的素质和能力。高素质的用户是不多见的（简直是凤毛麟角）。这种情况下，顾问（Consultant）这个角色就出现了，他们对于某方面的专门的业务有良好的基础（如财务，人力，物流等），对于业务应用软件的特征，有敏锐的触觉，他们能够诱导客户，充分的阐述出其实际业务的场景（stories），并且能够区分和抽取一个实际场景中混杂的看似相同实则有异的多个业务步骤。为系统的设计，做出高品质的准备工作。（这是多么理想的需求阶段啊～～）只有以上情况都成立的时候，完美的需求才可能出现。
假设业务清晰的情况下，设计又如何呢？设计是产生交付运行的产品的前奏（产品当然不仅仅只有可运行的artifacts，但上帝们最关心只是这个）。当然，很多时候是没有设计的，只有思维的片断，而这些片断则很经常被某些人叫做“解决方案”，然后告诉上帝的时候，“业务需求”稍为改一改，就变成了“系统设计”（SAP这样的超级ERP也不能完全做到，我想一般系统组件化程度不至于高超到可以马上从业务需求到系统设计的跳跃吧），当然有些有良心的会加上“数据库设计”意思一下（这样的数据库设计可靠吗？）。 这中情况，放眼望去，比比皆是，也统一的缺少一个项目关键人物：系统分析员。对，就是我们可爱的“系分”同学，做一个系分不容易，团队有一个好系分也不容易。没有系分怎么办？三个臭皮匠顶一个诸葛亮，发挥群众优势，大家民主议事。只可惜，议事之前“大家”通常没有完整的思考，议事之后“大家”也往往没有review，更可惜的是，每个“大家”都不可能站在足够的高度去考虑和评价每一个问题的解决办法。于是，问题背后的问题，或者问题解决带来的新问题，将在以后的阶段不断被遇到，越迟遇到的常常越难解决（玩游戏时越大的boss越在后面）。（回头看看最开始的假设“业务清晰”，如果没有这个假设，那么……）
哈哈，终于到了可以开发的时候了，再来假设系统设计是perfect的吧。（现在，通常的做法是详细设计由开发人员做，或者嵌入代码中。如果是在那些没有稍为像样的系统设计的情况下，可能也就完全不在意详细设计了。）开发语言是开发的最小颗粒，同一个问题在不同的人看来，都会写出不尽相同的代码。说这些干嘛？“反正写完了，以后也不是我维护，更也许再两天我就在这个项目组了”，“这样比较方便啊，就先这样吧，没关系能搞出来下班，再说了”。在没有完善的开发平台和系统的开发规范的情况下，开发人员间完全没有一致可言。你不能告诉一个开发：要这样写啊，这样对于以后的维护方便啊，对于整个项目或者其它开发人员有利啊。也就好比，在没有立法的情况下，你对造纸场说，爱护环境功在千秋啊，那完全是白搭。
又到了美丽的假设时间，我们再次假设，我们的淫是好淫，好淫是高素质的，写出的代码是，符合XXX结构滴、思路清晰滴、易于修改滴、便于维护滴好代码。对了还有，是没有错的代码。什么，居然没有错吗？是滴，因为超级的淫，是不需要单元测试，就能写出完美的class滴。（好淫又被假设成超级的淫了，汗啊……）
当然，超级淫也是淫，组合起来测试也使会有错的嘛，所以，没有智障的都会做一下功能测试、系统测试什么的，以免上帝暴走。在有错后怎么办，当然由超级淫改正嘛，知错能改当然是超级淫的优良品质。当然咯，超级淫之所以是超级，就是改正了代码以后就一定没有错了，错的地方没有错，其它地方也不会有错。干嘛，要回归测试做什么？你难到不相信超级淫的能力吗？超级淫说没错就没有错！
如此之多的假设，俺已经汗流浃背了，已经木有力气在写下去了，改天再继续扯吧～～～