项目开发管理经验集锦
背景
项目将近尾声，测试验收结束 认识到项目开发管理过程中出现了一些重大问题 交流项目开发管理过程中的体会目的
关注项目管理过程中的常见问题 吸取教训，总结经验，避免以后出现类似的情况 与大家共同探讨，共同提高//=================================================
端正态度，加强重视
项目管理是件费时耗力的事情 需要大量的沟通时间 需要解决许多潜在的问题 需要统计工时、项目状态报告、调整计划。。我本人曾经犯过这样的错误，当时有一个项目，从技术角度出发没有什么特别的难度，只是加了一块WEB方面的UI显示，因此当时在整个项目开发管理过程中，我没有投入太多的精力在项目开发过程中，只是定期的去问一下任务完成的如何，有没有做好类似这样的问题，平时更多的精力都放在了安排MPP，写项目状态报告上，因此当时觉得搞搞项目管理还挺轻松的，但是后期这种弊端就暴露出来了，开发工程师完成的并不理想，或者由于测试不充分导致了重大的BUG，导致项目的后期非常被动，拼命赶工，总结归纳下来就是在整个过程中，没有引起充分的重视，认为事情不多，忽视了仔细的检查，可能潜在的一些问题等，因此我想要想做好项目，第一件重要事情就是要加强重视，端正态度，只有勤勤恳恳的投入与努力，才有可能管理好，控制好一个项目。要想轻轻松松控制好项目是不可行的！
避免出现不合适的观点
过于乐观 “这个应该没啥问题。。” “很简单，搞搞就好了。。” “还有时间，来得及，我可以马上就做好的。。” “这个我以前试过的，肯定可以。。” ＝＝》真的没问题吗？？？由于软件的复杂性，总会由于环境不同、工具不同、新技术的不确定、测试的不充分而带来意想不到的结果
“啊？怎么会这样。。”
“哎呀，这个边界值还没考虑到。。” “哦。原来以前是这样做的，哪我这样做还不行。。”结果：工期延误、突发事件、维护困难。。
这个问题我想在日常的开发过程中都非常常见，好像软件工程师天生都比较乐观（也有可能是一种自满情绪？）诸如上面的话我们屡见不鲜，但是往往很多问题就是恰好出现在“没问题”的地方，归根结底就是过于乐观，“认为没问题”（其实可能有问题），结果导致很多的突发事件，给项目计划带来了不小的影响，我想归根结底是一种过于乐观的情绪，要解决这样的问题，只有踏踏实实的去做，去验证：
解决
动手去做，验证结果 在有限的精力内，尽可能做到测试充分 ＝＝》 确实是没问题！避免出现不合适的观点
过于自信 “我是项目经理，你该听我的。。” “我这方面比你强，我肯定是对的。。” “这个我以前做过，肯定是这样的。。”站在整个项目组的角度考虑问题，不是争个人胜负
切实有效的沟通，得到一个比较妥善的做法 无法达成一致的时候，可以做些测试，或者找些证据 ＝＝》一切为了让项目做的更好避免出现不合适的观点
切忌想当然 “我本来以为验收是这样的。。” “我原先以为你的意思是这样的。。” “我以为开发工程师都做好了。。” “用户的需求我一开始是这么理解的。。” ＝＝》通过沟通，检查等方式去确认，避免无谓的返工或者临时的手忙脚乱工作安排的确定
尽量避免关键路径的不确定性 尽量避免关键路径中出现真空 尽量避免关键路径改来改去关键路径指一个软件中最主要的框架、流程、算法、模块等对软件本身有着重大影响的因素。
并非开发工程师不想好好完成任务，缺乏明确目标，包括功能、时间约束
软件开发希望能一次就做好，不要反复 尽管在前期的确可能存在一些不确定因素，但最好能降低 通过良好的设计进行一些变化的隔离以更好的方式沟通
整个项目组是种协助关系 沟通的时候注意语气以及对方的心理变化等 如发现问题，可以坦诚的与对方交流 项目例会的重要性检查的重要性
及时深入的了解项目存在的或者潜在的一些问题 对重要问题多加了解，保持跟踪 开发规范的建立 不要像个监工一样监督 检查的目的是为了保证质量，保证需求理解的一致性 最有效的检查方式是 “让我看一下”测试的重要性
开发不仅仅是编码完成，应包括单元测试与集成测试 性能测试的重要性 边界测试、覆盖测试的重要性换位思考
站在用户的立场，考虑软件的安装、使用、配置。。。 站在测试的角度，考虑模块的接口、易用性。。 站在管理的角度，考虑交流、汇报、协调、安排。。