项目管理与沟通.ppt

1、1,项目管理与沟通,2009年4月14日,2,前言- 个人感觉,沟通是一场博弈，一种让别人跟着你走的博弈，也是博弈的目的。 要知己知彼，虚实结合。 沟通能力如何，不是培训出来的，是通过沟通练出来的 跟个人的性格、知识面、专业知识、课余知识息息相关，不是单方面强就能解决的 没有人员愿意直接拒绝，也没有人愿意感受到被拒绝 拒绝实际上理解为“说服”更为贴切，明白的拒绝实际上会坏事，也说明自己能力不够。 要引导而非拒绝，换位思考很重要。 道高一尺，魔高一丈，不要轻易承诺，否则会死的很惨。 公司讲诚信很好，但要善用，不要自己挖坑自己跳进去。 最后一招，才是拒绝,3,提纲,人们并不清楚应该做什么，却一直忙

2、碌不停地做着.,项目及项目管理 项目沟通管理,4,项目管理概念,什么是项目？,什么是项目管理？,5,项目的概念 PMI对项目的定义 A project is a temporary endeavor undertaken to create a unique product or service 项目是为完成某一独特的产品或服务所做的一次 性努力。 注：“PMI”：美国项目管理学会标准委员会,6,项目的属性或特点 1、项目的一次性 。 2、项目的惟一性。 3、项目的多目标属性。（成果性目标和约束性目标） 4、生命周期属性。（启动、开发、实施、结过程）,5、相互依赖性。 6、冲突属性。,范围,功

3、能要求,目标,完成期限,时间,有限预算,费用,项目的多目标属性示意图,7,从70年代开始，项目管理作为管理科学的重要分支，对项目的实施提供了一种有力的组织形式，改善了对各种人力和资源利用的计划、组织、执行和控制的方法，从而引起了广泛的重视，并对管理实践做出了重要的贡献。,项目管理,8,项目管理的概念 通过项目经理和项目组织的努力，运用系统理论和方法对项目及其资源进行计划、组织、协调、控制，旨在实现项目的特定目标的管理方法。,9,项目管理与日常组织管理的差异,L 日常管理主要关心其稳定性和连续性，日复一日、月复一月、年复一年，力求建立起达到预期目标的体制，为了提高起效率和效果，还要不断探索、优化

4、、完善该体制，是长期性的事业，可能超越你个人参与的极限。 项目管理则目标有限度的，是在预计好的预算内、预定好的时间内的目标；项目经理的一系列决定很大程度上决定了项目的成败。,日常管理中，组织内部上下级之间相互沟通或指令传递渠道是早已确定的。 项目管理则已项目经理为中心，组成的团队成员可能是第一次合作，需要用更多的技巧去凝聚他们的能力和才智，争取达到项目的每个目标。,二者的区别：项目管理是一种管理方法，日常管理是一个过程。,10,项目管理的相关概念,项目干系人：指参与项目和受项目影响的人，包括项目发 起人、项目组、协助人员、顾客、使用者、 供应商、项目反对人。 项目管理知识领域：项目经理必须具备

5、的一些重要的知识 和能力。从项目管理的职能领域看，主 要包括范围管理、时间管理、成本管理 质量管理、人力资源管理、风险管理、 沟通管理、采购管理、综合管理9部份,11,项目管理知识领域框架图,9大知识领域核心功能,范围管理,时间管理,成本管理,质量管理,项目综合管理,人力资源 管理,沟通管理,风险管理,采购管理,辅助功能,项 目 干 系 人 的 需 要 和 期 望,工具,技术,项目 成功,12,你会如何反应 ?,13,14,项目经理,项目经理要求有高超的筹划能力，优秀的领导素质，对团队成员最关切的问题的深刻理解，对工作环境的文化氛围的敏锐觉察，以及对计划中的风险预见能力和不断增强的个人奉献精神

6、。 项目经理基本上扮演着4种不同的角色： 策划者、管理者、领导者、沟通者 很多项目失败原因是：重管轻理，轻领导、拍板 还有一些是只管不理，单个环节都成功了， 但整体结果是失败的。为什么？脱节。,15,优秀的项目经理应关注什么,项目要做什么？,完成项目需要多长时间？,完成项目要花多少钱？,范围,时间,成本,16,项目的范围管理,指对项目包括什么与不包括什么的定义与控制过程。 这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。 我的理解：“做什么，不做什么，包括什么，不包括什么”，要说清楚。,17,范围管理的过程,启动,范围计划,范围定义,范围

7、核实,范围变更控制,制定战略计划，“SWOT”分析法,选择项目，净现值法、加权评分法,产生范围说明书，或立项报告,明确工作任务，并将工作任务分解，“WBS”分析法,项目干系人对范围的正式承认，形成书面确认的文件，如合同、阶段性验收报告等,18,项目的质量管理,质量管理概念,质量计划,质量保证,质量控制,质量管理工具,19,质量管理的核心是什么？,满足客户需要,20,质量管理概念,质量（符合性概念）： 符合标准就是合格的质量，符合程度反映了产品的一致性。,质量（适用性质量概念）： 产品在使用时能够成功地满足用户需求的程度。,21,项目质量管理的目的：,确保项目满足它所应满足的需求。,22,质量管

8、理概念,在项目中你遇到的引起项目质量问题的原因有哪些？,质量问题？ 多数由于缺乏高层管理者的关注,23,质量计划,质量政策 通常情况下，质量政策与组织整体政策相一致 由企业的最高层颁布的质量工作的总方向 最高层对质量方针贯彻负最终责任 项目团队应负责让项目的参与各方都充分理解该政策,24,质量保证,全面质量管理,追求客户满意,注重预防,全员参与,加强检查,持续改进,强调管理层责任,25,质量保证,质量系统的文档结构,手册 程序 指导书 图纸、规格、清单、检验报告 测试报告等,质量政策、 质量目标,做什么？,怎么做？,文档记录,26,质量控制,质量控制是什么？,对工作的过程进行检验、评价或测试以

9、保证质量。,项目进行质量控制的典型活动包括：,合同评审、立项评审、文档记录检查、评审会议、同行评审、测试等活动。,27,软件质量管理工具,数据检查表 帕雷托分析图 因果分析图 直方图 散布图 统计过程控制图 时序图（ Run Chart）,28,软件质量管理工具,帕累托图示例,50,40,30,20,10,0,60,70,80,90,100,登录问题,系统上锁,系统太慢,系统难于使用,报告不准确,这个星期的抱怨数,累积%,29,项目风险管理,指为了最好地达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。,30,风险管理的过程 风险识别 风险量化 风险应对计划制定 风险应对控制,提

10、问：你觉得在开发一个新的IT项目时应重点考虑哪几方面的风险？,31,项目整体管理,项目整体管理包括在项目生命周期中协调所有其他项目管理知识领域所涉及的过程。,32,项目整管理框架图,范围,时间,成本,质量,人力资源,沟通,风险,采购,概念,开发,实施,收尾,项目知识体系,项目生命周期各阶段,项目整体管理,项目成功,33,提纲,人们并不清楚应该做什么，却一直忙碌不停地做着.,项目及项目管理 项目沟通管理,34,项目经理可以运用7种习惯来提高项目工作的有效性。,1、保持积极状态 2、一开始就牢记结果 3、把最重要的事放在最重要的位置上 4、考虑双赢 5、首先去理解别人然后再被别人理解 6、协同 7

11、、“磨快锯子”,如何沟通基本原则,35,项目管理-沟通管理,把信息传达给需要它的人,沟通渠道 沟通技巧,36,链式沟通渠道：信息在高低层次见逐层传递,沟通渠道,37,轮式沟通渠道：主管人员分别同下属部门发生联系， 成为个别信息的汇集点和传递中心。,沟通渠道,38,环式沟通渠道：信息在组织不同成员之间依次传递。,沟通渠道,39,Y式沟通渠道：属于纵向沟通，有一个成员居于沟通活动 中心，成为中间媒介与中间环节。,沟通渠道,40,全通道式沟通渠道：属开放式沟通系统，每个成员之间 都有一定的联系。,沟通渠道,41,各种沟通渠道的比较：,沟通渠道,42,沟通技巧-决策方式,专制式：不参考任何意见独立决策

12、 咨询式：参考大量意见但独立决策 共识式：允许/鼓励团队决策 信任式：授权团队独立决策,43,主动倾听 身体语言 愿意倾听 鼓励 排除干扰 重述 控制情绪 从不打断,沟通渠道听与说,44,软件产品实施的主要工作,摸底 进场会议 制定方案 安装产品 收集需求 培训支持 解决问题 验收 收款退场 后续服务.,45,关于需求,什么是需求 了解客户、最终用户、间接用户 需求工程基本概念 需求开发的主要困难与对策 如何开展需求调查 如何进行需求分析 如何拒绝需求,46,1. 什么是需求,1.1 需求的基本概念 宽泛地讲，需求来源于用户的一些“需要”（欲望），这些“需要”被分析、确认后形成完整的文档，该文

13、档详细地说明了产品“必须或应当”做什么。 所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。 1.2 需求的重要性 Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性： 开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。 需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。 国内软件业的痼疾：人们并不

14、清楚究竟该做什么，但却一直忙碌不停地开发。,用户需要（欲望）,产品需求,开发实现,满足用户的需要（欲望）,47,2. 了解客户、最终用户、间接用户,2.1 基本概念 “用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。 掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个（类）人也可能不是同一个（类）人。 2.2 客户是掏钱买软件的人，所以他是“上帝” 某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位： 如果顾客先点鸡，那么就先有鸡；如果顾客先点

15、蛋，那么就先有蛋。 “现代营销学之父”菲利普科特勒所著的市场营销导论是这样描述客户的： 客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。 与客户打交道的主要目的是：一是获取需求，二是签合同。不要把钱仍到水里。 李鸿章和慈溪太后的故事（客户之事无小事） 电信供应商和运营商的关系,48,2. 了解客户、最终用户、间

16、接用户,2.3 即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。 如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。 公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。由于休息室空间有限，请大家自觉让位。午休时他们可以躺着睡，我们只能坐在位置上打个盹儿.。” 2.4 重视“间接用户”，千万别“大意失荆州” 间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。 例如，财务软件开发商在把“财务软件”卖给

17、客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。 同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。 某些客户企业存在“信息中心”这类间接用户。,49,3. 需求工程基本概念,3.1需求工程的一些感悟 不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。 开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产

18、品。 “被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。 “主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。 “领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个

19、份上，才能使产品立于不败之地，长盛不衰。,50,4. 需求开发的主要困难与对策,4.1 知识技能问题 应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。 当需求分析员缺乏应用域知识时，他该怎么办？ 首先他要有勇气做事，否则连实践的机会都没有。 其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。 4.2 态度问题

20、 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为： 需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。 用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。 软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用

21、户需求，如果做不到就是失职，不要找借口。,51,4. 需求开发的主要困难与对策,4.3 合作关系 如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。 倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法： 我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧 。 对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。 需求分析员不是实施人员，他们不可能象实施人员那样通过某些手段笼络住用户就能成功。出色的

22、需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。 开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。 开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。,52,4. 需求开发的主要困难与对策,用户在需求工程中的“权利”

23、1. 有权要求开发方派遣资质合格的需求分析员和相关人员。 2. 有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂得需求文档。 3. 有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。 4. 如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。 用户在需求工程中的“义务” 1. 以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。 2. 乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析员的问题。 3. 在不泄漏

24、机密的前提下，尽可能地向需求分析员提供与需求相关的材料。 4. 与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿。,53,4. 需求开发的主要困难与对策,4.4 用户说不清楚需求 用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。 有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。 例如开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。 例如前些年全国各地的很多政府机构大搞网络建设。这些机构的领导和办公人员大多数不清楚网络干什么用，就让开发人员替他们设想需求吧，反正是花公家的钱。 有些用户虽然心里明白想要什么，但

25、却说不清楚需求。 比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。（软件原型法，从“抛弃型”发展为“复用型”） 需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。 无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。,54,4. 需求开发的主要困难与对策,4.5 双方误解需求 人们在交流的时候，经常会发生“问非所求，答非所问”的事情。 有时用户会把开发人员的建议或答复给想歪了： 有一个软件开发人员滔滔不绝地向用户讲解在“信息高速

26、公路上做广告”的种种好处，用户听得津津有味。最后，心动的用户对软件开发人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。” 而用户表达的需求，不同的开发人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。就像作文写跑题了，写得再好也白搭。这类错误连高智商的外星人都不能避免： 有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。有趣的是，车里住着一种叫作人的寄生虫，这些寄生虫完全控制了车。” 不论是复杂的项目还是简单的项目

27、，需求分析员和用户都有可能误解需求。所以需求确认工作（属于需求管理）必不可少。,55,4. 需求开发的主要困难与对策,56,4. 需求开发的主要困难与对策,4 6. 开发人员写不好需求文档 需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。 古时候，一书生在考试前补习“写文章”，成天愁眉苦脸 所以要想写出好的需求文档，前提条件是把需求调查工作做好。 开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。 可以毫不夸张地说，国内90以上的软件开发人员，他们的写作能力远不及开发能力。 提高开发人员写作能力的根本办法就是让他们多练习写文档，熟能生

28、巧。 另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。,57,4. 需求开发的主要困难与对策,4.7 用户经常变更需求 需求变更通常会对项目的进度、人力资源、经费产生很大的影响，这是开发商非常畏惧的问题。 如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。 如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘

29、若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。 其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。,58,5 如何控制用户需求变更,客户的目标：简单说就是尽量少花钱多办事。 开发方的目标：就是能不改就不改（降低成本啊），即使非得要改，也要说的让客户觉得欠了你很大一个人情似的（为下一次他们再提出需求变更做好准备）。中间具体怎么沟通达到双赢，就看个人的本事了。 客户目标与公司目标永远是矛盾；实施与实施和售前也永远是矛盾，这个矛盾永远解决不掉，只能寻求双赢，彼此均作出一定

30、的妥协。 与客户沟通不是技术，是一门艺术，不能光讲诚信，没用，但关键是我们要诚恳。 提高沟通效率是必需的，但是做事情也要“有章法”“讲套路”，在这样的前提下能够更有效的沟通，避免扯皮。,59,5 如何控制用户需求变更,涉及需求变更的东西不应该由最终使用的用户和一线开发人员来沟通，这样的沟通费时费力而且不具有权威性。 开发人员直接向客户汇报的工作量往往比实际工作量要低，而且低的比较多。 原因很简单：客户问开发人员一个功能是否困难的时候，一般技术人员往往只考虑了单项功能的复杂度，而可能对这个需求变更对整个系统的工作量估计不足（比如美工的工作量、该功能引发的管理功能的工作量、测试工作量等等）。 这种

31、情况会对项目产生多个负面影响： a.向客户提供一个低于实际值的工作量，导致客户期望高，而实际无法按时完成导致客户失望大，降低用户满意度。 b.因为客户从开发人员口中听到的工作量总是比从项目经理口中听到的工作量低，造成客户对项目组内部不一致，沟通不足的感觉。 c.因为客户从开发人员口中听到的工作量总是比从项目经理口中听到的工作量低，引诱客户喜欢直接向开发人员提出需求变更，造成恶性循环，直接导致了项目组没法按时拿到奖金，士气下降。,60,所以对于客户提出的需求变更，一般技术人员最好的处理方式是： 委婉的告诉客户，这个问题需要项目经理来评估。哪怕用户用挑衅、教训的语气和你讲这个功能如何简单，如何如何

32、就可以实现，你都不能告诉他是否可以接受这个变更，更不能说实现需要多长时间。 拒绝了客户之后并不是大功告成，你最好能够早于客户通知自己的项目经理，客户想进行怎样的需求变更，你自己对工作量的评估是怎么样的。这样可以给项目经理一个准备时间，来完善的考虑需求变更的影响。 对于项目经理，尤其是从开发一线转向做项目经理的兄弟，应该主动的从项目全局来考虑一个变更的影响，而不是单纯从技术角度考虑。最好能按照公司的规范和制度以及项目实际情况为自己积累一份check list，以免在考虑需求变更时遗漏一些事项。作为开发方更要强化对于需求变更的控制。 控制需求变更最理想的办法当然是由客户方、开发方的项目经理和需求顾

33、问共同组织CCB(变更控制委员会) ，文档化所有需求变更，双方签字然后归档需求变更。 不过这样比较难以实现。但是最起码的要求是，必须由客户方项目经理（也就是甲方最终用户需要把需求变更汇总报告给甲方项目经理）向开发方项目经理提出需求变更，开发方项目经理评估工作量，并文档化需求变更，在与客户方负责人充分沟通后，使用正式方式将沟通结果（最好是打印出来给甲方签字，最起码是要求回执的电子邮件）通知客户。必要的时候需要业务人员协助，比如要求签署附加合同或者新开一个项目等等。 从做项目的经验来看，蛮不讲理的客户不是没有，但是是极少数，大多数客户，尤其是客户方项目经理都是通情达理的人。所以，只要你言之有理，对

34、方都有可能接纳。,5 如何控制用户需求变更,61,为客户寻求需求变更制造阻力，不能让他随意变更。 如果客户给项目造成很多困扰，而项目项目经理搞不定，可以向业务人员反馈。一般来说，业务与客户的私人关系肯定好过项目经理和客户的私人关系。他们有他们的渠道来和客户沟通。 如果业务不管，可以继续向高层反馈，毕竟项目拖久了，公司也是受害者。 如果客户提的需求你觉得有问题，你最好把你的想法整理清楚之后去和项目经理谈，让他去说服用户，或者向更高层的领导汇报。把利害关系分析清楚，我想没有那个公司想赔钱的。但是，如果你一边觉得有问题，一边又不说话只是埋头苦干，那只有哑巴吃黄莲了。程序员除了技术，沟通也是非常重要的

35、，尤其到了项目后期，沟通的重要性远远高于技术。 一般来说国内的软件项目，客户和开发方根本就不平等。所以在项目启动时期，把需求变更流程作为一个重要文档与客户沟通（客户需求变更整理正式文档提交项目经理意见及工作量评估公司审批(当涉及比较大的工作量的时候)变更回复变更执行） ，先制定这么一个流程，双方认可 ，然后在实际变更发生的时候严格按照这个流程处理。 -绑定客户，拉他们下水，不能让客户总是在岸上。 对于软件产品实施来说：同样要事先说明我们的实施计划、步骤、安排、风险，可能出现的问题，需要甲方做哪些方面的配合。 与客户经常沟通的效果往往胜过合同条款（如果到了非得拿出合同说事的程度，项目基本上就完蛋了）。切记不要逼客户。,5 如何控制用户需求变更,62,6 说服别人的策略,管理好自己的情绪： 实施人员把的消极的情绪带到实施工作中来，那么，实施过程就会变成负面的。实施是一种很艰难的工作，实施就是一种销售，销售的另一个名词就是“拒绝”。拒绝会带了悲伤，挫折，和失意等负面情绪。如果实施人员不能迅速调整