品牌推廣應用設計的最佳實踐

精選優(yōu)質(zhì)文檔-----傾情為你奉上精選優(yōu)質(zhì)文檔-----傾情為你奉上專心---專注---專業(yè)專心---專注---專業(yè)精選優(yōu)質(zhì)文檔-----傾情為你奉上專心---專注---專業(yè)品牌推廣應用設計的最佳實踐

作者RolandDeal譯者羅小平發(fā)布于2010年1月3日下午8時12分社區(qū)Architecture主題設計,RIA,商業(yè)標簽Adobe,最佳實踐,Flash

為了提升自己品牌或產(chǎn)品的知名度，你可能決定開發(fā)一個品牌推廣應用（brandedapplication，有時候也代指一個widget）?；蛟S你已經(jīng)讀過相關文章、看過相關新聞，甚至自己就已經(jīng)玩過幾個品牌推廣應用?，F(xiàn)在已經(jīng)決策要開發(fā)并準備了預算，找好了開發(fā)和實現(xiàn)品牌推廣應用以吸引用戶所需的資源。萬事俱備，只欠回答一個問題了：如何才能做出一個真正有效果的品牌推廣應用？什么該做，什么不該做？是否有別人已經(jīng)證明過的經(jīng)驗或規(guī)律可以依循呢？對于大多數(shù)商家而言，品牌推廣應用還是一個相對陌生的策略。因此著手之初，幾乎找不到業(yè)已存在的標準。沒有什么規(guī)則可以告訴他們?nèi)绾伪苊鈫栴}、在哪里優(yōu)化。而且，品牌推廣應用本質(zhì)上是個迷你應用，可以完成任何天才和頗具創(chuàng)造力的AdobeFlash開發(fā)人員所能想到的任何事情，包含各種功能、特性、品牌要素、市場信息等內(nèi)容。愛因斯坦曾指出：“一起都應該盡可能簡單，直到不能再簡單為止”，這是設計一個有效的品牌推廣應用的基本原則。有時候，事物簡化本身就是件非常困難的事情，但毫無疑問它對最終成功有最大貢獻。本文提出SIMPLE設計方法，并對其包含的每項元素（simplicity、intuitiveness、message、personalization、layout和engagement）逐一分析，幫助大家記憶并在自己的品牌推廣應用設計中應用這些最佳方案。

設計概述

在分析SIMPLE設計原則之前，請記住這樣一句話：優(yōu)異的、有創(chuàng)意的方案來源于目標、計劃和市場背景的清晰把握。品牌推廣應用的設計者要明確知道應用的目標，因為它的背后是更大的廣告和營銷活動。應用是為了傳遞品牌信息？是為了通過特性、優(yōu)點展示良好的品牌體驗？支持真實交互么（比如下載音樂、自定義頭像）？在將任何資源引入到設計之前，確定這些問題并得到重要決策人的支持，是至關重要的。和任何廣告活動一樣，用戶和目標的清晰，對品牌推廣應用的成功實現(xiàn)是非常重要的。誰是目標用戶？價值主張是否明確？品牌推廣應用應該滿足用戶的某種需求，如娛樂、自我展示，或幫助用戶實現(xiàn)價值。設計者必須明白誰是目標受眾，需要清楚知道目標受眾是誰、如何驅(qū)動交互（比如在用戶間構(gòu)建交互手段，或為用戶獲取有用信息提供支持）。最后，對環(huán)境的清晰認識也非常關鍵。品牌推廣應用的生存地點在哪里，是互聯(lián)網(wǎng)、手機還是桌面？這個應用是放到用戶的社交網(wǎng)絡個人資料頁，還是博客？因為像Facebook或MySpace訪問的者中，有自己的個人資料頁的比例較高，因此這些用戶很可能愿意將看到的品牌推廣應用放到自己頁面上去。相比較而言，很多博客的讀者其實并沒有自己的博客，那么為他們提供復制其他博客上的品牌推廣應用到自己博客的功能就顯得不那么重要了。與應用發(fā)布有關系的因素是應用的周期。你的品牌推廣應用將運行多長時間？它或者只是為期三個月的營銷活動的一個組成部分，過后就放棄不用管了么？還是打算無限期運行，持續(xù)為用戶傳遞價值？如果是后者，它是否需要定期更新？將這些問題一一定位，設計者、開發(fā)者才能有清晰的目標和導向，這是保證開發(fā)出的品牌推廣應用成功所必需的。一旦上述關鍵問題被一一確定、各方達成共識，那么創(chuàng)意和開發(fā)團隊就可以著手設計和開發(fā)了。設計你的品牌推廣應用

在設計你的品牌推廣應用時，有6條原則一定要時刻遵守，只要一直堅持，成功的可能性就會不斷加大，最終達成你之前設定的目標。這些原則放在一起可拼為SIMPLE，便于記憶和理解。簡單

要吸引用戶與你的品牌推廣應用交互，“少即是多”（less-is-more）或許是最為合適的。功能單一，往往也是目標明確，用戶也更易理解應用是什么、用來干什么，自己為什么要將寶貴的時間花在它上面。品牌推廣應用的尺寸一般較小，品牌形象和信息的展示、傳遞的可用空間受限。設計者需要盡可能利用有限的資源，在第一時間讓應用的目標清晰展現(xiàn)。如果應用中需要滾動條、下拉菜單才能顯示信息，那么就應該重新思考這些信息的價值了；如果應用包含了兩三項活動，那么就應該評估是否開發(fā)兩三個不同的應用，每個只負責傳遞單一信息和價值。同時要避免使用傳統(tǒng)的Web導航技術，例如多個頁面、鏈接到不同活動的按鈕等等。套用HansHofmann的一句話，簡單即“消滅不必要的，必要的才能發(fā)出聲音”。KraftRecipeAssistant應用（見圖1）是一個典型例子，功能非常簡單。它為用戶提出每日晚餐的建議，同時也允許用戶在應用中通過關鍵字或指定原料搜索其他食物。Kraft通過為用戶提供易于理解、使用而且有實際價值的工具，兌現(xiàn)了品牌承諾。圖1，KraftRecipeAssistant應用直覺

你的設計應該在最短時間內(nèi)暴露出自己的目標。用戶花在理解應用的目標的時間越少，TA愿意與之交互的可能性越大。應用的顯示界面需要在用戶無需介入的情況下，直接展示出要表達的價值和目的。將你的設計實現(xiàn)為簡單樣品后，開展實際測試（理想情況下，參與者應該來自于你的目標受眾群）。如果接受測試者不能在7-10秒內(nèi)明白應用的目的，你就應該重新設計，因為這已經(jīng)表明你的應用能在潛在用戶中引起多大程度的注意。Hyatt的eDeals桌面應用是這方面的一個好例子。它根據(jù)用戶的喜好（比如在指定地點的利率促銷情況），定時生成提醒。eDeals僅僅做一件事，并正確完成，因此任何由Hyatt指導過的營銷計劃都有最高的轉(zhuǎn)化率。消息

不要忘記品牌推廣應用的最終目標：傳遞某種符合你要推廣的品牌或產(chǎn)品的價值。用起來很有趣的應用（如一個能吸引用戶交互的休閑游戲），但并沒有提升對品牌或產(chǎn)品價值傳遞的支持，因此是對機會的浪費。未與一個特定的單一市場信息捆綁的品牌推廣應用，最終必然不能給消費者和商家?guī)砹钊藵M意的體驗。試想這樣一個問題，如果用戶被問及：“品牌推廣應用必須為正在推廣的品牌或產(chǎn)品做出什么貢獻”？用戶會如何回答呢，如果他們的答案并不清晰，那么就應該重新審視設計，因為現(xiàn)有的設計不能實現(xiàn)既定目標。想像一個品牌推廣應用是一個某人私人房產(chǎn)上的免費廣告板塊，你就需要考慮一下你應該多大程度傳達你的品牌和信息。如果信息過于嘈雜、花哨，可能你就永無登臺的機會。個性化

品牌推廣應用能由用戶定制，支持個性化，無疑是一項能吸引用戶、促進傳播的重要能力。社會媒體用戶通常可以自行控制個人資料頁、社會媒體環(huán)境，因此在品牌推廣應用上支持類似的個性化，邏輯上具有同樣的意義。例如支持用戶上傳照片或自定義頭像，給用戶帶來實用價值，就可以讓用戶為應用的產(chǎn)品投入、增加粘性。Purina發(fā)布的品牌推廣應用（見圖2），允許用戶上傳他們寵物的照片，寵物通過一個對話氣泡，可根據(jù)天氣條件和溫度將自己的健康狀況告訴主人。通過利用寵物照片個性化定制應用，Purina的設計者將一個傳統(tǒng)的天氣應用轉(zhuǎn)變成為一個交互的、具有高度個性化體驗，令人叫好的品牌。圖2，Purina的PetWeather應用布局

如果你想在社會媒體（如博客、社會化網(wǎng)絡等）上發(fā)布在線的品牌推廣應用，那么使用標準的IABadunitdimensions，無疑適應性更強、可見程度更高。設計界面更小的桌面或在線應用，將增加發(fā)布潛力。你的品牌推廣應用將和其他應用、內(nèi)容源等共存。更大、更突出品牌推廣應用將越來越少，因為它們界面太大，與其帶來的實際價值比例失調(diào)。在應用中應該使用易于閱讀的字體，避免使用小字體。測試表明，一個界面中有效的、易于理解的內(nèi)容比重不超過40%，也就是說剩余60%界面應該是干凈的，沒有內(nèi)容和導航元素。同樣，應該保證應用的體積最小。因為每個品牌推廣應用都能從單個源文件生成，內(nèi)容也很容易更新，對于生命周期多于2-3月的品牌推廣應用，推薦此方案。對于在線品牌推廣應用而言，要注意它在環(huán)境中的平衡。品牌推廣應用當然要引人注目，但不是為了和它所處頁面的其它內(nèi)容和組件相沖突而體現(xiàn)。相反，如果品牌推廣應用很像用戶界面的一個部分，就易被用戶當做該頁面或站點的一個功能而忽略。參與

一個廣告或品牌推廣應用能出現(xiàn)在用戶的個人資料頁、博客或桌面上，是因為用戶自己將它放置上去了。它包含的是用戶認可的商業(yè)內(nèi)容，用戶將其放在醒目位置，以便親朋好友能一眼看到。朋友和家人是我們最可信任的信息源，他們看到這些品牌推廣應用后，也更可能將這些應用嵌入到自己的個人資料頁。要讓這種感染式的傳播發(fā)生，應用就必須對用戶有真正的價值或用途。參與導致支持，支持會引來更多參與。這種良性的正面反饋是可以通過一開始就讓應用的價值顯而易見、立即被認可而觸發(fā)的。理想的品牌推廣應用能吸引用戶每天使用、參與多次。一個被認可的例子是一個提供實時交通狀況的交通報告品牌推廣應用，用戶每天至少會使用兩次。讓品牌推廣應用的參與用戶點擊一次——最多兩次，就能達到自己的目的。用戶就能快速發(fā)現(xiàn)應用的價值，而不需花好幾分鐘設置選項、加載內(nèi)容，從一堆皮膚、色彩主題中做出選擇。操作簡單、易于運行，保證用戶可以方便地將品牌推廣應用復制到自己的頁面或站點上。簡單實用一個“GrabIt”按鈕，已經(jīng)成為一個慣例，幾乎所有品牌推廣應用的用戶都能理解?？偨Y(jié)

越來越多的廣告客戶希望借助品牌推廣應用在他們自己的個人社會網(wǎng)絡和計算環(huán)境中贏取受眾，這種品牌推廣和廣告應用無疑將持續(xù)成長。Forrester統(tǒng)計表明，60%的成人社會網(wǎng)絡站點用戶和64%的年輕社會網(wǎng)絡站點用戶使用了這些應用。雖然他們的參與到底能為品牌轉(zhuǎn)化來多少實際價值，尚無明確數(shù)據(jù)，但無論什么樣的價值，都只能通過有效設計、易于使用和理解的品牌推廣應用來實現(xiàn)這一點，應該沒有多大爭議。作者簡介

Roland有近20年的市場營銷和廣告行業(yè)經(jīng)驗，曾在Saatchi、Saatchi和GreyWorldwide等公司工作，目前是Gyro:HSR公司總經(jīng)理，為Hewlett-Packard,VMware,Cisco,SanDisk,McAfee,Macrovision,Experian等很多客戶制定和執(zhí)行實施全球整合營銷和廣告策略。此外，Roland還是移動和社會化營銷方面的專家，為Adidas、MySpace、AtlanticRecords等很多在發(fā)行、社會媒體、內(nèi)容空間的領頭企業(yè)創(chuàng)立并實施了viralandbrandedapplications。Roland擁有哥倫比亞商學院、加州大學伯克利分校商學院的學位，和賓夕法尼亞州立大學肄業(yè)學位。閱讀英文原文：Bestpracticesforbrandedapplicationdesign。發(fā)表在2010年1月4日由川谷在上月舉辦的PDC09大會中，微軟ASP.NET團隊的JonathanCarter和ScottHunter演示了為ASP.NET4以后版本設計的一些功能，其主要方向是簡化應用程序的開發(fā)，支持Web標準，以及提高性能提升。在簡化應用程序開發(fā)方面，ASP.NET團隊正在考慮以下幾個功能：可用于ASP.NETMVC和WebForms的ActionRecord模式支持，基于EntityFramework，方便快速建模，快速開發(fā)。

更易于使用的Route規(guī)則：能結(jié)合各種信息（如硬盤上的文件路徑）自動判斷路由目標及相關參數(shù)。

可擴展的，基于常見任務/場景的輔助方法，例如：

圖片處理，如縮放，水印等常用操作。

OpenID支持，這樣開發(fā)人員可以輕松將ASP.NET認證與OpenID集成。

后臺計劃任務，如“每10分鐘”或“每天凌晨2點”執(zhí)行某個任務。

Email發(fā)送，以及使用Email進行驗證的注冊流程。

真實的文件上傳進度提示，目前實現(xiàn)這個功能需要使用某些危險的技巧，而今后ASP.NET可能會釋放更多接口來進行支持。

HTML5帶來了許多新特性，例如新的HTML標記，原生的視頻和音頻支持，以及拖放操作等等。未來的ASP.NET首先會支持HTML5中更符合語義的標記。如在ASP.NET2.0中，控件會生成復雜的table標記，在ASP.NET4中則會變成符合目前語義的ul/il嵌套，而在未來的ASP.NET中，便可能會生成標記。此外，HTML5的WebStorage功能允許將數(shù)據(jù)儲存在瀏覽器上，未來的MicrosoftAJAX庫中將會提供一個可選的IntermediateDataContext用于替換目前的AdoNetDataContext，后者將數(shù)據(jù)通過WCF接口存放在服務器端，而前者則將數(shù)據(jù)保存在本地。在性能提高方面，ASP.NET團隊會在在微軟的分布式緩存Velocity發(fā)布之后，為ASP.NET提供相應的各類provider。這樣ASP.NET便可以將數(shù)據(jù)緩存，會話狀態(tài)等各種信息存放在進程外的的分布式緩存中，以此得到更好的性能和健壯性。這些provider實現(xiàn)可以與ASP.NET現(xiàn)有的擴展方式良好集成，對開發(fā)人員的使用保持透明。由于Web應用程序的顯示效果越來越豐富，網(wǎng)頁前端性能優(yōu)化的重要性也隨之提高。未來的ASP.NET將會內(nèi)置CSS或JavaScript文件的壓縮及合并，并對CSSSprites等復雜優(yōu)化方式提供支持。CSSSprite的優(yōu)化原理是將頁面上大量的小圖片合并成一個文件，然后使用CSS定位機制來顯示其中的一部分，這么做的好處是大大減少了瀏覽器與服務器端的通信次數(shù)，往往可以使頁面加載速度有明顯提高。ASP.NET在未來可以根據(jù)開發(fā)人員的需求，自動將一組圖片進行合并，并通過一些接口將單獨某幅圖片的信息（如位置，尺寸）暴露出來，甚至直接在頁面上生成包含特定屬性的HTML標簽。你可以在PDC2009的網(wǎng)站上瀏覽或下載本次演講的完整錄像及幻燈片等資源。發(fā)表在2009年12月23日由川谷在我們所有的對手中，最強大的是時間。面對時間，我們絲毫沒有欺騙的機會，時間一分一秒的流逝，最終的勝利者總是時間。我們經(jīng)常會覺得“哦，兩天過去了，任務絲毫沒有進展，明天就是截止日期了，該怎么辦？”我們經(jīng)常忙于應付一個接一個的任務，沒有時間去學習充電，享受生活，并由此陷入很大的焦慮情緒。隨著社會不斷發(fā)展，工業(yè)文明極大地豐富了人際間的交流手段以及獲取信息的手段，我們的時間利用效率卻變得越來越低了。沉下心思專心做一件事情，對絕大多數(shù)人來說已經(jīng)變成一件不可能的任務。究其原因，主要有兩個：干擾太多。人們不能專心把一件事情做完后，再去做另一件事情。經(jīng)常是正在全神貫注工作的你，突然收到一封郵件，接著放下手頭的事情，回郵件。發(fā)出郵件后，切換回原來任務。每一次任務切換，往往要花更多的時間完成原來的任務。（平均每次切換要使原任務增加25%的時間。引用3、4）。設想一下，很多人一天要查看郵件50次、100次，還有MSN、電話等等。缺少明確的目標和優(yōu)先級。所有時間都在應付緊急任務，不停地救火。這些緊急任務可能來自于老板、團隊其他成員也可能來自于家人、朋友。為了應付新的緊急任務，經(jīng)常要放下手頭工作，在完成新任務過程中又出現(xiàn)中斷，最終在不停的任務中斷和切換中迷失了方向。一天下來不知道忙了些什么。排除干擾，確保首先完成最高優(yōu)先級的任務，是提高個人時間利用效率必須解決的問題。這與敏捷軟件開發(fā)（Scrum、XP、Lean）要解決的問題何其相似。針對軟件開發(fā)中的類似問題，九十年代起KenSchwaber、JeffSutherland、KentBeck、MartinFowler等大師們提出的敏捷開發(fā)解決方案，其中包括時間箱、不受干擾的迭代、具有優(yōu)先級的代辦任務列表、拉動（Pull）任務、承諾、計劃與反省等等。無獨有偶，從九十年代初開始，意大利人FrancescoCirillo也基于相同的策略設計并發(fā)展了番茄技術（ThePomodoroTechnique，Pomodoro意大利語“番茄”）來管理我們的個人時間。用到的工具很簡單，一個廚房定時器（PomodoroTimer），三個簡單表格（當天任務列表To-Do，任務清單ActivityInventory和記錄歷史數(shù)據(jù)的表格Records）。

番茄時段在敏捷開發(fā)中一個迭代的周期通常是一到四周，番茄技術的一個迭代是25分鐘，稱為一個番茄時段。跟敏捷開發(fā)的迭代類似，在一個番茄時段開始時需要從當天任務列表中找出目前最高優(yōu)先級的任務，然后不受干擾地去完成該項任務，一直到定時器的鈴聲響起。每個時段結(jié)束后可以有三五分鐘時間自由支配，然后再開始新一個時段。在敏捷開發(fā)的迭代過程中，團隊只會集中精力完成當前迭代中的任務，不會對新的任務需求做出響應，所有的新任務都放到產(chǎn)品Backlog。在番茄時段中，個人也是采用相同的策略，在緊急情況下，新的任務會放到當天任務列表，作為一個當天的一個未計劃任務；而一般的任務，只需要在任務清單上加一個新的任務項目。然后不受干擾地繼續(xù)當前的工作。即使任務完成時，定時器還沒有響，處理方法也很簡單，用剩余的時間去“重構(gòu)”完成的任務，使它更好一點兒。工作日程表以下以一個使用番茄技術的程序員的工作日程表為例。

在這個日程表很好地融入了戴明環(huán)PDCA（計劃Plan；執(zhí)行Do；檢查Check；糾正Act）。每一天總是從計劃番茄時段開始，最后一個番茄時段以分析反省結(jié)束。每天的歷史記錄一般包括計劃執(zhí)行情況、未計劃任務情況、估計與實際，干擾次數(shù)，干擾內(nèi)容等等。通過這些歷史數(shù)據(jù)我們可以很容易地觀察自己：計劃執(zhí)行是否有效估計是否準確，偏差有多少未計劃任務有多少，分別做什么工作中的干擾多不多，主要干擾有哪些通過切實的數(shù)據(jù)對自己的時間利用情況有了清晰的了解后，我們就可以在反省中有針對性地設計解決方案。如此不斷反復時間效率就會不斷得到提高。消除干擾番茄技術最大的好處是能夠幫我們集中精力，消除干擾。每個番茄時段只有25分鐘，除非是十分緊急的情況，一般情況下都是可以在完成當前時段后再去響應。通常我們會遇到兩種干擾：內(nèi)部干擾，主要是自己想做某些事情，比如喝水、查郵件、網(wǎng)上聊天、上網(wǎng)等等。針對內(nèi)部干擾，主要有兩種解決方法，第一種就是有針對性的計劃一些處理這種任務番茄時段，比如上面日程表中的專門用來處理郵件的時段；另外一種方法就是利用番茄時段之外的時間，比如那些自由支配的時間以及午飯時間。外部干擾，比如電話、同事來問問題等。與內(nèi)部干擾不同，外部干擾需要與其它人打交道，因此需要采用不同的策略。具體策略是“通知Inform，商量Negotiate，晚些時候響應CallBack”?？梢杂昧粞詸C接電話，郵件也可以暫時放到收件箱中稍后處理。如果有人當面過來，可以告訴他：“我先忙完手頭工作，二十分鐘后去找你?！保缓罄^續(xù)手頭的工作。晚25分鐘或者一兩個小時對通常意義上的緊急任務來說，是可以接受的。對對方來說需要等待25分鐘可能不是什么很大的問題，但是對自身來說卻有極大的意義，我可以繼續(xù)專心把我手頭上最重要的事情。當然很難避免的，也會出現(xiàn)不得不取消當前番茄時段，著手處理十分緊急的任務的情況，這其實跟在Scrum中取消當前Sprint一樣，只有萬不得已才會為之。每當有干擾的時候，都要在每日任務列表上做一下標記，如果需要，同時在每日任務列表（如果是緊急任務）和任務列表上填加一個未計劃任務。把干擾放入任務列表使得我們有機會重新思考一下每一個任務是否那么重要，是否真的需要，很可能過了一段時間我們?nèi)蝿樟斜砩系暮芏嗳蝿兆兊貌槐匾?。另外，所有的干擾都被顯式地標記在每日代辦任務列表和歷史記錄表上。每天都可以反思每天的干擾次數(shù)以及內(nèi)容。干擾數(shù)據(jù)能夠是我們更有意識地關注時間效率的問題，促使我們通過重新計劃，調(diào)整策略等等方式把干擾降到最低。比如對于電話太多的情況的一個有效的策略是，每天應該固定一段時間把電話放到留言，到會議室去辦公，然后告訴其他同事，在緊急情況在哪里能夠找到自己。而對于郵件太多的情況，可以多安排幾個番茄時段集中處理郵件。任務計劃與估計番茄技術的另一個好處是給我們提供了一種全新的估計和計劃的手段。在任務列表上的每個任務都需要有一個規(guī)模估計值，這個值其實是標明完成該任務需要花的番茄時段的數(shù)目。由于每個時段都是不受干擾的“純”投入的時間，因此可以通過番茄時段數(shù)目有效地把任務的規(guī)模與時間建立聯(lián)系。通過把實際花費的番茄時段數(shù)目與估計值相比較，分析，可以幫助提高自身的估計能力。同時，通過分析歷史記錄中非計劃任務的數(shù)目以及內(nèi)容，也可以幫助我們對自身的時間利用情況有更好的了解，從而更有助于計劃個人的時間。轉(zhuǎn)變時間的觀念番茄技術能夠改變我們對時間的態(tài)度。時間變成了一個個番茄時段。每一段25分鐘，滴答滴答從25分鐘減到0。從而給我們一種緊迫感(Eustress)，督促我們盡快完成任務，盡快做決定，從而有效的提高效率。效率的提高能夠有效地提升自信心和成就感。關于番茄技術的詳細介紹可以參見它的網(wǎng)站（引用1）以及ThePragmaticBookshelf的新書《》。引用ThePompatusofPomodoro,PragPubIssue#5,November2009ManageYourEffortNotYourTime,HarvardBusinessReview,October2007Perfection:作者簡介：滕振宇（DanielTeng），IrdetoBSS高級軟件經(jīng)理，CSP，敏捷教練。創(chuàng)建并領導IrdetoBSS上海研發(fā)團隊，負責大型付費媒體計費以及客戶管理系統(tǒng)軟件產(chǎn)品的開發(fā)。發(fā)表在2009年12月23日由川谷概要

近日InfoQ有幸獨家專訪了微軟VisualStudioBusinessApplications團隊的總經(jīng)理潘正磊，與她探討了微軟研發(fā)團隊管理的相關問題：技術人員的職業(yè)發(fā)展、如何培養(yǎng)接班人、如何管理不同規(guī)模的研發(fā)團隊等等。個人簡介

潘正磊女士是位于美國雷德蒙市的VisualStudioBusinessApplications團隊的總經(jīng)理。這個團隊通過提供多種工具，使全球開發(fā)人員能便捷地在微軟平臺上搭建商業(yè)應用程序。她同時領導開發(fā)工具部門的中國研發(fā)團隊，進行VisualStudio、VisualStudioTeamSystem等產(chǎn)品和技術的全球研發(fā)工作。92年，她以軟件開發(fā)員的身份加盟微軟，參與Access、VisualInterDev等產(chǎn)品的開發(fā)。1998年至2006年間，她先后擔任VisualBasic.NET開發(fā)經(jīng)理、VisualStudio產(chǎn)品線開發(fā)總監(jiān)、VisualStudioTeamArchitect產(chǎn)品總經(jīng)理和VisualBasic產(chǎn)品總經(jīng)理，為專業(yè)開發(fā)人員提供在.NET平臺上最高效的開發(fā)工具，使數(shù)百萬VisualBasic6.0用戶遷移到.NET平臺。

先給我們介紹一下你自己和你自己現(xiàn)在所做的事情吧？我是在1992年大學一畢業(yè)就參加了微軟，一開始是做開發(fā)程序員，就是Developer，最開始開發(fā)的項目是MicrosoftAccess，現(xiàn)在也是微軟賣的很好的一款產(chǎn)品。在Access開發(fā)了幾年之后，我轉(zhuǎn)做另外一個產(chǎn)品叫Visual

Interdev，那是我們微軟第一款針對網(wǎng)絡Web做的開發(fā)工具；那之后我在VisualBasic團隊做DeveloperManager，就是開發(fā)經(jīng)理的職位，當時我們整個從VB6到VB.NET

轉(zhuǎn)型，所以跟.NET做平臺開發(fā)，是一個非常艱苦的項目。之后還在VisualStudio里做了一系列的職務，包括開發(fā)總監(jiān)，包括我們VisualStudioTeam

Architect的產(chǎn)品總經(jīng)理，包括VisualBasic的產(chǎn)品總經(jīng)理?，F(xiàn)在是VisualStudioApplications的產(chǎn)品總經(jīng)理，像我們剛才所說的，主要我們這個團隊做的是針對企業(yè)的開發(fā)工具。

你是從一個基層的開發(fā)人員一直走到現(xiàn)在，那我想，在你整個過程中應該是有很多的感觸，特別是從一個開發(fā)人員然后到一個管理職位，在整個過程中有沒有什么比較難忘的事情？因為已經(jīng)工作十幾年了，所以說，確實有很多故事了，我覺得比較難忘的幾個故事，還是跟我們最高層打交道的時候比較有趣。我們在做VisualInterdev的時候，那是我們第一款針對Web的產(chǎn)品，當時微軟對Web的定義、對Internet的戰(zhàn)略不是非常清晰。記得我們跟Bill

Gates在做產(chǎn)品Review時候，他一開始對我們這個產(chǎn)品是有些意見的。他說，你這個產(chǎn)品做出來以后，對Windows有什么好處或者是壞處。這是一個挺尖銳的問題，讓我們所有人回去都要好好想一想。還有最近我們在做另外一款產(chǎn)品Review的時候，也是跟我們SteveBallmer，我們的CEO，跑上來我就要給他做一個演示Demo，我們的CEO就說現(xiàn)在所有演示都不要做，他叫我們最資深的副總裁，“你就到黑板上面去，把你們這個產(chǎn)品要做出來的三個目標先給我寫上去，寫完以后我們再做演示，看你這演示有沒有達到你這三個目標”，這個跟Steve

Ballmer做Review常常會碰到這種情況。

他會直接幫你梳理你的產(chǎn)品目標？他會用你很意料不到的方法來問你，因為一般我們?nèi)プ鲞@種總裁Review都是有準備好一套PowerPoint，有一套我們自己的思路，他就會從你的思路之外問一些問題，保證你確實能夠解釋出來你為什么要做這個東西，然后你的思路是什么，你的戰(zhàn)略是什么，這是一些蠻有挑戰(zhàn)性的東西。

在你的個人從開發(fā)人員到一個團隊管理的過程中，在做團隊管理的時候有沒有遇到一些困難、一些比較難忘的事情？做團隊管理的時候，因為團隊管理最主要的是幾大塊：第一，你要造就一個非常強的團隊。這中間有很多（差異），你這團隊是你自己接手的，還是這個團隊是你自己一個一個雇傭進來，這個完全是不同的。還有和你的Partner（合作）團隊，因為微軟很多項目需要好多幾個團隊來一起合做才能做好，那跟你Partner的這個運行過程中也有很多的這種Interaction（互動），有的時候如果大家的戰(zhàn)略目標不一樣，就會造成很多各種各樣的問題，那所以這都是有很多故事的。我現(xiàn)在一下想不出來一個特別好的、最有挑戰(zhàn)的。因為從組建團隊中，這么多年走過來，基本上什么場景都碰到過了，所以我還真一下想不出來一個最好的故事，或者是說最有挑戰(zhàn)性的故事。

其實我也了解到在你整個的發(fā)展過程中，到最后成為全球微軟有兩千多個總經(jīng)理，你是為數(shù)不多的華人，那么從整個階段來看，你是如何去總結(jié)自己的這段歷史？我覺得微軟現(xiàn)在華人的總經(jīng)理比較少，但是我覺得從長遠來說肯定會越來越多，這實際上是我們在九幾年有大量的大學畢業(yè)生開始出國，然后開始在美國，或者這種（國外的）地方開始就業(yè)有關。我相對來說出國比較早一些，所以我進微軟也很早。那像九幾年之后，95、96，包括90年代末期，有大批的中國員工進入微軟，所以我相信這以后的華人工程師或者華人總經(jīng)理，各方面只會越來越多。那另一方面，在微軟或者是在很多大企業(yè)里，自己的一步一步都是要慢慢走過來，然后都是要腳踏實地，最主要的是要想到說你對這個團隊有什么貢獻，你對你的客戶有什么貢獻，如果能夠比較的專注于某方面工作的話，那我覺得在成長中是很有好處的。

進入微軟的華人很多，工程師也很多，但我想也淘汰了很多，最終可能會有一個人冒上來，而且這個人就是你，我想問一個比較直接的問題，你覺得為什么會是你走到今天這個位置？我覺得每個人的長處是不太一樣的，我覺得我自己的長處，第一是技術方面還不錯，因為一開始在做工程師，如果你技術上面做不好，是不可能往上走的。另一方面，我覺得我對資源整合這一方面是比較強的，我的一個強項是我很快就能看出我下面的員工他們最適合什么，他們不太適合什么，那把他們放在最適合于他們的工作崗位上。這樣第一能夠是最大的調(diào)動他們的積極性，第二整個團隊可以成一個非常高效的團隊。而且我在管理人員方面，很多跟我做了很多年的員工，愿意跟我做很多年，所以這也是作為一個領導者應該比較重要的素質(zhì)。我覺得是這些是可以學的，但有些可能有的人就會比較容易一些，比較自然一些，有的人可能就是要學的更多一些。

但是我想在你的團隊里面應該也有一些能力非常強的，比如說他的存在會讓你有所威脅，那么在這種情況之下，你是如何和他們相處的？你看，我這個考慮思路跟你完全不一樣，我不會覺得我團隊里面有誰對我是有所威脅的，我的出發(fā)點就是我希望能夠培養(yǎng)一批人才，如果有一天我能夠不用去上班了，而且我的團隊還可以執(zhí)行得非常好，這才是我的目標，所以我是希望有人能夠來代替我。因為微軟里面包括很多公司是這樣的，有挑戰(zhàn)性的工作是非常多的，如果我這個工作做完了，如果我下面培養(yǎng)出一批人才，能夠取代于我的話，那還有更加具有挑戰(zhàn)性的工作在等著我去做，所以這個思路不是說有這個人會對我造成危險性，而是我如果有一天能夠找到一個，或者請到一個比我更強的員工，這是一個非常高興的事情，非常令人振奮的事情。實際上在我的職業(yè)生涯中也確實有過這樣的經(jīng)歷，我那時候在做VisualBasic開發(fā)經(jīng)理的時候懷孕了，我知道會休蠻長的產(chǎn)假，而且一度還動過可能不回來上班的想法，做全職媽媽的這種心思，所以我那時候就把我下面的一個開發(fā)主管，一個開發(fā)主管一直培養(yǎng)他，而且當時就是培養(yǎng)他到最后，我去休假之前，說那這個團隊就交給你了。等我五個月休完產(chǎn)假回來之后一看，那個團隊雖然是我打造的，交給他之后他還是管理的非常好。我說太好了，那你就來做開發(fā)經(jīng)理。那個時候我就去做了我們Division另外一個工作，整個部門的開發(fā)總監(jiān)。就像我說的，這世界需要能人的事情非常的多，所以你是一個能干的人你不要有這種危險感，因為需要你的地方是非常多的。

所以我想，一個人的自信對于他的整個的成長是非常有幫助的？實際上我覺得如果在微軟來說，如果你沒有自信，那你可能很難從一個開發(fā)工程師往上走非常的遠。因為在微軟我們招的都是，真的是世界上英文詞叫“creamofthe

crop”，都是最最頂尖的大學生，或者是外面有經(jīng)驗的人。在這樣一種環(huán)境中，你怎么樣能夠跟大家交流，怎么樣可以說服大家同意你的觀點，怎么樣聽取別人的反饋，自信心實際上是一個非?；镜乃刭|(zhì)。如果你沒有這個素質(zhì)，就是作為一般的開發(fā)工程師也不會走的太遠的。

另外我比較好奇的一點，比如說在你整個的幾個階段里面：有基本的開發(fā)人員，然后到一個比如說項目經(jīng)理、一個產(chǎn)品的帶頭人，然后再成為一個產(chǎn)品的總監(jiān)，最后成為總經(jīng)理，那么這幾個段它有什么特別的不同嗎，除了你管理的人越來越多？那是有非常大的不同的。作為一個開發(fā)工程師來說，你最主要的是要把你的代碼寫得越快越多越好。因為你對產(chǎn)品的貢獻是鑒于你代碼的數(shù)量，你寫代碼數(shù)量直接就反映成你對這個產(chǎn)品功能多少的體現(xiàn)，你的代碼行寫得多，那這個功能才增加得多，你寫的代碼行是最難的那部分，那才說明你對這個產(chǎn)品最主要的核心部分有貢獻，這是作為開發(fā)工程師。作為一個開發(fā)主管來說，就是我們叫DevelopmentLead，第一方面，作為管理者，你對這個團隊的價值，不僅僅是說你自己寫了多少行代碼，這相對來說是比較少的，最主要是你這個團隊對整個產(chǎn)品的貢獻是什么，那還是基于你這個開發(fā)的功能有多少，然后你這個功能是不是做得好，你架構(gòu)是不是做得好，但是你的核心價值是把你這些資源都組合起來，然后能夠幫助你團隊的員工掃平障礙，讓他們非常順利地開發(fā)。像我最開始做管理的時候，我只管理了三個員工，有一個員工如果做得慢一點，那我最多周末去加一加班，他沒有做完幫他補做完就完成了，我覺得相當簡單的一件事情。等我那個團隊長到10個人的時候，你就發(fā)現(xiàn)，第一，不可能我周末再來加班，也不可能把10個人里面有兩三個人可能要做的慢一點，如果按同樣的比例來說，我不可能把這兩三個人要做的東西都做完了。那這個時候你要做，就是我們從這個Skill來說，如果要整個團隊都能夠非常順利高效，你就要想“我怎么樣讓這十個人互相之間能夠（協(xié)調(diào)好）”，就是很多程序是有順序的問題，把順序問題安排好，有些東西可能要需要一些決定，盡早的把決定做好，下面的架構(gòu)可以做好，跟其他團隊的關系要搞好，因為他們可能有些東西要拿來，他們先做完之后我們才能做，所以有很多東西Dependency

Management，這些東西全部都要管理好，就像造房子，管理一個項目一樣。這樣管理好你這十個人才能都是馬不停蹄、非常高效地把這個東西做好。等你做開發(fā)經(jīng)理的時候，開發(fā)經(jīng)理因為不是一個第一線的管理者，而是第二線的管理者，這個時候最最有挑戰(zhàn)性可能是，你很多東西要通過你第一線的開發(fā)主管傳達到下面去，如果你開發(fā)主管對你說的話不認可，那你的觀念、決定不一定真正能夠傳達到最下面的開發(fā)人員。而且你下面的開發(fā)主管可能每個人都還要管一攤不同的東西，你怎么樣讓他們之間能夠互相配合、互相合作，從一個大局上面來看你整個這個開發(fā)團隊缺什么，有的時候他們開發(fā)主管在那里面做，他不一定會知道說，我實際上比較缺一個真正能幫我把這個架構(gòu)搞在一起的人，或者一個特別懂客戶的人，那要把這個全部都想清楚，真正打造一個非常強的團隊，這又是另外一套的藝術，我覺得。在微軟如果你不懂這產(chǎn)品（技術），你是沒有辦法做一個合格管理者的，你不僅要做人員的管理者，你還要做這個產(chǎn)品的定義，而且還要跟你的團隊交流，什么地方是應該做的，什么地方是不應該做的。

是多重角色了？對，因為從開發(fā)經(jīng)理來說，我在美國喜歡說三個P，你要管理產(chǎn)品（Product），你要管理人員（People），你還要管理流程（Process），這三樣東西都要抓起來，你才能作為一個合格的開發(fā)經(jīng)理，然后讓整個團隊都能高效地運行。

他和現(xiàn)在的總經(jīng)理有很大的區(qū)別嗎？非常大的區(qū)別，因為從開發(fā)經(jīng)理來說，他還只是主要是管開發(fā)團隊的。開發(fā)團隊總的來說只是占了可能是1/3。總經(jīng)理跟產(chǎn)品經(jīng)理是兩個不同的概念，產(chǎn)品經(jīng)理是說你管一個產(chǎn)品，那總經(jīng)理你是管多種產(chǎn)品，像我剛才所說的，實際上我現(xiàn)在這個組里面有三種不同的產(chǎn)品。那這三種不同產(chǎn)品很多時候會有不同的進度表，發(fā)布時間會不一樣。怎么樣把里面相同的東西能夠整合出來，讓大家最有效地利用，而且還要針對每一個產(chǎn)品有他特別的開發(fā)。怎么樣管理這一套產(chǎn)品線，而且跟我們的市場部，跟我們的營銷部，跟我們的DPE（開發(fā)工具及平臺事業(yè)部），那些合作都是在這個層面上面是完全不同的。而且在這上面你就更要想說，這幾個產(chǎn)品，就像我們叫Portfolio（投資組合），就好像如果你要是投資，你可能有些放風險基金，有些放銀行存款，有些是放外匯，你還要再從比較高的角度上，看你每一個產(chǎn)品到底里面放多少的資源進去，為什么這個產(chǎn)品放這么多資源，而且要看你成功的定義是什么。而做一個產(chǎn)品的開發(fā)經(jīng)理，這么多資源實際上已經(jīng)分配給你的，你在這個資源的基礎上面把它做到最大最好，所以這還是不同的概念。

更加強調(diào)統(tǒng)籌的作用，那我們回到技術層面來講，在你的身上可以看到一個，我認為他是微軟一個研發(fā)團隊的技術變遷史，或者一個縮影。那么我想問的問題是，在你的理解當中，從你進入微軟研發(fā)團隊一直到現(xiàn)在，在整個的產(chǎn)品的開發(fā)過程中，主要經(jīng)歷了哪幾個比較重大的階段？我覺得這個問題非常好，因為你讓我回想了一下。確實有幾個非常大的不同（階段）。在我進微軟的時候還是微軟比較新，很多產(chǎn)品還是剛剛第一代，像我那時候做MicrosoftAccess，現(xiàn)在已經(jīng)無窮代了。那時候剛剛是第一版，當時發(fā)布時非常振奮人心的。如果打一個比喻，就比較像我們80年代剛剛開放的時候，那時候商品比較少，用計算機的人數(shù)少，相對來說需求也少。所以那個時候從微軟來說，只要發(fā)布產(chǎn)品就會有很多的用戶來使用。因為我們有很多很基本的需求，而市場上卻都沒有。那我們發(fā)布的產(chǎn)品只要大面上不錯的話，就可以非常容易地滿足用戶的需求。從Word第一版開始發(fā)行的時候，前面幾版你可以想有很多很多基本的功能是，現(xiàn)在覺得都是肯定是應該有的，但是當時都是很新的東西。但是產(chǎn)品在做了時間久了之后，等你發(fā)布第五版、第六版、第七版、第八版的時候，這時有很多基本的用戶需求已經(jīng)滿足了，在那個前提上怎么樣把你的產(chǎn)品更上一層樓，這實際上就變成一個相對來說比較困難的問題。很多時候，像我們的Office團隊最大競爭者不是別人，是前面一個版本的Office。所以在一開始我覺得我們在微軟里邊定義產(chǎn)品的時候，比方說90年代初，跟客戶溝通之后我們就是用一個Waterfall（瀑布式開發(fā)模式）這種Model，因為我們覺得我們知道這個產(chǎn)品應該做什么，我們就把它做完了，然后放在外面市場上，相對來說一定是賣得不錯的，賣得很好的，所以這是我們比較成功的一個模式。

自己可以主導？當然我們還是要跟客戶有反饋，一開始要跟客戶研究，但是我覺得相對來說做得少，而且相對來說比較容易滿足客戶的需求。因為那時候大家的基本需求有很多都沒有滿足。等到我覺得差不多就是99年、2000年，就是差不多那個階段，我們那時候很多產(chǎn)品已經(jīng)開發(fā)了好幾代了，等到那個時候我們就有一個危機，因為我記得是差不多是2000年的時候，那時候客戶對我們的滿意度相對來說比較低，而且我們跟合作伙伴的關系相對來說比較僵一點，在美國還有很多的訴訟案，那個時候我覺得實際上是微軟處于一個比較低潮的階段。但是從那之后，我們確實就開始轉(zhuǎn)型了，我覺得一個最基本的理念，我自己有這個感受，一開始就覺得說我們可以定義這個產(chǎn)品，定義了以后就做，做完以后賣，這是我們最開始的運營模式。大概是2000年之后，我們就發(fā)現(xiàn)對用戶反饋的需求變得非常多，而且一個版本一開始跟用戶反饋一次是遠遠不夠的。從開發(fā)模式來說，開始時我知道什么是對的，我知道用戶需要什么，我只要開發(fā)什么，這是我們本來的模式。在那之后，我們的模式時我不太確定用戶確實需要的是什么，我們可能要先做一些prototype，試驗品出來，讓用戶去體驗一下，體驗完了以后再給我們反饋，這是不是他們確實要的，我們在這個反饋基礎上再更改。所以你可以看出來整個流程，一開始的想法跟后來想法是不太一樣的，而且我們在2000年以后，在后面的開發(fā)中，對用戶的反饋的需求比以前是大大增加了，而且我們fundamental

mindset（最基本的理念），從一開始我絕對知道什么樣是一個對的產(chǎn)品，到我不太確定，那我需要跟用戶多次反饋，才能知道真正什么是對的產(chǎn)品，那這兩個其實是非常不一樣的開發(fā)模式。我們之后開始用這種開發(fā)模式之后，因為微軟作為一個很大的團隊，確實也碰到很多的挑戰(zhàn)，因為很多時候你要想改一點東西實際上是非常難的。

涉及到方方面面。方方面面，我就喜歡說，像你要是自己想在家里后院造一個小房子，你怎么改都沒有關系。但是你要想造金茂大廈，造到一半想改一點什么東西，那你可以想到有很多的東西要配合。你如果要改一點東西，那對你的電梯、電路、樓層、重量，都有很多的考慮因素在里面。那作為一個大的開發(fā)團隊，你怎么樣能夠同時滿足客戶的需求，又能夠在你的架構(gòu)基礎上能夠做這種改動。因為最后你的產(chǎn)品還是要滿足客戶需求，才能夠有賣點。你怎么樣做這么一個調(diào)整，這也是我們在前七、八年中慢慢轉(zhuǎn)型的過程。那相反過來，你如果看，拿我們Visual

Studio作為一個例子，從08年，我們前面幾個例子看到我們開始大量的出我們叫CTP（CommunityTechnologyPreview，社區(qū)技術預覽版），而且跟我們的客戶、開發(fā)人員的交流變得非常的透明，很多時候我們很早就把我們想做什么，愿意做什么，有的時候把我們寫的Spec，就是產(chǎn)品定義放在網(wǎng)上，給我們的MVP（微軟最有價值專家）先讓他們反饋，我們現(xiàn)在做很多這樣的工作，在這之前都是沒有的。

對于你們內(nèi)部的開發(fā)團隊來講，產(chǎn)品的設計方面是有很大的挑戰(zhàn)，也是一種很大的轉(zhuǎn)型。那么你們在自己做開發(fā)的過程中是不是也有一些分為幾個階段來呢？對！如果是按以前的開發(fā)模式，那你可以想到我們更多的是這種，我們現(xiàn)在決定要做這些feature（功能），這些功能需要這樣這樣，那就是一條線做下來，最后把它發(fā)布就可以了。

就像瀑布模型一樣的？對。如果你要是想象做的功能可能需要在做的過程中調(diào)整的話，你中間的每一個開發(fā)階段，就要設計一個跟用戶反饋的過程，然后真正把那反饋拿回來，然后在下面一個過程中做調(diào)整。同時你還不能把你的那個發(fā)布日期改動的太多，所以你就可以看到這個難度實際上是增加了很多。

在每一個改變的環(huán)節(jié)上，根據(jù)剛才我們的交流，他應該是客戶來進行推動的。那還有一個問題是，在什么時候你們認為這是一個改變的時機，認為這個開發(fā)模式應該改變了，這個產(chǎn)品設計的模式應該改變了，你們做決定的時候，有沒有某一個觀點來刺激著你們?nèi)プ鲞@種改變呢？沒有，因為微軟很多事情不是Top-Down，不是從上面這么Drive（推動）下來的。第一，從管理層來說，我們比較注重抓的是用戶的滿意度，看他的滿意度如何，就能體現(xiàn)我們跟他一開始交流的夠不夠。另一方面，比方說我們這個產(chǎn)品真正是有多少用戶反饋，而且是把這些反饋做到了產(chǎn)品里面去，這也是我們可以衡量的、量化的。而且很多時候微軟有一個團隊開始做一個比較好的模式，那其他團隊會說，這個模式不錯，他也開始借鑒。所以我們這個轉(zhuǎn)型也是慢慢轉(zhuǎn)型，不是說一下子，整個全部團隊開始轉(zhuǎn)型，不是這么一個過程。

可能是某一個團隊他先采用了某一種方法，然后其他團隊開始慢慢的效仿，應該從底下往上推？然后從小到大這么一種方式？說的非常對，因為我們不是Top-Down。從上面管理來說，你要抓的是最后的那個結(jié)果，你想看到的結(jié)果是什么，那么你鼓勵下面團隊去實驗不同的方法能夠達到這個結(jié)果，有的試驗可能比較成功，有的試驗可能不是很成功，那么你再把成功的這種方法，然后再在其他團隊里面推廣，一般多半都是使用這種模式比較多。

微軟的高層他不會認為就是，OK了，所有的開發(fā)團隊應該采用這么一種統(tǒng)一的開發(fā)方法來去做，他沒有這么一種強制的要求嗎？絕對沒有，因為微軟的產(chǎn)品線非常的長，有各種各樣的產(chǎn)品。開發(fā)方式實際上就是我們說的Process（流程），很多時候根據(jù)你這個產(chǎn)品不一樣，各方面會不一樣的。那我對Process理解是這樣，就說Process是應該幫助你的開發(fā)更有效、更快，很多時候我們覺得Process非常煩瑣，時間上會讓你慢下來，實際上這個不是它的（目的），它就是沒有達到要求。用另外一個比喻，其實像我們來的路上都是有很多紅綠燈，有的地方是有那種轉(zhuǎn)盤。像美國還有一種就是叫Four-Way

Stop（四向停車），就是你到那邊停下來看看左邊、右邊有沒有車，沒有車就可以通過。那他實際上都是不同的管理交通方式，管理這個車流量的一種方法，根據(jù)不同的地點，你要選擇最適合地點的一種方法，有的地方如果車流量不是很大，用這個Four-Way

Stop就可以了，有的地方可能有六、七個不同的出口，那用轉(zhuǎn)盤是最合理的。有的地方，在美國比方說有的地方你停了電，本來有紅綠燈的地方，你停了電就變成了Four-Way

Stop，那時這個地方一定是堵車堵得不得了，因為紅綠燈可以幫助流量的增加。開發(fā)的管理方法也是非常類似的，根據(jù)不同的項目你要選擇對你來說比較合適的方法。如果是一個比較小的項目，你用一個heavyweight(重量級)的方法那就是不合適的。這是為什么微軟不會從上面說你一定要用什么樣的方法，他考核得是你最后那刻做出來的結(jié)果，你的結(jié)果是怎么樣，能不能在你所承諾的時間里面把東西做出來，你做出來東西用戶是不是認可，你做出來的東西后面是不是有很多質(zhì)量問題，還是說很好用。你在做下面一個版本的時候，就可以反映出你前面做的架構(gòu)好不好。如果你前面做架構(gòu)延伸性非常差，你第二個版本相對來說就會多花時間，因為要把前面重新（改造）。

遇到很多兼容性的問題？對，所以這種才是比較硬性的考核標準，那下面用什么樣的方式，你自己應該去選一個對你團隊來說最合適的方式。

那我們再具體一點，就是你作為一個開發(fā)團隊的負責人，肯定在整個的團隊管理生涯當中，采用了很多新的技術，很多的新的開發(fā)方法，那你是有一種什么樣的觀點來評估這個技術、這個方法是不是應該用在自己的團隊里面？一般還是看結(jié)果。我本人是比較愿意去試驗新的方法，我會讓一個featurecrew(功能小組)去試驗這個方法。然后給他一段時間，他來給我反饋，這個不管是方法還是新的工具，他有什么優(yōu)點，他有什么缺點，因為很多時候你想是想不出來，你還一定要去試，試了之后才知道它到底是好用還是不好用，它什么地方好，什么地方不好，就跟車一樣，你得要去試開一下。然后在這之后，根據(jù)他的好處跟壞處，你還再可以跟現(xiàn)有的方法再看，再評估一下，你是把它全盤拿過來呢，還是把它改動之后再引用，或者有沒有什么辦法把它好的地方能夠結(jié)合到現(xiàn)有的方法之中，不好的地方把它拋開不用。你每換一個開發(fā)工具，或者是每換一個開發(fā)流程，尤其是團隊大了，相對來說實際上是一個比較難的事情。因為你對整個開發(fā)、測試，還有工程師，你都要進行一個訓練的過