项目的心得体会_第1页
项目的心得体会_第2页
项目的心得体会_第3页
项目的心得体会_第4页
项目的心得体会_第5页
已阅读5页,还剩8页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、项目心得体会通过这次做项目,使我对编程有了进一步的认识。做项目的时候,最重要的不是自己如何快速地将自己分配的任务做完,而是要注重团队合作。一开始组内必须对这个项目的数据库的命名进行讨论,定义表的属性的数据类型,表与表之间会有关联,所以有的属性的类型与长度必须定义一致,这样访问数据库时才不会出错。如果一开始不将这些步骤统一下来的话,就会给后面的编程带来一系列的问题。我做的是销售管理,做的内容包括查询销售记录、查询退货记录、销售添加和商品退货这四个界面。同时对四个表进行处理,对销售主表、销售明细表这两个表插入数据;对销售主表和销售明细表进行退货操作的同时,对退货表进行插入数据的操作;最后对销售主表

2、和退货表进行查询操作。做这个项目的时候,我浪费了太多的时间在销售添加界面上。首先对于界面的一些布局没有考虑清楚就动手, 不知道如何运用 java 语言来对数据库进行处理, 对于细节方面考虑地不全面,导致了遇到了错误就不停地修改。在插入数据到销售主表中停留的时间太长,不懂得运用打印功能来检查错误。同时在修改库存的时候完全没有思路,只对库存进行了修改却在销售时没有对库存进行判断,这就是程序的一大错误之处。正如老师所说,在第一个界面完成之后,接下来的商品退货界面做起来就不太难了,对这个项目实现的功能也有了一定的了解,以及对这个项目如何动作的有了基本的了解。其实我在这个模块遇到的最大的问题就是,一开始

3、对这块模块到底实现的功能与细节分析得不彻底,所以在开始编程的时候就手足无措。于是这部分的代码就出现了许多漏洞,然后在运行程序的时候就不停地修补漏洞。接着就对这个界面的功能进行不停地完善,在修改的过程中也就浪费了许多时间。当组长将这个项目组合完成之后,我知道了做一个项目不是一个人就能完成的,需要组员之间的配合,因为有的功能与别的人所做的功能是相连接的。如果只顾自己,这个项目也不会完成。这需要与组内的成员进行交流,以及组长的辛苦努力与组员们一起解决问题。篇二:项目实施心得体会项目实施心得体会逝者如斯夫,不舍昼夜。不觉中暑期社会实践调研项目已到了提交研究报告的阶段,回顾项目的前期准备、 申请答辩、

4、现场实施以及报告撰写整个过程中, 团队七名成员沟通交流,激烈讨论的场景依然历历在目;团结协作、互帮互助的精神至今难以忘却。正是有了这样的付出才保障了调研项目顺利实施。以下从项目实施前期准备、现场实施以及后期报告撰写三个方面总结,将本次暑期社会实践调研的心得体会与评委组老师汇报,与同学们分享。一、凡事预则立不预则废项目实施的前期准备是项目实施乃至整个项目的成功推进的最重要的一步。在项目申请成功之后,小组立即组织成员围绕着项目的实施召开内部讨论,全体成员再次明确项目的目标,围绕着既定的目标针对项目实施的全过程进行了模拟,同时在七位小组成员中进行了明确分工。 其次, 各成员依据各个分工职责着手工作,

5、 组长负责调研地点相关人事的沟通协商,确定调研的具体事宜。其他四位同学分别负责科研经费的使用管理、小组成员行程相关事宜的安排等。小组内的明确分工,使我们认识了项目的整理实施流程,明确了小组成员各自的责任,同时意识到组内成员之间互补互助,协同合作的必要性,充分调动起了我们积极性。二、千里之行始于足下现场实施实施阶段是项目推进的核心阶段。全体成员在确定各自分工职责的基础上积极展开了相应的工作。项目的现场实施主要以定性访谈为主,分别采访了相关政府官员和机构管理人员,实地参观了目标机构的相关情况。在确定样本机构时,由于事前未能与其管理人员进行明确的商定,致使替换了先前的部分样本机构。这件事让我们深刻的

6、体会到在项目准备阶段做好充分准备的重要性,不能放掉每一个细节。接下来在采访相关政府官员和机构管理这时,我们遇到了语言和沟通上的一些问题,比如,某机构由于以往学生采访带给机构带来了不良影响, 其管理者对我们的调研也有疑虑。 面对这些棘手的问题, 小组成员拿出诚意,耐心认真的和相关人员沟通,化解管理者的疑虑,保障访谈资料的真实性。在每次现场调研完,小组都会及时总结,对现场调研的过程中的不足之处展开内部讨论并商榷解决的方案,为下一个机构访谈做准备。在队员的齐心协力下,最终顺利的完成了现场实施的工作。三、前事不忘后事之师实地调研收集完资料后, 项目进入了报告撰写的阶段, 报告是我们项目产出的重要标志,

7、所以小组全体成员都认真对待。同时也进行了分工,包括文献查阅、理论知识支撑、数据整理分析、总报告撰写以及ppt 制作。各个成员在不同工作中能力得到了提升,比如,专业知识的加强,文献查阅技术的提高,文字撰写能力的提升等等。至此项目即将告一段落,其实施过程中有以下几点体会愿与老师、同学们分享。第一,面对一个项目,我们首先应该确立总目标,知道我们要去干什么;其次,要把总目标分解成一个个小目标,明白我们该如何去做;最后,还要对目标进行有效的管理,查看目标的进度多少,方向是否偏离。科研项目也不例外。第二,团队的协同合作是非常重要的。现代社会是建立在分工的基础上的,科研项目也必然是要求分工明确的。此次调研中

8、,小组从课题准备,现场调研以及报告撰写都有着清晰的分工,各司其职使队员明白自己的责任,同时也提高了团队的工作效率。但我们也没有忽略协作的重要,实施过程组员间互帮互助,共同应对难题挑战。第三,沟通交流的技巧必不可少。无论是与队员之间的讨论,还是对调研对象的访谈都少不了有效沟通交流,尤其是定性的访谈。真实的资料是科研中发现问题、验证问题、解决问题的基石。所以怎么样从访谈人员口中得到真实的资料就显得格外重要。我们在调研中的体会则是,要真诚的去向他们了解情况,此刻他们是老师。还要善于倾听,耐心听他们说,而不是仅仅让他们说出你想知道的问题。随着项目临近尾声,适时总结整个项目实施的过程的成功经验与失败教训

9、,将为我们以后开展科研工作打下坚实的基础。最后,衷心地感谢关心与支持我们的所有老师和同学们。篇三:项目经理10 年心得体会, 共勉项目经理 10 年心得体会项目经理,顾名思义就是做项目的,一个项目的成功百分百归功于这个项目团队,而失败则百分百责任于项目经理人一人,可能失败的责任归于一人用之过大,但其实不然,作为一个项目经理,首先要对项目的需求、进度等情况了如指掌,知道自己要做什么,正在做什么,下阶段要做什么,当别人问起时,才能脱口而出,不会一问三不知。那么我们需要从哪几个方面来做呢?第一、项目需求:项目经理接到一个项目,首先应该问商务人员索取项目方案书或招标文件,通读全文,对项目有个大概的了解

10、,明确项目范围,知道你的项目应该要做些什么?什么时候开始?什么时候结束?最后自己能提出一些问题!为调研时做好准备工作!有疑问的地方应该找市场人员或售前工程师了解咨询!第二、项目调研:有些人连项目方案书都没看过,就匆匆忙忙去客户处调研了。那么结果就是在跟客户沟通时,一问三不知,很被动,只能听客户讲;客户提出一些不在项目范围内的需求时,你也不知道,只能暂时应承下来!前面一点我提到要找市场人员或售前工程师了解咨询的另一原因就是,客户已经跟我们讲过的问题,如果项目经理再去跟客户提问时,那么就会给客户一种我们内部缺乏沟通的感觉!第三、项目计划:发现在工作中有些人不重视项目计划的制定,有些人可能会说,这个

11、项目太小, 周期也不长, 几天就搞定了, 没必要去浪费时间去做项目计划了。 项目不管大小, 哪怕只有一个人,哪怕周期再短,我们也要制定项目计划,不同规模的项目,制定的项目计划规模也有所不同。且不管我们制定项目计划祥略与否,但起码已经有了一个好的开始,在以后的工作也不会一团乱麻,主次不分。而制定项目计划的另一个目的,就是明确相关干系人,避免在项目过程中发生推委扯皮现象。该找谁就找谁,应该由谁负责就由谁负责,计划里面很明确。大多项目经理是从技术出身,在制定项目计划时,不要只考虑开发的计划,还应涉及到跟客户的沟通确认,需求调研、商务方面的协调、实施部署、项目验收后的维护等内容!第四、项目沟通:在实际

12、工作中,有些人把项目中遇到的问题仅仅跟客户或项目干系人汇报一下就认为是沟通了,其实不然,所谓沟通用最简单的方式来说就是你所说的内容能得到对方的认可, 我认为就算沟通成功了! 当然有能力的项目经理会说服对方按你的想法来走。第五、项目协调:在项目实施过程中,不仅要跟客户协调、项目成员协调;还需要跟其他公司的人员进行协调。例如在客户现场开发时,我们需要的办公环境、网络环境都需要事先跟客户协调好,不要到进场时才发现缺这缺那,让客户很被动;又例如硬件情况,如果硬件是其他供应商提供,应协调硬件到位安装的情况,免得我们系统要布暑了,结果服务器也没有。注意点:在对外协调沟通时,最好由项目经理去沟通协调,不要不

13、同的人去跟客户提同一个问题或同一件事,那么客户会很反感!第六、项目控制:常听人说制定好项目计划后,这个项目就成功了一半,那另一半是什么呢?那就是项目控制。很多人作了一个项目计划表,从来就没有跟踪或更新过,这样的项目很难按计划做好,我们应该经常根据项目的实际情况进行调整或变更等,到达每个里程碑时,应该根据计划内容检查这一阶段的交付物(成果) 。第七、项目汇报:我们千万不要错过项目汇报的合理时间,在每个阶段应及时对项目情况进行汇报, 可以是给老板, 也可以是给客户, 不管是给谁看, 及时性是放在首位的。 例如:今天与客户开过了一次沟通的会议,项目延期或变更了,应在第一时间发给相关的人,这里的相关人

14、不仅仅是参加会议的,也包括关注此项目的人。除了以上20%知识之外,另外80%的东西才是重点。、 协调能力!这是一个合格的项目经理必须具备的能力什么叫协调能力?就是与各色人等打交道的能力。项目经理的职位,在很多外企里其实是没有行政管理的权力的,就是对项目内的成员没有管理的权力,更多的时候做的工作是一个项目协调人。一个项目启动后,项目的成员可能都是临时从各个部门调来的,作为项目经理,需要与各个部门的人去协调每个成员的参与项目的时间期限。 项目经理需要安排工作与每个项目成员, 人都是一个个体, 各种性格都有, 如何与不同性格的人交道, 这可不是一时半会儿能学得会的。项目经理也需要与上层领导协调,当项

15、目推迟了,如何向领导解释原因,如何向领导申请更多的资金与资源, 如何说服领导更加支持这个项目, 这都是协调能力的体现。 除此之外,项目经理还需要与客户协调,面对客户漫无边际的需求要求,如何加以限制,面对客户的种种苛求,如何一一化解,当最终产品提交给客户后,如何减少客户的抱怨,尽早的签收, 这些都需要项目经理有非常强的, 把与项目相关的所有全部摆平的能力。 这一点, 应该占到40%的比例,也就是说, 如果达到上面两条, 你就可以做一个及格的项目经理了。 但这还是远远不够的。、 文笔!项目经理几乎可以不用写代码,但更多的工作是写文档以及报告。这几乎占据了项目经理大半的工作时间。 从合同到项目计划再

16、到项目报告, 项目经理都需要极强的文笔写作功底。清晰,明确是文档的基本要求,更多的时清晰,明确是文档的基本要求从合同到项目计划再到项目报告清晰候, 项目经理需要从不同的角度解析同一个问题, 而让人得到不同的结果。当然,如果你能把死的写成活的,黑的写成白的,项目经理需要从不同的角度解析同一个问题,而让人得到不同的结果、沟通能力!不仅仅是语言沟通能力,还包括察颜观色的能力。项目经理未必需要口若悬河,出口成章,但说出的话一定让人清项目经理未必需要口若悬河,出口成章,项目经理未必需要口若悬河楚的明白;同时,也要通过表情,动作等身材语言,了解对方的内心想法楚的明白 同时,也要通过表情,动作等身材语言,了

17、解对方的内心想法。这一点,真得很难,有的人一辈子未必学得 同时会与别人沟通。所以,只能看你的天份了。这一点,应该点到10%。最后10%,就是抗压能力,作为项目经理,一定要能承受常人不能承受的巨大压力。 尤其在项目遇到问题, 进展不顺的时候, 在成本上升和面 尤其在项目遇到问题, 进展不顺的时候, 尤其在项目遇到问题临着最终期限快到的时候, 如何承受并缓解那种压力,不是每一个人都能够做到的。 临着最终期限快到的时候,如何承受并缓解那种压力,不是每一个人都能够做到的。 如果你遇到一点事就郁郁寡欢, 放不下, 那在项目的重压之下,会是对你精神与身材的双重折磨。篇四:项目管理心得体会本人做项目经理工作

18、多年,感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导, 只有最合适的, 没有什么叫对的, 什么叫错的, 项目经理最忌讳的就是完美主义倾向,尤其是做技术人员出身的,喜欢寻找标准答案,耽误了工作进度,也迷茫了自己。以下是本人一些做项目的个人体会,写出来供大家指点,在讨论过程中共同提高水平。项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候,首先要尽可能地多从各个方面了解项目的情况,如:这个项目是什么项目,具体大概做什么事情,是谁提出来的,目的是解决什么问题。在国内很多客户都很不成熟的情况下,千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能

19、在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统。前期了解情况的工作越详细,后面的惊讶就越少,项目的风险就越小。这个项目里牵涉哪些方面的人,如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等,很多项目里除了业主单位的结构很复杂以外,还有一些其他单位也会牵涉进来,如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望,可以让你在做项目碰到问题的时候,就每件事情分析哪些人会在什么方面支持你,哪些人会出于什么目的反对你,从而提前准备联合朋友去对抗敌人,让事情向你所希望的方向发展。没有永远的朋友,也没

20、有永远的敌人,只有一致的利益,这句话作为项目经理是一定要记住的。基本了解了客户的情况后,下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视,这个决定了你在需要资源的时候,公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的,你需要做的是了解公司对这个项目的实际期望,是想把项目越做越大还是想赚钱?是想做样板工程还是干脆想敷衍了事,公司领导对项目的态度决定了你做这个项目的战略,而这个战略方针将对你做项目计划产生直接的影响。在做整体项目计划前, 还要大致计算一下你手上的资源。 首先是时间, 现在市场竞争激烈,往往很多项目要求在几乎不可能的时间范围里完成。对于这一点,你

21、在做项目的风险控制计划的时候要充分考虑。其次是人员,根据项目预算和已往经验,大致计算一下未来的项目小组有多少种角色,每个角色目前公司是否有人,是否能完全归这个项目使用,是否需要另外招聘一些人员,招聘的准备工作要尽早启动。最后就是一些设备的准备,项目所需大件关键设备要尽早预定, 以后不管发生设备等人还是人等设备的情况, 浪费的都是你的时间。现在是做项目说明书的时候了。 一份好的项目说明书不仅将要做的事情描述得很清楚(主要是讲做什么, 而不是说怎么做) , 而且把如何检查也说明得很透彻。 也就是说它不仅说明白了要做哪些事情,也让客户的业务人员(一般不懂技术)知道项目做成什么样就算完成了。简单地说,

22、项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。是到做总体计划的时间了吗?不, 你现在已经知道了客户的目标和你手上的资源, 那么做计划以前,你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的,你需要写一份报告,详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话,将发生什么样的后果。如果资源不够,就要高层改变策略,增加对这个项目的投入。甚至在条件许可的情况下,有些公司会放弃这个项目。 总之, 没有人能完成一个不可能完成的任务, 如果项目经理不能尽早发现风险,那么就只能去当烈士了。明白了要做哪些事情和你手上的筹码以及你做这个项目的总

23、体策略, 现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利,那么,就尽量发挥你的影响力去寻找那些你想要的人吧。 成员的组成根据项目不同, 相差较大, 很难有什么具体要求, 但是,一定要有精通客户业务的人,很多小项目里,这个人就是项目经理本人,大项目里会配备行业专家( industry expert ) ,这样和客户沟通起来才不会鸡同鸭讲,双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语, 结果搞得客户一头雾水,反过来,他还指责客户不懂技术。其实,明白自己想做什么的客户已经是很好的客户了,不知道自己要做什么,更不懂怎么做还要指手画脚的客户到处存在,但

24、是要明白,是客户选择了你,而不是你选择了客户,有了客户你才有工资拿,心平气和一点吧。对于这种需求天天变的客户,你就一定要事先做好规矩:一、 统一联系人, 客户指定一个人和项目组进行沟通, 不能张领导、 王领导都来说几句,如果他们意见不一致,那你只有得罪领导的选择了。所以,项目的最初就要定好规矩,我项目组只认一个的意见,有什么要求你们内部先统一再和我谈,我不想卷入你们内部业务部门之间的矛盾之中。二、所有需求变更全部要有书面文字,这点切记!这样做好处多多:? 有书面证据,以后他还想改,你有了他以前要求的证据,告诉他:你以前可是这么说的。?便于需求变更管理,需求如何慢慢演变的历史可以看清楚,从而更深

25、切地体会客户的目。?对于客户来说,嘴巴一动最方便, 反正是你们做, 不花他的资源, 所以要求是否合理,是否和项目的目的一致,他是不负责任的。但是如果要他写书面要求,还要签字盖章,他就要谨慎多了,而且一写东西,思想就会更加深入,很多无理要求也就这样胎死腹中了。现在你要面对三群人: 你的领导、 你的组员和你的客户, 和这些人沟通, 让他们知道你打算怎么做,什么时候要他们做什么准备,这些事情将是你的主要工作。既然沟通这么重要,那事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则,如果你在一个部门时间做长了,对这些规则的运用觉得是一件理所应当的事情。但是,你现在面对的是多个部门甚至多个

26、单位,不把沟通规则说清楚,你以后就会吃亏。下面的东西看起来无聊,其实还是很管用的:第一个是规定信息的流动方式和介质,是推还是拉。推的意思就是项目经理将主动发布信息,不管通过电话、邮件还是书面方式,保证将信息传达到每个人。这种情况适合小项目,人少。拉的意思就是项目经理就是一个类似web 服务器,你自己需要什么信息就去问他。当然,没有项目经理把自己搞得那么累,他会用发布信息到公共介质的方式公布信息,简单的是白板,复杂一点的是项目的公共信息交互区,潜规则就是我发了你没去看就不要说我没告诉你。 说这些看似很无聊, 其实里面牵涉信息传达不完全的责任问题。当然,这些都是指一般的方式,而且不要绝对化,一般情

27、况下,主动沟通和被动访问是同时存在的,尤其是对领导,项目经理更加应该主动去和领导沟通。第二个问题就是文档问题,很多人怕写文档,但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢?就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的,比如项目经理的项目日志,每个星期至少让客户签字,另外所有达成共识的东西,比如会议纪要,甚至领导的讲话记录,都要写成文档,双方签字,这样以后扯皮的时候,就能做到有据可查。记住:说了的就和没说一样,只有写下来大家签字后才算真正发生了的。还有一些问题,比如你提交的报告,给领导(包括本方领导和客户领导)做一个选择题,结果领导压住不

28、批,让你无所适从,结果拖延了进度。这时候,你可以等,但是注意要留记录,标明是谁的责任;另外,如果你在开始阶段就和领导商定:如果批示提交三天后没有得到领导答复就算对方同意,这样你就会主动很多。再比如不同事件的审批流程问题:什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到,以后的工作就越主动好了, 做了很多前期工作, 定义了一些游戏规则, 现在是坐下来做计划的时候了。 这一节,任意找一本项目管理的书都会说得比我好,所以我就少写一点,说一些自己的体会就是了。首先是找几个关键组员,比如客户业务专家、系统分析员等等,

29、做一下项目模块划分工作。项目分成几块去做,每一块完成什么,模块之间的信息如何交换等等。需求定义的是做什么的问题, 而这里说的是怎么做的问题。 这里要强调一点: 完成一个目标有很多种方式,你要选一种你最熟悉的,而不是看上去最完美的,这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动,坚持要你采用那种新技术,你就应该告诉他:你选我做这个项目,就应该容许我采用自己最喜欢的方式做事情,新技术之所以有诱惑力,就是因为吃亏的人还不多,我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确,比如用微软的 project 软件,你填写完表格以后,就可以知道这个项目有多少件事情要做,每件事情需

30、要什么资源,他们之间的前后关系如何,消耗的时间有多长,完成后有什么标志等。所有的结果最后用一个叫做甘特图的形式表现出来。你做完这个表以后会惊奇地发现,甘特图上项目的结束时间会远远落后于你的计划结束时间 (签合同的人永远不会先征求你的意见的)当然,学过项目管理的人会大谈什么wbs、优化路径之类的东西,但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题,在我恭喜你挑了一个轻松活之前,请你再去确认你是否罗列了所有要做的事情和正确评估了它们所需要的时间。这时候,你就要考虑牺牲一些任务的时间(也意味着质量)了。按照什么标准牺牲?这个项目的战略!我们在第三节提到过的战略。我

31、的经验是如果你什么都赶进度,其结果可能就是十件事情你一件也没做好,想想多么失败啊。所以,把资源投到你熟悉和有把握的事情上,最后的结果是十件事情,你有三件做成了精品,三件完成,还有四件因为某些原因延误,成绩单是否靓丽了很多呢?战略决定优先级,而正确排列事情的优先级是一个项目经理能力的主要体现。好,现在项目已经完成了前期工作,了解了项目的目标、搞清楚了手上的资源,制定了项目的策略,然后编制了项目的整体计划,项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候,不像前期的时候项目经理要象记者一样到处和不同的人接触,搞清楚他们在说什么,努力猜测他们在想什么和他们的真正目的,那才是最累人的事情。当

32、然,小项目的项目经理往往自己也是一个资源,要做很多事情,这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。 和客户领导沟通时特别要注意,除非你需要对方给你支持,那么你才需要讲得具体一点,否则,告诉他一切正常就可以了,而且态度要积极一些, 千万不要说一些领导不懂的细节, 比如: “王局长, 最近项目进度还算正常,就是jvm经常发生一些内存泄漏的情况一”王局长: (*&$。和自己的领导汇报也要注意这个问题,除非他是一个技术高手,你需要他的技术经验,否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了,有些需要他支持的地方,比如资源调用需要说详细一点。和组员开

33、会,除了一些项目进度跟踪会议以外,还有很多讨论会,需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员,他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强(如果总结得不对,欢迎大家拍砖) ,所以,你作为会议的主持人,只要负责提出问题和记录下他们的观点,千万不要做评判者的角色。一个问题,有很多方面,从不同的角度看,现象是完全不同的,想想盲人摸象的故事吧。这些技术人员,他们往往精通一个方面,就自己的角度发表见解,除非一些很特别的情况,你都应该认为,他们提出的方案,从他们的角度来看是最合理的。你的长处是掌握事情的优先级,评估各个方面的轻重缓急, 从而根据他们的意见得出一个合适的 (而不

34、是正确的) 方案。 所以,在会议上,你要充分尊重每一个人和他的意见,夸奖那些意见提得比较好的人,千万不要把会议带入无休止的争论(你要让大家知道事情不是非黑即白的,而是多元的,唉,我们的教育惹的祸)。会后,你自己写文档,做决定。会议上大家的面子都被照顾了,自己实施起来的阻力就小,如果还有意见的,你就私下找他聊,如果还不能说服他,你就要让他明白,因为你负责这个项目、你担当风险,所以,这个优先级应该你来判断。组织中的高层,并不见得水平会比一般的成员高,但是,他要承担组织的风险,加之信息的不对称性,所以,对事情的优先级的判断肯定比下属强。 终可交付成果一定要是可以被检查的,比如, 【界面要求:美观大方

35、、简洁明快】 ,这个要求我就不知道如何检查。所以,给开发小组布置任务的时候就要考虑如何检查结果, 比如我见过一个计划, 里面有一个任务 【开发人员熟悉 ejb 编程】 ,这个任务,除了让这些人去参加一些专业认证考试,否则,结果很难被检查。所以,时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情,我听说有些老项目经理拿到项目是倒排计划的,即首先看如何验收和验收标准,然后决定工作计划。很多项目开始了很久,还不知道如何验收,那么这个项目出问题的可能性就很大了。做项目就是为了验收,我们的角色不是研究机构,我们的目的就是在付出那么多劳动后得到结果。另外我插一句:我是极其不主张到客户现场开发的

36、。尤其是一大群技术人员直接和客户交流, 很容易引起冲突和矛盾 (技术人员的本性决定的) 。 我的做法是项目经理和项目实施人员到现场,软件开发人员还是在公司做项目。项目实施人员就是初级项目经理,他们了解自己的产品,懂得一些客户的业务,关键是在于他们具有良好的沟通能力,俗称“皮厚” 。他们是客户和研发人员的桥梁,其职业方向也是很机动灵活,以后可以有很多方向可以转,比开发人员的路要宽得多。接着,我们再谈谈最让人头痛的需求变更问题。变更通常分为两种:一种是部分更改了原先的目标,即需求变更;另一种是没改变目标,但是客户不满意目前的实现方式,大到流程的实现,小到界面的布局,都是属于这类。碰到这种情况是难以

37、避免的,主要是事先沟通的不够充分和客户随着项目的进展,慢慢想清楚了问题,改变了以前的思路。这时候,如果需要改并且你的战略是容许这种情况的,那么注意下面几点:确保以前的文档, 就是记载着以前的结论的东西, 客户是否签过字, 如果没有, 赶紧把你的工作停下来, 赶快再和客户自己确认一下你的方案, 然后让他签字, 避免以后说话没有凭据;和客户坐下来, 探讨他修改的根本目的是什么, 是不是有同样能达到相同目的、 但是对你来说有代价更小的选择?(项目初期的工作) 明确更改流程, 一般是客户指定一人签字 (否则客户每个领导都有权力来插一杠子,你就废了) ,以正式项目文件的方式提交给你,然后,你做评估分析,

38、分析对成本、进度的影响,在你的领导同意后,出相应意见书,主要是要说明更改设计的原因和指出由此带来的不确定后果 (这个东西先写出来, 后面如果真的发生了, 至少不是你的错) 。 然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗?对,就学习那个,让大家都意识到任何的更改都有成本和代价。系统开发告一段落后,就进入客户培训、系统验收阶段,这个阶段,我一般会注意以下几个问题:一、给客户做培训前,多注意一些表面功夫。很多程序员认为,系统的逻辑核心是否正确是关键,至于界面如何,界面上的用词是否准确,那是无关紧要的问题,而且培训的时候也是信手拈来,想到哪里说到哪里,下面听讲的人不知所云,云

39、山雾罩,培训效果自然可以想象。我的体会是,给客户做培训的版本,如果你在做多次测试以后仍然不能确定逻辑是否合乎要求,那么,你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等,总之不要让客户看到一些他不该看到的东西。文档方面,准备至少两个文档:用户手册和培训手册。这两个文档的内容很多都是一致的,但是角度完全不同。用户手册往往是站在系统设计者的角度,按照自己的思路,分模块讲解系统的操作和功能;而培训手册,一定要站在客户业务人员的角度,根据每个角色面对不同业务的办理,如何通过使用本系统的一系列功能来实现目标。所以,第一次培训以前,系统界面是否完整正确、培训文档是否完备都是很关键的

40、因素,第一炮打不响,以后就麻烦很多作为项目经理,其实脑子里就是几样东西:做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想,这四个方面都是相互矛盾的,属于典型的又要马儿跑,又要马儿不吃草的类型。考虑问题的轻重缓急方面,往往是把快放在第一位,各方领导都会给你最后期限,所以保进度是第一位的;省是第二位的,企业的根本目的是盈利,如果收入不能增加的话,至少费用要控制住;好是第三位的,没办法,谁都想精益求精,但是,没有强大的资源保障,质量只好先牺牲了;最后是多,客户的要求源源不断, 如何降低客户的期望值, 让他们从理想回到现实也是项目经理的分内工作。 验收前,

41、除了做好文档工作,即可交付成果以外,多花时间搞清楚客户的做事情流程是很重要的事情,这些在前面已经有所提及,这里就不再多说。我对验收最大的体会就是举证问题。即千万不要让客户这么想:你必须有证据证明你的系统是没问题的。 这样你就没戏了, 微软那么多天才, 做了 xp 还天天打补丁, 要你的程序没问题,既不可能,你也没办法拿出证据。你要让客户明白,所谓验收,就是我按照测试文档的测试用例跑一遍,结果和预期结果一致就应该算通过了,而且还容许有一些小错误留在验收后改正,他可以对测试用例提意见。所以,验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求,那么他应该举证,证明这个系统和最初设计相背离的

42、。所以,参考法律概念,千万不要举证倒置。另外,认为系统完美了才能验收的想法也是错误的,软件开发合同里一定要注明验收以后维护期的费用问题,否则,客户担心一旦验收就得不到你们的支持,自然不配合验收,那么,你这个项目经理就很难交功课了。篇五:项目实施心得体会再论实施前言:在昆明公司这一年多来,发现昆明公司服务部在实施方面效果都不太好,表现在:一、 实施周期过长, (一家医院使用到医嘱基本上都超过了四个月, 标准版基本在两个月甚至更长,而签验收的时间长达一年的周期(比如官渡区人民医院、镇雄县人民医院等)二、实施效果不好,系统启用后实际使用没有达到计划,操作员操作不规范致使系统运行时频繁出现操作错误,而

43、我们的技术人员就一而再再而三的跑医院处理尾巴工作,甚至坐20 几个小时的车去安装一个客户端。 his 系统数据不能完全提炼出来达到医院要求,造成后期不停的补写报表,更改应用模式以达到医院的使用要求,颇为浪费人力物力。三、实施期间实施人员和医院方的关系不融洽,医院不满意我们的实施人员,而我们实施人员又对医院产生抱怨,甚至关系似同水火。由于上面三个方面的表象最终结果是实施不能按计划进行,收款不能按合同进行,服务满意度提升不起来,给整个昆明公司带来了发展局限,并留下种种隐患,为后期工作带来了很大的被动。针对上述种种,个人参照自己以往的实施经验和一些感想心得总结出来与大家探讨,希望能给于大家一些启发,

44、最好是能为大家以后的实施工作带来一些帮助。个人对实施的理解一、 实施的目的简单的来说实施最终目的就是让我们的软件在医院正常使用而我自身对实施的目的的理解是,按我们公司积累的经验,运用标准化实施规范,让我们的软件在预期的时间里按照标准的计划进行软件在医院的应用,通过规范的实施以促进公司软件款项的正常回款周期,并让使用软件的用户满意,建立一个良好的相互合作发展的合作伙伴关系,为公司的后续市场挖潜铺好路,让医院通过使用我们软件来实现信息化管理,实现双赢。二、如何才能做好实施?如何保障实施的目的的实现?下面我讲讲我认为在整个实施过程中四个重要的环节、 实施心态首先心态很重要, 从中联企业文化的角度出发

45、, 我们要把 “我是中联” 彻底理解和运用,当你负责一家医院项目实施时,你就是一个项目负责人,这个负责人就不简单了,从工作上来理解你是整个项目的责任人,这需要一种高度的责任心才能从事的工作。从合作方面看,你是代表中联公司到医院来协助医院进行信息化建设的工程师,你带表了整个中联,时刻维持中联的形象和利益。你必须给院方面前树立一个医院信息化方面的专家形象。这样才能说服医院按你给于医院正确的软件管理应用方面的建议进行实施配合。 如果你都说服不了医院,你如何让医院正确使用我们的软件?所以这点我认为是很重要的一点。另外还有我个人的一点经验也是一个非常重要的认识。做为实施人员从进入医院那一刻起一定要把自己

46、当作医院的一份子。当你真正把自己当成了医院一份子后,你在实施工作中的站在医院的立场为医院进行服务工作,这样的好处在与你会在相对来长时间的实施工作中不会产生孤独感, 并且能让自己在实施中保持一种平和的心态工作, 避免一些不必要的冲突。另外院方感觉到了你的这种心态后,医院会更好的接受你和配合你的工作,还会带来意想不到的好处。 (比如医院活动带你参与,免费娱乐等等)其次是自我心态的调整, 自娱自乐很重要, 毕(转载于 : 项目的心得体会)竟在外一个人实施始终是有些孤独感和工作压力产生的压抑感,拒科学考证一个人长时间的感到孤独和压抑时就会情绪不稳定,脾气变得暴躁,如果这种状态你的实施工作肯定是做不好的

47、。随时都在发脾气的人,医院如何和你相处?会给你好脸色看?而这点是我的强项,我把我自己的解压心得提供给大家参考一下,在医院如果有条件上网的时候,那么网络上的一系列活动都成为我的解压手段, (游戏、电影、聊天)当然这些要在工作之余进行,否则你会死得很难看。如果没条件上网,那么你就在医院交交朋友,医院值得结交的朋友还是很多的,如果和医生交上朋友那么你可以免费看病,和药房人员交上朋友那么你可以免费吃药,和医技科室交上朋友那么你可以免费检查,如果和漂亮的单身护士小姐交上朋友那么你可以开展一段值得回忆的邂逅。 。 。 。 。 。另外每到一个地方实施实际上也可以看做是一个变相的旅游度假,每个地方总有一些值得

48、去看去玩的特色和景点,这也是不可多得的人生体验。这样的心态下我是完全把实施看做一个充满新鲜、刺激、丰富多彩的生活,而非看成一项枯燥苦闷的工作。最后一个心态就是享受成就感,人在世上无外乎追求的两方面,一个物质方面的享受,另一个就是精神方面的享受,而成就感是精神享受中最具代表的一个方面。当你用自己的努力完成了一个医院的信息化建设是多么值得骄傲的事情。我们都有这种经历,当经过一个或者谈起一家自己成功实施过的医院会给旁边的人说这家是我实施的,这时如果大家细心一点会发现说这句话的时候他的脸上会浮现出一种自豪的幸福表情。对这就是幸福,我们都要懂得如何去享受工作给我们带来的幸福,这才是积极的人生。、 实施沟

49、通实施环节最难做的工作是什么?我认为不是医院的要求和应用模式暂时不能满足,也不是人员素质低下,而是沟通。沟通不到位,你就不能完全理解医院的实际应用模式,以及真实的流程处理想法。并且实施过医院的技术人员都有个感受,医院的需求好像随时都在变,早上说了这种模式下午又变了,带来工作的被动性,并造成你辛辛苦苦加班加点做的工作付之东流,这时候你会有种说不出的无力感。而医院在使用软件过程中对应用模式感到不适应就会让医院产生怀疑态度,医院在这方面是很敏感并且具有一种惯性思维,如果你某一项不能满足或符合医院使用要求,那可以认为你整个软件都不行,不光怀疑实施人员的能力还会怀疑公司,带来很不好的负面影响。如何才能少

50、做或不做无用工?如何保障工做进度正常按计划进行?如何保障实施效果?结合我的实际实施经验来看,只有做好沟通工作才能解决上面提出的三个方面问题。第一个沟通,是进场时的实施动员和应用模式确认大会,这个会议是重中之重,首先医院需要做相关准备,做为实施人员也要做相关准备,然后通过会议进行敲定落实,还要整理出文字报表让医院方的该项信息建设工作负责人和院长签字认可, 最好是各个科室都要确认,但需要给医院说明实施模式确定后由于医院可能有些方面估计不完善会产生一些工作方面或使用流程方面考虑不完善的地方,以后可以进行协商,但必须是医院相关领导组织讨论后再由会议的形式两方进行讨论和辩证后协商落实。依然要出具文字性的报告,这样才能让医院方认识到该项工作的重要性,不是随便改改就行的第二个沟通,是和科室实际操作人员之间的沟通,首先你要把自己推销出去,让医院的绝大多数人都认可你后再进行工作讨论和沟通交流。如果相互之间不认可,那这个沟通工作形同虚设。医院各个层面的人都对你本人认可,对整个实施工作也是非常有用的,医院相对来说人际关系方面相对复杂,你短时间内不可能了解透彻,那退而求其次就只有做好所有

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论