本文是项目经理在项目交接前的总结报告，强调了项目起始阶段的准备工作、执行阶段的文档管理和沟通协调，以及结束阶段的实施与维护。项目经理指出，沟通是解决项目中遇到的问题、规避风险的关键，包括与客户、团队成员及公司高层的有效交流。同时，文档管理对于项目信息保留和团队协作至关重要。
下文中，为了语句通顺，有的采用甲乙方，有的采用我们、公司，客户的说法；有的地方是涉众，有的地方是项目干系人。
本阶段也可以细化为准备阶段和计划阶段。
作为项目经理，在项目意向明晰后，首先做的事情是：
查阅资料，确定助手，制定工作计划。
查阅资料主要分两方面：
Ø 系统的技术实现
Ø 企业的业务运作
助手的主要工作内容是在技术和业务方面与项目经理有互补作用。
本阶段的工作计划内容：
Ø 就是和客户（在本项目中，我们的客户就是技术支持部的应用维护人员）面对面的沟通
Ø 了解客户的期望以及对项目的认知情况
Ø 了解客户的业务
Ø 进一步了解相关技术。
这三方面的工作都是非常重要的，查阅资料表明项目经理需要获知项目的难关和风险在哪里，并开始采取措施去规避风险。确定助手为组建项目实施团队奠定基础。工作计划的目的就是要定义项目（主要是
项目范围。划分项目阶段和工期等），其作用是尽可能使甲、乙对项目的各个方面达成共识，这会为项目的成功奠定基础。如果不详细定义项目，将会导致用户需求的不断变更和扩大，导致项目严重超期。所以说尽量严格的定义项目，可以最大范围的保证项目的正常进行（即使用户不签字，我们也可通过邮件或者讲解的方式让甲方理解乙方的想法，并消除分歧）。
作为一个团队，一定要知己知彼。知己，就是要明白团队到底能为客户做多少，做到什么程度，一时不能做到的，怎么说服客户，让客户能够理解和接受我们的建议；知彼，就是要清楚的认识到客户对项目的评价标准是什么。
在进行设计之前，首先要做的事情就是要了解客户的业务。这可以通过
获取
-
确认
-
再获取
-
再确认
……的方式来获取。如果客户不配合的话，那么可以通过各种方式和客户进行沟通，或者咨询乙方公司的业务人员，其它公司的产品介绍来最大范围获取。当然，不管客户是否配合，我们都要
识别甲方的主要人员，要对这些人员进行重点沟通（这对项目开展以后的工作会有良好的基础）。要识别客户的利益点，要找到利益点、技术以及业务的结合点，因为技术人员和业务人员总是一对矛盾体，如果不对这些矛盾进行调和，即使技术做的再好，客户也会挑各种毛病，导致项目失败。
总之，
沟通，沟通，再沟通。
那么除了和客户之间的沟通外，还有一件重要的事情，就是
让公司高层重视，有了这一点，就可以尽量获得充足的资源和来自高层的支持。
再有一件，就是
和其它项目涉众保持良好的关系和沟通，在我们的项目中，如果没有质量部和支持部的通力配合，我们的项目也不会进展的比较顺利。比如，在测试阶段，支持部的测试工作非常认真和全面，把绝大部分客户能想到的东西都想到、测试到，使我们到客户那里除了少量新增需求外，对原有的系统几乎就没有需求的变更。对于支持部，我们从他们那里获取了大量的业务知识和集团客户的想法，因为毕竟他们是在一线和客户直接交流的人，为我们说服客户提供了大量的素材。
在进入本阶段后，项目经理和助手留任并组建实施团队。这样做的好处是项目信息不会损耗，并且通过双方的沟通，可以事先发现很多问题和风险。
在这个阶段，很重要的一个工作就是
文档。
文档内容：
Ø
文档管理规范
Ø
项目管理文档
Ø
软件开发文档
通过这些文档，以
保证项目信息的最大保留。
经过上述的准备和计划后，接下来的工作就是：
Ø 就要选择项目组其它成员
Ø 组织项目启动会议
向项目组成员通报项目的工期和目标，以及确认每个人的职责（这些在后继的工作中是需要根据实际情况进行调整的）。
鉴于并不是每个项目成员在各个方面都很熟悉，作为项目经理必须发挥自己对技术的总体把握能力，随时了解项目成员的业务、技术的熟悉程度，以及进展，并给予必要的指导和帮助，最终成功规避由于项目成员在业务、技术方面的不熟悉可能造成的风险。
在项目启动会议后，就要进行实质性的
WBS
和项目计划，使每个人都明白自己身上的担子。遇到问题的时候，可以尽快的提出来，在最早阶段规避问题和风险。
在人员、计划、WBS等等都确定后，就要根据实际的工作情况，来调整计划，跟踪风险和问题，不过重要的一点，还是沟通。而且
要从业务的角度看项目和技术，而不要仅仅从技术的角度看技术和项目。
再有，通过这次项目的实施，先确认功能，完成功能的开发，再进行界面的开发，可以确保开发过程的顺利进行。因为业务要是都不熟悉的话，页面再好又能怎样，而良好的业务实现，可以在任何形式的页面下进行快速的调整，根据我以往的经验，不要在页面上浪费宝贵的时间，虽然页面的展现也非常重要。
我们这个项目，由于在公司内部开发，因此各项进度还比较顺利，但是到了实施阶段，客户的参与程度有很大的提高，但也带来明显的弊病（好在出发前意识到了这个问题），因为参与的客户人员会随时向项目组成员提出些修改要求（由于我们对业务比较熟悉，客户的修改需求往往是体现的怎么使用舒服上面），开始时我们对细小问题有求必应，后来发现有的要求很有必要的，但有的要求则是很不成熟（还好，通过沟通，没有出现来回变了好几次的情况）。对于这种情况，尤其是随着项目的进展，对项目的不利影响越来越大。对于这种情况，我们首先要做的就是说服用户不要修改（无非是说如果改了对你有什么影响，会对系统有什么影响等等，这些最终会给你带来什么），如果客户非要改的话，就要他们出书面报告，我们提出变更的方案以及工期，让客户确认变更的优先级，让他们也意识到我们的工作量到底是多少。
在项目执行的过程中，要主要到会有一段时期是项目组的
低潮期，内部成员之间也出现过一些问题，比如彼此工作习惯的不同、外界因素影响等等，从而对项目的工作气氛产生不良影响。
解决的办法是什么？
Ø 倾听
一开始就注意和所有项目成员有非正式的沟通渠道，注意倾听他们的述说，使各自的情绪能够排遣。
Ø 定期召开例会
通报项目的进度、问题、新的计划等，统一思想。
Ø 活跃项目气氛
不定期聚餐，不伤感情的笑话,……。
Ø 信任
树立公正客观的工作环境，求异存同，使每个成员都有被尊重的感觉。充分信任每个人的能力。
与最终的客户尽早沟通是可以保持甲乙方关系的一条捷径，可以及时让用户校正开发方向（不过我们因为长期施工此类项目，所以本项目只是后期，用户才进入项目的）。
主要进行的就是项目的实施、后期维护和初验、终验工作。为了公司以后的发展，还要整理文档，对软件产品的发展提出建议，供公司领导决策，目的是为继续拓展市场做准备。
我在这个项目中还有一件没有做的事情，就是对项目成员工作的表彰和最后聚会。而这一方面是对成员工作的认可，另一方面是提高成员对项目的认同感，让大家都有一种
“高兴而来，满载而归”的感觉吧。
我认为，在任何一个项目在执行过程中都会碰到各种各样的问题，评价一个项目是否成功并不能仅仅以碰到问题的多少、工作量的多少作为标准，其标准应是按时、保质实现预先确定的各项指标。
在这个项目中，也碰到很多问题，比如：
Ø 项目起始阶段和执行阶段的前半段，甲方代表的“过渡参与”
Ø 资源问题
Ø 成员的冲突等
其实，解决这些事情的办法也是很多的，关键就看我们的态度，是否想去解决，如何去解决。
比如第一条，站在客户的角度思考问题，取得客户的信任；这样最后客户也会站在你的角度替你思考问题的。其实，大部分客户都是通情达理的，问题在于我们实施项目时做的每一件事情是否到位。
资源问题。争取领导的支持，与相关部门沟通并配合我们的工作；原定资源不能到位时，不要一条路走到黑，一定可以找到替换办法的，因为每个项目都不可能自始至终都会资源充足的。
成员冲突。倾听，沟通与信任。
说了这些，我所围绕的都是项目管理中的沟通来说的，沟通的涉众都是谁呐，公司领导，项目成员，客户。沟通好了，问题都会解决，风险也会规避。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
