不懂技术的PM，该如何管理技术大牛们？ - 简书
不懂技术的PM，该如何管理技术大牛们？
半路出家，转行项目经理，学了PMP专业管理知识。
新到一个公司，基本上沟通顺畅，作为一个弱女子，一般情况下，只要虚心求教，设身处地沟通，基本上没多大问题，唯遇到一个服务器负责人，各种不屑。一个问题不会和你说明白，而是用他那专业术语搪塞，同时秉承着“你们到底算干嘛地”的态度，感觉似乎项目经理反而额外给他增加了工作量。
遇到这种话情况，我该怎么办？观点1:首先，PM不是管理人的，所以这一点无论你还是大牛们都必须要明确，你的权利只来自于项目和公司领导授权。其次，PM不一定是技术专家，但一定是沟通专家，学习大牛的技术不是你的重点，你只需要了解常用术语和基础知识即可，你的重点是如何安排好牛人们在合适的岗位上发挥他的长项。
再次，项目管理必须有套路和章法，利用领导授权给你的管理权限去和组员做好沟通，让项目的目标成为大家的目标，而不是你个人的目标，他们的价值不是因为服从你而产生，但绝对会因为服从你而提升。
最后，你需要建立一定的气场，加强和大牛们的沟通，不光是技术与工作上的，还有生活和三观上的，让组员看到你的亮点，愿意接受你的指挥。观点2:态度不能太强硬了，要多多学习，他不像你解释的事情可以请教其他人。感觉做技术的大多数人脾气都还不错，一定不要在大牛们忙得时候请教。观点3:对于这种问题不能全怪别人，很多人遇到过，仔细想想，项目经理如果不懂太多，什么都问，没问到点子上，这样确实花销了别人的时间。
解决这个问题，当然是请客吃饭，虚心接受别人的意见，同时对于所处的事情，你要积极学习。
工作上没有谁真正的会去难为谁，只能加强自己的理解能力了，而且有时候，你认为很专业的词汇，可能在他眼里，是你必须要懂的东西。 观点4:项目经理必做的工作包括WBS，在自己不懂技术的时候，分解项目的工作可以在会议中进行，把任务分解完成后，就可以进行后续工作了。 1. 工期确定：如果觉得某个任务的工期不合理，直接在项目会议中提出，这个部分会影响到项目工期以及前置后置任务工期，那对应任务的负责人自然会做出解释，如果项目组所有干系人都认同，那么OK，调整项目。同样，故意拖延的就会有人提出疑问甚至被高层质疑能力。 2. 控制进度：严格按进度执行，定期发送进度报告，提醒相关干系人，如果进度延误，上报相关干系人。沟通时注意方式：邮件+即时通讯，一定要确认对方收到信息。
有以上2点，不懂技术，那就不关心好了，只要按时完成项目一切皆好，会议中承诺的进度完不成，那相应的负责人会承担延期的后果。
当然，如果能了解技术，能加强和各部门的沟通，对项目是有利无害。不用精深，但面要广。观点5:说明没有问对人，要选择不同的问题问，先问小兵一些小问题，搞清楚方向，再根据方向，提出更高级一点的问题，到时候，人家就不会不屑你了。
一上来就是一个门外汉的问题，多来几个，人家自然觉得你估计找茬，浪费人家时间。 观点6:一切以解决问题为目的，有些技术人员是不善表达的，也不能强求他们说的一清二白。 观点7:我现在遇到的就是这种情况。我的方法是我要找技术之前会有一个大致的熟悉。如果太专业的实在不清楚就虚心请教。但是绝对不会问第二次，一般要是哪块不懂就网上查。观点8:想从别人那里学东西，就要懂做人，这要靠情商。什么动不动就不懂，那要你来管我干什么，该干啥干啥去。所以沟通之前要明确主题内容，避虚就实。如果是虚心请教专业技术问题，就放下项目经理的身份，营造良好沟通氛围，做个乖巧的好学生。观点9: 一定要知道项目经理不是要控制或要管理人，更重要的是协调与沟通，通过协调与沟通来促使项目在预期内实现目的。
专业技术还是需要学一下的，但是只要够用就行，千万不要走弯路，你的责任是项目控制，不是知识控制，要用自己的话语或气场去让项目组的同事觉得你不是高高在上，而是和他们处于同一条船上，而且有直接的利益关系。
如果你在项目经理初期，确实不懂技术，那可能要累点，问题尽量以邮件方式确认，必要的时候邮件确认一遍，电话确认一遍，换一个人再确认一遍。
多交朋友，多请吃个饭，建立铁关系。
多查度娘，了解术语的意思，够用就行，不要特意去学。
利用空闲时间多多与人交流，加强自己的交流能力，我们的重点是为我所用，而不是我为别人所用！怎样面对遇到只会说，不懂管理和技术的项目经理-一个软件项目的项目经理不懂技术 能当好项目经理么 _汇潮装饰网
您当前位置：
怎样面对遇到只会说，不懂管理和技术的项目经理
怎样面对遇到只会说，不懂管理和技术的项目经理
拿好自己的钱。技术上你给出建议，然后你根据实际情况我想他肯定有他的优点，做好事情。这些都要有据可查，他给出决策。我告诉你，我做事的原则，或者技术决策出现问题。那用事实说明问题，管好自己的嘴巴，当然你目前看到的是缺点，做好自己的事情。不要过多废话，抱怨，通常邮件作为证据。一旦时间延误，不可取
人的素质不高确实非常可悲,她不知怎样与同事和睦相处最终吃亏的还是她自己。不要以为她一时得逞而高兴,同...）
后退有时只是回到起点,是为了再一次冲刺）
优秀员工与拙劣员工的区别表面有时并不大,只不过优秀员工比规定的只多作了15%,而拙劣员工比规定的只少...）
在我们的一生中会遇到你最爱的人, 最爱你的人,还有个就是是共度一生的人. 首先会遇到你最爱的人,然後...）
遇到个只为自己想的领导,该怎么办
GYZ2370 | 浏览41 次 我有更好的...2014-03...）
吵架可以!外出一天不归家就不好了! 看你回复网友的回答!! 貌似你腰板直不起来啊! 看样子女方家庭比...）项目经理是不是技术出身有影响吗--拓源优课的博客当前位置： >>
项目管理心得：一个项目经理的个人体会、经验总结
项目管理心得：一个项目经理的个人体会、经验总结介于许多人对项目经理这个职位的陌生和含糊， 将自己的切身经历和阅读、 交流得到的一些 经典案例整理出来，有朋友问我，这篇文章出处在哪里？这些经历很多不是一个人的经历， 这些总结很多也不是出自一个人之手， 如同我们觉得一段代码写的很好， 必定会收藏整理成 为自己的一部分加以完善共享， 接着不断的有人完善共享下去...所以每一个有相同观感的人 都可以成为这篇文章的作者， 将宝贵的经验完善和传递下去， 如同先师张孝祥所倡导的我不 是最聪明的人， 所以要不断的学习总结别人已经有的成功经验， 才能在最短的时间赶超别人！ 要做好一个项目经理，是很有点难的？他首先必须要是技术和管理的化身，其 次要具备较好的形象和极佳的口才， 同时拥有一定的人格魅力， 另外他还要具备一定的设计 头脑和审美观，还有很多，不再赘述....在大多数 boss 的眼里，是没有体系分工的概念或者 基于各种原因分工比较简单， 所以很多书里讲的东西拿到现实里都会有点靠不住， 在没有产 品经理，没有需求分析师，没有架构师，没有系统分析师，更有甚至没有实施和运维，也要 能毫无怨言的把事情做好！它是一个攻守兼备的全能型职业，很多 boss 都把它放在了至关 重要的位置去看待，舍不吃舍不得花也要把你留住，也是你的舞台！而这在老美“山姆大叔” 的眼里是绝对不能容忍的，就像福特汽车流水线，肯德基，麦当劳一样，他们更希望所有员 工都能这样被取代，当中国的所有企业进步到那种境地以后，我们能做的事情就不多了，你 想走到更高端的塔尖会更难！ 投刘备还是投曹操都没有错只要你能更快的走到塔尖， 只要你 是舞台的主角那就是正确的选择！ 不管你是正在转型做项目经理，还是有打算转型，那一定要转变以前种种思想 的包袱了，由内而外的改变自己，很多路子只是苦于我们没有发现，没有人指引。我们不希 望每字每句的总结和讨论都能去符合每个人的行走线路， 因为那是不可能， 只希望当我们遇 到困难缺乏指引时它能成为我们的坚强后盾和理论依据，因为沟通才是通往成功最好的桥 梁！正文 ： 做项目经理工作多年， 感到做这个工作最要紧的就是要明白什么是因地制宜、 因势 利导， 只有最合适的， 没有什么叫对的， 什么叫错的， 项目经理最忌讳的就是完美主义倾向， 尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。以下是本 人一些做项目的个人体会，写出来供大家指点，在讨论过程中共同提高水平。软件工程跟其 它建筑工程之间的区别之一是， 总有人会拿各种各样的事来讽刺软件的设计和开发过程中的 不确定性， 但从没有听说过有什么大桥建成之后和图纸上设计的不一样的。 之前有一个漫画 《 客户真正的需求是这样的 》 已经足够一针见血的了， 今天的这幅漫画同样一点情面的不 留，虽是漫画，但现实生活中不乏实例项目开始阶段是一个最重要的阶段。 项目经理在接手一个新项目的时候， 首先要尽可能地多 从各个方面了解项目的情况，如： 1. 这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。 在国内很多客户都很不成熟的情况下， 千万不要根据项目的名称望文生义地去想象项目的目 标。 一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一 个计算机生产管理辅助信息系统。前期了解情况的工作越详细，后面的惊讶就越少，项目的 风险就越小。 2. 这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、 技术监督方等等， 很多项目里除了业主单位的结构很复杂以外， 还有一些其他单位也会牵涉 进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项 目的看法和期望是什么。 事先了解各个方面的看法和期望， 可以让你在做项目碰到问题的时 候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前 准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的 敌人，只有一致的利益，这句话作为项目经理是一定要记住的。 3. 基本了解了客户的情况后， 下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视， 这个决定了你在需要资源的时候， 公司是否会根据你的要求提供 最有力的支持。领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望， 是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷衍了事， 公司领导对项目的 态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响。 4. 在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞 争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在做项目的风 险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来 的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否 需要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需 大件关键设备要尽早预定， 以后不管发生设备等人还是人等设备的情况， 浪费的都是你的时 间。 5. 现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清 楚（主要是讲做什么，而不是说怎么做） ，而且把如何检查也说明得很透彻。也就是说它不 仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算 完成了。 简单地说， 项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查 每一个结果。 6. 是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资源， 那么做计划以前， 你还需要和你的经理和客户充分沟通资源的问题。 因为很多资源是还不明 确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题 不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个 项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一 个不可能完成的任务，如果项目经理不能尽早发现风险，那么就只能去当烈士了。 7. 明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项 目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力 去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但 是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配 备行业专家（Industry expert） ，这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理 解。 我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语， 结果搞得客户一头 雾水，反过来，他还指责客户不懂技术。其实，明白自己想做什么的客户已经是很好的客户 了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客 户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧。 对于这种需求天天变的客户，你就一定要事先做好规矩： 一、 统一联系人， 客户指定一个人和项目组进行沟通， 不能张领导、 王领导都来说几句， 如果他们意见不一致，那你只有得罪领导的选择了。所以，项目的最初就要定好规矩，我项 目组只认一个的意见， 有什么要求你们内部先统一再和我谈， 我不想卷入你们内部业务部门之间的矛盾之中。 二、所有需求变更全部要有书面文字，这点切记！这样做好处多多： ? ? ? 有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的。 便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目。 对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖 章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死 腹中了。 8. 现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知 道你打算怎么做，什么时候要他们做什么准备，这些事情将是你的主要工作。既然沟通这么 重要，那事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则，如果 你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情。但是，你现在面 对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。下面的东西看起来 无聊，其实还是很管用的：第一个是规定信息的流动方式和介质，是推还是拉。推的意思就 是项目经理将主动发布信息， 不管通过电话、 邮件还是书面方式， 保证将信息传达到每个人。 这种情况适合小项目，人少。拉的意思就是项目经理就是一个类似 web 服务器，你自己需 要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质 的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了 你没去看就不要说我没告诉你。 说这些看似很无聊， 其实里面牵涉信息传达不完全的责任问 题。当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是 同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。第二个问题就是文档问 题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为 什么会说不清呢？就是因为没有证据。 所以项目经理开始就要和客户说清楚有些文档是必须 签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西， 比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就 能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。 还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结 果领导压住不批，让你无所适从，结果拖延了进度。 这时候，你可以等，但是注意要留记录， 标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领 导答复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的 事情记录在项目日志里、 什么等级的事情要双方项目经理专门签署备忘录、 什么等级的事情 要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动 9. 好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会 就是了。首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划 分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的 是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完成一个目标有很多种方 式， 你要选一种你最熟悉的， 而不是看上去最完美的， 这个思路会让你的项目减少很多风险。 有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我做这 个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃 亏的人还不多，我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确，比如 用微软的 Project 软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件 事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。 所有的结果最后用一个叫做甘特图的形式表现出来。 你做完这个表以后会惊奇地发现， 甘特 图上项目的结束时间会远远落后于你的计划结束时间 （签合同的人永远不会先征求你的意见 的） 。当然，学过项目管理的人会大谈什么 WBS、优化路径之类的东西，但是我的经验是你 再优化也不可能把这些东西安排到计划的时间结束。 如果你没碰到这个问题， 在我恭喜你挑 了一个轻松活之前， 请你再去确认你是否罗列了所有要做的事情和正确评估了它们所需要的 时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么标准牺牲？ 这个项目的战略！我们在第三节提到过的战略。我的经验是如果你什么都赶进度，其结果可 能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事 情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延 误， 成绩单是否靓丽了很多呢？战略决定优先级， 而正确排列事情的优先级是一个项目经理 能力的主要体现。 10. 好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制 定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段反而是项 目经理比较空闲的时候， 不像前期的时候项目经理要象记者一样到处和不同的人接触， 搞清 楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然， 小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。项目经理 这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注 意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以 了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：“王局长，最近项目进 度还算正常，就是 JVM 经常发生一些内存泄漏的情况…”王局长：“(*&$@@”。和自己的领 导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报 进度是否正常以及有问题时你的对策和打算就可以了， 有些需要他支持的地方， 比如资源调 用需要说详细一点。和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要 大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、 缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍砖） ，所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。一个问 题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。这些技术 人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该 认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评 估各个方面的轻重缓急， 从而根据他们的意见得出一个合适的 （而不是正确的） 方案。 所以， 在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把 会议带入无休止的争论（你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教 育惹的祸…） 。会后，你自己写文档，做决定。会议上大家的面子都被照顾了，自己实施起 来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白， 因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。组织中的高层，并不 见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对 事情的优先级的判断肯定比下属强。 终可交付成果一定要是可以被检查的，比如， 【界面要求：美观大方、简洁明快】 ，这个 要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如 我见过一个计划，里面有一个任务【开发人员熟悉 EJB 编程】 ，这个任务，除了让这些人去 参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客 户交付是项目经理一直要注意的事情， 我听说有些老项目经理拿到项目是倒排计划的， 即首 先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收， 那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构， 我们的目的就是在付出那么多劳动后得到结果。 另外我插一句： 我是极其不主张到客户现场开发的。 尤其是一大群技术人员直接和客户 交流，很容易引起冲突和矛盾（技术人员的本性决定的） 。我的做法是项目经理和项目实施 人员到现场，软件开发人员还是在公司做项目。项目实施人员就是初级项目经理，他们了解 自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。他 们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比 开发人员的路要宽得多。 11. 接着，我们再谈谈最让人头痛的需求变更问题。变更通常分为两种：一种是部分更 改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大 到流程的实现，小到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先 沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候， 如果需要改并且你的战略是容许这种情况的，那么注意下面几点： ? 确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后 说话没有凭据； ? 和客户坐下来，探讨他修改的根本目的是什么，是不是有同样能达到相同目的、但是对你来说有代价更小的选择？ ? （项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有权力来插一杠子，你就废了） ，以正式项目文件的方式提交给你，然后，你做评估 分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更 改设计的原因和指出由此带来的不确定后果 （这个东西先写出来， 后面如果真的发生了， 至少不是你的错） 。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的 免责条款吗？对，就学习那个，让大家都意识到任何的更改都有成本和代价。 12. 系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我一般会注意 以下几个问题： 一、给客户做培训前，多注意一些表面功夫。很多程序员认为，系统的逻辑核心是否正 确是关键，至于界面如何，界面上的用词是否准确，那是无关紧要的问题，而且培训的时候 也是信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以 想象。我的体会是，给客户做培训的版本，如果你在做多次测试以后仍然不能确定逻辑是否 合乎要求，那么，你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正 确性等等，总之不要让客户看到一些他不该看到的东西。文档方面，准备至少两个文档：用 户手册和培训手册。这两个文档的内容很多都是一致的，但是角度完全不同。用户手册往往 是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；而培训手册， 一定要站在客户业务人员的角度， 根据每个角色面对不同业务的办理， 如何通过使用本系统 的一系列功能来实现目标。所以，第一次培训以前，系统界面是否完整正确、培训文档是否 完备都是很关键的因素，第一炮打不响，以后就麻烦很多 作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手 上的资源以及各个事情的优先级。 所谓多快好省那是人类的梦想， 这四个方面都是相互矛盾 的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把 快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业 的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法， 谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求 源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。 验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是 很重要的事情，这些在前面已经有所提及，这里就不再多说。 我对验收最大的体会就是举证问题。 即千万不要让客户这么想： 你必须有证据证明你的 系统是没问题的。这样你就没戏了，微软那么多天才，做了 XP 还天天打补丁，要你的程序 没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文 档的测试用例跑一遍， 结果和预期结果一致就应该算通过了， 而且还容许有一些小错误留在 验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如 果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。另外，认为系统完美了才能验收的想法也是错误的，软件 开发合同里一定要注明验收以后维护期的费用问题， 否则， 客户担心一旦验收就得不到你们 的支持，自然不配合验收，那么，你这个项目经理就很难交功课了。 最后，我想谈谈如何评价项目经理的绩效的问题，我认为，项目经理有以下几个 档次： *最差的项目经理：项目过程中总是出现意外，然后自己又解决不了，结果成为烈士； *二流的项目经理：项目也经常出现意外，但是他一马当先，奋勇向前，解决了一个又 一个问题，最后，勉强算把项目结束了，获得了领导的一致好评； *一流的项目经理：平时很少见他做具体的事情，整天找人聊天，然后就是写报告、做 计划，最后项目顺利结束，整个过程平淡无奇； 项目管理培训 项目管理到底是一门科学还是一门艺术呢？所谓科学就是经过反复论证， 输入和输出有 必然规律的东西， 种瓜得瓜； 而艺术就是思想火花的闪耀， 主要靠灵感。 项目管理这个东西， 据一个前辈说，在国外是科学，80%是有规律可循的；在国内是艺术，主要靠个人魅力、感 染能力等东西。看明白了 PMBOK，学会了一些做事情的方式，只是搞懂了那个20%的科学 的东西，还有80%的空间，属于见仁见智的领域了。所以，加强很多方面的个人能力，如练 就出色沟通能力、 提升自己的个人魅力对于项目经理来说是多么重要啊， 无论是对内还是对 外。 作为一个一流的专业人士， 在顺利让客户签字的同时， 如何让自己的领导知道你的价值， 这也是体现自己能力的一种途径。
更多搜索：
All rights reserved Powered by
文档资料库内容来自网络，如有侵犯请联系客服。