二战期间，英国国防部发现参战的飞机难免挨上高射机枪的枪子儿，受限于飞机重量和成本，他们只能在一处安装装甲增强防御力。但是在位置选择上犯了难：应该把装甲装在什么位置？
数学家对战斗中返回的战机作了一项统计，发现39%的弹孔在机翼上，60%在机身，1%在发动机部位。于是他们给出答案：装在发动机部位。
国防部官员们不得其解：不该是弹孔最多的机身上吗？数学家说，统计已经很清楚了，发动机中弹的飞机，大部分都飞不回来了。个人认为成功不可复制，失败或可避免；所有的成功都不是必然的；成功都一样，失败各不同；失败的项目也许值得你警醒。
不久前遇到一个比较棘手的软件项目，为公司带来很大的麻烦，为了避免大家也重蹈覆辙，现在将个人心得与经验教训总结如下：
不在多，在精，在强，每个人能独当一面，以人为本；智力密集型工作单个人的水平比劳动密集型工作更加突出。
避免过快的人员更迭，反省公司制度。
软件开发团队要稳定发展，他们的成功依赖于高效的信息传递和领导能力。精进高效的团队是公司最宝贵的财富。避免外行管理内行。
有目的有计划的做事情，项目管理者监控项目计划进度，进度的把控比制定工作计划更难。项目计划做出详细合理的进度表，提高项目经理的计划意识，采用进度和计划严格一致，加强对计划、进度进行有效的评估。做出进度滞后的应对办法，把握主次。不要为计划而计划，把握粒度。
如功能设计思路、类的命名、窗体命名、变量命名、数据库命名、注释、风格、主色彩、辅助色彩等。
勤于整理代码与文档，复用；对于开发者来说复用是终极目标，复用的最大敌人是变化。
如git，开源免费的有coding.net、阿里云等。
世界上没有任何事情是绝对成功的，要做好项目失败的准备，做最坏的打算，尽最大的努力。
含需求、设计、编码、测试、进度管理等功能。
1.需求管理：项目的需求变更，跟踪，控制
2.资源管理:项目的可利用的资源(人力，物力，财力)
4.进度管理:日历，工作流，项目路线图和Gantt甘特图
5.测试管理:项目软件缺陷Bug状态跟踪，反馈
6.文档管理:发布文档文件，存储文件，集成源代码管理与git,svn
7.信息管理:活动统计报表，项目报表的导入和导出功能，信息筛选，预警和邮件提示
0、ZenTaoPHP轻量级的PHP项目管理开发框架，以开源的项目管理软件
1.Dotproject基于php免费开源
8.BugFree国产软件，使用MS的软件开发流程规范
不要做前后没有联系的项目（也就是公司没有任何可以复用的资源）、谨慎被多次转包的项目、小而精的项目、与现金、人事有关的项目。
对于大而全的项目把握住用户的痛点，找出系统的核心需求，分期，分批开发;关键需求与用户共同画出产品原型。
有时客户并不知道自己要什么，把可以分析出解决办法后让客户选择
麻雀虽小五脏俱全，小项目谨慎选择
完成一部分、测试一部分、验收一部分；迭代。。。迭代。。。
可卖服务，卖产品，卖技术，卖运维等，换一种挣钱的思路
系统中包含基础功能；简单功能应该通过平台自动生成，加快项目进度
更换系统架构，但也不推荐天天吃老本，建议隔代升级。不要跟风，技术选择项是不要考虑现在流行什么，而要考虑需要什么，适合什么。一般的客户对你用什么技术实现是不关心的。
天下功夫唯快不破
包括项目经理不具备业务知识，行业知识和项目知识，缺乏软技能，面对压力无法做出关键决策，无法看到问题的本质，无法从全局提出系统性解决方案从而推动项目的发展，不能随时就环境做出调整等；
包括没有整体思路、对项目各个组成部分以及他们之间的联系没有整体把握、软硬件无法进行整体的思考、考虑问题经常是头疼医头，脚疼医脚、人为的把项目进行分段，从而没有预见项目的整体性风险等；
5.3.1、没有良好的沟通渠道设计；
5.3.2、不主动去激发用户参与项目的热情；
5.3.3、靠主观感觉盲目制定项目计划；
5.3.4、在不了解项目具体情况下对项目盲目下定义；
5.3.5、计划资源把一切想的太美好，主观性强；
5.3.6、靠个人感觉来分派工作而不是客观的评估每个人的能力匹配程度；
5.3.7、对变更没有实质管理，更多是体现在文档上而不是实际工作中；
5.3.8、胡乱控制项目节点，而不是从项目特点本身出发；
5.3.9、缺乏对项目失败的定义以及评估失败风险；
5.3.10、项目已经失败的客观现实面前缺乏终止项目的管理机制；
5.3.11、过分看重项目的当前经济价值，利令智昏；应该注意项目的附加值，复用价值等。
5.3.12、项目开发周期多数情况被低估
总之如果您加强项目管理意识、注意团队建设，规范开发过程、找准个人与公司的定位、不断提升开发技术与积累资源、善于总结失败教训，这样将大大提高您项目的成功率。
成功不可复制，失败或可避免；
逃避不一定躲得过，面对不一定可怕；
当然，项目管理在现实中存在多样性与复杂性，我说的也许有些不对，欢迎大家补允，我随时添加，谢谢！