项目管理经验积累.docxVIP

.疑问为什么工程进度慢？ .工程经理分配的浮动时间是否被浪费掉。 1.2为什么做出产品客户满意度低？ .客户对于工程的参与度是否太低1.3为什么工程bug很多？ .开发人员对于业务的理解是否有偏差.问题讨论 一个团队，是分工明确好，还是人人全能，各项工作都 能统筹兼顾好？ 分工明确： .责任明确便于管理，在组织上可提高工作效率，也更有利于个人专业技能方面的开展。 .社会的开展和人类的进化，更加凸显了个体差异。分工明确，是高效利用人才的方法。正 如经济学家张五常所言，承包制表达了个体差异。 .1.2人人全能： .有利于资源平衡，容错率高，但容易变成救火队员。 ,都能兼顾最可怕的地方就是会相互去影响对方的工作，一个懂运营的程序员每天不想着怎 么去实现好产品，而是去操心运营，设计师去干扰前端的实现，人人在其位不思其职，团队 气氛和效率都不好。 .1.3综合考虑： L如果条件满足全能的情况下，肯定是希望全能。在全能的情况下，我可以再去明确分工。 3,分工明确的良性效果，需要有个全能型的，有影响力的领导，来协调和营造团队的外部和 内容环境，毕竟，再NB的个人，也无法离开外部环境而有所作为，怀才不遇的人多于过江 之鲫。 你要始终明白你肩负的一个任务，那就是形成你的团队文化和做事的方法，这是 一个长期的任务。你不可能一下子把想做的事都做到。 因此不要急于求成，要根据自己的处境有所选择，沉着处理。 3.2工程失败原因分析工程经理实战经验缺乏 工程经理都是从企业高级软件工程师和高级构架师提升来的工程经理职位， 因此不可防止的造就了这样的工程经理过分集中于技术上，从而忽视用户的角度 去分析。以技术为主的应该将重心放在IT工程交付上，以商业为主的要满足用 户的商业目标的需求。 322工程计划不够合理 工程计划过程中存在不合理假设和风险预测缺乏导致工程失败的主要因素， 在计划过程中必须留时间处理不可预知的问题，因此在任何工程过程中各种无法 预知的都应该预留10%的时间来应对。 需求不确定性 需求分析和开发过程中不断的进行修改与变更，需求在初期的过程中对需求 定义阶段出现很多不确定的因素，本可以防止的错误在后期过程中影响进度和预 算等情况，从而导致工程失败,还有就是开发过程中需求变更处理机制的不合理, 麻木进行用户满意度追求，导致附加功能不断增加，原有设计不停变更等，以致 于超出预算本钱导致工程失败。 324工程测试缺乏 工程开发过程中工程经理经常牺牲工程测试时间压缩几天内完成工程测试， 从而导致工程测试结果不到位，用户也放弃测试与检测的责任，开发人员关注系 统的性能从而对结果的商业需求满意度缺失导致致命的错误。 无工程时间节点 工程没有具体的开始时间和结束时间，会导致工程在永远不确定的时间无休 止的进行，工程成员疲惫最终工程失败。因此必须明确工程何时开始何时结束。 领导者经验缺乏 工程成功的关键在于领导而不是过多的管理制度，领导需要卓越技能和丰富 的经验以及职能以外的奉献精神，也需要激发和带着团队的领导气质。 2.2工程中如何应对甲方不配合的情况? 解决方案.如果甲方长期使用技术外包，一般情况下，甲方公司会有专设的工程经理（可 能是IT工程经理，也可能是业务端专职工程经理），并且，很多情况此人同时 亦是甲方合同签署的代理人，此角色在甲方一般具备上达公司一把手，中达业务 单元一把手，下达具体业务需求代表（即参与到工程的业务人员）的管理权力。 故而，首先，合作期初订立了工程制度了，这些问题你一提，甲方工程经理就懂 了，基本都会配合你；倘假设没有订立对应的制度，那赶紧找甲方工程经理对需求、 测试、验收的里程碑的重要性加以强调，争取到甲方工程经理的支持，基本上问 题就解决了。 .倘假设，该工程仅仅是公司临时外包的一个工程，那甲方的合同签署代理人， 很可能是甲方IT老大或者业务老大，估计除了签合同那天你基本后面都见不到 他，合同签署后，甲方IT老大或者业务老大基本都不会请自参与到工程中来， 很可能扔给你一堆业务需求方加个吧IT的人。 .这个时候，甲方人员配合自然问题不大，要是甲方人员不配合的话，简单来 看就是甲方公司没把这个事当一个工程来做，本质讲，甲方参与“工程”的人员 并未在甲方公司获得本“工程”对应的激励，简单说，工程做的好坏甲方这些人 不奖也不罚，那这种情况就很难搞了，甲方给自己的工程成员发不发奖金乙方怎 么搞得定啊？ 但解决问题的本质还是一点一一甲方须有内部协调人员，能够统筹甲方的人员参 与到工程中，换而言之，在你的引导下，帮助甲方推出一个临时工程经理，前面 不是说了么，甲方领导本就不重视这个工程，工程激励八成一片空白，不然早给 你配了工程经理（甲方）了，那从一帮甲方中如何找出这个“临时工程经理” 4.做事尽量多留证据，多沟通、多汇报。实在推不动就不