项目管理过程总结

1 / 29 项目管理过程总结 时间管理 项目管理心得 通过在课堂上的学习，我对项目管理有了一个大概的了解和综合的认识。再在老师的教导下，我对项目管理有了进一步的学习和认识，我真正认识 T项目管理在现实生活中的运用。现将我对项目管理的理解总结如下。 项目管理是项目管理在领域的应用。它结合了行业特点并且运用了项目管理技术、理念和方法，包含着多个知 识领域。 由于项目管理是项目管理在领域的应用，因此它有着在信息技术行业的许多特征：任务的明确性、管理工具的先进性、信息沟通的及时性、资源提供的必要性、测试的完善和严谨性、度量的准确性及项目管理的贯穿性等。项目集成管理是指在项目的整个生命周期内，汇集项目管理的知识领域，对所有项目计划，进行整合执行及控制，以保证项目各要素相互协调的全部工作和活动过程。项目集成管理是从全局的、2 / 29 集成的观点出发通过有机的 协调项目各个要素 (进度、成本、质量和资源等 )，在相互影响的项目各项具体目标与方案中权衡和选择，尽可能地消除项目各单项管理的局限性，从而实现最大限度地满足项目干系人的需求和希望的目的。 项目的范围管理影响到信息系统项目的成功。在实践中，“ 需求蔓延 ” 是信息系统失败最常见的原因之一，信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能，无论是客户的要求还是项目实现人员对新技术的试验，都可能 导致信息系统项目范围的失控，从而使得信息系统项目无论在时间、资源和质量上都受到严重影响。项目管理的首要任务是制定一个构思良好的项目计划，以确定项目的范围、进度和费用。在给定的时间完成项目是项目的重要约束性目标，能否按进度交付是衡量项目是否成功的重要标志。因此，进度控制是项目控制的首要内容，是项目的灵魂。同时，由于项目管理是一个带有创造性的过程，项目不确定性很大，项目的进度控制是项目管理中的最大难点。 项目的成本是项目的全过程所耗用的各种费用的总和。项目的成本管理对于组织来说非常重要，成本管理并不只是把项目的成本进行监控和记录，而是需要对成本数据进行分析，以发现项目的成本隐患和问题，在项目遭受可能的损失之前3 / 29 采取必要的行动。 项目成本管理希望节约项目的费用，但并不意味着要一味减少成本。例如：在信息系统项目中，减少测试无疑能够减少项目的费用，但没有测试，如同许多曾经进行过的信息系统一样，把用 户当做测试者，可能对项目造成灾难性的后果，最终，或者使得项目的成本大为提高，或者让项目走向失败的边缘。质量是 “ 使实体具备满足明确或隐含需求能力的各项特征之总和 ” ，明确或隐含的需求是指按项目需求制定的基础性文件。质量管理作为项目管理的一部分，具有非常重要的地位。质量管理的目的是通过执行项目质量管理过程，使用一些基本项目管理工具和技术来保证信息系统的质量。时间、成本、质量是项目管理的三大目标，如果质量不能满足要求，即使进度再快，成本再节省，项目也没有意义。 人是决定组织和项目成败的关键。尤其是在信息系统领域，合格人选很难找到和保留在某个项目中。有效的管理人力资源，是项目经理们认为最困难的一件事情。项目人力资源管理包括为最有效地使用参与项目人员所需的各项过程。它 包括项目的所有利害关系者，如赞助人、顾客、合伙人、供应商 /分包商、项目团队成员等。而讨论对赞助人、合伙人、顾客的管理已经超出本章的范围， 本章将重点关注项目团队4 / 29 的人力资源管理。 项目人力资源管理主要包括编制人力资源计划，组建项目团队和项目团队建设三个主要的过程。人力资源计划编制的主要内容包括确定、记录并分派项目角色、职责，请示汇报关系，这个过程的输出主要包括角色和职责分配矩阵、报告关系，以及项目的组织结构；项目团队组建的内容主要是招募、分派到项目工作的所需人力资源，得到项目所需的人员是信息系统项目成败的关键；而项目团队建设的内容主 要包括培养项目团队个人与集体的能力，以提高项目的绩效。对于许多信息系统项目而言，是否能够培养团队和集体的能力，也是项目成功要考虑的因素之一。 沟通是指人际之间传递和沟通信息的过程，对于项目取得成功是必不可少的，而且也是非常重要的。沟通的主旨在于互动双方建立彼此相互了解的关系，相互回应，并期待能经由沟通的行为与过程相互接纳及达成共识。在信息系统项目中，项目干系人之间的沟通贯穿项自整个生命周期，很多 专家认为信息系统项目失败的重要原因就是沟通的失败。 项目需要以有限的成本在有限的时间内达到项目目标，而风险会影响这一点。风险管理的目的就是最小化风险对项目目5 / 29 标的负面影响，抓住风险带来的机会，增加项目干系人的收益。作为项目管理人员，必须评估项目中的风险，制定风险应对策略，有针对性地分配资源、制定计划，保证项目顺利的进行。项目采购是从项目外部购买项目所需的产品和服务的过程。采购过程涉及具有不同目标的 双方或多方，各方在一定市场条件下相互影响和制约。通过流程化和标准化的采购管理和运作，可以达到降低成本、增加利润的作用。项目采购管理过程包括采购计划、合同编制、招标、供方选择、合同管理和合同收尾等。 在此，我想将学习此门课程的心得总结为一下几点：一、项目管理就在我们的身边刚刚开始的时候，觉得项目管理就是一个项目的项目管理者对项目所要涉及到的全部工作、资源等进行有效地管理。然而在学习的过程中渐渐的发 现我对项目管理只是表面的认识，正确理解应该是以 IT 项目为对象的系统管理方法，是通过一个临时性的、专门的柔性组织，对项目进行高效率的计划、组织、指导和控制，以实现项目全过程的动态管理和项目目标的综合协调与优化。二、团队是项目管理成功与否的大环境好的项目团队，应该有一个共同认可的明确的目标、合理的分工协作、良好的信息沟通、队员之间相互信任并且能积极的参与到自己的队伍中。在我们平时的工作中，我们所在的公司是一个大的项目团队，每6 / 29 个部门和每个作业小组就是一个小项目团队。三、项目经理是项目管理的灵魂项目经理是项目管理的 角色，是实现项目目标的责任人，同时是一个团队的灵魂人物。项目经理不一定是这个团队中能力最强的人，却是责任最重大的那个。他应该是有较强的意志力、凝聚力，有抗压能力的人，不会轻易被外界和他人影响。四、沟通是项目管理的桥梁沟通是项目成功必不可少的桥梁。要做好项目每个阶段的工作，达到预期的效果，就必须在项目组内部以及项目组与外部环境之间建立沟通渠道，快速准确的传递信息从而达到各成员的协调一致；使项目成员明确各自的职责，了解他们的工作对实现项目目标所做的贡献。这就是我在 IT 项目管理当中的学习心得，希望在接下来的生活、 工作和学习中能更好的领悟和运用学习所得。 项目管理是在大的规模上对问题的处理。我们生活中也在不断的遇到各种各 样的问题，在进行项目管理的过程中，随着工作的进展，也给我们生活中解 决问题指明了一条正确的思路和方法。项目问题就是人的问题，在做事的时候不要怨天尤人，惟有付之行动，生活才会回报付出者；没有计划，就没有控制；要积极主动，不要被动反应；承担责任，争取权力；所有的行为7 / 29 只有从执行者的视角来理解才有意义；人最害怕的是被拒绝，最需要的是被接受；沟通技能是项目经理最应具备的技能之一。 在一个项目的进行过程中，我们不可避免的要和用户之间沟通和交流，当然，在交流过程中，会遇到一些 问题。不管用户是非对错，用户提出问题，我的思想老是照着用户的问题去解决问题。在这本书中针对这种情况有详细的解析。我往往把用户的问题定义成了问题。想尽方法帮用户解决。读完此书，以后在用户提出问题后，需先想想问题到底出在哪里？找出问题的真正定义！在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在解决的问题。每种解决方 法都会带来新的问题，的确存在很多问题解决之后，产生了更大的问题。针对这种现象 ,问题最难以处理的部分恰恰是去意识到它们的存在 ,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。 美国著名项目管理专家刘易斯提出 16 步管理模型。从 16 步8 / 29 管理模型中可以看到项目的战略计划所处的位置：概念确立。就是对所要做的事情有一个框架性的设计，有一种思想；问题的定义。即对长远目标说明。第二步骤是对第一步的进一步细化和 具体化；生成项目的备选方案和战略计划。就是提供思路、备选方案和战略计划总体思路；战略计划评估和选择。就是在选择方案的同时，有一个从总体技术路线到总体项目管理策略的评价和选择；战略的确立。就是确定具体的战略、目标；制订项目的实施计划。这是一个更加具体的、第二个层次的项目计划，就是怎样实施；项目干系人批准计划。这里的计划包括战略计划、初步计划、详细计划，在这些项目实施之前，有一个批准过程；签署项目计划。项目的批准人、参与项目的有关干系人要签署项目计划，对计划做出承诺，同时建立项目的跟踪记录，做一个项目进展情况日志或者周志、月志、记录，根据这些记录信息进行知识管理；执行项目计划。执行项目就是正式开展计划，进展这个项目；监控项目进展。计划开始实施之后，就要考虑计划执行得如何，有无问题，要对进展情况进行监控、监测和控制；审查项目定义。项目实施之后，需要做一些评审，评审包括对原来工作的评审，同时也包括对项目目标定义的评审，如有问题就返回到步骤二，重新修正项目的定义；对项目的战略进行评审。首先是评价目标或项目的定义，然后评审战略计划、战略制订是不是有问题，如果有问题就返回步骤四，重新修9 / 29 正你的项目战略；项目的实施计划。具体的 计划工作流程、对一些细节要进行评审，有问题就进行修改；循环。按照整个过程不断地从计划的执行到监测、评审，有问题就要修改计划，然后再执行，再评审，这个过程一直延续到全部工作结束；总结经验教训。项目全部完成以后，及时总结经验教训，对一些问题进行归档，作为今后项目的指导和借鉴；结束项目。这是一个完整的项目管理流程，从这个流程可以看到整个项目战略计划实际上是在制订项目的详细计划和实施计划之前。在项目计划的时候，首先要有一个总体的战略计划，在总体的战略计划指导下再开展具体的项目计划。 在我们开始一个项目时，首先应该搞清楚项目的使命，前景，目标和目的。 确定是否要进行此项目。当我们决定要开始一个项目后，就应该制定相应的战略计划，战略要回答 “ 我们怎样对这项工作展开活动 ” 这样的广泛问题，而制定实 施计划则要求一丝不苟，换句话说，制定实施计划有关怎样做这项工作的详细事宜。制定计划涉及回答的问题包括：做什么、谁来做、何时、何地、多长时间和怎么做。 项目进度计划编制既是一门科学，又是一门艺术。关于进度10 / 29 计划，真正的重点是为在最短的时间完成项目，找出并行尽可能多的活动的方法。项目管理科学的一面涉及到资源的平衡，它通过计算机运算完成，并存在许多算法。但是，同首次进行项目人力资源分配应用的技术相比，其 结果差不多。资源计划也是重要的一环。完成一项活动的时间取决于分配给它的资源，并且如果没有相应数量的资源，工作就不能按计划完成。如果项目经理不能解决资源分配的问题，项目进度计划就不会成功。 此外，要对项目控制和评审。要达到项目目标，有必要采取适合的项目控制和评审。项目检查有三种类型：即状况、设计和工作过程检查。状况检查主要检查项目是否在进度计划和预算之内、范围是否正确、绩效的要求有没有问题。而设计 检查仅仅适用于包括设计工作的项目，检查中经常要问的问题是达到规范了吗？用户界面友好吗？我们有能力制造吗？市场需要我们开发的产品吗？投资回报及其他的产品开发理由荏苒适合吗？之所以进行项目需要检查时因为：随着项目管理水平的提高，同时提高项目绩效；确保项目工作质量不居于进度和成本问题之后；尽早找出开发问题，以便提前采取措施；识别应采取不同管理方式的其他项目领域；确保业主获知项目状况。 11 / 29 在项目即将结束之 时应该总结经验教训，若失败，则分析失败原因，可以从以下几个层次进行分析：项目管理环境中的失败。这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的 “ 配合 ” 。它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型，以及缺乏高层管理部门对项目的支持等。项目不具备正确的组织结构、项目经理或者团队来 “ 配合 ” 项目。项目管理系统中的失败。这些失败的根源可以追溯到项目领导及错误实践。它们包括项目经理在项目生命周期中对系统方法的忽略，以及项目管理技巧的错误应用等。具体的可 以归结为：不胜任的项目经理；忽略了项目的系统本质；管理技巧不恰当或者错误的运用。在计划和控制过程中的失败：项目中没有良好的沟通；没有用户的参与；不充分的项目计划；不充分的项目定义；糟糕的时间和资源估计；不正确的工期安排和资源处理；在执行阶段为数众多的变更；不恰当的控制；项目终止的计划很拙劣。同样项目成功也应该总结经验。要取得项目成功，项目的目标定义、项目的系统、整体系统控制、整体计划，包括战略计划、实施计划、日程计划要通过详细、认真地预算、估算，保证项目能够得到充分的资源。在项目的实施过程当中，要通过经常性的审查、控制和评审来保证项目能够按计划不断地推进。除此之外，组织目标的实现还需要在组织上保证。包括项目经12 / 29 理的领导艺术、项目经理的管理才能、管理技能以及相关的技能、组织结构和团队建设方面。所有的这些，都是保证项目走向成功必不可少的环节。 感觉在这门课程的学习过程当中，老师给我们很大帮助，给我们讲诉了一个全新的概念，也给我们留了足够的自由学习空间，更能发挥我们学生的学习主动性和积极性。 /leslies2/archive/2016/06/29/ 一、 风险评估 软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题，以及由这些问题而对项目所产生的影响。项目的风险与其可行性成反比，其可行性越高，风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需求风险、相关性风险、管理风险、安全风险等六个方面： 1. 产品规模风险 13 / 29 项目的风险是与产品的规模成正比的，一般产品规模越大，问题就越突出。尤其是估算产品规模的方法，复用软件的多少，需求变更的多少等因素与产品风险息息相关： (1) 估算产品规模的 方法 (2) 产品规模估算的信任度 (3) 产品规模与以前产品规模平均值的偏差 (4) 产品的用户数 (5) 复用软件的多少 (6) 产品需求变更的多少 2. 需求风险 很多项目在确定需求时都面临着一些不确定性。当在项目早期容 忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或14 / 29 者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的，这些的风险因素有 : (1) 对产品缺少清晰的认识 (2) 对产品需求缺少认 同 (3) 在做需求分析过程中客户参与不够 (4) 没有优先需求 (5) 由于不确定的需求导致新的市场 (6) 不断变化需求 (7) 缺少有效的需求变化管理过程 (8) 对需求的变化缺少相关分析等 3. 相关性风险 许多风险都是因为项目的外部环境或因素的相关性产生的。15 / 29 控制外部的相关性风险， 能缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并觉察潜在的问题 ,与外部环境相关的因素有： (1) 客户供应条目或信息 (2) 交互成员或交互团体依赖性 (3) 内部或外部转包商的关系 (4) 经验丰富人员的可得性 (5) 项目的复用性 4. 技术风险 软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。 在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、聘请顾问以及为项目团队招聘合适的人才等。关于技术主要有下面这些风险因素： 16 / 29 1 (1) 缺乏培训 (2) 对方法、工具和技术理解的不够 (3) 应用领域的经验不足 (4) 对新的技术和开发方法应用不熟悉 5. 管理风险 尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的不足 不能检查到自己的错误。因而，使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素： (1) 计划和任务定义不够充分 17 / 29 (2) 对实际项目状态不了解 (3) 项目所有者和决策者分不清 (4) 不切实际的承诺 (5) 不能与员工之间的进行充分地沟通 6. 安全风险 软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。但一直以来，我们在软件这方 面的 安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。软件行业的技术人员流动是很普遍的现象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范，这也是我们 软件项目潜在的风险。 7. 回避风险的方式 18 / 29 (1) 以开发方诱导能保证需求的完整，使需求与客户的真实期望高度一致。再以书面方便形成用户需求这一重要的文档，避免疏漏造成的损失在软件系统的后续阶段被逐步地放大。 (2) 设立监督制度，项目开发中任何较大的决定都必须有客户参与进行的，在该项目中项目监督由项目开发中的质量监督组来实施。 (3) 需求变更需要经过统一的负责人提出 ,并且要用户需求的审核领导认可 ,需求变更应该是定期而不是随时的提出 ,而且开发方应该做好详细的记录 ,让客户了解需求变更的实际情况。 (4) 控制系统的复杂程度，过于简单的系统结构，对用户来使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会 上升，这又会在实现和测试阶段带来风险。适当控制系统的复杂程度有利于降低开发的风险。 (5) 从软件工程的角度看，软件维护费用约占总费用的55%70%，系统越大，该费用越高。对系统可维护性的轻视19 / 29 是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。 (6) 设定应急计划，每个开发计划都至少应该设定一个应急预案去应对出现突发情况和不可遇知的风险。 二、 成本预算 1. 成本预算方式 (1) 自上而下的预算方法 自上而下的预方法主要是依据上层、中层项目管理人员的管理经验进行判断，对构成项目整体成本的子项目成本进行估计，并把这些判断估计的结果传递给低一层的管理人员，在此基础上由这一层的管理人员对组成项目的子任务和子项目的成本进行估计，然后继续向下一层传递他们的成本估计，直到传递到最低一层。 2 使用此预算方式，在上层的管理人员根据他们的经验进行的20 / 29 费用估计分解到下层时，可能会出现下层人员认为上层的估计不足以完成相应任务的情况。这时，下层人员不一定会表达出自己的真实观点，不一定会和上层管理人员进行理智地讨论，从而得出更为合理的预算分配方案。在实际中，他们往往只能沉默地等待上层管理者自行发 现问题并予以纠正，这样往往会给项目带来诸多问题。 自上而下更适用于项目启动的前期，与真实费用相差在 30% 70%之间。 Scrum 使用自上而下的成本预算方式，它不会立即精确地确定成本，而是以最大限度容纳 客户对未来产品要求所 产生的变更。 (2) 自下而上的预算方法 自下而上方法要求运用 WBS对项目的所有工作任务的时间和预算进行仔细考察。最初，预算是针对资源进行的，项目经理在此之上再加上适当的间接费用以及项目要达到的利润目标就形成了项目的总预算。自下而上的预算方法要求全面考虑所有涉及 到的工作任务，更适用于项目的初期与中期，21 / 29 它能准备地评估项目的成本，与真实费用相差在 5% 10%之间。 注解： WBS WBS 是面向提交成果对项目的分解，从提交成果的列表可以确定每个 提交成果需要执行的活动。 Scrum 会对 WBS 进一步细化，把每个迭代分解为更细小的工作包。 2. 确定项目支出 总体成本预算就是结合下列多个成本预算方式，组成开发的总体成本： (1) 零基数预算 在成本预算的初期应该使用零基数的计算原则，而不可以使用类似于：以上一年总体费用加上 20% 这样粗略的方式计算项目成本。 (2) 软硬件成本、物品成本 22 / 29 物品成本是指类似于：服务器成本、维护成本、机房租金、光纤通讯成本、软件成本等的成本。 计算成本时需要考虑组装硬盘需时的长短，技术人员需要具备的质素，产品供应商能否提供保证质量，管理时是否需要额外的管理人员这些多方因素。 (3) 软件许可证成本 (4) 外包成本 当使用类似：视频、短信、移动电信类服务、门户网站等子项目时可以考虑以外包形式完成，以降低开发成本。 (5) 人力资源成本 计算人力资源成本时应该使用以最高和最低的工作效率估算平均效率的方式，计算出人力资源的平均成本。 (6) 维修保养成本 三、 客户沟通的 过程 23 / 29 从客户沟通的方向出发来看，软件项目可分为：需求识别、方案定制、项目实施、项目结束等 4 个不同的阶段，各个阶段都具有不同的沟通重点。 3 1. 需求识别阶段 (1) 文本沟通 在需求识别的前期，应该通过问卷、原型展示、界面展示、逻辑处理展示、准化文档模板等方式进行全方位多角度的分析，随时将不明确之处反馈给客户 ,以期待客户解答。并以文本记录的方式建立需要分析书，并要求客户审核需求分析书，以达到需要分析与客户的真实期望高度一致的结果。 (2) 业务逻辑沟通 在进行业务沟通时，应该了解客户的行业语言，以促进业务分析的过程，越过应用需求和开发之间的鸿沟。沟通过程提倡以草图或者可视信息化的方式进行 ,针对不同层面的企业24 / 29 用户提供最适合的操作界面。以多角度的方式思考问题，要抓住需求重点 ,尤其是客户方领导所关注的创新类和实用类需求。 (3) 需求变更的规范化管理 需求变更在软件开发类项目中是可以理解的 ,但必须对需求变更做好规范化的管理，以避免出现需求无止境变更的风险。需求变更必须由统一的负责人提出 ,并且由用户需求的审核领导者认可。需求变更的提出应该是定期而不是随时的，开发方应该做好详细的文本记录 ,让客户了解需求变更的实际情况和开发方为之所付出的成本代价。 2. 方案定制阶段 该阶段项目的主要任务是与客户共同制定一个以前期明确的需求、双方的资源、项目开始的阶段、实施的时间约定、项目费用限制等为基础的具有可操作性的项目计划 ,从本阶段开始争取客户全面参与项目的管理，并以双方的共同利益考虑项目实施的具体计划与风险规避。 3. 项目实施阶段 25 / 29 在该阶段 ,软件项目团队应该与客户共同领导项目的实施。同时 ,项目团队应实时评估客户满意度 ,并通过持续改进的方式提高客户满意度 ,还应要求客户参加必要的培训 ,以及在必要时检查项目产品。在出现客户的需求变更前 ,应主动与客户沟通交流 ,使客户充分了解项目的每个环节 ,以及变更带来的影响 ,减少需求变更。如果出现客户需求变更 ,应与客户一起共同解决由变更引起的成本、进 度、质量变化。 4. 结束阶段 该阶段主要进行项目成果的移交，并把系统交付给维护人员，帮助客户实现商务目标，结清各种款项。完成这些工作后应该进行项目评估，审核此项目的成果并总结项目经验。 5. 售前人员注意事项 在产品型项目作为开发成果时，相关销售人员应该注意：对产品的推销不应该过分承诺。如果过分承诺 ,会给后续的项目实施带来困难 ;一旦承诺没有兑现 ,也会降低客户满意度 ,影响今后合作。如果有附加承诺 ,一定要以文本形式记录，让实施项目经理知晓并传