文档介绍：项目总结经验教训
篇1：我的项目阅历总结
我的项目阅历总结
么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧; ：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你准备怎么做，什么时候要他们做什么打算这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。许多沟通原则都是潜规则，假如你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清晰，你以后就会吃亏。下面的东西看起来无聊，其实还是很管用的：第一个是规定信息的流淌方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种状况适合小项目，人少;拉的意思就是项目经理就是一个类似web服务器，你自己须要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简洁的是白板，困难一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告知你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要肯定化，一般状况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应当主动去和领导沟通。其次个问题就是文档问题，许多人怕写文档，但是项目经理肯定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢?就是因为没有证据。所以项目经理起先就要和客户说清晰有些文档是必需签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外全部达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。还有一些问题，比如你提交的报告，给领导(包括本方领导和客户领导)做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是留意要留记录，标明是谁的责任;另外，假如你在起先阶段就和领导商定：假如批示提交三天后没有得到领导答复就算对方同意，这样你就会主动许多。再比如不同事务的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理特地签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。
，定义了一些嬉戏规则，现在是坐下来做安排的时候了。这一节，随意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完成一个目标有许多种方式，你要选一种你最熟识的，而不是看上去最完备的，这个思路会让你的项目削减许多风险。有时候客户会被某种新技术打动，坚持要你采纳那种新技术，你就应当告知他：你选我做这个项目，就应当容许我采纳自己最喜爱的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。采纳一个安排会让你的工作更加明确，比如用微软的project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情须要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标记等。全部的结果最终用一个叫做甘特图的形式表现出来。你做完这个表以后会惊异地发觉，甘特图上项目的结束时间会远远落后于你的安排结束时间(签合同的人恒久不会先征求你的看法的)。当
然，学过项目管理的人会大谈什么wbs、优化路径之类的东西，但是我的阅历是你再优化也不行能把这些东西支配到安排的时间结束。假如你没遇到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否排列了全部要做的事情和正确评估了他们所须要的时间。这时候，你就要考虑牺牲一些任务的时间(也意味着质量)了。根据什么标准牺牲?这个项目的战略!我们在第三节提到过的战略。我的阅历是