大型项目管理经验会议总结

仅此记录作为笔记

项目周报工作的开展，后续可以考虑引进模块开展百分比定量考核制度，对于需求点、修改点，采取权重值乘以工时数衡量百分比，做出波线图，更加直观。

其次，项目周报方面，个人觉得会议上提到的引入各种工具等等，都有一个致命的错误，不同工作岗位角色的工作周报都是同一个模板，这样欠妥，像项目组长、项目经理等

职位的有不同的着眼程度，并不是所有的领导管理者都不去追究和着眼细节。那单凭一两个人写出来的代码，绝对是没有太高的质量和健壮性的，单靠测试部门的后期测试，

来达到代码修正的结果，是需要很长周期的，这对于快速开发是比较不利的。

需求收集与设计进行交叉，代码评审制度的开展得细化评审周期，评审人员，评审结果考评，评审结果知识库录入制度。部门的知识库建设个人认为是重中之重，

每个IT企业人员流失是必然的，知识库建设对于企业对于个人来说，都是一个很重要的积累过程。

部门领导布置任务，现有的模式都是说哪去哪，整个年终总结都要靠自己去回忆，很少有个人的工作日志记录，事情一多，自然有些东西会忘掉，

因此引入一个工作日程的部门公用的工具，也是很重要的，在员工自己安排时间任务的同时，领导们也可以时刻关注下属在忙些什么，之前看到过类似的工具，

基于excel或者access数据库自己简单开发一个未尝不可，反正就是填一些表格罢了。

会议上说到的需求的受理、需求收集完善化，规范化，其实说白了就是我们公司自己在和客户接触时，如何引导客户正确地进入我们的整个开发流程中，

做好自己的需求提出者的角色。对于一些难以推脱的需求，个人觉得，做技术的，不用太在意一些傻B客户的强制需求，做产品经理，要保持好整个产品的健壮性，

必然要拒绝掉一些东西，坚持自己的立场。否则产品还是没有立足的，当然一般来说，客户提出来需求的目的固然是好的，不过还是需要进一步引导客户走向更加合理，

更加通用化的一个需求提供。这才是产品经理应该做的。

visio有空可以研究下，mm已经用的差不多了，个人觉得也玩不出什么新花样来了，用来给客户讲解产品思路的时候炫一下足够了。

project也可以研究使用一下，看有没有在线功能，然后去熟悉青铜器之类的。

时间控制一直是个难题，后期需要提高估算能力。我们部门的最大的弱点，就是工程进度无法估算和控制，导致产品线一直拉的很长，不能完全控制的情况下，

争取部分达到控制。