本文出自

職涯大布局

職涯大布局

2008年2月號

搬開經驗絆腳石

The Experience Trap
基修爾.森加塔 Kishore Sengupta , 塔瑞克.艾伯達-哈米德 Tarek K. Abdel-Hamid , 陸克.范瓦森霍夫 Luk N. Van Wassenhove
瀏覽人數:13195
  • 文章摘要
  • "搬開經驗絆腳石"

  • 字放大
  • 授課文章購買
    購買〈搬開經驗絆腳石〉文章
  • 個人收藏購買
    購買〈搬開經驗絆腳石〉PDF檔
    下載點數 10
愈是經驗老到的經理人,愈會被公司委以大任,執掌重要專案。這很理所當然。 出人意表的是,經理人處理的專案日益複雜,卻不再從中學習,結果往往執行不力,闕漏處處。 因此,必須了解為何會發生這種事,以及如何改變。

如果你正在尋找一位經驗豐富的經理人來帶領軟體開發團隊,在合適人選並不多的情況下,資深經理人艾力克斯(Alex)會是你的首選。艾力克斯進入職場後,大部分時間都從事軟體專案計畫。他的第一個職務是為美國太空總署(NASA)開發軟體,之後,他曾為多家公司和政府機關督導更複雜的專案。

我們有一項研究計畫,共有好幾百位專案經理人參與,艾力克斯正是其中的一員。這項計畫主要是要了解,在複雜環境下,有經驗基礎的人如何去學習。我們請他在電腦上玩一個遊戲,測試他的技能,他必須從頭到尾管理一個模擬的軟體專案計畫,包括制定計畫、監督並管理進度、觀察結果。我們為他設定目標:準時完成、預算不超支,並盡量達到最高品質(衡量品質的標準,是軟體產品還有多少缺陷)。

艾力克斯所作的各種決定,以及因而導致的各項結果,正反映受測經理人的典型表現。一開始,他組成只有四名工程師的小團隊,著重在開發工作。短期內,這個做法就收到良好的效果,團隊的生產力很高,開發工作快速進展。不過,專案不斷擴大,直到超出原先估計的規模時,突然冒出問題來了。艾力克斯決定讓團隊維持小規模,因此工程師必須更加賣力工作才能趕上進度;結果他們連連出錯,覺得筋疲力竭,終於紛紛求去。艾力克斯試圖雇用更多人,但這需要時間,而且訓練新人也需要時間。不久,專案就開始落後進度,而且就在這時,艾力克斯在專案早期疏於控管品質的後遺症就開始出現,軟體的錯誤如滾雪球般湧現,解決這些問題則需要更多時間和精力。後來專案終於完成了,不但逾期、超出預算,還有許多缺陷。

未能從經驗中學習

遊戲結束後,我們請艾力克斯反省整個模擬操作的過程。專案的成長超出他的預期嗎?缺陷的數目很多,或是人才招募很困難,令他大感震驚嗎?不幸的是,艾力克斯的回答和多數參與研究計畫的經理人一樣:這種令人意外和震驚的事,在他參與的專案中,經常發生。

大多數公司指派像艾力克斯這樣經驗老到的人,執掌重要的專案計畫時,並沒有預期到會出現令人傷腦筋的品質和人事問題。這類人才已是如此資深,即使未能防範這些問題的發生,也應該知道如何有效率地解決問題。不過,我們的實驗卻發現,經驗豐富的經理人並沒有創造高水準成果。我們的研究運用模擬遊戲,來檢視經理人在許多不同狀況下的決策過程。研究結果強烈顯示,艾力克斯和其他專案經理人從遊戲中學到經驗的方式,有些地方出錯了。他們在做新決策時,似乎沒有考慮到先前決策的後果,而且在行動產生不良結果時,也沒有改變做法。

我們的研究報告指出,參與者面對模擬遊戲中出現的挑戰,其實是熟悉的。我們要求參與實驗的人將這個遊戲與他們現實生活中的專案經驗作比較,以衡量相似程度,由1到5級給分,第5級代表「完全相同」。結果平均分數是4.32,表示我們的實驗確實與軟體專案的真實情況很相似。經理人過去在工作中雖然遭遇過類似情況,但他們在模擬實驗中仍然窮於應付。因此,我們得到一個結論:他們並沒有從現實生活的專案工作中學到經驗。

接下來,我們就要探討這種明顯的學習障礙現象,找出哪三個可能成因,並提出一些方法,建議有關的組織採行,以促使員工再度開始學習。

學習遇上了障礙

任何人在做決定時,會用到一些既有的知識,我們稱為「心智模式」(mental model),其中主要是對所處環境中因果關係所擬定的假設。人們在做了決定後,會觀察那些決定造成的結果,從中了解新的事實,進而對環境中的因果關係也會有新發現。如果覺得有些事物適用於其他情況,就會把這些發現再放入(或說「納入」)自己的心智模式中。表面看來,這個流程非常科學化:人們就因果關係擬定假設,根據這些假設行事,然後解讀行動結果,以確認原先的假設,否則就修改假設。問題是,這種做法似乎只在相當單純的環境中有效,因為其中的因果關係直截了當,很容易看出來。在較複雜的環境,例如軟體專案計畫,這個學習的過程經常會中斷。我們邀請一些經理人參與上述的實驗,就找出了現實世界中,和學習過程障礙有關的三種複雜形態。

形態1

因果之間有時間差

在現實世界中,因和果之間如果有時間差(time lag),恐怕就很難把兩者聯想在一起,也更難確認兩者之間有因果關係。為了解專案經理人如何處理這種問題,我們要求參與者玩一個模擬遊戲,由他們管理中型的衛星軟體開發專案。由於對產品的要求增加了,專案的規模也隨之大增。我們一共設計了四種作業環境,這些環境的不同之處在於,決定要聘用人員,和新成員到任之間的時間差各有不同;人員到任和融入團隊(assimilation)之間的時間差也不一樣;每個參與者必須在其中一種環境下,督導專案的進行。每個專案大約需要18個月才能完成,參與者必須每兩個月決定團隊的成員編制。接下來,我們評估經理人處理時間差的能力,評估方法是,把他們聘用團隊成員的決策,和兩種假設性的經理人決策作比較:一種經理人是經驗不足、從來沒有想到會有時間差,另一種是十分優秀、總是會考慮到時間差的經理人。

時間差愈長,專案完成得愈慢

所有參與實驗的經理人,他們督導的專案中,無論團隊成員的聘用和融入團隊之間的時間差如何,他們所做的決策都和經驗不足的經理人大同小異。這顯示他們在做規畫決策時,並未考慮到時間差造成的影響;也顯示出在單純環境中,也就是決策和後果的時間差很小,或根本沒有時間差的環境中,他們的心智模式較能發揮作用。時間差的長短很重要:參與者所處的環境中,如果成員由聘用到融入團隊之間的時間差較長,這些參與者在處理專案上遇到的困難,比時間差較短的參與者要多。而時間差的種類也很要緊:參與者在處理成員融入團隊的時間差方面,較為困難,因為這方面的時間差,遠比成員聘用的時間差更難掌控。若參與者負責管理的專案,在成員的聘用,和聘用後融入團隊這兩件事上,都有長期的時間差,他們處理時間差的能力就會急遽惡化,而且程度很嚴重。若和成員聘用與融入的時間差都比較短的情況相較,在時間差較長的情況下,參與實驗者要多付出83%的時間,而且整個專案完成時間也延後40%。

學到了知識,沒學會運用

有趣的是,許多案例中,參與實驗者是在專案末期才決定要加聘人手,但這和他們後來的說法相反。在遊戲結束後的報告中,我們要求參與者說明,如果專案進度落後,應該採用何種聘用政策較為恰當。大多數經驗豐富的經理人都說,他們不會加聘人員,而是先嘗試其他辦法,例如調整計畫、集中心力在少數幾項優先要務上,或是延長完成期限。不過,他們實際上並未這麼做。我們要求參與者在這項報告後進行第二項實驗,結果他們還是出現同樣的行為:管理長期時間差的經理人,還是到了專案末期才加聘人手。這顯示就算經理人已經具備或學到了某項知識,也未必懂得如何運用。

形態2

事先估計並不可靠

開發軟體時,經理人最初對專案的估計,會影響他在整個專案進行期間的決策走向。例如,對團隊成員生產力的估算,會影響他對團隊規模大小的抉擇,這項抉擇又會影響團隊實際的產出。問題是,初步估計到後來往往是錯的。

為了解經理人如何處理估計值不可靠的問題,我們進行另一個實驗以檢視他們的決策過程。在實驗中,我們提供經理人有關專案團隊生產力的初步估計值,之後,經理人必須根據工作進展,定期提出他們對團隊實際生產力的估計。我們準備了三種初步估計值,每個經理人會拿到其中一種。我們估計的是團隊中每人每天能完成多少工作,估計值分為低、中、高三種,這代表同一個專案若用不同的估算工具,所得出的估計值會有很大差異。經理人在實驗期間,必須針對團隊在三個時點的生產力,提供最新的估計值:在設計階段末期(第五個月),程式撰寫階段中期(第十個月),以及程式撰寫階段末期(第15個月)。經理人在每個時點上,會接到有關專案實際情況的進度報告,以及有關生產力的新估計;我們建議他們先參考這些報告的估計,然後再提出他們自己對團隊實際生產力的估計。

我們告訴參與者,會根據他們對生產力的估計,調整專案的人員編制和時程。但事實上,我們的實驗並沒有採用他們的估計值,這是為了要讓所有參與者都拿到相同的進度報告,才能比較不同的人所作的生產力估計值長期會如何變化。我們的假設是,那些經理人的生產力估計值會趨於相似(一段時日後,起初估計較低的人會提高估計值,起初估計較高的人則會降低)。

但實際情形如何?一段時日後,經理人的生產力估計值並沒有趨於相似,反而很明顯地偏向保守心態:所有的估計值都降低了,不但在一開始時收到高估計值的人如此,那些收到低估計值的人也一樣。而且,當經理人面對兩種生產力估計值(他們先前的估計,以及後來進度報告提供的新數值),他們會依據其中較低的那個數值來修改估計值。我們推測經理人持這種保守態度,是因為他們想要從系統中得到更多資源。

形態3

偏離初步目標

通常一開始,專案經理人會依據成本、時間與其他因素設定一套目標,但大多數專案的範圍會改變,甚或出現意外發展,以致早期訂定的目標常會不再適用。一旦發生這種情況,經理人就必須根據新情況來修正目標。

為了解經理人如何修正目標以因應專案範圍的改變,我們要求兩組不同的參與者負責管理專案,而且對那些專案的要求會愈來愈多。每一組經理人都有一套初步目標,每一套目標都包含兩個項目。「成本組」經理人受命要在預算內(944人-日)如期(272個工作天)製造出產品。「品質組」則受命要在同樣的時程內製造出產品,而且產品缺陷盡量降至最少。我們清楚表明,這些只是根據當時資料訂的初步目標;但我們會根據整體結果來評斷參與者的成敗,而不是根據初期目標。實驗進行到四分之一時,專案範圍擴大了,這時,經理人可以選擇修改他們最初的目標,像是預計預算會增加或期限會延後,但初期所訂的品質要求維持不變。雖然我們沒有明確要求參與者重新審視目標,但我們刻意讓參與者可以選擇這麼做。

不調整目標,壓低成果

結果兩組經理人都沒有根據新資訊而調整目標,相反地,他們堅守既定目標,結果都未能獲得最理想的成果。「成本組」為了壓低成本,以符合初期所訂的目標,雇用的人員遠少於理想人數,並且拖長了完成期限。結果,這些參與者雖然把超出的成本控制在59%以下,卻多花了17%的時間才完成專案,而且產品缺陷的數量激增到1,950項。另一方面,「品質組」雇用了太多人手,所以雖然在產品缺陷的控管方面達到目標,卻多花了9%的時間完成,而且預算超支多達107%。在一些案例中,固守既定目標反而會產生不良後果。「成本組」的經理人為了不超出預算,幾乎完全忽視品質保證(quality assurance)的要求。他們在整個過程中犯了許多錯誤,為了修正那些錯誤,使總體成本大幅上揚。

這些結果顯示,即使事態的發展讓專案原本設定的目標不合時宜,如果沒有明確要求經理人重訂目標,他們還是會繼續追求那些目標。我們不難看出這種偏差做法的成因。大多數有關發展與學習的心理研究都顯示,身為資淺人員時,人們會認為外界為他們設定的目標不可更改,並且把這個觀念納入他們的心智模式。這種偏見在他們成為經理人後,會進一步強化。在許多公司,修改目標等於承認失敗,所以經理人很快就發現,如果堅守最初的目標,並努力達成,對自己的事業發展較為有利,即使這麼做得到的整體結果較差也無妨。這樣的偏見深植在經理人的心智模式中。這就難怪,即使參與實驗的經理人明知,自己的表現是依據專案結果來評量,但他們在做決策時,還是受到上述那種偏見的影響。

不改變,也不認錯

我們的結論是,經理人或從較單純環境中得到的經驗,或是由老師傳授,培養出那種心智模式,因而覺得很難跳脫。一旦情況變得複雜,他們若不是視若無睹,就是試圖運用簡單的基本法則來處理。事實上,那種法則卻只適用於簡單的情況。他們並沒有大幅提升自己心智模式的品質,把專案的複雜情況考慮進去。

對於不斷強調從工作中學習的公司,這個結論有兩項重大涵義:

第一項是,經理人即使有出色的背景,對他們管理複雜專案的能力並沒有多少助益。許多公司通常會發現,把某個經驗豐富的專案經理人換掉,改由另一位經驗豐富的主管接手,並沒有什麼差別。儘管兩人都有處理複雜專案的經驗,但他們不會去改變在單純並類似環境養成的心智模式。其實在某些情況下,公司若聘用沒有經驗的經理人,反而可能獲得較佳結果。這並不代表經理人所做的決策截然不同,也不是說,外在條件可能會讓某個專案無法獲致良好結果,更不是說,有些經理人無法持續保持佳績。但大多數經理人,包括那些資歷無懈可擊的經理人,都未能持續在他們管理的專案上展現良好績效,更別提要精益求精以求取改進了。即使某些經理人的表現持續有進步,也可能是因為他們經驗略為不同所致,而不是因為他們從複雜專案中漸進、有系統地學習。

第二項涵義其實是源自第一項涵義。既然不論由誰來管理專案,結果都差不多,那麼經理人到最後都不會承認是自己的決策導致專案失敗,而會推給其他因素,例如,計畫太好高騖遠,或財務部門的要求過高(還有一種常見的藉口,就是業務代表對客戶誇下海口,所以為專案設定的目標太不切實際)。一旦經理人深信是別人的錯,就會開始往錯誤方向去尋找解決方案,來解決自己績效不佳的問題。這可能會造成慘痛的後果。

改正從經驗學習的過程

對大多數複雜專案的經理人來說,他們不再自經驗學習,但這個問題是可以解決的。組織可以採行一些步驟,讓經理人開始在複雜情境下學習。我們建議的做法中,有一些是承認經驗學習過程的缺失,並以其他方式來協助經理人克服這些問題,或是努力發現缺失,力求減少缺失發生。採行這些建議的公司很快就會發現,他們改善專案管理績效的能力可以持續提升。

做法1

提供更多認知回饋

在專案的進度報告中,通常會記錄很多與專案成果相關的回饋訊息。但在因果關係含糊不清的環境中,就無法把這些回饋訊息當作發現或確認問題成因的有效機制。在專案進行過程中,經理人所需要的回饋,必須能深入呈現專案重要變數間的關係,我們稱為「認知回饋」(cognitive feedback)。舉例來說,「複雜專案的認知回饋」表顯示的是,專案最初八十天發現缺陷所占比率,與品質保證水準之間的關係。在這個案例中,經理人起初選擇了相當低的品質保證水準,但在一段時日後提高了品保水準;但由於人們更努力去尋找缺陷,缺陷率也隨之提高,而提高的幅度比品保水準更大,只是發生的時間較遲。接下來,缺陷率下降,顯示已經找出大多數缺陷加以修正,現在經理人可以把品質保證維持在這個水準,甚至是缺陷率更低的水準。雖然這種回饋並非完全沒有錯誤,但可以讓經理人了解複雜的動態關係。

我們的研究中,清楚顯示這種回饋的優點:模擬實驗中,經理人得到認知回饋後,對所處環境有更深入的了解,做出的決策也得到較佳結果。我們建議,各公司致力把認知回饋納入專案定期進度報告。我們也發現,將不同專案的資料匯集在一起時,這種回饋更加有效,也得以檢視橫跨多項專案的行動會有什麼影響。

我們認識的一家知名企業軟體供應商,在進行開發專案時就運用到認知回饋;這家公司的高階主管一致認為,認知回饋有助於專案經理人獲得更深入的見解。經理人的決策也明顯有了改進:據公司計算,在三年內,專案問題出現的比例下降了56%。

做法2

運用決策支援工具

我們的研究都顯示,經理人在動態的軟體專案管理方面,無法做到足夠的心智紀錄(mental bookkeeping)。光靠直覺並不夠,經理人在決策關頭,需要運用工具協助。以人員編制決策為例,經理人雇用一些人員後,每個人從錄用到上任之間,以及上任到融入團隊之間,都會有時間差。一段時日後,經理人就很難估計現有的生產力,也不容易預測未來的生產力;如果有成員離職,更是格外因難。但如果這位經理人有一些工具,可以用來計算不同時期增加人手的效果和流動率,他就能更清楚了解,人員異動在中期可能會持續對團隊生產力產生哪些影響。這類工具也可以包含為有問題專案設置的「警報觸發器」機制(例如,在應該考慮縮減規模時,就會發出訊號提醒經理人);或者制定規則,以便在專案各階段,都能在開發工作的進行和品質保證之間取得適當平衡。我們的研究顯示,這類工具改善了決策,並協助新經理人可以更快進入狀況。

和我們合作的一家軟體業領導廠商,有一套專為這個目的而設置的決策支援系統。這家公司的經理人可以運用這些系統,預估可能的離職率、分析新聘人員對團隊生產力的影響,還可以為一些問題找答案,像是專案後期增聘人員是否有用等問題。使用這些決策支援工具的經理人表示,他們覺得自己的專案掌控能力遠勝從前,他們專案的績效也大為提升。在業界,這家公司也以產品品質一流享有盛名。

做法3

依專案選用預測工具

組織可以依照專案特定的情況,選用專案預測工具,其中考慮的因素包括:產業、當地環境、可用人員的技能。

不過,許多組織只是直接從其他環境和公司,引進專案管理的預測工具。我們研究的某家軟體公司,採用原為航太公司使用的工具。

此外,許多組織根據過去的專案資料來建立新專案的假設,卻沒有先行「清理」(scrubbing)那些資料(也就是沒有先說明那些專案面對的異常狀況),使得進行預測更加複雜。難怪用那些工具作出的預測通常並不可靠,難以取信經理人。如果經理人不相信那些預測,就會仰賴自己的觀感,重新採用他們在單純情況下發展出來的法則。

為了避免這種情形,公司應該盡力強化經理人對專案預測的信心,也就是要依照專案的需要,打造專用的預測模式,並「清理」那些用來擬定假設和推論因果的資料。而在資料蒐集和處理方面,經理人下的工夫愈多,預測就會愈準確。在這個領域中,如果以成功的專案經理人為學習比較對象,進行簡化的「最佳實務」(best practice)標竿管理,其實是很危險的做法。

某家半導體業領導廠商研發中心,設計了一個可減少預估錯誤的方法。每當有專案完成時,研發中心就啟動一個分成三步驟的流程,將那個專案的結果「正常化」(normalize)。這三步驟是:找出不尋常的事件、概略計算這些事件的影響,然後從結果中排除這個影響。之後,這個「清理過」的價值(scrubbed value)就被納入預測模式中。

做法4

不為績效設定目標

預測工具的另一個通病是,這些工具通常是根據產品的規模大小來作預測,例如,程式碼有多少行或功能點(function point)多少,這些在規畫階段都極難精確預測。

此外,經過一段時日後,可交貨的產品可能會有變化,而且變化的方式很難預測。因此,最初的預測並不是好目標。如果以最初的預測為目標,經理人會因而採行不當的因應做法,例如在成本和品質間作取捨,導致不理想的結果。

不過,軟體專案通常都是依據初步的預測,來制定成本和時程的目標。如果公司根據不可靠的預估值來訂定目標,然後依據那些目標來衡量經理人的表現,經理人就會選擇「安全的」預估值,以便取得寬鬆的成本和時程。結果他們會把那些寬鬆條件浪費在無謂的工作上,在專案裡增添一些沒有必要的功能。因此,重新思考設定專案目標的方式很重要。

公司尤其必須了解,若要讓預估值和目標都發揮最佳功效,就應該把預估值當成規畫和控管工具,把目標當成促進員工展現合宜行為的機制。

我們建議公司在設定目標時,採行兩步驟的流程:首先,決定公司想要促成的行為,然後設定能激發這種行為的目標。在單一專案中,組織可能會決定要求經理人,讓團隊成員的流動率降到最低(如此可以提高生產力和學習效果,並減少錯誤)。然後,就可以把這一點明確納入整組目標中。為達成這個目標,經理人必須設法減輕團隊的時程壓力,並降低人員常態離職對團隊的衝擊。

我們發現,如果經理人負責管理多項專案,目標就應該是採行具體措施,以盡量擴大所有專案的績效(而不是個別專案的成功)。設定這種目標時,組織必須給予經理人某種程度的自由,比方說,由他們來協商決定專案範圍和時程,以維持團隊的穩定性,或是防止問題產生而波及其他專案。此外,組織在設定目標時,應該讓經理人有機會表達意見,以確保他們會熱忱投入專案。

做法5

開發專案的「模擬飛行器」

實際運作的專案,顯然不是最好的學習環境,不過,還是可能建立一個人為控制的環境,不致因環境複雜而讓人無法從中學習。

我們在此用模擬飛行器來作比喻。駕駛飛機的技巧,和機型有很大的關係:飛行員改飛不同機型的飛機時,都得接受大量訓練(即使只是從波音747貨機改飛同型客機,都得如此)。模擬飛行器是這個轉換流程的關鍵部分。

在軟體專案的管理上,適當建構的「模擬飛行器」,可以扮演類似的角色,讓人在虛擬的環境下接受訓練。我們特別提出這種需求,是因為目前的專案經理人比過去更常跳槽。由於知識和環境(或和公司)有密切相關性,每次經理人轉換公司或工作環境時,就必須了解新環境內的各種關係,例如,哪些因素會提升生產力和品質。我們建議公司實施分等級的訓練計畫,讓經理人在一開始時處於因果關係很單純的輕鬆環境;接下來逐漸進入因果關係比較複雜的嚴峻環境,其中回饋的訊息也比較不可靠(若要創造這種環境,可以逐漸拉長因與果之間的時間差)。我們建議,隨著受訓者的進步,訓練計畫應該更加著重動態關係,例如,著重用人決策和品質保證成果之間的關係,因為這些都是經理人最難了解的關係。

和我們合作的一家衛星軟體公司,使用這種「模擬飛行器」的方法,結果成效良好。

這家公司開發了一套專案管理遊戲,把公司所處環境的現實情況納入,例如,納入對產品品質與生產力衝擊最大的因素,並模仿公司實際專案的流程和結果。新經理人在負責掌管專案前,利用這個遊戲來學習專案管理的必備知識。初步成果很令人振奮:經理人比過去更深入了解專案中的動態關係,專案的績效也因而提升了。

高階人員更要培訓

我們描述了學習過程的問題,但這些並不是學習過程中出現的唯一障礙。我們也不會自認本文所提的建議可以解決所有問題。

但我們所做的研究,以及本文中提出的研究結果,都提出強烈的證據,顯示由做中學的方式,只有在最基本單純的環境中才有效;若要讓經理人持續學習,組織就必須針對他們未來會面臨的挑戰,設計正式的訓練和決策的支援工具,供他們運用。一般公司通常會把大部分訓練經費花在初階人員身上,往往是從其他公司把整套專案規畫工具搬來套用。

另一方面,公司期望資深人員一到任就能上手,也以為過去的最佳實務真的就是最佳實務。正因如此,才會有這麼多經驗豐富的經理人在承擔新職責時失敗了。公司應該讓低階人員自行學習,而把大筆訓練預算花在層級較高的人員上,同時放棄從其他地方尋求快速解決辦法的念頭。

(侯秀琴譯自“The Experience Trap,” HBR, February 2008)



基修爾.森加塔 Kishore Sengupta

(kishore.sengupta@insead.edu) 法國歐洲工商管理學院(Insead)教授。


塔瑞克.艾伯達-哈米德 Tarek K. Abdel-Hamid

(tkabdelh@nps.edu) 加州的美國海軍研究學院(Naval Postgraduate School)教授。


陸克.范瓦森霍夫 Luk N. Van Wassenhove

法國楓丹白露(Fontainebleau)歐洲工商管理學院(Insead)製造學講座教授。〈逆向供應鏈〉(“The Reverse Supply Chain,”HBR , February 2002)的共同作者。


本篇文章主題培養領導力