一下问题由@utopialxw 整理
http://utopialxw.iteye.com/blog/1483220
1. 不能很好的理解用户的需求，缺少与用户之间的沟通。
2. 错误的预估项目的大小和难易度。
3. 没有计划就匆匆开始编码。
4. 没有在项目初期就开始做测试，一直拖到项目后期才做，或者根本不做什么测试。
5. 选择时下最cool的技术还是已经被团队使用比较成熟的技术，往往不能做出很正确的选择。
6. 不采用任何软件过程或者方法学。
7. 没有一个真正的项目经理，让开发人员无计划的主导项目。
8. 拖延计划，把进度压力留在后期。
9. 不做版本控制，混乱的代码库和开发环境.
10. 在项目过程中随意的更换开发工具和环境。
11. 客户的任何需求都答应下来，需求会永无止境，记得学会说“不”。
12. 只有一个大的计划，没有把计划分割成一个个更小的任务，要知道，大的计划如果不分割成任务很难落实和具体实施。
13. 对开发团队的管理不足。
14. 在项目后期增加人员来加快开发速度，很多时候往往适得其反。
15. 开发人员不做单元测试。
16. 一旦项目中遇到问题，就把压力抛给开发人员。
17. 不关注软件实际的运营环境和硬件条件。
18. 没有命名规范和代码规范。
19. 到处都用全局变量。
20. 遇到问题的时候往往不请教别人，而是一个人闷头搞，到最后还是不得以还是通过别人来解决。
21. 没有写代码注释的习惯。
22. 对输入输出的数据不做验证。
23. 不做压力测试，到实际环境中往往就会出现更多的跟环境和性能相关的问题。
24. 项目内部沟通不畅，每个成员只是埋头做自己的事情。
25. 没有很好的bug管理规范和系统，往往用word、email、excel等文本方式来跟踪bug，将会导致整个项目的bug管理陷入混沌。

资源问题
内部因素
外部因素
不可抗因素.。

正常来说，项目需求变动打到20%以内的是允许的，20%+就属于需求变动过大了，那么怎么界定是需求变动还是功能优化呢？比如系统中的bug是必须解决的，比如很小的改动，改个文字、改个样式，一个小时以内的是可以接受的，但是需求是原有功能设定没有的，需要半天+才能完成的就属于需求的变动了，需要拒绝或是不强硬的拒绝，向项目经理反映了