项目心得

　　怎么说呢，一个项目，说大不大，涉及到的部门就一个，但是説小呢也不小，毕竟也花了几百万，人数也有400多个，但也不至于差劲到要做一年呀。这中间也有些需要总结的。

　　1、明确和挖掘用户的需求。

　　为什么说明确呢，这中间主要是需求调研时，用户也看不到你未来的系统是个什么样子，只能说根据自己平常工作生活中碰到比较繁琐，比较麻烦的地方提出来，如果你在调研时只看到一个用户有这个问题就轻易的判断，那就等着判死刑吧，因为事物之间是有联系的。所以在需求调研时要充分了解各个部门的业务流程以及各部门间的联系，根据关键用户的需求，综合各部门的业务情况再进行评估判断，哪些能做，哪些不能做，可以提供哪些方案，方案的利与弊在哪。这才是用户所想要的，而且也更加专业。至于为什么说挖掘呢。主要是在用户尚不明确尚不清楚系统的前提下，对于很多需求其实他们也是不可能完全想到的，因此就涉及到一些潜在的，用户不易察觉但是对系统又有着致命性的打击的，这些就需要实施方去根据掌握的业务流程结合已有的经验，主动的去挖掘，否则后果很严重。

     其次在明确需求的时候，最好是对业务有个全局把控的人来着手，也就是科长或主管级别的，因为站的高才能看得远，需求过于往下了会导致思维受到限制，思考的想到的看到的也会比较狭窄。同时在这个过程中，也可以让领导人员有个熟悉系统的过程，日后在推动和督促系统的运行方面是大有好处的。

　　2、结合产品的特点以及自身的实力来评估需求的可行性。

　　　　 项目之前就必须充分熟悉所开发产品的特点，优势在哪，劣势在哪，以便以后有利于结合产品的特点取长补短。例如目前这个项目主要是做内容管理方面，肯定会涉及到上传下载，其中采用IBM的ECM产品，使用的TSM备份服务器，而在业务方面，超过2G的文件上传也是大有的，在需求调研的时候，项目经理也是亲口承认能做的，但是在开发阶段，却发现上传小文件系统是没问题，只要超过2G，系统就会报错，结果急忙着找出错原因，最后找到IBM实验室的人才知道ECM是不支持2G的文件上传的，没辙，只能业务部门作妥协。这中间不仅仅浪费了大量的人力物力，更严重的是项目经理的权威性就会受到动摇。　

　　　　　与此同时，对自身的开发团队和公司的实力也是要十分清楚的，若对自身实力不够加上产品不熟悉，需求调研时对用户所提需求来者不拒，没有仔细去衡量，在开发阶段却发现：哎呀，妈呀，这需求也忒难了，大大超出了我方的开发实力啊，这时候再和业务部门去解释，做不了，没法做，这样给业务部门的印象就非常不好了，让人伤心，让人失望，让人受打击，简直是自己给自己挖坑往里跳。

　　3、及时与业务部门进行需求确认。

　　　　在项目开发阶段时，每开发一个新的功能模块，要及时与业务部门进行沟通确认，这样的功能是不是他们想要的，这样的设计是否满足业务部门的需求，而不是等到全部实现后再一股脑丢给业务部门确认，这样业务部门就不爽了，前期让我闲着，现在一下子让我确认这么多，而且系统都不熟，模块间的联系都没搞清，就来确认，怎么整，有了这样的情绪，估计结果也不会好到哪去的。

　　4、项目经理的作用很重大。

　　　　在项目中，项目经理的担子还是蛮重大的。对内上，在内部开发团队中要起到协调沟通的作用。总之其技术方面是其次，重要的协调沟通能力是要充分强的。遇到项目紧张，需要团队们加班加点完成任务时，虽说程序员开发加班是家常便饭，可是也得让人心服口服的替你加班呀，特别是在没有计算加班费的情况下。而实施方项目经理在这点上应该是做的够差劲的。你说没有犒劳也就算了，没有聚餐也就算了，但是也不至于到团队中用一卷纸还得大家平摊费用呀，这一卷纸多少钱呀，自己掏一掏，也掉不下一点肉，何必为了这点小钱影响团队的凝聚力呢，一卷纸也就算了，平常要大家加班加点，早上上班还得正常时间，可自己却在家中睡大觉，中午才慢悠悠拖着肥肿的身体来上班。大家肯定心里就不爽了，还暗地里给起了个称号：睡觉哥。试问这样的项目经理能有多少人服呢。凝聚力差了，效率也就自然降低了。其次在制定项目计划时，要往细里钻，需要明确每个项目组成员的责任，并且让项目组成员的每个人都非常清晰自己的责任和风险所在。有时候，虽然项目计划制定了，但是个人的职责还是不清楚。

          在对外上，项目经理要保持与业务部门良好的合作关系，主动积极推动业务部门的项目运作，将项目的运行状况传达到每个部门，每个科室负责人，让大家有个清晰的了解，知道在每个阶段，业务部门的任务是什么，责任在哪里，从而让业务部门来推动项目业务方面工作的进行。

　　5、严格执行项目计划。

　　　　做项目计划时应该综合考虑各方面因素，各方面的风险。而不能单纯了为了门面功夫，是怎么样的就怎么样。项目做出了计划，之后的事情应该严格按照计划来执行，而不是看到项目这样了，再重新做计划来适应项目。这中间其实涉及到一个执行力的问题，一味的更改项目计划，会养成团队的懈怠，导致执行力不够，计划一变再变，项目一拖再拖。如果说能够在充分考虑到各种风险，各种问题的前提下做出务实的计划，然后严格按照这个计划来分配项目组每个成员的任务，再具体到某个月，某个星期，某一天，没有完成要求加班加点都要完成。这样效率会提高的很多，同时对个人的成长都是很有利的。

 　　　　上面只是说到对内部的项目计划，由于项目计划是需要有业务需求部门进行确认的，其中自然也包括业务部门或者实施方的任务，这就涉及到多方的关系，有时候这方做完了，那一方还没开始动，任务完成不一定能按预期的进行，各方任务关联比较大，这时候对于项目是非常不利的。为了防止这种现象的发生，可以在每周的开始将项目计划坦诚布公，明确责任人，在每周结束之时及时对项目进度进行总结，明确指出项目哪些任务没有完成，负责人是谁，哪些任务有完成，其负责人又是谁，无形中给大家一种压力，督促各方按计划完成任务。

　　6、需求变更时要有严格的需求变更管理。

　　　　在项目初期，和用户确认需求变更的流程。在后期需求变更时，一定要严格执行需求变更管理，没有必要要求用户到签字画押的地步，但是一定要有个确认的过程，用法律的角度来说，一定要有物证、人证，以便以后进行问题追溯。这样的好处是可以防止用户无休止的变更需求，降低项目的风险性，也减缓开发人员的工作量。目前我们项目就是由于没有需求变更管理，导致用户不断提出需求，而提的需求有时候用户自身都没有统一，按照这个用户的要求来实现，那个用户又提出意见了。这样弄得实施方很不爽，用户也不爽。

     总之，项目管理是门艺术，也是门技术，需要仔细琢磨和摸索。