有些事情你们觉得不可思议，不可理解，不可能！
但是，就是有人，不假思索的就去做了。
项目要结束了，想写个总结，总结以下系统设计设计上的缺陷，代码编写中考虑不足的地方，项目管理方面的不足。
我已经不知道什么叫成功的项目，什么叫失败的项目了。因为定义失败或成功的标准不一样，按照PMP的标准几乎不存在成功的项目，但实际不是按照那个标准衡量的。延期8个月后还是步履蹒跚的上线了，算不算失败，恐怕还要从经济的角度计算以下成本和收益，如果收益大于成本就还是成功的(当然也包括因为延期而不能去做别的项目所产生成本)。
项目不理想的原因是多种多样的，但最主要的一个原因是团队的素质，包括每一个项目成员的素质，和参与项目的客户的素质。开发团队的素质决定了团队以一种什么样的方式和客户沟通，得到客户真实的需求；客户的素质决定了他以一种什么样的方式告诉开发团队他需要什么样的软件，要解决什么样的问题，更有可能的情况是他只知道要解决什么样的问题，而对软件一无所知。
编码的规范和知识共享：在项目初期要对项目要使用到的技术有明确的评估，优势和不足。项目要使用的相关软件的版本，工程的存放目录，发布方式做统一的规定，避免因版本不一致造成代码风格的不一致。项目成员的能力是不同的，一般一个项目都会有一两个新的成员加入，如何把以前项目开发中遇到的问题和解决思路以最快的方式传授给新的成员就至关重要。现在普遍的做法是建立内部的WIKI共享资料，发布问题，得到解决的思路，确实是个不错的方式。但是面对面的交流也是不可少的，一次迭代完成之后应该大家坐在一起交流一下开发中的问题和解决办法的思路，以及对新的可能出现的偏离客户需求的功能做一个讨论，避免行动迟缓造成的重复开发。知识的共享不仅包括技术资料的共享，更多的是对软件的认识和思想的共享。
技术框架：因为技术框架而成功的项目并不少见，但很少有技术框架的失败而最终导致失败的项目。很多人对框架有错误的认识，盲目的追求新的技术，认为只要技术上够强了就会成就一个项目的辉煌。框架最大的一个作用就是对使用框架的成员有强制规范的效应，使得实现同一个功能所需的代码从结构上是一致的，不管是初出江湖，还是老于世故，别无选择，易于复用，便于维护，对于这一点项目越大优势就越突出。就像工业时代的来临，以及大工业时代创造的辉煌，并不是因为瓦特发明了蒸汽机，爱迪生发明了白炽灯，而是一系列工业标准的建立，减少了重复生产，明确了社会分工，框架的作用也是如此。
面向对象和问题域：面向对象是一种思想，面向对象本身对于如何描述问题域明没有太大的帮助，项目设计上的缺陷大多来源于对问题域的错误分析，无端的扭曲了来自客户的问题描述，这一点已经屡见不鲜了。设计人员过多的追求面向对象的设计模式，而错误的把问题域往自己设计的模式上靠，进而蛮横无理的要求客户改变工作方式是不明智的。这一种错误来源于设计人员和需求分析人员对问题域相关知识的无知。突然想起一句话：对于一个不知道自己站在那里要去那里的旅人来说再好的地图都是徒劳的，描述的很精准。
软件的商业价值：客户所需要的不是一堆代码，也不是可以秀的程序，而是要解决他遇到的问题，软件卖给客户，客户不能再去买软件挣钱，所以软件本身不能创造利润，对企业来说软件所能做的就是降低成本，其中包括降低流程运作的成本，和便利的获取信息以便降低决策成本。现在做软件市场空间已经很狭小了，越来越多的软件企业向服务业转型。更好的软件和更优质的服务才能创造更多的价值。信息化不是软件化，更多的是信息化的服务。
软件所创造的真正价值是什么?产生真正价值的前提条件又是什么?
没有创造价值而祈求回报即使得到了也是暂时的.
没有人是傻子,没有项目做总有它的原因的,很想知道!
|