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