Zen of PM 原文刊于这里： http://microsoftjobsblog.com/zen-of-pm/
两年多以前刚刚加入微软的时候，就读过这篇“Zen of PM”，但其实当时并不完全了解这篇文章是什么意思。而现在读起来，却有了许多感悟。花些时间翻译出来，一方面自己加深理解，一方面也借机与大家分享。很多地方翻译的不够理想，请见谅。
这篇文章算是微软PM的必读学习材料，所以其实它的目标读者是微软的PM，即Program Manager。对比现在日新月异的互联网行业，Program Manager非常像Product Manager和Project Manager的混合体（坦白讲，我对互联网Product Manager和Project Manager的理解相当有局限）。所以请大家有个正确的理解和预期。我会把Program Manager翻译为项目经理，因为这里的Program一词在微软的定义为“A set of projects”，但Program Manager还是与Project Manager有所差别，文中有相关评解。
转载请注明出处。多谢。
PM之“禅”
如果您在考虑项目管理（program management）的工作，或是希望了解项目经理们（program managers）做什么，那您需要读这篇文章！
这篇文章会告诉您关于项目管理的一切，但又什么都没讲。它揭示了项目管理中的“禅”。这不是对微软Career Stage Profiles [1] 中项目管理的解读，也不是一本如何成为高效项目经理的指南手册。这篇文章讲述了项目管理在能力上和角色上的独特之处。请欣赏！
版本 1.0e: 2007年2月14日
项目管理中的“禅”
项目经理是价值定位（Value Proposition）的守护者。
在早期的规划中，我们埋头于用户需求、竞争环境、技术趋势以及业务重点之中，并且从这些嘈杂的声音里提炼出一个清晰、专注的价值定位。
我们清楚的表达出团队一致努力要交付什么，交付给谁，以及需要达到的目标。
对价值定位的清楚表达，可以认为是一个“构架（frame）”，团队在此构架下进行功能、设计、时间表以及优先级的决策。
随着项目由规划阶段进展到设计阶段，我们通过故事脚本、原型、以及最为有效的规格说明书，描绘出团队未来发布的产品的细节图纸。
当项目进展至实施阶段，并一路走向完成的时候，我们要保持洞察力，确保实施中所做的决策适合于价值定位的构架。
最终，我们确保发布的产品或功能表现出有力的价值定位，并且的确实现承诺过的价值。
绪言
项目管理中的“禅”存在于客户和价值定位与产品或服务之间的联系中。项目经理团结团队，在项目开始和结束之间建立这种联系。
这篇文章的目的是提供对项目管理角色更深入的见解，并清楚地指出项目经理为何独一无二及其具有的独特价值。这篇文章专注于项目管理的价值，而此价值需要在整个团队中才能显现出来。团队合作是最为重要的，没有任何一个角色可以担当整个团队。
此文章的内容包括了软件产品周期中的三个主要步骤，以及每一步中项目经理所发挥的价值：
- 规划：纷繁中做构架
- 设计：定义解决方案
- 执行：在价值定位之上交付
规划：纷繁中做构架
软件无限的潜能使得项目管理成为非常令人兴奋的工作，同样也使得项目管理成为十分重要的工作。在每个产品周期中的每个里程碑里，产品组都会面临本质上无限多的可能性。他们几乎可以开发任何他们梦想的东西。但如果要成功，团队需要对关注什么以及开发什么做出聪明的决定。在无尽的可能性面前，功能团队如何做出这些抉择呢？
构架是一门艺术，找出真正重要的，并且区分“能够”和“应该”的艺术。在一个项目的早期规划阶段，项目经理与客户、规划师、以及其他团队成员一起来定义这个构架，并确保团队中的每个成员都理解并接受了它。
为了创建这一构架，项目经理会从问一些宽泛的问题开始：
- 谁是用户？他们的需求和重点是什么？
- 市场中正在发生什么事情？竞争对手在做什么？作为回应和差异化，我们有何选择？
- 技术在怎样变化？这给我们的客户带来了怎样的可能性？
- 我们的业务重点是什么？
这些问题的答案可以描绘出我们所处的境地，而我们要在此境地中开发产品及其功能。
构架的目的是，在此境地上，找到合适的清晰并有说服力的愿景，并基于此愿景集中关注范围。当前境地与愿景之间的联系非常关键。一个脱离现实的愿景是弱不禁风的，而且在团队每天面对的无数不可避免的决策面前，无法提供做决定的基础。
所以，一个项目经理要如何创建这一构架呢？有三个关键因素：收集信息，深思熟虑，以及团队就绪。
收集信息
作为项目经理，第一步要做的就是找到正确的信息，理解您现有或未来的产品/服务所处的产业环境。愿意花费精力的项目经理可以找到丰富的信息：客户研究与调查、客户满意度指数、角色设定（personas）、可用性数据、SQM/Watson数据[2]、在线新闻组、客户委员会、合作伙伴反馈、产品支持报告、行业分析、竞争产品评价、焦点小组（focus group）结果，等等。
无论您是负责定义产品愿景的群项目经理（Group Program Manager，通常是主管PM们的经理），还是设计特定功能的个人贡献者（Individual Contributor，非管理人员），都需要以此信息为基础。
不要忘记您的同事们，产品规划、市场推广、研究院，以及来自公司外部的帮助。他们是收集、提炼这些信息的极佳同盟。但是，如果您没有可以联络的产品规划师或市场人员，您仍然在团队中担负收集此类信息的职责。项目经理必须能够找到灵活多样的方法收集这种信息。您需确保团队能够尽早获得这些信息，为项目计划提供必要的背景。
注意：虽然会有无限的大量信息，而您可能会很难找到答案。别慌张。记住，您并不是真的在寻找特定的答案。您是要理解现状并了解背景。您所了解到的内容没准会带来更多的问题和相互冲突的工作重点。收集信息并不像是寻找彩蛋。如果把它看作是寻找答案，您会发现这是无尽的探索。收集信息只是一个开始——您的工作在此处并未完成，所以带上您所了解到的，继续前进。
深思熟虑
现在，您沉浸在关于客户、竞争对手等等的信息当中。这些信息告诉了您什么？如果您可以使用一个简单的公式就得出正确的产品路线，是不是很棒？您可以停下来不要在互联网上搜索这个公式了，而是照照镜子。就算拥有世界上所有的数据，您也不能证明应该做哪个功能或是应该采用哪种设计。这些决定既是艺术又是科学，而驾驭这种混合情况是成为一个项目经理的重要组成部分。
围绕着这些数据，仔细琢磨，和您的团队成员讨论您了解到了什么，以及这些数据展现出的未来的方向。有些是关于哪些信息是噪声，哪些是信号。有些是找出没关系或看起来不相关的信息之间的联系。而最终，您需要知道什么是有意义的，然后最好准备，找到真正的机会在哪里。
如果您盯着大量信息，却又看不到明显的模式或更深入的意义，不要感到惊讶。这需要时间、迭代、甚至对话来找出数据指引的方向。通常，都是在您用光了整块白板，画满了小方块，丢弃了一些幻灯片，骚扰一番团队成员之后，才开始觉得开了窍的。
团队就绪
一旦您理解了背景并且准备好专注于一个特定的机会时，您应该与您的团队分享您的理解。如果您想有影响力，那影响力一定是通过与同事分享知识、想法、以及理解达到的。要成功的做到这一点，您必须用容易消化的方法让您的团队理解大背景和大框架，从而更清晰地显露出各个机会的价值和优先级。对此进行有效的沟通，是帮助您的团队成员理解您是如何从“我们的竞争对手击败我们的一个最大原因就是他们有更好的3年总有成本”思考到“我们需要让客户能够在4小时之内部署我们的解决方案”，并且这一思维飞跃为何重要的关键。
这里有一些需要注意的地方。不要陷入经典的项目经理陷阱：您收集信息，深思熟虑，然后回来向团队报告，“同志们，我全都搞清楚了——这就是我们要干的什么什么。”一个团队会痛恨这样！他们很可能最终不理睬你，而不会照着你仔细研究好的计划行事。我们雇佣聪明的人，他们想要分享您的见解，而不只是听您的结论。在团队开始集体工作之前，您必须分享您思考时的前因后果，如何从这些数据得出结论的过程。很多情况下，分享这些信息的过程可以帮助您推敲您的想法……不要错过从集体智慧中学习的机会！
认清这种现实后，好的项目经理会花时间审视从其他项目经理以及功能团队收集来的信息和资料，挑出关键数据，并且与大家分享自己觉得这些信息之间有何关联。记住，项目经理的首要角色就是用一种团队能够理解，并用来制定方向和重要性的方法来描述项目。您的角色不是做决定，而是让整个团队拥有统一的认识，共同在产品的生命周期中做出决定。
设计：定义解决方案
当一个问题被描述清楚后，接着是一个艰巨的工作：找到解决问题的方法。每个问题都通常有几十种潜在的解决方案，而通常，最好的解决方案是在许多相互制约的因素下权衡的结果：成本、资源、美感、稳健性、功能、技术约束、兼容性要求、等等。如果问题被描述的很清楚，这种描述可以用来指导项目经理和功能团队达到最好的权衡结果。
在开始思考一个成型的设计之前，首先确立功能的价值定位。价值定位是对这个功能能够给用户带来什么好处的清晰说明。如果您的用户会说这样的话“这个功能帮助我完成了工作”，或者“这个功能用起来很有趣”，再或者“这个功能为我节约了许多时间”，那么这个功能就有了价值定位。现在再进一步：回想一下构架，并且试问这一价值定位是否与您想实现的价值吻合。许多功能（及产品）失败了，并非因为他们没有实现价值，而是因为实现了错误的价值。
从构架及价值定位阶段到设计阶段，有3个关键的步骤：从白纸到概念，迭代出好设计，和沟通中设计。
从白纸到概念
从空空如也的一张白纸（或是空白的白板，或是空白幻灯片）开始的关键，是制作方案、选择立场或是实现一个想法的意愿。设计一个解决方案不同于解决代数问题：您无法自己找到一个可以证明为正确的答案。从一个解决问题的主意开始——任何主意——然后看看您是否能向同事解释清楚。通过邮件、短小的文档、或是白板上的涂鸦来分享您的原始想法。去其他团队成员的办公室里做头脑风暴。
您可能会立即发现，即使是您对自己的想法也并没有了解得足够清楚，没法给别人解释清楚。一旦您克服了这令人为难的第一关，您就能迅速发现您的方案中哪里好哪里差了，并且同您一起工作的聪明人们会用各种想法淹没您，从而有机会做出更好的方案。（记住，您的工作是引导大家的工作得到出色的解决方案，而不是成为那个拥有所有好点子的人。）
迭代出好设计
拥抱迭代，但要使其在控制范围之内。把原始想法展露出来，可以提高脑力用于设计，这可是件好事儿。同时，噪音和混乱也随之而来，所以要在相对独立的迭代周期中，推进流程向前发展。从前一个周期中收集反馈，留住好主意，去除糟点子，更新设计，然后让全组成员关注设计中仍需注意的部分。当您作为项目经理不断成长的时候，您会遇到许多乐趣和有用的设计技巧（故事脚本，真实场景调查[Contextual Inquiry]，等等），但是，最为重要的技能是有效地管理、推进迭代过程。
在每个迭代中，需要保证功能确实凸显了价值定位，与这个问题的原始构架契合。
在整个过程中，肯定会有各种不同意见，请记住，这绝非是针对个人的。当您主导一个功能团队进行设计，团队里都是聪明人，肯定会有很多好主意从争论中显现出来。但是大家都期待您做出判断。不会每个人都永远同意您的判断，但如果必须为进行迭代设计做出决定，那您需要承担此责任与风险。
成功地做好迭代意味着您需要清楚地了解设计中的哪些部分需要提早完成，哪些部分可以晚一些。
您和您的功能团队进行迭代设计时，可以征求利益相关者的反馈，以及从不同岗位的专家那里获得意见，来确保解决方案可行。可用性工程师可以判断当前设计的接口是否容易使用，包括残障人士的使用。基于可用原型的早期用户反馈十分宝贵，可以用来确认解决方案是否可行。即使在早期设计阶段，安全专家也能找到潜在的缺陷。其他项目经理——同级的或经理——是好点子的珍贵来源，也会帮忙避免走错路。
沟通中设计
设计一旦充实起来后，就需要进一步的沟通，让团队中所有的成员对正在开发的功能拥有统一的认识。多数情况下，设计用于沟通的最终形式为一个写好的功能规格说明书（the spec）。用高质量的spec描述该设计的关键好处在于：
- 除非对正确的功能有清晰的说明，否则这个功能就无法测试。如果没有spec扮演“神谕”的角色，或是spec不完整、不正确、含混不清，则没有测试，只有试验和争论。
- spec记录的版本是在最大范围内被相关人员认可的：功能团队，产品组经理，以及其他利益相关人士（stakeholders）。
- 除了实现功能的开发/测试工程师，设计的细节会影响许多其他人，比如：翻译、文档撰写人、培训讲师、支持工程师。
- 对微软的企业生命而言，法规遵从愈发重要，而法规遵从通常要求设计和实现细节通过法规审查。
关注细节和精细度是撰写高质量spec的关键。Spec需要有丰富的细节，从客户场景开始设计，包含功能中所有接口和操作的完整描述。画出每个对话框，描述每个操作。考虑用户可能看到的每个单词。如果您不这么做，那么有些人就会替您做出设计决定，很可能是仓促的，并且没有体现您对问题构架的理解和解决方案的精妙之处。错误的解决方案会被实现出来，而文档记录并没能反映真实状况。
执行：在价值定位之上交付
您清楚地描述问题并且设计出解决方案后，就是执行部分了——完成您已经开始的工作。为了顺利完成，项目经理需埋头于使产品出色的各种细节之中。这些细节包括场景、设计和功能规格说明、客户讨论、发布前的冲刺会议、以及无数需要完成的小任务和截止日期。在大图景和小细节之间保持完整和一致性是项目管理角色的关键，出色的项目经理懂得如何根据需要在这些角色中转变。
您不只是要把软件做出来，而还必须是价值定位的保护者。您必须确保发布了正确的体验、正确的功能、正确的价值定位、并且遵从正确的时间表。要完成这些，最好的项目经理会有一种“主人翁意识”——他们感觉到一种做正确事情的强烈动力。这种动力尤为重要，可以帮助跨越人为阻碍，应对变化的环境，使项目获得成功。
与客户和合作伙伴验证您的产品
只是了解用户，认真地进行迭代，优化设计，并不能保证客户会像预想的那样把您设计的产品带回家。随着产品成型，项目经理在与客户和合作伙伴验证设计中，扮演重要的角色。您越早获得高质量的反馈，越可以根据需要及时调整计划。即使在设计被实现之前，像幻灯片和故事脚本之类的工具就可以用来收集早期反馈。也就是说，总有一些教训是要在做出产品时才能领会到。与客户验证早期的编译版本或测试版是必须的，项目经理在反馈计划中扮演尤为重要的角色，要将从测试版、可用性研究、以及其他来源收集到的反馈汇总起来。一旦开始收集反馈，指导团队如何回复反馈也是项目经理的职责所在。什么应该立即变更？什么可以等到下一版？如何回复客户？什么地方可以用更好的文档或细小的设计变更给客户体验带来大的改善？
清晰的立场和声音
随着设计转化为实现，即便是最好的计划和设计都仍需改善。如果放任不管，小的设计变更可能会变成巨大威胁，影响团队准备交付的核心价值定位。在项目的各个阶段，包括执行阶段中，项目经理始终保持警醒，保护客户和价值定位。软件开发的真相是必须有妥协，功能削减，以及放弃修复故障。但是，为了做出正确的妥协，项目经理需要提供清晰的立场和声音，保证问题的重新定义（更准确的说，是再次申明初始的问题定义）。
项目临近结尾的时候，事情通常变得复杂而紧张。团队在压力之下削减功能，放弃修复故障，危机出现，功能可能无法与预期一致。多数情况下，如果您正确地对问题进行了定义，您应该可以根据此定义对各种权衡排出优先级，做出最后的决策。但是，在有些情况下，使您做出初始问题定义的环境可能已经变化了，您可能需要退回去重新定义问题，重做解决方案，或甚至放弃已有的成果。最彪悍的项目经理懂得“病人已经没救了”的时刻，并且他们不允许因情感或个人喜好造成主观的立场。
项目经理的立场对于评估产品是否可以发布同样重要。它能否交付足够赢得市场的客户价值？用户体验是否是客户所需要的？是令人欣喜还是失望？它能超出、满足还是无法达到市场承诺？与客户、市场部门、用户体验部门、以及项目本身花费了大量时间之后，项目经理处于理想的位置，可以指导项目的最后阶段，确保团队的工作不只是按时交付，还交付出了正确的产品。
项目管理的传说
有一些关于微软项目管理的传说。根据听众不同，这些传说在英雄和男仆之间波动，但有一些关于项目经理角色的普遍传说，是时候终结了。
- 传说：项目经理的工作就是记笔记和安排会议：项目经理经常记笔记和安排会议，但这并不是因为其他人的时间更有价值，而是因为他们意识到记录决议、建立共识的价值。他们还利用这些活动建立日程表，集中注意力于决议上，并确保结果被清楚的记录了下来。有一份做了什么决定，以及为什么的记录，从项目管理的角度上看，是找寻解决方案的过程以及优秀工程中必需的一步。通常，您会看到其他岗位的领导在扮演这样的角色，这是因为他们认同这一价值。记笔记和安排会议并非项目管理特有的技能。
- 传说：项目经理根本是个传教士：项目经理通常都是优秀的演讲家，并且能够跟不同的听众沟通得很好。但这意味着，项目管理的基本角色是作为产品开发团队的一部分，而不是内部或外部的市场资源。项目经理试图成为优秀的沟通者这一事实，并不表示项目经理应该花费绝大多数时间来向客户或微软的其他部门解释项目计划。也不表示所有需要发言的活动都要交给项目经理去做。给项目经理分配过多演示工作的话，会占用他们做更重要事情的时间：设计软件，定期与功能团队沟通，维护客户和价值定位。需要发言的活动对项目经理而言很有价值，而对其他角色的人员也一样。并且这不能成为该角色的重点。
- 传说：“PM”表示“project manager”：项目经理（program manager）的角色从根本上说是打造软件，而不仅仅是管理打造软件的过程。有时候某些项目需要全职的project manager，而这通常是项目经理（program manager）角色中的一小部分。即使项目经理在某一时间段全职处理这一工作，项目管理的CSP要求项目经理拥有更多的技能，才能获得长期的成功。一个优秀的项目经理可以挑战开发/测试人员，并且提出不同的行动路线。这必须依靠项目经理对项目有深刻的理解，并且对解决方案中所使用的技术有丰富的知识。只会计算任务数量、任务都分配给了谁、是否按计划进行的项目经理，无法在项目的重要阶段中给出深刻的洞察力——产品是否能够在价值定位之上交付，能否满足客户所需。此外，项目管理技能并非项目管理所独有，通常，其他的职务也同样需要。谁能够比编写代码的开发人员更好地推进进度？谁能比准确了解当前产品状态的测试人员能更好的管理发布流程？
- 传说：项目经理应该给开发人员准备咖啡：在发布前的最后时刻给忙于修复故障的开发人员准备咖啡或午餐的项目经理，只是单纯地想做个好团队伙伴。这并不意味着项目经理的存在只是为开发人员服务的（无论是打比方还是名副其实的）。项目经理和他们的开发/测试同伴一起，为服务客户而存在。最好的产品团队认为项目管理、开发、测试角色在优秀软件的生产中，同样重要。
- 传说：项目经理“说了算”：您是团队中的一分子——相互平等的一个成员。没错，最好的项目经理在主导功能交付时，会有主人翁精神。而最好的团队中，所有的成员都具备开发正确产品的主人翁精神。当鼓励全组成员都想要成为主人翁时，您才最为成功。把开发和测试想象成为一个小企业中的合伙人——所有人都是老板，所有人都为全组的成功贡献巨大力量。表现出色的团队会根据个性优势和偏好，自然的分化出不同的角色。但是，项目经理或任何其他人都不会“说了算”。（这个传说有很多变种。比如“项目经理为战略负责”，“项目经理独自撰写规格说明文档”，以及“只有项目经理才跟客户沟通”。这些都是错误的。）
成功的项目经理的个性品质
如何判断您是否是个天生的项目经理呢？拥有体现项目管理之禅的天资、才能和个性品质？如果您经常与成功的项目经理呆在一起，就会发现一些趋势。我们选取了5种天性和行为，用短句表达出来。我们相信这些天性在不同级别的项目经理身上都是共通的（很多情况下，在人们成为项目经理之前很久，这些特征就显现出来了）。
而我们并不是要把项目管理CSP中的内容照抄一遍，应该可以很容易看出个性品质与CSP发展之间的关系。这是否是说所有的项目经理都要有相似的个性么？不。项目经历是否是天生的？或是环境影响的产物（培养出来的）？简单的答案是：都是。项目管理CSP中相当大的一部分技能是可以通过学习得到的。但是，个性品质和接下来讨论的天性，是决定一个人能否从“足够好的”项目经理成长为“出色的”项目经理的重要因素。
1. “我们是不是真的需要个计划？”即使在行动当中，出色的项目经理会回过头来考虑他们（朋友和同事）是否是在按照可靠的计划行事。如果您考虑以项目管理作为职业，就应该乐于挑战计划记录、发起行动、并且领导计划的制定。实际上，项目经理在团队（工作以外，这可能是他们的朋友或家庭成员）有了清晰完整的目标之前都不会罢休，必须清楚找到令人信服的目标才能为之行动。
2. “ 如果是我设计了xxx，我会……”出色的项目经理是天生的设计师，渴望在日常生活中创造、设计、解决问题。他们不由自主地去解决问题，时常在朋友的新车里检查温度控制器，并对这些控制器是否能满足所需提出疑问，然后提出这款车的下一代可以有哪些潜在的改进。
3. “有个不错的电影我们一起去看吧。”出色的项目经理在工作之外也经常是天生的领袖。你知道有时候，一大群人需要决定个很简单的事，比如选个电影？是没有“正确”答案的，所以很难统一意见。天生的项目经理至少会提出个建议，或是促成统一的意见，让整组人开动。如果您考虑未来从事项目管理工作的话，就不要怕主导讨论、负责会议、或是促进团队统一意见，即使您自己并不是做决定的最合格人选。出色的项目经理勇于挑战不确定性，并努力推动事情发展，而不会因没有方向而陷入麻痹。
4. “我给你讲个故事……”出色的项目经理通常是热情而令人舒服的沟通者，有着阐述整个故事的耐心。他们会用类比和故事的方式来沟通，无论是谈论政治、爱好、或产品。邀请别人来自己家做客时，他们会提供细节的，但简明的方位信息。这种鼓励并引导沟通的天性通常会积极有力地鼓励团队向共同的目标前进。如果您觉得梳理复杂和混乱的东西很有乐趣，那您可能就是个天生的项目经理。
5. “我是这么想的（虽然可能不对）。”出色的项目经理是天生的合作者，他们听取想法，促进讨论，收集不同的数据和观点。他们不怕提出或收到异议，愿意把自己的想法说出来让大家提反馈，并承担风险。这些人甚至会去尝试非常可能失败的事情，因为他们本能地知道，即使失败，也能从中得到有价值的收获。如果您遇到出色并且成熟的项目经理，问问他们是否有过严重的失败。您很可能会听到一个很棒的故事并且能够从中学到许多。如果您倾向于为失败开脱，或是追求永不失败，甚至您很自信不会失败的话，您可能要再想想是不是真的要做项目管理这一行了。
所以，并不是有特定一类人能够成为成功的项目经理，而一些常见的“特征”可以透露出这一角色的特性。如果您在上文的描述中看到自己的影子，那您就很有潜力成为出色的项目经理！
项目经理的个性品质
解决问题与责任感
|
沟通力
|
领导力
|
客户与合作伙伴
|
[1] Career Stage Profiles（CSP）是微软内部的职业规划工具。描述了不同职责在不同级别上对员工能力的详细要求。
[2] SQM/Watson是微软用来收集用户反馈的工具。
[3] 一直都不知道怎么翻译empathy（移情）。我对这个词的理解就是，用户看到产品就由内心生发出喜爱之情。
<以下为版权信息>
***
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, any companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.
© 2007 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.
竟然到现在都没有评论！