Group items tagged

50. 你们的程序员能看到测试用例么？MVM：要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。 51. 你们是否随便抓一些人来做易用性测试？MVM：要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。 52. 你对自动测试的期望正确么？MVM：别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。 53. 你们的性能测试是等所有功能都开发完才做的么？MVM：不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。 54. 你注意到测试中的杀虫剂效应了么？MVM：虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。 55. 你们项目组中有人能说出产品的当前整体质量情况么？MVM：要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。 56. 你们有单元测试么？MVM：单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。 57. 你们的程序员是写完代码就扔过墙的么 ？MVM：大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。 58. 你们的程序中所有的函数都有输入检查么？MVM：不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。 59. 产品有统一的错误处理机制和报错界面么？MVM： 要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。 60. 你们有统一的代码书写规范么？MVM：要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。 61. 你们的每个人都了解项目的商业意义么？MVM： 要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。 62. 产品各部分的界面和操作习惯一致么？MVM：要这样。要让用户觉得整个程序好像是一个人写出来的那样。 63. 有可以作为宣传亮点的Cool Feature么？MVM：要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。 64. 尽可能缩短产品的启动时间MVM：要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。

65. 不要过于注重内在品质而忽视了第一眼的外在印象MVM：程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。 66. 你们根据详细产品功能说明书做开发么？MVM：要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。 67. 开始开发和测试之前每个人都仔细审阅功能设计么？MVM：要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧” 68. 所有人都始终想着The Whole Image么？MVM：要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。 69. Dev工作的划分是单纯纵向或横向的么？MVM：不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。 70. 你们的程序员写程序设计说明文档么？MVM：要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。 71. 你在招人面试时让他写一段程序么？MVM：要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。 72. 你们有没有技术交流讲座？MVM：要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。 73. 你们的程序员都能专注于一件事情么？MVM： 要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5 个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的 资源了。

74. 你们的程序员会夸大完成某项工作所需要的时间么？MVM：会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。 75. 尽量不要用Virtual HeadsMVM： 最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对 Resource Manager的。

PM是什么? 传统意义上PM就是一个产品的主管，为了方便讨论，我们这里将产品定义为软件、网站、网络应用、局域网或技术产品。 作为一名领导者，PM将对整个产品的成功负责，这其中包括用户体验。对技术产品而言，用户体验是产品成功中非常重要的部分，当然还包括其他方面，像产品的销售、技术、法律、商业模式、定位、品牌和营销等。 PM应该扮演一个领导者而非独裁者的形象，才能保证产品的成功，并得到各方的支持。像总统会与负责防务、交通、农业等的官员共事一样，PM团队也包括营销、技术、财务和其他领域的人。与票选民主不同，PM对用户和客户负责，通过收入、利润、用途和其他市场驱动因素来实行决定民主。 产品管理中涉及的各项任务和领域使得PM必须精通业务的方方面面。

产品管理与用户体验的冲突 最常见的UE与PM间的冲突就发生在该产品应该做什么与产品该怎么做的讨论上，双方经常辩论谁应该负责定义产品特性与需求。PM感觉应该由他们负责，因为他们管理产品，但是UE人员感觉应该由他们负责，因为他们花了时间来研究用户需求并直接与客户和用户互动。 最终由于PM对整个产品的成功负责，他们也就成了决定产品做什么的最后仲裁者。好的以市场为重点的PM应能理解市场背景和客户需求，并在第一手经验和已有研究的基础上决定合适的产品特性与功能。 然而UE人员常常对此非常光火，因为他们认为自己更贴近客户和用户，理应负责产品的需求收集和定义。好的PM应该象UE人员那样贴近自己的用户，否则就会脱离用户，只知道坐在办公室里开大会，让UE人员来做此类研究。 好的PM能深知用户体验这个角色并理解其重要性，重视他们的投入并利用他们的研究和建议来创造优秀的产品。正如总统需要从自己的内阁成员那里获得建议一样，PM也应该利用自己的"内阁成员" — 用户体验、市场营销、技术等 — 去做出决策。 从UE人员向PM角色的转换远不止去操作所有的界面设计， PM一项很重要也很有挑战的任务是负责确定产品的目标与策略，树立内在和外在的产品领导能力，创造商业模式及获得资本，从小事出发又能着眼大局，并协调市场、工程技术、财务、销售当然还有UE一起向成功迈进。 在第二章，我们将向你介绍迈向产品管理的方方面面，包括你在UE岗位上不可以做而在PM角色上需要做的事情、成为PM你必须做哪些准备、UE背景的人成为PM后常有的缺陷等，来帮助你作出这中转变。

平衡各方力量 确保你的产品重点是客户和用户需求非常重要，但是其他方面同样值得关注，包括但不限于: • 销售目标 • 市场/品牌目标 • 技术趋势 • 文档管理 • 预算管理 • 市场趋势 • 竞争力 • 商业模式与回报 (可能的人员浮动、变局影响、价格杠杆等) 做好一款产品需要在商业目标、用户需求和市场效应之间进行一系列权衡，作为PM，你就必须在各方之间努力做好平衡。

推广产品 你必须同时在内部(包括销售、市场、管理层、开发者等)和外部(包括客户、用户、业界分析员和媒体)取得支持。仅仅只是开发出一款好的产品还不够，你还必须让人们知道它，推广它的好处。 向组织中的其他产品提供策略投入 如果你是一间中型或大型公司的PM，你在这个位置上同样需要影响其他产品。你也会同其他公司内的其他PM交流，你需要考虑公司的全部产品线，并将你的产品融合其中。 你面临的挑战与压力 PM这个新角色会让你很有荣誉感和责权感，而且新头衔带给你的影响力可能会胜过其他，但它也是”带刺的玫瑰” — 你同样必须应付挑战和压力。

在前一章中，我们勾勒了PM的职责、PM与UE人员的差异以及为什么两种角色之间会产生冲突等。 现在我们来介绍当UE人员成为PM后其思考重点、职责与挑战将会发生哪些改变，离开UE工作岗位后你将有哪些收获与损失以及如何为这种转变做准备等。 在你向PM的角色纵身一跃之时，最好清楚这次跳跃对自身的影响。 作为UE人员不可以做而作为PM必须做的事情 成为PM后，你每天的工作将会发生巨大的变化! 你必须运用你的全部知识投入到整个产品中。作为UE人员你也许能同样做到这一点，但是限于行政授权你未必需要和公司内的全部决策部门打交道，以下就是你的一些"新职责": 关注产品策略以及客户和终端用户的需求(这也是你做出转换决定的原因) 你必须长期地研究客户和用户，找出用户需求与商业目标的切合点。相应地了解这方面的知识并有意识地利用它。 从产品的整体性上协助确定用户的焦点，不只是设计 沟通、政策以及定价都必须整合成为"客户体验"的整体，过去我们常常对这些方面的重要性认识不够，成为PM后你就必须对关乎产品体验的方方面面负责了。

学习并准备成为PM 因此，你想成为PM? 不知道从何做起? 除了上面提到的以外, 你还应该增加你在产品管理方面的知识，从中找到你为这一角色转变所需要的东西。 想想你迈向UE之路时候所做的事吧: 书、博客、会议、小组讨论、各种组织以及导师等，它们都发挥了很大的作用。如果你想成为PM，这些方式依然有效。 成为PM最好的条件是通过培训和会议。差点忘记提了，我们在IA 2007峰会: 你想成为产品经理 上有一个预备会议，这个半天的训练营上将会集中讨论如何从UE向PM的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。 还有其他组织提供类似的训练营活动，包括: • 实务营销 • 280小组 • Blackbot • ZigZag营销 • 硅谷产品小组 有大量非常好的Blog在讨论产品管理，你也可以从中选择: • Roger Cauvin的博客 • 实务营销的博客 • SVPG博客 • 产品管理观察 • Tyner Blain • Michael的产品管理与营销 • 如何成为优秀的PM (它的联合作者之一便是 Jeff Lash) 还有很多从UE角度来谈产品管理的书籍，这些都应该作为PM的珍藏: • 赢在新产品: 产品从创意到启动的加速实现, 作者Robert Cooper • 软件产品管理精华, 作者Alissa Dver • 产品经理手册, 作者Linda Gorchels 此外，有志成为PM的人还应该阅读一些综合的管理类图书，包括领导力、管理、市场营销、财务、技术、策略学等。 产品管理有两个主流的社团组织: PDMA (产品发展与管理协会)和AIPMM (国际产品营销与产品管理协会)。两者都提供培训、会议、本地讨论小组及其他产品管理资源。 同时，你还可以利用你的一些职业网络，也许能从类似LinkedIn — 帮你寻找能建立联系并回答有关产品管理问题 — 这样的服务中获得帮助。在你的公司里项目管理也能指导你，况且来自其他组织的产品经理也能给予你不同的或许更真诚的帮助。 正因为你学习产品管理并思考如何迈向这一步，可以找你的经理谈谈。优秀的经理会帮助你的职业化成长，即使这也许意味着你将进入公司的其他岗位。

作为PM，你的权力很有限 Guy Kawasaki形容PM是"一个背负全部职责却没有任何权力的人"。大部分为你的产品工作的人会向不同的管理层汇报，很少甚至没有人会直接向你汇报。你必须梳理这些分散的资源，指导他们的工作 — 尽管他们从各自的经理那里获得了不同的工作方向。 你必须做出决定并对此负责，而不仅仅是建议 事实上你必须做出很多的决定并为此负责，不是所有人都会认同(你的这些决定)。当然如果你的工作干的好，你可以向他们证明你的决定是正确的，明确解释你的原则，其他人也就不会显得焦急或轻视 — 但这并不容易! UE出身的PM会发现所创建的体验也许不是对用户"最好"的体验， 因为还需要考虑其他重要的因素(比如管理层的需求、商业策略、商业模式等)，让这些人理解做出这样的决定或许有损用户，但最终有益于产品往往需要时间。 你将经常处在利害分歧的中心 销售人员希望有不同的功能、开发人员将你制定的时间表往回推、财务人员需要新的后端功能、商业开发人员希望能为合作伙伴做一些产品调整、设计师希望更改一些功能的实现、用户希望增加一项你的竞争对手推出的新功能、管理层希望你的产品能与公司新产品进行整合… … PM就处在这样不同的竞争中心，在一些公司中这样的处境是很不妙的。你必须调节好这些冲突的想法，制定相互之间的优先级以推动产品策略并保证皆大欢喜(至少不能让某个人动怒)。 成功的PM总是围绕着整体的目标和策略来平衡各方的要求，决定做哪些可以最大限度地支持这些目标。PM对目标与策略的理解越深，就越能做出权衡考量。有时候一点小的让步能够得到更多的收益，有时候则需要更好地梳理目标。 管理层需要从你这里得到关于产品的信息 PM不只是产品开发团队的一员，你是整个产品的象征。无论你把事情做好了或搞砸了，也无论你是否真的能驾御局面，你都必须为此负责。 作为UE人员可以做而作为PM不可以做的事情 从UE岗位转换到PM岗位的人会对新职责感到兴奋和有挑战性，与此同时，他们也会失去一些UE工作的一些方面: PM不必插手过多细节 这是很多之前习惯过问小事的人面临的最艰难的挑战。作为PM很多具体的工作都应该是委派给其他人(来做)，一个花费太多时间去处理细节问题的PM注定没有做好他们的本职工作 — PM需要关注的是战略层而不是战术层。 PM并不追求尽善尽美和理论上的完美 有一个针对UE的笑话是UE人员经常回答问题的时候说"这个取决于…"。对PM来说，也许它确实取决于某件事情，但这不是紧要的。这并不是什么理论上应该发生的问题，而是在此情况下我们马上要做什么以及为什么做的问题。 你必须习惯够用即可的观念，做出在用户看来未必完美但在有限的资源下很受用的决定即可。 PM对产品的核心问题不只是建议 这一点和上面的有点背道而驰，UE实践者们提出建议，而PM需要决定策略、较高层面的用户体验、功能设置、市场规划、定价及其他方面。之所以又提到这一点，是希望促成你进行反省。如果你只是习惯建议或很难做决策，你也许不适合成为PM。 PM不是艺术家或专家型实践者 PM并不专注与产品的某个部分，而是知晓全局。他们有点类似船长或教练去驾御局面。在这个层面上，PM需要保障一起共事的人能将产品目标反映到方方面面，例如营销策略、界面设计、版权书写等。 由于不是专家，在各个方面进行调节是比较困难的，PM就必须在后面的工作中不断学习如何领导其他专家向一个共同的目标努力。 从现在起更好地配合你的PM 如果知道"幕后"产品管理，你可能已经动心了。有一条捷径能帮助你开始: 从现在开始更紧密和有效地配合你的PM! 这个办法即使对那些并没有这方面特质、技能或只是想成为PM的人来说都是值得一试的。作为一名UE实践者，更好地理解其他角色的同事所面临的责任与挑战可以帮助你调整与他人共事的方式，并且最终使你变得更有价值、更受尊敬、更有影响力。 有UE背景的人在某些领域是能够很好地与PM相处的，有些办法能很好地帮助你探路，而无论你是否迈出了这一步。 领导力 不要只知向PM或其他同事索要具体的研究和设计成果，在很多情况下，其他同事很欢迎你能有主动性和创意，不过同时他们也保留不同的观念，只要把事做起来就能迅速公开和集中地进行具体地讨论，总好过停留在理论和臆测层面。 向PM问清楚他们的产品目标是什么 问清目标非常重要，体现在两个方面：第一，PM自己有可能之前没有仔细想过产品目标，你这一问后，有可能让你成为最受信赖的顾问之一并帮助他们建立目标。 第二，如果PM已经有了目标，那么你也就能清晰地建立一系列的目标和预期。如果他们的目标存在问题，你还可进行澄清和确认，并决定怎样让它回到正确的道路上。 帮助PM评估设计的各方面因素 不要只是提出设计方案然后让PM做决定，要让自己准备好参与讨论特定设计选择的影响，向他人展现你的设计背后的原因已经他们在更广范围内与产品远景和目标的联系，聆听PM怎么说并搞清楚他们拒绝或认可的理由。 提出带有远期规划的强烈建议 你所能提供一些证据和经验将支持着你更紧密地成为产品的一份子，而不只是一个辅助的参考者。你也能从纷繁复杂的因素中做出决定的过程中得到锻炼，如果你立志想做PM的话这些很有帮助。 展现你对工作的远期规划将使你能成为团队中最重要的成员之一，并且能展现你有担负更多职责的潜力 — 不管你现在的角色是什么。 帮助PM走出办公室 PM不应该对客户和用户视而不见，尽管有人是这么干的。你应该通过询问他们最后一次见用户是什么时候来帮助他们，把他们带入到正式或非正式的用户研究中，或者给他们讲在用户访谈中的一些有意义的故事，邀请他们下次同去。如果被拒绝了，下次继续邀请。 如果PM能自愿去拜访用户，让他们带上你。除了了解用户需求之外，这也是一个你有时间向PM求教他们的观点、兴趣与目标的好机会。 如果你真的无法把PM带出办公室，那就把用户们带进来吧。在这种情况下，应该没有哪个PM(包括其他开发成员)能找借口拒绝和用户沟通。

2.项目估算 软件项目中的功能点法估算-实例 软件项目中的功能点法估算-原理 COCOMOII成本估算模型 IT项目管理-计划-估算 软件项目计划-估算杂谈

4.挣值管理 IT项目管理中的挣值分析 使用Project进行挣值分析

5.QFD质量功能部署 QFD质量功能展开基础 软件产品QFD第一层分解 软件产品QFD第二层分解

7.质量七工具 SPC统计过程控制-控制图 质量管理七工具

8.TOC约束理论 高德拉特博士TOC总体解决方案 关于瓶颈管理TOC的九大原则 TOC和项目管理

6.蒙特卡洛模拟 水晶球软件工具使用 多项目选择的模拟 IT项目组合风险分析

Openworkbench（http://www.openworkbench.org ）也是一个开源的项目管理软件，其功能跟Project 2003相似，是一个值得大家去使用的一个工具，但对于中国很多软件公司，都是使用特别版的Project 2003。假如你很尊重版权，又不想使用Project 2003，那Openworkbench是一个非常好的选择。

第二、需求分析工具     需求分析工具用得比较多可能就是Rational Rose、MicroSoft Visio或MindManager，一般我们使用Rational Rose来进行用例分析，画用例图，画状态图；使用MicroSoft Visio来画出应用系统的结构图、流程图等。当然，对于MicroSoft Visio能画出来的东西，其实Rose也一样可以实现，只是，大家都是这么干，我们也没有必要专门去做一些特例的东西，特别是对于一些比较特殊的公司及行业。

二、系统设计阶段： 第一、系统设计工具     主流的系统设计工具有大家非常熟悉的Rose2003，不过，现在已经不叫Rose了，现在IBM最新的设计工具是RSA（Ration Software Architect），Borland Together，SyBase PowerDesinger，MicroSoft Visio，对于开源的系统设计工具也有很多，比如ArgoUML、DBDesigner等等。

第二、开发的技术框架     技术框架的选择是非常关键，一个好的技术框架，可以让我们的开发更加快速、团队的分工更加合理、系统能够支持多种数据库平台、我们的维护更加方便。     Web前端MVC框架是Struts 2。Struts 2可以说是Struts穿上了WebWork的外衣，其内核大部分都是采用了WebWork的技术，并且基于AOP的设计思想，让我们在软件设计上的能够更加多地体现“高内聚，低耦合”的设计思想。

第三、开发规范的定制     文件命名规范、数据库设计规范、编码规范、团队协作规定等等一些规范性的东西，需要在系统开发前就规定好，并且做相应的培训。QA也要做好监督的作用，定期做评审工作，对已发生的问题及可能出现的问题，及早发现，及早处理。

第四、开发工具的选择     团队一定要选择同样的开发工具，开发工具相同，软件版本相同。为什么要这样子做，其实假如你作为一个Team Leader，你会在管理你的团队的时候发现很多问题，而解决这个问题，那在项目编码前，就把什么东西都规定好，以免其中发生问题，影响整个团队的开发速 度。开发工具的选择也是非常重要的，目前企业用得比较多的开发工具有：Eclipse、Jbuilder、NetBeans、IDEA。

三、开发阶段 第一、配置管理工具 代码管理工具有很多，现在公司用得比较多的代码管理工具有CVS、VSS、SVN。 对于一个开发团队只有2-5个人，并且这两三个人是同一间办公室里，那使用VSS是一个非常不错的选择，个人觉得他小团队的管理方面非常好用。个人觉得 VSS唯一的缺点就是一个文件当被一个人锁定，那其他人就没有办法进行修改了，当一个文件为多个人所共用且开发团队人数较多时，这种问题将会显示非常严 重。VSS客户端跟服务器你都可以从Visio Studio里面找到。

对于一个开发团队有超过5个人，那此如选择CVS或SVN将是一个更好的选择，并且，假如你的团队是分散的，可能不在一间办公室或者根本不在同一个城市，那使用CVS或SVN是一个非常更想的选择。CVS的服务器一般是使用CVSNT或CVSServer。

四、软件测试阶段  第一、缺陷管理工具     软件你不能保证它永远不会错，只是，有些错误你暂时还没有发现而已；有些错误需要在某些特定的环境下它才会发生。就像Windows，时不时会有一些系统 更新文件要求更新。可能这些更新不是错误，只是一些系统安全方面的隐患。这些都可以算是软件系统的缺陷。那这些缺陷我们应该怎么进行管理？怎么进行跟踪 呢？现在缺陷管理用得比较多的有两个：第一个是开源的bugzilla，另一个是商业的JIRA。

六、软件维护阶段 第一、客户CASE跟踪管理工具     客户CASE跟踪系统相信很多做CISCO公司金牌代理的人都会用过。我们必须在公司内部建立相应的CASE跟踪制度。当用户使用系统的时候，发现一些问 题，那我们需要对这些问题进行录入并进行跟踪。像客户呼叫服务系统等等一些商业化的软件外面还是很多的，这些系统其实公司自己开发一个也是很快的。但必须 要有。这个也是提高整个公司整体服务形象的一种态度。