品牌推广应用设计的最佳实践
作者 Roland Deal 译者 罗小平 发布于 2010年1月3日 下午8时12分

社区 Architecture 主题 设计, RIA, 商业 标签 Adobe, 最佳实践, Flash
为了提升自己品牌或产品的知名度，你可能决定开发一个品牌推广应用（branded application，有时候也代指一个widget）。或许你已经读过相关文章、看过相关新闻，甚至自己就已经玩过几个品牌推广应用。现在已经决策要开发并准备了预算，找好了开发和实现品牌推广应用以吸引用户所需的资源。万事俱备，只欠回答一个问题了：如何才能做出一个真正有效果的品牌推广应用？什么该做，什么不该做？是否有别人已经证明过的经验或规律可以依循呢？

对于大多数商家而言，品牌推广应用还是一个相对陌生的策略。因此着手之初，几乎找不到业已存在的标准。没有什么规则可以告诉他们如何避免问题、在哪里优化。而且，品牌推广应用本质上是个迷你应用，可以完成任何天才和颇具创造力的Adobe Flash开发人员所能想到的任何事情，包含各种功能、特性、品牌要素、市场信息等内容。

爱因斯坦曾指出：“一起都应该尽可能简单，直到不能再简单为止”，这是设计一个有效的品牌推广应用的基本原则。有时候，事物简化本身就是件非常困难的事情，但毫无疑问它对最终成功有最大贡献。本文提出SIMPLE设计方法，并对其包含的每项元素（simplicity、intuitiveness、message、personalization、layout和engagement）逐一分析，帮助大家记忆并在自己的品牌推广应用设计中应用这些最佳方案。
设计概述
在分析SIMPLE设计原则之前，请记住这样一句话：优异的、有创意的方案来源于目标、计划和市场背景的清晰把握。品牌推广应用的设计者要明确知道应用的目标，因为它的背后是更大的广告和营销活动。应用是为了传递品牌信息？是为了通过特性、优点展示良好的品牌体验？支持真实交互么（比如下载音乐、自定义头像）？在将任何资源引入到设计之前，确定这些问题并得到重要决策人的支持，是至关重要的。

和任何广告活动一样，用户和目标的清晰，对品牌推广应用的成功实现是非常重要的。谁是目标用户？价值主张是否明确？品牌推广应用应该满足用户的某种需求，如娱乐、自我展示，或帮助用户实现价值。设计者必须明白谁是目标受众，需要清楚知道目标受众是谁、如何驱动交互（比如在用户间构建交互手段，或为用户获取有用信息提供支持）。

最后，对环境的清晰认识也非常关键。品牌推广应用的生存地点在哪里，是互联网、手机还是桌面？这个应用是放到用户的社交网络个人资料页，还是博客？因为像Facebook或MySpace访问的者中，有自己的个人资料页的比例较高，因此这些用户很可能愿意将看到的品牌推广应用放到自己页面上去。相比较而言，很多博客的读者其实并没有自己的博客，那么为他们提供复制其他博客上的品牌推广应用到自己博客的功能就显得不那么重要了。

与应用发布有关系的因素是应用的周期。你的品牌推广应用将运行多长时间？它或者只是为期三个月的营销活动的一个组成部分，过后就放弃不用管了么？还是打算无限期运行，持续为用户传递价值？如果是后者，它是否需要定期更新？将这些问题一一定位，设计者、开发者才能有清晰的目标和导向，这是保证开发出的品牌推广应用成功所必需的。

一旦上述关键问题被一一确定、各方达成共识，那么创意和开发团队就可以着手设计和开发了。

设计你的品牌推广应用
在设计你的品牌推广应用时，有6条原则一定要时刻遵守，只要一直坚持，成功的可能性就会不断加大，最终达成你之前设定的目标。这些原则放在一起可拼为SIMPLE，便于记忆和理解。

简单
要吸引用户与你的品牌推广应用交互，“少即是多”（less-is-more）或许是最为合适的。功能单一，往往也是目标明确，用户也更易理解应用是什么、用来干什么，自己为什么要将宝贵的时间花在它上面。品牌推广应用的尺寸一般较小，品牌形象和信息的展示、传递的可用空间受限。设计者需要尽可能利用有限的资源，在第一时间让应用的目标清晰展现。如果应用中需要滚动条、下拉菜单才能显示信息，那么就应该重新思考这些信息的价值了；如果应用包含了两三项活动，那么就应该评估是否开发两三个不同的应用，每个只负责传递单一信息和价值。

同时要避免使用传统的Web导航技术，例如多个页面、链接到不同活动的按钮等等。套用Hans Hofmann的一句话，简单即“消灭不必要的，必要的才能发出声音”。Kraft Recipe Assistant应用（见图1）是一个典型例子，功能非常简单。它为用户提出每日晚餐的建议，同时也允许用户在应用中通过关键字或指定原料搜索其他食物。Kraft通过为用户提供易于理解、使用而且有实际价值的工具，兑现了品牌承诺。

图1，Kraft Recipe Assistant应用

直觉
你的设计应该在最短时间内暴露出自己的目标。用户花在理解应用的目标的时间越少，TA愿意与之交互的可能性越大。应用的显示界面需要在用户无需介入的情况下，直接展示出要表达的价值和目的。将你的设计实现为简单样品后，开展实际测试（理想情况下，参与者应该来自于你的目标受众群）。如果接受测试者不能在7-10秒内明白应用的目的，你就应该重新设计，因为这已经表明你的应用能在潜在用户中引起多大程度的注意。

Hyatt的eDeals桌面应用是这方面的一个好例子。它根据用户的喜好（比如在指定地点的利率促销情况），定时生成提醒。eDeals仅仅做一件事，并正确完成，因此任何由Hyatt指导过的营销计划都有最高的转化率。

消息
不要忘记品牌推广应用的最终目标：传递某种符合你要推广的品牌或产品的价值。用起来很有趣的应用（如一个能吸引用户交互的休闲游戏），但并没有提升对品牌或产品价值传递的支持，因此是对机会的浪费。

未与一个特定的单一市场信息捆绑的品牌推广应用，最终必然不能给消费者和商家带来令人满意的体验。试想这样一个问题，如果用户被问及：“品牌推广应用必须为正在推广的品牌或产品做出什么贡献”？用户会如何回答呢，如果他们的答案并不清晰，那么就应该重新审视设计，因为现有的设计不能实现既定目标。想像一个品牌推广应用是一个某人私人房产上的免费广告板块，你就需要考虑一下你应该多大程度传达你的品牌和信息。如果信息过于嘈杂、花哨，可能你就永无登台的机会。

个性化
品牌推广应用能由用户定制，支持个性化，无疑是一项能吸引用户、促进传播的重要能力。社会媒体用户通常可以自行控制个人资料页、社会媒体环境，因此在品牌推广应用上支持类似的个性化，逻辑上具有同样的意义。例如支持用户上传照片或自定义头像，给用户带来实用价值，就可以让用户为应用的产品投入、增加粘性。Purina发布的品牌推广应用（见图2），允许用户上传他们宠物的照片，宠物通过一个对话气泡，可根据天气条件和温度将自己的健康状况告诉主人。通过利用宠物照片个性化定制应用，Purina的设计者将一个传统的天气应用转变成为一个交互的、具有高度个性化体验，令人叫好的品牌。

图2，Purina的Pet Weather应用

布局
如果你想在社会媒体（如博客、社会化网络等）上发布在线的品牌推广应用，那么使用标准的IAB ad unit dimensions，无疑适应性更强、可见程度更高。设计界面更小的桌面或在线应用，将增加发布潜力。你的品牌推广应用将和其他应用、内容源等共存。更大、更突出品牌推广应用将越来越少，因为它们界面太大，与其带来的实际价值比例失调。在应用中应该使用易于阅读的字体，避免使用小字体。测试表明，一个界面中有效的、易于理解的内容比重不超过40%，也就是说剩余60%界面应该是干净的，没有内容和导航元素。

同样，应该保证应用的体积最小。因为每个品牌推广应用都能从单个源文件生成，内容也很容易更新，对于生命周期多于2-3月的品牌推广应用，推荐此方案。

对于在线品牌推广应用而言，要注意它在环境中的平衡。品牌推广应用当然要引人注目，但不是为了和它所处页面的其它内容和组件相冲突而体现。相反，如果品牌推广应用很像用户界面的一个部分，就易被用户当做该页面或站点的一个功能而忽略。

参与
一个广告或品牌推广应用能出现在用户的个人资料页、博客或桌面上，是因为用户自己将它放置上去了。它包含的是用户认可的商业内容，用户将其放在醒目位置，以便亲朋好友能一眼看到。朋友和家人是我们最可信任的信息源，他们看到这些品牌推广应用后，也更可能将这些应用嵌入到自己的个人资料页。要让这种感染式的传播发生，应用就必须对用户有真正的价值或用途。参与导致支持，支持会引来更多参与。这种良性的正面反馈是可以通过一开始就让应用的价值显而易见、立即被认可而触发的。

理想的品牌推广应用能吸引用户每天使用、参与多次。一个被认可的例子是一个提供实时交通状况的交通报告品牌推广应用，用户每天至少会使用两次。让品牌推广应用的参与用户点击一次——最多两次，就能达到自己的目的。用户就能快速发现应用的价值，而不需花好几分钟设置选项、加载内容，从一堆皮肤、色彩主题中做出选择。操作简单、易于运行，保证用户可以方便地将品牌推广应用复制到自己的页面或站点上。简单实用一个“Grab It”按钮，已经成为一个惯例，几乎所有品牌推广应用的用户都能理解。

总结
越来越多的广告客户希望借助品牌推广应用在他们自己的个人社会网络和计算环境中赢取受众，这种品牌推广和广告应用无疑将持续成长。 Forrester统计表明，60%的成人社会网络站点用户和64%的年轻社会网络站点用户使用了这些应用。虽然他们的参与到底能为品牌转化来多少实际价值，尚无明确数据，但无论什么样的价值，都只能通过有效设计、易于使用和理解的品牌推广应用来实现这一点，应该没有多大争议。

作者简介
Roland有近20年的市场营销和广告行业经验，曾在Saatchi、Saatchi和 Grey Worldwide等公司工作，目前是Gyro:HSR公司总经理，为Hewlett-Packard, VMware, Cisco, SanDisk, McAfee, Macrovision, Experian等很多客户制定和执行实施全球整合营销和广告策略。此外，Roland还是移动和社会化营销方面的专家，为Adidas、 MySpace、Atlantic Records等很多在发行、社会媒体、内容空间的领头企业创立并实施了viral and branded applications。Roland拥有哥伦比亚商学院、加州大学伯克利分校商学院的学位，和宾夕法尼亚州立大学肄业学位。

阅读英文原文：Best practices for branded application design。

在我们所有的对手中，最强大的是时间。面对时间，我们丝毫没有欺骗的机会，时间一分一秒的流逝，最终的胜利者总是时间。我们经常会觉得“哦，两天过去了，任务丝毫没有进展，明天就是截止日期了，该怎么办？”我们经常忙于应付一个接一个的任务，没有时间去学习充电，享受生活，并由此陷入很大的焦虑情绪。随着社会不断发展，工业文明极大地丰富了人际间的交流手段以及获取信息的手段，我们的时间利用效率却变得越来越低了。沉下心思专心做一件事情，对绝大多数人来说已经变成一件不可能的任务。究其原因，主要有两个：

• 干扰太多。人们不能专心把一件事情做完后，再去做另一件事情。经常是正在全神贯注工作的你，突然收到一封邮件，接着放下手头的事情，回邮件。发出邮件后，切换回原来任务。每一次任务切换，往往要花更多的时间完成原来的任务。（平均每次切换要使原任务增加25%的时间。引用3、 4）。设想一下，很多人一天要查看邮件50次、100次，还有MSN、电话等等。
• 缺少明确的目标和优先级。所有时间都在应付紧急任务，不停地救火。这些紧急任务可能来自于老板、团队其他成员也可能来自于家人、朋友。为了应付新的紧急任务，经常要放下手头工作，在完成新任务过程中又出现中断，最终在不停的任务中断和切换中迷失了方向。一天下来不知道忙了些什么。

排除干扰，确保首先完成最高优先级的任务，是提高个人时间利用效率必须解决的问题。这与敏捷软件开发（Scrum、XP、Lean）要解决的问题何其相似。针对软件开发中的类似问题，九十年代起Ken Schwaber、Jeff Sutherland、Kent Beck、Martin Fowler等大师们提出的敏捷开发解决方案，其中包括时间箱、不受干扰的迭代、具有优先级的代办任务列表、拉动（Pull）任务、承诺、计划与反省等等。无独有偶，从九十年代初开始，意大利人Francesco Cirillo也基于相同的策略设计并发展了番茄技术（The Pomodoro Technique，Pomodoro意大利语“番茄”）来管理我们的个人时间。用到的工具很简单，一个厨房定时器（Pomodoro Timer），三个简单表格（当天任务列表 To-Do，任务清单Activity Inventory和记录历史数据的表格Records）。

番茄时段

在敏捷开发中一个迭代的周期通常是一到四周，番茄技术的一个迭代是25分钟，称为一个番茄时段。跟敏捷开发的迭代类似，在一个番茄时段开始时需要从当天任务列表中找出目前最高优先级的任务，然后不受干扰地去完成该项任务，一直到定时器的铃声响起。每个时段结束后可以有三五分钟时间自由支配，然后再开始新一个时段。在敏捷开发的迭代过程中，团队只会集中精力完成当前迭代中的任务，不会对新的任务需求做出响应，所有的新任务都放到产品 Backlog。在番茄时段中，个人也是采用相同的策略，在紧急情况下，新的任务会放到当天任务列表，作为一个当天的一个未计划任务；而一般的任务，只需要在任务清单上加一个新的任务项目。然后不受干扰地继续当前的工作。即使任务完成时，定时器还没有响，处理方法也很简单，用剩余的时间去“重构”完成的任务，使它更好一点儿。

工作日程表

以下以一个使用番茄技术的程序员的工作日程表为例。

在这个日程表很好地融入了戴明环PDCA（计划Plan；执行Do；检查Check；纠正Act）。每一天总是从计划番茄时段开始，最后一个番茄时段以分析反省结束。每天的历史记录一般包括计划执行情况、未计划任务情况、估计与实际，干扰次数，干扰内容等等。通过这些历史数据我们可以很容易地观察自己：

• 计划执行是否有效
• 估计是否准确，偏差有多少
• 未计划任务有多少，分别做什么
• 工作中的干扰多不多，主要干扰有哪些

通过切实的数据对自己的时间利用情况有了清晰的了解后，我们就可以在反省中有针对性地设计解决方案。如此不断反复时间效率就会不断得到提高。

消除干扰

番茄技术最大的好处是能够帮我们集中精力，消除干扰。每个番茄时段只有25分钟，除非是十分紧急的情况，一般情况下都是可以在完成当前时段后再去响应。通常我们会遇到两种干扰：

• 内部干扰，主要是自己想做某些事情，比如喝水、查邮件、网上聊天、上网等等。针对内部干扰，主要有两种解决方法，第一种就是有针对性的计划一些处理这种任务番茄时段，比如上面日程表中的专门用来处理邮件的时段；另外一种方法就是利用番茄时段之外的时间，比如那些自由支配的时间以及午饭时间。
• 外部干扰，比如电话、同事来问问题等。与内部干扰不同，外部干扰需要与其它人打交道，因此需要采用不同的策略。具体策略是“通知Inform，商量Negotiate，晚些时候响应Call Back”。可以用留言机接电话，邮件也可以暂时放到收件箱中稍后处理。如果有人当面过来，可以告诉他：“我先忙完手头工作，二十分钟后去找你。”，然后继续手头的工作。晚25分钟或者一两个小时对通常意义上的紧急任务来说，是可以接受的。对对方来说需要等待25分钟可能不是什么很大的问题，但是对自身来说却有极大的意义，我可以继续专心把我手头上最重要的事情。当然很难避免的，也会出现不得不取消当前番茄时段，着手处理十分紧急的任务的情况，这其实跟在 Scrum中取消当前Sprint一样，只有万不得已才会为之。

每当有干扰的时候，都要在每日任务列表上做一下标记，如果需要，同时在每日任务列表（如果是紧急任务）和任务列表上填加一个未计划任务。把干扰放入任务列表使得我们有机会重新思考一下每一个任务是否那么重要，是否真的需要，很可能过了一段时间我们任务列表上的很多任务变得不必要了。另外，所有的干扰都被显式地标记在每日代办任务列表和历史记录表上。每天都可以反思每天的干扰次数以及内容。干扰数据能够是我们更有意识地关注时间效率的问题，促使我们通过重新计划，调整策略等等方式把干扰降到最低。比如对于电话太多的情况的一个有效的策略是，每天应该固定一段时间把电话放到留言，到会议室去办公，然后告诉其他同事，在紧急情况在哪里能够找到自己。而对于邮件太多的情况，可以多安排几个番茄时段集中处理邮件。

任务计划与估计

番茄技术的另一个好处是给我们提供了一种全新的估计和计划的手段。在任务列表上的每个任务都需要有一个规模估计值，这个值其实是标明完成该任务需要花的番茄时段的数目。由于每个时段都是不受干扰的“纯”投入的时间，因此可以通过番茄时段数目有效地把任务的规模与时间建立联系。通过把实际花费的番茄时段数目与估计值相比较，分析，可以帮助提高自身的估计能力。同时，通过分析历史记录中非计划任务的数目以及内容，也可以帮助我们对自身的时间利用情况有更好的了解，从而更有助于计划个人的时间。

转变时间的观念

番茄技术能够改变我们对时间的态度。时间变成了一个个番茄时段。每一段25分钟，滴答滴答从25分钟减到0。从而给我们一种紧迫感(Eustress)，督促我们尽快完成任务，尽快做决定，从而有效的提高效率。效率的提高能够有效地提升自信心和成就感。

关于番茄技术的详细介绍可以参见它的网站（引用1）以及The Pragmatic Bookshelf的新书《Pomodoro Technique Illustrated》。

引用

1. The Podomoro Technique
2. The Pompatus of Pomodoro, PragPub Issue #5, November 2009
3. Manage Your Effort Not Your Time, Harvard Business Review, October 2007
4. Perfection: An Unrealistic Goal – The Challenge of Being Agile

作者简介：滕振宇（Daniel Teng），Irdeto BSS高级软件经理，CSP，敏捷教练。创建并领导Irdeto BSS上海研发团队，负责大型付费媒体计费以及客户管理系统软件产品的开发。

概要
近日InfoQ有幸独家专访了微软Visual Studio Business Applications团队的总经理潘正磊，与她探讨了微软研发团队管理的相关问题：技术人员的职业发展、如何培养接班人、如何管理不同规模的研发团队等等。

个人简介
潘正磊女士是位于美国雷德蒙市的Visual Studio Business Applications团队的总经理。这个团队通过提供多种工具，使全球开发人员能便捷地在微软平台上搭建商业应用程序。她同时领导开发工具部门的中国研发团队，进行Visual Studio、Visual Studio Team System等产品和技术的全球研发工作。92年，她以软件开发员的身份加盟微软，参与Access、Visual InterDev等产品的开发。1998年至2006年间，她先后担任Visual Basic.NET开发经理、Visual Studio产品线开发总监、Visual Studio Team Architect产品总经理和Visual Basic产品总经理，为专业开发人员提供在.NET平台上最高效的开发工具，使数百万Visual Basic 6.0用户迁移到.NET平台。

先给我们介绍一下你自己和你自己现在所做的事情吧？

我是在1992年大学一毕业就参加了微软，一开始是做开发程序员，就是Developer，最开始开发的项目是Microsoft Access，现在也是微软卖的很好的一款产品。在Access开发了几年之后，我转做另外一个产品叫Visual
Interdev，那是我们微软第一款针对网络Web做的开发工具；那之后我在Visual Basic团队做Developer Manager，就是开发经理的职位，当时我们整个从VB6到VB.NET
转型，所以跟.NET做平台开发，是一个非常艰苦的项目。之后还在Visual Studio里做了一系列的职务，包括开发总监，包括我们Visual Studio Team
Architect的产品总经理，包括Visual Basic的产品总经理。现在是Visual Studio Applications的产品总经理，像我们刚才所说的，主要我们这个团队做的是针对企业的开发工具。

你是从一个基层的开发人员一直走到现在，那我想，在你整个过程中应该是有很多的感触，特别是从一个开发人员然后到一个管理职位，在整个过程中有没有什么比较难忘的事情？

因为已经工作十几年了，所以说，确实有很多故事了，我觉得比较难忘的几个故事，还是跟我们最高层打交道的时候比较有趣。我们在做Visual Interdev的时候，那是我们第一款针对Web的产品，当时微软对Web的定义、对Internet的战略不是非常清晰。记得我们跟Bill
Gates在做产品Review时候，他一开始对我们这个产品是有些意见的。他说，你这个产品做出来以后，对Windows有什么好处或者是坏处。这是一个挺尖锐的问题，让我们所有人回去都要好好想一想。

还有最近我们在做另外一款产品Review的时候，也是跟我们Steve Ballmer，我们的CEO，跑上来我就要给他做一个演示Demo，我们的CEO就说现在所有演示都不要做，他叫我们最资深的副总裁，“你就到黑板上面去，把你们这个产品要做出来的三个目标先给我写上去，写完以后我们再做演示，看你这演示有没有达到你这三个目标”，这个跟Steve
Ballmer做Review常常会碰到这种情况。

他会直接帮你梳理你的产品目标？

他会用你很意料不到的方法来问你，因为一般我们去做这种总裁Review都是有准备好一套PowerPoint，有一套我们自己的思路，他就会从你的思路之外问一些问题，保证你确实能够解释出来你为什么要做这个东西，然后你的思路是什么，你的战略是什么，这是一些蛮有挑战性的东西。

在你的个人从开发人员到一个团队管理的过程中，在做团队管理的时候有没有遇到一些困难、一些比较难忘的事情？

做团队管理的时候，因为团队管理最主要的是几大块：第一，你要造就一个非常强的团队。这中间有很多（差异），你这团队是你自己接手的，还是这个团队是你自己一个一个雇佣进来，这个完全是不同的。还有和你的Partner（合作）团队，因为微软很多项目需要好多几个团队来一起合做才能做好，那跟你Partner的这个运行过程中也有很多的这种Interaction（互动），有的时候如果大家的战略目标不一样，就会造成很多各种各样的问题，那所以这都是有很多故事的。我现在一下想不出来一个特别好的、最有挑战的。因为从组建团队中，这么多年走过来，基本上什么场景都碰到过了，所以我还真一下想不出来一个最好的故事，或者是说最有挑战性的故事。

其实我也了解到在你整个的发展过程中，到最后成为全球微软有两千多个总经理，你是为数不多的华人，那么从整个阶段来看，你是如何去总结自己的这段历史？

我觉得微软现在华人的总经理比较少，但是我觉得从长远来说肯定会越来越多，这实际上是我们在九几年有大量的大学毕业生开始出国，然后开始在美国，或者这种（国外的）地方开始就业有关。我相对来说出国比较早一些，所以我进微软也很早。那像九几年之后，95、96，包括90年代末期，有大批的中国员工进入微软，所以我相信这以后的华人工程师或者华人总经理，各方面只会越来越多。那另一方面，在微软或者是在很多大企业里，自己的一步一步都是要慢慢走过来，然后都是要脚踏实地，最主要的是要想到说你对这个团队有什么贡献，你对你的客户有什么贡献，如果能够比较的专注于某方面工作的话，那我觉得在成长中是很有好处的。

进入微软的华人很多，工程师也很多，但我想也淘汰了很多，最终可能会有一个人冒上来，而且这个人就是你，我想问一个比较直接的问题，你觉得为什么会是你走到今天这个位置？

我觉得每个人的长处是不太一样的，我觉得我自己的长处，第一是技术方面还不错，因为一开始在做工程师，如果你技术上面做不好，是不可能往上走的。另一方面，我觉得我对资源整合这一方面是比较强的，我的一个强项是我很快就能看出我下面的员工他们最适合什么，他们不太适合什么，那把他们放在最适合于他们的工作岗位上。这样第一能够是最大的调动他们的积极性，第二整个团队可以成一个非常高效的团队。

而且我在管理人员方面，很多跟我做了很多年的员工，愿意跟我做很多年，所以这也是作为一个领导者应该比较重要的素质。

我觉得是这些是可以学的，但有些可能有的人就会比较容易一些，比较自然一些，有的人可能就是要学的更多一些。

但是我想在你的团队里面应该也有一些能力非常强的，比如说他的存在会让你有所威胁，那么在这种情况之下，你是如何和他们相处的？

你看，我这个考虑思路跟你完全不一样，我不会觉得我团队里面有谁对我是有所威胁的，我的出发点就是我希望能够培养一批人才，如果有一天我能够不用去上班了，而且我的团队还可以执行得非常好，这才是我的目标，所以我是希望有人能够来代替我。

因为微软里面包括很多公司是这样的，有挑战性的工作是非常多的，如果我这个工作做完了，如果我下面培养出一批人才，能够取代于我的话，那还有更加具有挑战性的工作在等着我去做，所以这个思路不是说有这个人会对我造成危险性，而是我如果有一天能够找到一个，或者请到一个比我更强的员工，这是一个非常高兴的事情，非常令人振奋的事情。

实际上在我的职业生涯中也确实有过这样的经历，我那时候在做Visual Basic开发经理的时候怀孕了，我知道会休蛮长的产假，而且一度还动过可能不回来上班的想法，做全职妈妈的这种心思，所以我那时候就把我下面的一个开发主管，一个开发主管一直培养他，而且当时就是培养他到最后，我去休假之前，说那这个团队就交给你了。等我五个月休完产假回来之后一看，那个团队虽然是我打造的，交给他之后他还是管理的非常好。我说太好了，那你就来做开发经理。那个时候我就去做了我们Division另外一个工作，整个部门的开发总监。

就像我说的，这世界需要能人的事情非常的多，所以你是一个能干的人你不要有这种危险感，因为需要你的地方是非常多的。

所以我想，一个人的自信对于他的整个的成长是非常有帮助的？

实际上我觉得如果在微软来说，如果你没有自信，那你可能很难从一个开发工程师往上走非常的远。因为在微软我们招的都是，真的是世界上英文词叫“cream of the
crop”，都是最最顶尖的大学生，或者是外面有经验的人。在这样一种环境中，你怎么样能够跟大家交流，怎么样可以说服大家同意你的观点，怎么样听取别人的反馈，自信心实际上是一个非常基本的素质。如果你没有这个素质，就是作为一般的开发工程师也不会走的太远的。

另外我比较好奇的一点，比如说在你整个的几个阶段里面：有基本的开发人员，然后到一个比如说项目经理、一个产品的带头人，然后再成为一个产品的总监，最后成为总经理，那么这几个段它有什么特别的不同吗，除了你管理的人越来越多？

那是有非常大的不同的。作为一个开发工程师来说，你最主要的是要把你的代码写得越快越多越好。因为你对产品的贡献是鉴于你代码的数量，你写代码数量直接就反映成你对这个产品功能多少的体现，你的代码行写得多，那这个功能才增加得多，你写的代码行是最难的那部分，那才说明你对这个产品最主要的核心部分有贡献，这是作为开发工程师。

作为一个开发主管来说，就是我们叫Development Lead，第一方面，作为管理者，你对这个团队的价值，不仅仅是说你自己写了多少行代码，这相对来说是比较少的，最主要是你这个团队对整个产品的贡献是什么，那还是基于你这个开发的功能有多少，然后你这个功能是不是做得好，你架构是不是做得好，但是你的核心价值是把你这些资源都组合起来，然后能够帮助你团队的员工扫平障碍，让他们非常顺利地开发。

像我最开始做管理的时候，我只管理了三个员工，有一个员工如果做得慢一点，那我最多周末去加一加班，他没有做完帮他补做完就完成了，我觉得相当简单的一件事情。等我那个团队长到10个人的时候，你就发现，第一，不可能我周末再来加班，也不可能把10个人里面有两三个人可能要做的慢一点，如果按同样的比例来说，我不可能把这两三个人要做的东西都做完了。那这个时候你要做，就是我们从这个Skill来说，如果要整个团队都能够非常顺利高效，你就要想“我怎么样让这十个人互相之间能够（协调好）”，就是很多程序是有顺序的问题，把顺序问题安排好，有些东西可能要需要一些决定，尽早的把决定做好，下面的架构可以做好，跟其他团队的关系要搞好，因为他们可能有些东西要拿来，他们先做完之后我们才能做，所以有很多东西Dependency
Management，这些东西全部都要管理好，就像造房子，管理一个项目一样。这样管理好你这十个人才能都是马不停蹄、非常高效地把这个东西做好。

等你做开发经理的时候，开发经理因为不是一个第一线的管理者，而是第二线的管理者，这个时候最最有挑战性可能是，你很多东西要通过你第一线的开发主管传达到下面去，如果你开发主管对你说的话不认可，那你的观念、决定不一定真正能够传达到最下面的开发人员。而且你下面的开发主管可能每个人都还要管一摊不同的东西，你怎么样让他们之间能够互相配合、互相合作，从一个大局上面来看你整个这个开发团队缺什么，有的时候他们开发主管在那里面做，他不一定会知道说，我实际上比较缺一个真正能帮我把这个架构搞在一起的人，或者一个特别懂客户的人，那要把这个全部都想清楚，真正打造一个非常强的团队，这又是另外一套的艺术，我觉得。

在微软如果你不懂这产品（技术），你是没有办法做一个合格管理者的，你不仅要做人员的管理者，你还要做这个产品的定义，而且还要跟你的团队交流，什么地方是应该做的，什么地方是不应该做的。

是多重角色了？

对，因为从开发经理来说，我在美国喜欢说三个P，你要管理产品（Product），你要管理人员（People），你还要管理流程（Process），这三样东西都要抓起来，你才能作为一个合格的开发经理，然后让整个团队都能高效地运行。

他和现在的总经理有很大的区别吗？

非常大的区别，因为从开发经理来说，他还只是主要是管开发团队的。开发团队总的来说只是占了可能是1/3。总经理跟产品经理是两个不同的概念，产品经理是说你管一个产品，那总经理你是管多种产品，像我刚才所说的，实际上我现在这个组里面有三种不同的产品。

那这三种不同产品很多时候会有不同的进度表，发布时间会不一样。怎么样把里面相同的东西能够整合出来，让大家最有效地利用，而且还要针对每一个产品有他特别的开发。怎么样管理这一套产品线，而且跟我们的市场部，跟我们的营销部，跟我们的DPE（开发工具及平台事业部），那些合作都是在这个层面上面是完全不同的。而且在这上面你就更要想说，这几个产品，就像我们叫Portfolio（投资组合），就好像如果你要是投资，你可能有些放风险基金，有些放银行存款，有些是放外汇，你还要再从比较高的角度上，看你每一个产品到底里面放多少的资源进去，为什么这个产品放这么多资源，而且要看你成功的定义是什么。

而做一个产品的开发经理，这么多资源实际上已经分配给你的，你在这个资源的基础上面把它做到最大最好，所以这还是不同的概念。

更加强调统筹的作用，那我们回到技术层面来讲，在你的身上可以看到一个，我认为他是微软一个研发团队的技术变迁史，或者一个缩影。那么我想问的问题是，在你的理解当中，从你进入微软研发团队一直到现在，在整个的产品的开发过程中，主要经历了哪几个比较重大的阶段？

我觉得这个问题非常好，因为你让我回想了一下。确实有几个非常大的不同（阶段）。

在我进微软的时候还是微软比较新，很多产品还是刚刚第一代，像我那时候做Microsoft Access，现在已经无穷代了。那时候刚刚是第一版，当时发布时非常振奋人心的。如果打一个比喻，就比较像我们80年代刚刚开放的时候，那时候商品比较少，用计算机的人数少，相对来说需求也少。所以那个时候从微软来说，只要发布产品就会有很多的用户来使用。因为我们有很多很基本的需求，而市场上却都没有。那我们发布的产品只要大面上不错的话，就可以非常容易地满足用户的需求。从Word第一版开始发行的时候，前面几版你可以想有很多很多基本的功能是，现在觉得都是肯定是应该有的，但是当时都是很新的东西。

但是产品在做了时间久了之后，等你发布第五版、第六版、第七版、第八版的时候，这时有很多基本的用户需求已经满足了，在那个前提上怎么样把你的产品更上一层楼，这实际上就变成一个相对来说比较困难的问题。很多时候，像我们的Office团队最大竞争者不是别人，是前面一个版本的Office。所以在一开始我觉得我们在微软里边定义产品的时候，比方说90年代初，跟客户沟通之后我们就是用一个Waterfall（瀑布式开发模式）这种Model，因为我们觉得我们知道这个产品应该做什么，我们就把它做完了，然后放在外面市场上，相对来说一定是卖得不错的，卖得很好的，所以这是我们比较成功的一个模式。

自己可以主导？

当然我们还是要跟客户有反馈，一开始要跟客户研究，但是我觉得相对来说做得少，而且相对来说比较容易满足客户的需求。因为那时候大家的基本需求有很多都没有满足。等到我觉得差不多就是99年、2000年，就是差不多那个阶段，我们那时候很多产品已经开发了好几代了，等到那个时候我们就有一个危机，因为我记得是差不多是2000年的时候，那时候客户对我们的满意度相对来说比较低，而且我们跟合作伙伴的关系相对来说比较僵一点，在美国还有很多的诉讼案，那个时候我觉得实际上是微软处于一个比较低潮的阶段。但是从那之后，我们确实就开始转型了，我觉得一个最基本的理念，我自己有这个感受，一开始就觉得说我们可以定义这个产品，定义了以后就做，做完以后卖，这是我们最开始的运营模式。

大概是2000年之后，我们就发现对用户反馈的需求变得非常多，而且一个版本一开始跟用户反馈一次是远远不够的。从开发模式来说，开始时我知道什么是对的，我知道用户需要什么，我只要开发什么，这是我们本来的模式。在那之后，我们的模式时我不太确定用户确实需要的是什么，我们可能要先做一些prototype，试验品出来，让用户去体验一下，体验完了以后再给我们反馈，这是不是他们确实要的，我们在这个反馈基础上再更改。所以你可以看出来整个流程，一开始的想法跟后来想法是不太一样的，而且我们在2000年以后，在后面的开发中，对用户的反馈的需求比以前是大大增加了，而且我们fundamental
mindset（最基本的理念），从一开始我绝对知道什么样是一个对的产品，到我不太确定，那我需要跟用户多次反馈，才能知道真正什么是对的产品，那这两个其实是非常不一样的开发模式。我们之后开始用这种开发模式之后，因为微软作为一个很大的团队，确实也碰到很多的挑战，因为很多时候你要想改一点东西实际上是非常难的。

涉及到方方面面。
alt="" />

方方面面，我就喜欢说，像你要是自己想在家里后院造一个小房子，你怎么改都没有关系。但是你要想造金茂大厦，造到一半想改一点什么东西，那你可以想到有很多的东西要配合。你如果要改一点东西，那对你的电梯、电路、楼层、重量，都有很多的考虑因素在里面。

那作为一个大的开发团队，你怎么样能够同时满足客户的需求，又能够在你的架构基础上能够做这种改动。因为最后你的产品还是要满足客户需求，才能够有卖点。你怎么样做这么一个调整，这也是我们在前七、八年中慢慢转型的过程。那相反过来，你如果看，拿我们Visual
Studio作为一个例子，从08年，我们前面几个例子看到我们开始大量的出我们叫CTP（Community Technology Preview，社区技术预览版），而且跟我们的客户、开发人员的交流变得非常的透明，很多时候我们很早就把我们想做什么，愿意做什么，有的时候把我们写的Spec，就是产品定义放在网上，给我们的MVP（微软最有价值专家）先让他们反馈，我们现在做很多这样的工作，在这之前都是没有的。

对于你们内部的开发团队来讲，产品的设计方面是有很大的挑战，也是一种很大的转型。那么你们在自己做开发的过程中是不是也有一些分为几个阶段来呢？

对！如果是按以前的开发模式，那你可以想到我们更多的是这种，我们现在决定要做这些feature（功能），这些功能需要这样这样，那就是一条线做下来，最后把它发布就可以了。

就像瀑布模型一样的？

对。如果你要是想象做的功能可能需要在做的过程中调整的话，你中间的每一个开发阶段，就要设计一个跟用户反馈的过程，然后真正把那反馈拿回来，然后在下面一个过程中做调整。同时你还不能把你的那个发布日期改动的太多，所以你就可以看到这个难度实际上是增加了很多。

在每一个改变的环节上，根据刚才我们的交流，他应该是客户来进行推动的。那还有一个问题是，在什么时候你们认为这是一个改变的时机，认为这个开发模式应该改变了，这个产品设计的模式应该改变了，你们做决定的时候，有没有某一个观点来刺激着你们去做这种改变呢？

没有，因为微软很多事情不是Top-Down，不是从上面这么Drive（推动）下来的。第一，从管理层来说，我们比较注重抓的是用户的满意度，看他的满意度如何，就能体现我们跟他一开始交流的够不够。另一方面，比方说我们这个产品真正是有多少用户反馈，而且是把这些反馈做到了产品里面去，这也是我们可以衡量的、量化的。而且很多时候微软有一个团队开始做一个比较好的模式，那其他团队会说，这个模式不错，他也开始借鉴。所以我们这个转型也是慢慢转型，不是说一下子，整个全部团队开始转型，不是这么一个过程。

可能是某一个团队他先采用了某一种方法，然后其他团队开始慢慢的效仿，应该从底下往上推？然后从小到大这么一种方式？

说的非常对，因为我们不是Top-Down。从上面管理来说，你要抓的是最后的那个结果，你想看到的结果是什么，那么你鼓励下面团队去实验不同的方法能够达到这个结果，有的试验可能比较成功，有的试验可能不是很成功，那么你再把成功的这种方法，然后再在其他团队里面推广，一般多半都是使用这种模式比较多。

微软的高层他不会认为就是，OK了，所有的开发团队应该采用这么一种统一的开发方法来去做，他没有这么一种强制的要求吗？

绝对没有，因为微软的产品线非常的长，有各种各样的产品。开发方式实际上就是我们说的Process（流程），很多时候根据你这个产品不一样，各方面会不一样的。那我对Process理解是这样，就说Process是应该帮助你的开发更有效、更快，很多时候我们觉得Process非常烦琐，时间上会让你慢下来，实际上这个不是它的（目的），它就是没有达到要求。用另外一个比喻，其实像我们来的路上都是有很多红绿灯，有的地方是有那种转盘。像美国还有一种就是叫Four-Way
Stop（四向停车），就是你到那边停下来看看左边、右边有没有车，没有车就可以通过。那他实际上都是不同的管理交通方式，管理这个车流量的一种方法，根据不同的地点，你要选择最适合地点的一种方法，有的地方如果车流量不是很大，用这个Four-Way
Stop就可以了，有的地方可能有六、七个不同的出口，那用转盘是最合理的。有的地方，在美国比方说有的地方你停了电，本来有红绿灯的地方，你停了电就变成了Four-Way
Stop，那时这个地方一定是堵车堵得不得了，因为红绿灯可以帮助流量的增加。

开发的管理方法也是非常类似的，根据不同的项目你要选择对你来说比较合适的方法。如果是一个比较小的项目，你用一个heavy weight(重量级)的方法那就是不合适的。这是为什么微软不会从上面说你一定要用什么样的方法，他考核得是你最后那刻做出来的结果，你的结果是怎么样，能不能在你所承诺的时间里面把东西做出来，你做出来东西用户是不是认可，你做出来的东西后面是不是有很多质量问题，还是说很好用。你在做下面一个版本的时候，就可以反映出你前面做的架构好不好。如果你前面做架构延伸性非常差，你第二个版本相对来说就会多花时间，因为要把前面重新（改造）。

遇到很多兼容性的问题？

对，所以这种才是比较硬性的考核标准，那下面用什么样的方式，你自己应该去选一个对你团队来说最合适的方式。

那我们再具体一点，就是你作为一个开发团队的负责人，肯定在整个的团队管理生涯当中，采用了很多新的技术，很多的新的开发方法，那你是有一种什么样的观点来评估这个技术、这个方法是不是应该用在自己的团队里面？

一般还是看结果。我本人是比较愿意去试验新的方法，我会让一个feature crew (功能小组)去试验这个方法。然后给他一段时间，他来给我反馈，这个不管是方法还是新的工具，他有什么优点，他有什么缺点，因为很多时候你想是想不出来，你还一定要去试，试了之后才知道它到底是好用还是不好用，它什么地方好，什么地方不好，就跟车一样，你得要去试开一下。然后在这之后，根据他的好处跟坏处，你还再可以跟现有的方法再看，再评估一下，你是把它全盘拿过来呢，还是把它改动之后再引用，或者有没有什么办法把它好的地方能够结合到现有的方法之中，不好的地方把它抛开不用。

你每换一个开发工具，或者是每换一个开发流程，尤其是团队大了，相对来说实际上是一个比较难的事情。因为你对整个开发、测试，还有工程师，你都要进行一个训练的过程。所以一般来说，我并不鼓励有什么是最热门的，我们都来试一下，因为这个是不太可能达到效果的。很多时候如果一个新的办法在推行之中，大家对这个方法不熟悉，很多时候员工也会有抵触情绪。因为我本来这个用的很好，我也知道怎么用，它里面好的、坏的我都知道了。那现在你如果是一个新的东西，我对它第一不知道，第二没有感觉，然后第三现在我就是不知道怎么跟大家合作，那一开始可能会有生产效率的这种降低。所以从这种方面来说你都要考虑进去，尤其是团队大的话，有的时候是在现有方法之上，说哪些是一定要改动的，哪些是不能改动的，那很重要一方面就是把这个理念，你为什么要改，你不是教你这个团队方法，你要把你想最关键解决的这个问题，为什么你要做这个改动，你现有方法你觉得最最不好的问题是什么，你要把这个问题跟团队讲清楚。那团队在理解了这个东西而且他也认可的情况下，比方说我们以前的开发方法是假设我们知道用户需要什么的，我们现在开发方法是假设我们并不完全知道用户需要什么的。这是一个非常基本的理念不同，你把这个要跟团队讲清楚，那他真正能够明白体会了这个问题之后，那再接下来他会和你一起改进他的工作方法。

工作方法不是我来改进的，是我的团队来改进的。因为他在日常工作（开发、测试）中发现了问题，发现什么是更好的解决方案，他要有这种主观能动性，他要明白我想解决的问题是什么，他才能够主动帮我来想更好的解决方法。那想出解决方法之后，我们大家再分享，一般都是这样。

很多可能都是从底下往上冒出来的？

绝大多数。因为我每天不在那里做开发，我不可能知道什么是最好的解决方案，确实要每天在做的人才会在他做的过程中发现说，我们这个地方好像浪费了很多时间，我们有没有什么好的方法把它给解决一下。他如果是这个涉及比较广，他会跟我们有一个汇报的过程，因为他可能会问我要资源，或者要其他的东西，那在这个时候我会给一些比较方向性的东西：这个问题我早就知道了，但是我现在决定不解决，因为可能有其他的方方面面的原因，所以我不解决；或者说这个想法非常好，我给你资源，你去给我做一个试验原型出来，然后我们再来看一下，这是非常常见的。

那我想作为一个比较成功的技术研发团队的管理者，给我们其他团队的负责人，如果提三点建议有没有什么好的建议？

我觉得对中国团队来说，有些是不是适合国情我就不知道了，但是我先说一下三点建议：

第一，就是真正的要有这种自信心，要去培养你的接班人。而且是不仅是你要培养你的接班人，每一个重要的职位下面都要有一个接班人，而且这个需要和你重要职位的人一起在培养，因为这是打造一个长久的成功的团队非常重要的一点。因为你没有这种传帮带的话，那你这个团队也许是现在可以把这个产品做出来，如果你们有重要人员离职之后，你还能不能是一个成功的团队，这是一个非常重要一点。

第二点，你怎么样能够调动员工最大的积极性，而且我觉得有的时候中国的员工不够主动，你让他做他会做得非常好，但是你不跟他说的事情，他也许就不做。这个我看得比较多，不管在美国和中国的华人员工里面都是比较常见的一个问题。作为一个管理者，你怎么样能够让他能够非常主动把问题告诉你，而且把解决方案也告诉你，这个是从微软文化上面来说是非常重要的一件事情。

第三个方面，从微软来说是人脑加电脑，从我们做IT来说是人脑加电脑，那实际上最主要的还是人脑，那你是不是真的培养员工，真正是让员工在你团队里的重要性充分的发挥了出来，只有在这个时候员工才认可你的管理的方式，才能认可他是这个团队的一员，才能想到怎么样在这个团队里面发挥最大的重要的作用，那这也是我觉得开发管理者应该多思考的问题，和多做的事情。

还有没有其他想和我们读者做分享的呢？

我觉得我们中国IT员工，从IQ上面来说非常的高。而且尤其从钻研角度来说，也是非常（努力），真的是。我们在微软自己就觉得我们在中国招的大学生素质，比我们在美国招的大学生素质要高，真的是从那个IQ上面来说。

但是，我觉得有一些可能文化上面的东西，可能会限制这些员工的发展。我看到比较多的是，有的时候员工他们碰到一个问题，我觉得可能是考试考太多了，他们看到一个问题，他们不太会去跟旁边的人，一起跟周围的团队里面的人，或者跟美国团队人一起交流，一起想最好的解决方案，能够把大家不同的观点整合起来。很多的时候看到他们自己在非常辛苦地在干。那苦干之后真的是做出来成果就说，你有没有考虑到一二三四五六，那你有没有跟这个人这个人去谈过，好像这方面做得相对来说比较差一点。因为我觉得我们考试的模式就说你不能问别人，你都要自己解决。

我们在工作中都是，你不可能一个人把方方面面都考虑全，这是不可能的。所以你一定要跟你团队里面的人搞好关系，一定要把团队里面帮你一起想这个问题，还有什么其他的观点，而且能够非常坦然的把这个观点结合到你的解决方案中去，那我觉得这方面相对来说就是相对弱一点。而且就是这种主动性比较差，如果你没有跟他说要做什么事情，你交代的我都做好了就完了。那这两方面我觉得中国员工需要想一想怎么样加强的地方。

感谢您接受我们的采访。

谢谢！