從Scrum之父探源敏捷方法論

2022-01-30 創新禪

         「Jeff Sutherland」Scrum之父,敏捷宣言(Agile Manifesto)起草人。薩瑟蘭畢業於西點軍校,越戰期間是出色的戰鬥機飛行員,擅長低空飛越北越進行偵察任務。越戰歸來後,先在史丹佛大學取得統計碩士學位,後於科羅拉多大學醫學院取得生物統計學博士學位,其指導教授John Bailar是醫學暨統計學最知名的研究學者之一。現在為Scrum基金會總裁。他在空軍訓練中學到:觀察(Observe)、導向(Orient)、決定(Decide)、行動(Act)的循環方法。

        Scrum是目前全球最為廣泛採用的敏捷工作法(1,500萬人正在天天使用中),Amazon有3,300個Scrum開發團隊,Intel則有500個Scrum teams,Tesla、Apple、BOSCH、J.P. Morgan、及日本的TRI-AD/Toyota、Docomo、KDDI .

       911事件發生後,事件調查委員會試圖找出事情發生的關鍵原因。該委員會指出,負責分析情報的人員未能取得一些原本應該要分析的情報。 「FBI的資訊系統效能不彰,」報告中寫道,「這意謂著情報分析人員多半得仰賴與工作部門或工作小組成員間的私交, 才能從存放情報的單位取得情報。」 這是該委員會的結論:「FBI缺乏知道自己欠缺什麼的能力:內部缺少一個能吸收或分享組織知識的有效機制。」 

        FBI「自動化案件支援」(Automated Case Support)系統架設於 1980年代曾經走在時代尖端的大型主機上。但是,很多幹員根本不用這套系統,因為它實在太笨重又太遲緩。

     「你得在文書處理軟體中打好內容,然後列印出三份。第一份是 要請上級層層核可的;第二份是要存放起來,以防第一份遺失的;第三份你得拿一枝紅筆──我沒開玩笑,真的是紅筆,圈出關鍵字,輸入 資料庫中,因為你得為自己的報告做索引。」 這樣的情景在官僚化系統裡最為常見。

       這種管理方式實在太過時又鬆散,一度備受詬病:FBI明明早在九一一事件前幾個星期就已得知,有多名激進組織的份子進入美國,卻未能把種種跡象的關聯性加以串連,有人認為部分的原因就出在檔案系統上。當時FBI的某單位對某個目標起疑,另一個單位對於有這麼多可疑的外國人在接受飛行訓練感到事有蹊蹺,還有一個單位則是把某蓋達成員列入監視名單,卻從未通知其他單位。在FBI 內部,沒有人把這些事情全部拼湊在一起。

       當參議員們開始質詢FBI一些難堪的問題時,FBI基本上都會回 答:「別擔心,我們已經有一個正在進行中的現代化計劃了。」該計劃要發展的是一套名為「虛擬案件檔案」(Virtual Case File, VCF) 的系統,照理說這應該可以讓一切改觀。FBI的官員很懂得利用每一 次面臨的危機,他們向參議院表示,該計劃除了原本已撥款的1億美元經費以外,只需要再追加7,000萬美元經費就夠了。假如你回頭去找當時媒體對VCF系統的報導,你會發現內文大量使用諸如「革命性 的」與「轉型」之類的字眼。三年後,計劃終止了,因為根本不管用,連一絲一毫的效果都沒有。FBI已經花費納稅人1.7億美元的辛苦錢,買到的卻是一個永遠不會有人使用的電腦系統──沒有任何一行程式碼、應用程式派得上用場,也不會有任何的滑鼠點擊。整個計劃根本是一場災難。

       2005年,FBI展開名為「哨兵」(Sentinel)的新計劃。這次一定要管用,這次一定要用對預防措施,一定要跑對預算流程,一定要做好控管。畢竟FBI已經得到教訓。哨兵計劃造價多少?只要4.51億美元,而且2009年就能全面上線。 受僱建置哨兵系統的承包商Lockheed Martin已經用掉4.05億美元的經費,卻只完成一半的工作,而且這時候的進度還落後了一年。一項獨立分析預估,這個專案可能還要六年到八年才能完成,而且納稅人為此至少必須再花3.5億美元。FBI花費近十年的時間試圖更新局裡的電腦系統,但是專案看起來即將「再次」失敗,成為史上最大的軟體災難。

      原因不在於這些人不夠聰明,也不在於FBI所託非人,甚至不是選錯技術的問題。問題無關乎職業道德,或是缺乏外來的競爭刺激。原因在於大家工作的方式不對,大多數人都用錯了工作方法。我們都以為工作應該要那樣完成,只因為別人教我們的就是那一套。

       Lockheed Martin的成員在投標前先開會檢視系統需求(有1,100項需求,堆起來大概幾吋厚),而後開始著手規劃如何打造出一個滿足所有需求的系統。他們會交由公司內部的大量人才處理,花費幾個月的時間整理出必須完成的事項。接著,再花幾個月的時間 規劃如何完成。他們會劃出許多美觀的圖表、解說每件必須完成的工 作,以及每件工作所需的時間。然後會小心挑選顏色,把計劃的每一個部分以層層相接的形式呈現出來,看起來就像一道傾瀉而下的瀑布。

        大多數的軟體開發專案都還是採用瀑布法,專案分成多個階段完成,一個又一個階段發展出準備釋出 給顧客或軟體使用者的終極版。流程很緩慢,也無法預知成果,而且往往會做出使用者並不想要或不願付費購買的產品。進度延遲幾個月或幾年是家常便飯。這種事前先把每一步都規劃好的計劃, 會把所有細節都畫成甘特圖,也讓管理高層相信開發的過程完全在掌控中,但結果往往是進度很快就開始落後,而且預算嚴重超支。

        這類圖表叫做甘特圖(Gantt chart),因為它是由亨利.甘特 (Henry Gantt)所發明的。1980年代,個人電腦的問世讓大家能很容易就畫出這種複雜的圖表,但是也讓圖表變得極其複雜,甘特圖於是成為一種藝術品。專案中的每一個階段都巨細靡遺地設定好了,包括每一個裡程碑、每一個交日期在內。這些圖表看了真的會讓人留 下深刻的印象,但唯一的問題卻在於它們往往是錯的。

       甘特大約在1910年發明這種知名圖表,最早使用甘特圖的是第一次世界大戰時擔任陸軍軍械部部長的William Crozier將軍。任何研究過第一次世界大戰的人都知道,有效的組織能力在那次大戰中實在稱不上是什麼突出的特質。我一直都很納悶, 為什麼甘特圖這種一次世界大戰時的玩意兒會變成21世紀專案管理中的既定標準工具。我們現在已經不再打壕溝戰,但是當年用於規劃壕溝戰的思維到現在卻依然流行。艾森豪曾說過,為戰爭擬定計劃固然重要,但是等到開了第一槍後,計劃就化為烏有了。他很有見地的沒有使用甘特圖。

       傳統上,管理團隊對於任何專案都會要求兩個條件:控制和可預測性。這會帶來為數眾多的文件與圖表,就像Lockheed Martin一樣,會花好幾個月的時間規劃所有細節,以確保沒有任何錯誤,沒有任何成本超支,而每件事也都能按照時程完成。

       問題在於,這樣美好情節從未真正發生。所有用於規劃的心力、用於限制變化與釐清未知事項的努力全部都是白費。每個專案一定都會出現許多的問題,冒出許多新想法。試圖把任何規模的人類行為限制在全彩圖表裡,不但愚蠢,而且註定會一敗塗地。人不是這樣做事的,專案不是這樣進展的,想法也不是這樣落實的,美好的成果更不是這樣創造的。

        Scrum的固定儀式之一是詢問大家很簡單的三個問題:從我們上次交談後到現在,你做了什麼?在我們下次再討論之前,你打算做什麼?有什麼事情幹擾你嗎?這可以促使 特派員們彼此討論並分享資訊。在每次開會後,Scrum Master要負責確保任何幹擾團隊工作的因素在下一次開會前已經被排除,否則流程就無法「流動」。

      大野耐一提出的關鍵概念「流程」,意思是生產流程應該流暢平順;管理團隊的重要任務之一在於找出流程中的阻礙,並且予以排除。任何擋在路中央的東西都會造成浪費。他的經典著作《豐田生產方式:追求超脫規模的經營》(The Toyota Production System)中,評定「浪費」的道德價值及商業價值:在低成長時期,這樣的浪費不但是商業損失,更是社會犯罪。排除浪費必須是企業的首要目標。想要讓Scrum真正發揮功能,高階管理團隊中必須有人發自內心地把阻礙視為近乎罪犯。大野耐一談到三種不同的浪費,他用的是日文字眼:Muri、 Mura、Muda。Muri指的是因為不合理、不恰當導致浪費;Mura指的 是因為缺乏一致性導致浪費;Muda指的是成果欠佳導致浪費。這些想法與PDCA循環高度契合,也就是規劃、執 行、檢核、行動。規劃意謂著要避免Muri,執行意謂著要避免Mura, 檢核意謂著要避免Muda,而行動意謂著我們要有意志、動機及決心把這些事做好。節奏是Scrum的核心,運作得宜的Scrum團隊可望實現我們所稱的「超生產力」。

      美國太空總署採用的「階段-關卡」流程就是經典案例。美國太空總署在1960年代、1970年代及1980年代就是使用這套流程執行太空梭等計劃。現在的流程已經大不相同了,這裡講述的是他們那套舊流程的運作方法。首先,從探索「階段」著手,大家決定要設法完成的目標,比如說打造一艘登月火箭。一群策略人員坐在房裡,想像著那幅場景。接著會有一個「關卡」,由一位或一群管理者籤名,認可該專案有發展的價值。再來進入初步調查階段,所有的「需求人員」 必須決定該做哪些事。接著會有另一個關卡,又要開好幾次的會,產出的所有龐大文件要轉交到下一個階段──細步調查階段,並擬定專案計劃。再來,所有的計畫又必須歷經一連串的會議與核可,完畢之後再送到下一個階段──開發階段,到這時才會真的開始動手生產。接著又是一堆會議與文件,然後把產品交到另一群人手中,進入下一個階 段──測試。測試人員先前從未看過產品,但他們還是照測不誤,然後籤名核可,再把產品放到另一個關卡前,也就是永無止盡的開會,這時會再產出一批根本沒有人會閱讀的文件。直到這裡,產品總算要送到第六批人員的手中,由這些人實際推動上市。光是把這些過程寫出來就累死人了,但這卻是美國太空總署過去發展計劃的過程。物理學家Richard Feynman:「無論是出於內部或外部所需的任何理由,看來美國太空總署的管理當局誇大產品的可靠度已經到了幻想的地步。」只要資料在不同團隊間移交,就有發生災難的可能。正如刊載在《美國聯合部隊季刊》(Joint Force Quarterly)上,一篇名為􏰀情報監偵之運用:特種部隊最佳實務􏰀(Employing ISR: SOF Best Practices)的文章中所寫的:跨部門團隊在伊拉克讓不同盟軍團隊之間更加合作無間,可以 「目不轉睛地」緊盯重要目標.假如不同單位或組織間還得交接任務,恐怕將創造出「三不管地帶」,不但會讓行動的動能減緩,目標還可能趁機逃走。

      人類非常不善於預估事情,但是幸好我們倒是很擅長設定相對規模,也就是比較兩件事之間的相對大小,像是在 一堆T恤中挑出S尺寸、M尺寸、L尺寸。這就是設定相對規模,只比較任務的大小。這些數字有種規則:1、3、5、8、13。8是前兩個數字的總和,13也是前兩個數字的總和,這種數列稱為「費氏數列」(Fibonacci sequence)。研究顯示,即便花費好幾個月規劃,預測值與實際值之間還是可能有上下四倍的落差。所以,我才會認為做事時若採用瀑布法規劃真的是蠢得可以。

     「敏捷」一詞要回溯到2001年的一場秘密會議,當時Jeff Sutherland和另外十六位軟體開發的領導人物共同擬定後來大家所知道的「敏捷軟體開發宣言」(Agile Manifesto)。宣言中明白指出以下幾種價值: 人比流程重要;產品實際管用比在文件中列出產品應有規格重要;與顧客合作比和顧客談判重要;因應變化比遵循計劃重要。Scrum是一 個我用來落實這幾項價值的架構。

        Nicola Dourambeis在Salesforce.com負責敏捷實務。在這家經常名列Fortune「百大最佳僱主」與 Forbes「全球最創新企業」的公司裡,她得帶領兩百多個Scrum團隊。她表示,她視Scrum為公司的「秘方」。「以前我們還是新創企業時,」她說:「每年我們都會發表三、四次的新產 品。但是,隨著公司成長、規模擴大,改為以典型的瀑布法管理專案後,在2005年至2006年間卻下降到一年發表一次新產品。我們一定得改變這樣的狀況不可,因此才會導入Scrum。在那之後,我們一直都維持每年發表三次,並沒有多少大企業能做到這點。」

        這個世界日趨複雜,我們的工作也以愈來愈快的速度複雜化。以車子為例,過去的人時常在愛車上做一些基本維修工作。現在打開引擎蓋後,看到的東西可能有如電腦內部一樣。因為新款福特汽車的程式碼行數已經比臉書與推特加起來還多。要打造這麼複雜的東西,得耗費龐大的心力。但是,當人經手複雜的創造性活動, 不管是把火箭送上太空、設計更好的電燈開關,或是追捕罪犯,傳統的管理手法根本就不管用。

      我們也都聽別人說過,把表格填對會比把工作做好來得重要,或是我們得為即將到來的會議先開個會前會。這太愚蠢了,但我們卻還是照做不誤,即便我們已承受過絕對且全面的失敗。

       為了免除這些缺失,Jeff Sutherland在1993年想出一種做事的新方法: Scrum。這個名詞來自於橄欖球中的「爭球」,指的是全隊通力合作把球往後場傳的一種方式。這必須結合細膩的團隊合作、一致的意念,以及明確的目標才能做到,用來比喻我對團隊的要求再適切不過了。Scrum源自於豐田生產系統(Toyota Production System),以及空戰的OODA循環。它徹底改變過去那種由上而下、規範式的專案管理手法。相較之下,Scrum可說是一種具備進化能力、有彈性、還能自我修正的制度。

       1950年,戴明曾對日本企業領導者進行一次知名的演說。聽眾中還包括索尼(Sony)創辦人之一的盛田昭夫。戴明在演說中告訴聽眾:.無論你們的技術人員有多麼出色,身為領導者的你們都必須追求改善產品品質與一致性,技術人員才會懂得改善。因此,第一步就在管理階層的身上。首先,你必須讓技術人員與工廠知道,你是一 個對於提升產品品質與一致性很有熱情的人,對於產品的品質也很有責任感。假如你只是光說不練,這一切都不會發生。身體力行是很重要的。至於身體力行的方法,就是PDCA循環〔規劃(Plan)、執行 (Do)、檢核(Check)、行動(Act)〕,這或許也是戴明最出名的理論。這樣的循環幾乎可以用在任何東西的生產上,無論是汽車、 電玩,甚至連紙飛機都行。任何類型的 「精實」(Lean)生產(美國人以此稱呼豐田生產系統的概念),或是Scrum的產品開發,依據的也都是PDCA。

        Scrum,就像合氣道或者像跳探戈一樣,是一種只能從做中學的學問,你的身體、思維及性靈可以透過經常的實踐與改善而趨於一致。在武術中有一種概念稱為「守破離」,分別是指三種不同的精通層次。

「守」的狀態指的是你懂得所有規則與動作。不斷重複動作,好讓身體學會,就像在學習舞步時那樣。守就是能做到不會出錯。

「破」的狀態指的是,在精熟動作之後開始懂得創新。像是跳舞時在地板上一踏後又自己多加一甩。

 「離」的狀態指的是,已經不受既有動作的限制,能夠真正融入其中,可以隨心所欲地創造新動作,因為對於合氣道或探戈的知識與意義已經瞭然於胸,你的一舉手一投足都會展現出精髓。

        Scrum把不確定性與創造性都納入考量。它的結構是隨著學習過程而建立的,團隊可藉以評估既有的成果,也評估創造出成果的手法,而這兩者其實同樣重要。Scrum架構會控管團隊的實際工作方式,並提供自我組織、快速改善工作速度與品質的工具。

         Scrum最根本的想法很簡單:在展開一項專案時,經常審視它,看看正在處理的事是否朝著正確方向進行?它是不是大家真正想要的?同時檢視是否能改善目前正在採用的行事手法,如何做得更好又更快,以及可能會成為阻礙的因素。這個循環稱為「檢驗與調整」(Inspect and Adapt)。

       竹內弘高與野中鬱次郎教授在最早談及Scrum原型的文章􏰀新新產品開發遊戲􏰀中,描述他們在全球一流企業中的團隊看見的特質:

卓越:這些團隊都抱持著非比尋常的目標,這種自我實現的目標促使從平凡往超凡發展。他們不甘平凡、想要出眾的決心, 不但改變他們看待自己的方式,也讓他們的能耐變得不同。

自主:這些團隊都懂得自我組織與自我管理,有權力自行決定如何做事,並被賦權堅持自己的決定。

跨功能:這些團隊都擁有完成專案需要的所有技能,規劃、設計、生產、銷售、配送,而且不同技能會在相輔相成中日益精進。正如為佳能(Canon)設計出一款革命性新相機的團隊成員所言:「當所有團隊成員都身處於一個大房間裡,別人提供的資訊都會變成你的資訊,你根本不用再試。因此,你就會設想,對這個團隊來說,最佳選擇或次佳選擇是什麼?你不會只從自己的角度來思考。」

      在Scrum中有一個很重要的觀念是:團隊成員必須自行決定要如何完成工作。管理階層的職責在於制定策略目標,但團隊的工作則是在於決定如何達成目標。

       Scrum之道並非只能運用在商業上。這套方法來處理我們的物種正在面臨的問題,像是依賴石油、教育品質低劣、全球一些貧困地區缺乏乾淨水源的問題,或是犯罪猖獗等問題上嗎?難道不能用不同方法過生活、工作與解決問題嗎?難道不能當成一種我們能實際改變世界的方法嗎?答案是可以的。有人正在利用Scurm解決我所提到的這些問題,而且已經創造出可觀的影響。

Jeff Sutherland敏捷思想指導方法

擬定計劃是有用的,盲目跟隨計劃是愚蠢的。把眾多圖表全都畫出來的誘惑很難抵擋。這可以把一項龐大專案中所有必須完成的工作,全都一一攤在每個人的眼前提供檢視,問題是,詳細製作的計劃一碰到現實,馬上就會隨之瓦解。應該把對於變化、發現與新想法的假定,都內建於工作方法中。

檢驗與調整。每隔一陣子,就要暫停手邊的工作,檢驗既有成果, 看看它是否仍是你該做的,也看看有沒有更好的方法可以採行。

不改變,就等死。對於老派的工作方法、「命令-控制」的管理手 法,以及高度可預測性的堅持,只會導致失敗。同時,還可能會被採用Scrum的競爭對手拋在腦後。

快快失敗,才能速速改正。企業文化往往看重形式、程序及會議, 而非短期內創造出可供使用者檢驗的可見價值。任何無法創造價值的工作都是愚行。把工作切割為多個較小的循環,可容許早期使用者提供回饋,開發人員也能即時免除明顯會白費的心力。

遲疑是會致命的。觀察、導向、決定、行動。了解身處何地、評估選項、做決定,然後行動!

向外部尋找答案。複雜的適應系統都有少數幾項簡單法則可循,而且是從環境中學來的。

出色的團隊是:跨功能、自主、得到授權,具有崇高目標。

別用猜的,要規劃、執行、檢核、行動。規劃好你要做什麼,然後執行。檢核成果是否如同預期,然後據此採取行動、調整做法。一 直重複這樣的循環,就能實現持續改善。

守破離。首先,要學會規則與動作,等到精熟之後開始創新。最 後,進入高度精熟的狀態,捨棄形式,只是自然而然地存在,因為一切都已內化,可以不假思索就做出決定。

要拉對控制杆。改善團隊績效的影響比改善個人績效的效果大得多,而兩者可能會相差好幾倍。

卓越的目標。傑出團隊都抱持著超越個人層次的目標,像是為麥克阿瑟將軍送行、贏得NBA冠軍等。

自主性。要給予團隊自行決定如何行事的自由,尊重他們的專業。無論是在中東報導革命運動,還是在談生意,現場的因應能力都可能會帶來很大的不同。

跨功能。團隊必須擁有完成一項專案需要的所有技能,不管是推銷 Salesforce.com的軟體,還是逮捕伊拉克的恐怖份子都一樣。

小團隊致勝。小團隊完成工作的速度比大團隊來得快。以經驗法則來說,最適成員人數以七人加減兩人為宜,寧可人少一點。

指責是一種愚行。別數落成員的不是,應該挑出不良制度的毛病, 也就是針對那些鼓勵不良行為、獎勵低劣表現的制度挑毛病。

時間有限,請善待它。把你的工作分割為在已經設定好的一段固定的短時間內能完成的量,最好是以一周至四周為一段。假如你熱衷 於Scrum,不妨稱它為「衝刺」。

不展示,就完蛋。每段衝刺結束時,都要提出已經完成的部分── 某種能使用的東西(像是能飛、能開等)。

丟掉你的名片。頭銜是你專業地位的象徵。應該要讓人知道的是你做什麼事,而非別人怎麼稱呼你。

要讓每個人都知道每件事情的進展。溝通飽和度可提升工作速度。

每天開會。這種全員出席的場合只要一天一次就夠了。大家在每日立會中碰頭十五分鐘,找出有什麼事能加快工作速度,然後去做。

多工使人變笨。一次做超過一件事會拖慢你做這些事的速度,也會讓成果變差。不要這麼做。假如你覺得自己不會這樣,你就錯了。

事情做一半等於沒完成。生產到一半的車子,只耗費原本可以用來創造價值或節省金錢的資源而已。任何「在制」的東西都一樣,只會耗費金錢與心力,卻沒傳遞出任何東西。

第一次就把事做對。當你犯錯時要馬上改正,停下手邊所有事,把它處理好。過一陣子再回來改正,可能會比當下就改正花費二十多倍的時間。

太努力工作會增加工作量。長時間工作並不會讓你做完更多的事, 反而讓你做得更少。工作太操勞會導致疲憊,疲憊就會導致錯誤, 迫使你必須改正自己才剛完成的事物。平常和周末都不要加班,只在平日以自己能接受的速度做事,也別忘了要休假。

避免不合理。有挑戰性的目標可以激勵人心;不可能的目標只會打擊人心。

不走英雄主義。假如你需要一個英雄來把事情完成,你就有問題 了。靠英雄來解決,應該視為規劃發生了問題。

不再忍受莫名其妙的規定。任何讓人覺得離譜的規定,很可能真的很離譜。莫名其妙的表格、莫名其妙的會議、莫名其妙的批准過程、莫名其妙的標準等,真的就是莫名其妙。假如你們辦公室和 《呆伯特》漫畫裡的情境很相像,趕快改正它。

拒絕渾球。別當渾球,也別容許渾球行徑。任何會造成別人情緒紊亂、引發恐懼或驚慌、貶抑或輕視他人的傢伙,都必須全面阻止。

追求自然流動。選擇最順暢、最不困難的方式做事,Scrum就是要儘可能促成這樣的自然流動。

地圖並不代表實際地貌。別愛上自己的計劃,它十之八九會有問題。

只規劃必須做的事。別試圖規劃未來幾年內的某件事,只要規劃足以讓團隊忙碌的計劃即可。

它是哪種狗?預估進度時別用「小時」之類的絕對單位。事實已經證明,人類很不擅長做估計。要預估相對複雜度,它是哪一種品種的狗?哪一種大小的T恤(S、M、L、XL、XXL)?或是更簡單一 點,就用費氏數列的數字來估算。

問問神諭。使用匿名估算的技巧,像是德菲法,以避免月暈效應或 從眾效應等定錨偏誤,或是純粹的團體迷思出現。

運用撲克牌。使用規劃撲克牌迅速估算出必須完成的工作。

工作就是故事。先想想誰會從某些事中得到價值,再想想那是什麼 價值,以及這些人為何會需要這些價值。人們都是用情節來思考 的,就為他們編一個故事吧!身為X,我想要Y,所以Z。

了解自己的速度。每個團隊都應該具體知道自己在每段衝刺中能完 成多少工作,並且藉由採用更聰明的工作方法與去除拖慢速度的障 礙,能夠改善多少速度。

速度×時間=交期。得知工作速度,就能算出完成日。

設定大膽目標。有了Scrum,要讓生產力翻倍或交期減半並不是那 麼困難。只要以正確方式實施Scrum,營收與股價應該也會翻倍。

重點是旅程,而非目的地。真正的快樂來自過程,而非結果。我們 往往只獎勵結果,但我們真正想獎勵的應該是努力朝向卓越邁進的那些人。

快樂是時興的潮流。快樂有助於你做出更聰明的決定,而且在你快 樂時,你會更有創造力、比較不會離職,也更可能創造出超出自己 想像的成果。

把快樂量化。光是「感覺」不錯並不夠,還必須測量感覺的強弱, 與實際績效相互比較。其他指標都是回顧過去,而快樂卻是一個展 望未來的指標。

每天進步一點,也別忘了要衡量成果。在每段衝刺結束時,團隊應 該找出一項未來能讓大家更快樂的改善項目,並且指定為下一段衝 刺時應該完成的重要事項。

秘而不宣會害死你。沒有任何事應該隱瞞,每個人都應該知道每件 事的資訊,包括薪水與公司財務狀況在內。只有那些私利至上的人 才會打迷糊仗。

工作要可視化。在辦公室擺上一面板子,把所有應完成的工作、進 行中的工作,以及已實際完成的工作都列出來。每個人都應該去 看,也應該每天更新。

自主、精熟及有目標就是快樂。人人都想掌控自己的命運、都想把 正在處理的事做得更好,也都想追求超乎個人層次的目標。

戳破快樂泡沫。別太過快樂到連自己沒做好的事都覺得做得很好。要把自己的快樂和績效做比較,如果兩者之間存在落差就要準備採 取行動。自我感覺良好是成功的死對頭。

擬定清單,檢查兩次。建立一份清單,裡面是所有你在專案裡可能 做到的事,然後安排優先順序。把最有價值、風險又最低的項目放 在待辦事項清單的第一位,再列下一個和下下一個。

產品負責人。負責把願景轉換成待辦事項清單;必須了解案件、市 場及顧客。

領導者不是老闆。產品負責人決定必須做的事項與原因,至於該怎 麼做、由誰來做則是團隊自己的事。 

產品負責人:有專業領域的知識,以及做最終決定的權力。必須讓 人找得到發問,以創造價值為己任。

觀察、導向、決定、行動(OODA)。觀看策略情境的全貌,然後 迅速採取戰術行動。

恐懼、不確定性及懷疑。主動總比被動好,掌控競爭對手的OODA 循環,在他們自亂陣腳時打敗他們。

花錢一無所得,而免費卻能變更。唯有在新事物能帶來價值時才去 創造它。要做好心理準備,必要時可能要把它們換成需要同等心力 的其他事項。你一開始覺得需要的,從來不會是你實際需要的。

Scrum可幫助人加快完成計畫。計畫的類型或問題並不是重點,因 為Scrum可以用於任何的事情,藉由改善績效與成果。

學校裡的Scrum。荷蘭有愈來愈多的老師採用Scrum手法教授高中 課程。他們發現,學生的考試成績馬上進步超過10%。目前他們正 在針對所有學生都採取這樣的教學方式,無論是走就業路線或天資 聰穎的學生都一樣。

脫貧的Scrum。在烏幹達,鄉村基金會使用Scrum把農業與市場資 訊提供給貧困的鄉村農民,成果是讓全球最貧困族群的這些人產出 和營收都加倍。

撕了你的名片。去除所有頭銜、所有管理者、所有架構。讓人們自 由去做他們覺得最棒的事,並且為之負起責任,成果將會讓你跌破 眼鏡。

————————————————

團隊為什麼要小?

————————————————

        在軟體開發中有個名詞稱為「布魯克斯定律」(Brooks's Law),最早是1975年由佛雷德.布魯克斯(Fred Brooks)在他的重 要著作《人月神話:軟體專案管理之道》(The Mythical Man- Month)中提到的。布魯克斯認為,「在一個已經延遲的軟體案中再加入人力,會讓它的進度變得更慢。」這項定律是在無數研究過後才推導出來的。他發現了兩個原因:其一是 新加入的成員要花費一段時間才能上手,你可以預見要帶領新人上軌 道將會拖慢其他人的工作速度;其二是不只和我們的思考方式有關, 也不折不扣地與我們的大腦能夠思考什麼有關。當團隊的人數增加時,兩兩之間的溝通管道將大幅增加,超出大腦所能負荷的範圍。如果你想計算團隊規模的影響會有多大,只要把團隊成員人數乘 以「成員人數減一」,再除以二就可以了。溝通管道=n(n-1)/2。所以 舉例來說,如果團隊有五個人,就有十條溝通管道;六個人就有十五 條溝通管道;七個人就有二十一條;八個人就有二十八條;九個人就 有三十六條;十個人就有四十五條。我們的大腦根本無法同時維繫和 這麼多人之間的溝通管道,我們無法得知其他人都在做什麼,而當我 們試著尋找答案時,速度就會減慢。

       Lawrence Putnam是軟體開發 的傳奇人物,他窮盡一生都在研究許多事情所花費的時間,以及背後 的原因何在。他的研究一再顯示,一個專案如果有二十人以上參與, 所耗費的心力會比只有五人以下參與來得多,而且是多出很多,不是 只有多出一點。和小團隊相比,大團隊得花費五倍以上的時間才能完 成。只要團隊成員多於八人,完成事情所需的時間 就會大幅增加。由三人至七人組成的團隊在完成同樣作業量的工作時 需要的心力,只要九人至二十人團隊的四分之一,而這個結果也一再 出現在成千上百個專案中。人數較多的團隊成效較差,似乎成為人類 活動中牢不可破的鐵律。但是為何會如此?要回答這個問題,就必須先檢視人腦的極限。你可能聽過1956年喬治.米勒(George Miller)所做的經典研究,得知一般人在短期記憶中最多可以記住七樣東西。這或許也是電話號碼 之所以會是七位數的原因。但是米勒的研究有問題,後來有其他研究 證明他是錯的。2001年,密蘇裡大學的尼爾森.科文(Nelson Cowan)希望驗 證前述的「七位數定律」是否為真,於是針對該主題進行全新的廣泛 研究。結果發現,一個人能在短期記憶中記住的項目數並不是七,而是四。

       人們常以為自己可以藉助記憶技巧或是提升專注度,來記住 更多東西;但是這項研究的結果卻清楚顯示,我們只能記住四「串」 資料。典型的例子是,假如把以下的十二個字母丟給某個人去記憶: fbicbsibmirs,大家通常只能記住四個字母左右;除非他們發現,他們 可以把這串字「切」成耳熟能詳的幾個縮寫:FBI、CBS、IBM、 IRS。如果你能把短期記憶中的東西與長期記憶的東西加以連結,就 能記住更多的內容。但是,我們的思維裡負責集中心神的那部分,也 就是有意識的那部分,一次只能記住大約四個不同的東西。

      Scrum團隊中的每個成員都必須知道其他人正 在進行的事。所有正在進行的行動、正在面臨的挑戰,以及目前的進度,都必須透明地攤在每個人的面前。但是,如果團隊的人數過多, 大家與其他人之間維持良好溝通的能力往往會受到影響,會有太多彼 此相左的意見。這時團隊在社交上與功能上常會分裂成行事、目的不 盡相同的次團體,團隊就會失去跨功能性。過去開會只要幾分鐘,現 在可能就要幾個小時。別讓這種事發生,讓團隊保持小巧吧!

————————————————————

持續改善什麼?

————————————————————

       「Scrum大師」這個名字。這個人不管是男是女,都要負責促成會議的召開,確保團隊運作的透明化,還有最重要的是要協助團隊找出影響進度的阻礙。其中的關鍵在於,成員們必須知道阻礙往往不單只是機器不靈光,或是負責會計工作的不夠聰明,而是還有流程本身。Scrum大師的職責在於引領團隊做到持續改善,引導大家經常自問:「我們如何才能把目前在做的事做得更好?」理想的狀況是,在每個循環(也就是每段衝刺的結尾),團隊能夠仔細自我檢視,看看互動狀況、實際做法及流程,然後問兩個問 題:「我們可以如何調整工作方式?」與「我們碰到的最大阻礙是什 麼?」假如團隊能夠坦率地回答這些問題,專案的進展速度將會比外人想像得還快。

       你知道嗎?當你在談論你自己時,你百分之百是對的;但是你在談論別人時,卻犯了人 類最常見也最具破壞性的錯誤,那就是論斷別人的行為。甚至還有一 個名詞是專門用來形容這種狀況的,就是「基本歸因錯誤」 (Fundamental Attribution Error)。

在John Holland等人的著作《歸納: 推斷、學習與發現的過程》(Induction: Processes of Inference, Learning, and Discovery)一書中,找到一些與此相關的有趣研究。我們對於社會動機抱持錯誤認知,一如非科學家或只用直覺理解物理的人對於物理世界抱持有色眼光。

      當你看到別人以這種方式看待這個世界時,你會覺得很好玩。這 些人明顯做出錯誤判斷。但是在你嘲笑他們之前,你得承認自己也總 是這樣,並沒有什麼不同。每個人都是如此。我們都覺得自己的行事 是在因應環境,但卻覺得別人的行事是受到他們自己的個性所觸動。還有一個令人發噱的副作用是,每當有人要我們描述自己的人格特質 與朋友的人格特質時,我們總是會把自己講得比實際上平淡許多,我 們會覺得自己遠不如朋友有個性。

       一個只憑直覺的物理學家要解釋為何巖石會掉落時,可能會說 「石頭本身帶有重力的特性」,而不會去說「重力是作用在石頭上的 諸多力量之一」。同理,當我們在談論別人時,也只是談論別人與生 俱來的特質,卻不去看那些與外在環境有關的特質。事實上,就是那 些與環境間的互動才會促成我們的行為。我們絕大部分的行為都根源 於四周環境的系統,而非任何既有特質。設計出Scrum的用意就是要改變這個系統。Scrum不會要大家指責別人或挑出錯誤,而是藉由促使大家集中共事與完成工作來獎勵良好的行為。

        每個人都是自己所處制度中的生物,而 Scrum的用意就在於先接受這個現實,進而檢視導致失敗的制度並予以改正,而非找一個人來譴責。大家還是習慣於譴責個人,而非制度,因為這樣會讓人感覺比較好。基本歸因錯誤會引發我們的正義感,假如我們譴責某人,就像是排除自己做同樣事情的可能性,如同排除自己在同樣情境下也會按 下電擊鈕的可能性。

       位於加州佛蒙特的New United Motor Manufacturing, Inc.; NUMMI的汽車工廠,該公司是由通用汽車與豐田汽車合資成立,工廠在1982年被通用汽車關閉,因為管理階層認為工廠的工人是全美最糟糕的一群,大家在上班時喝酒、上班不到班,還會對車子做一些小破壞。豐田汽車在1984年重新啟用該工廠。通用汽車告訴他們,工廠原本的工人很糟糕,但是管理階層很出色,應該重新僱用。不過,豐田卻拒絕 重新僱用管理者,反倒重新僱用大多數原本的工人,甚至還送其中一 部分的工人到日本學習豐田生產系統。NUMMI工廠幾乎馬上就以與日本工廠同等的精準度,生產出同樣少瑕疵的車子。同樣一群工人,但是制度卻不同。通用汽車在旗下的其他美國工廠從未達到那種水準的 品質,於宣告破產的同一年就退出聯合經營協議。

       承包商以Scrum團隊的型態施工。業主A訂出一些以周為單位的專案,承包商必須把專案完成, 並移至「已完成」欄位。承包商的拖車就停在他家前院的草皮上,他 在那裡放置一塊Scrum板,貼滿他列出待辦任務的便利貼。每天早上,他會召集木匠、電工、水管工人,或是當周衝刺過程中會需要的 任何人,大家一起探討前一天做了什麼、今天預計要做什麼,以及有沒有什麼阻礙大家施工的因素。業主A的鄰居僱用同一批工人,但是這次卻花了三個月才完工。同樣一批人、同樣一種設計的房子、同樣的工程規模。施工時間卻多出一倍,成本當然也多了一倍。唯一的差別在於,鄰居家沒有使用 Scrum,因此很晚才察覺到被Scrum逼得現形的那些問題。工人們未能調整步調朝著同一個方向前進,也被迫必須等待其他人完成工作 後,自己才能展開工作。最後,鄰居花費將近兩倍的成本,多出來的部分多半是支付給那些在等待別人完成工作的人。

       可見制度性BUG或框架問題,往往帶來的是效率低下、惡性循環、無序環境。像是「阿里員工的阿里味」、拼多多員工猝死連環事件、企業利用公權跨省追究等現象。

————————————————

透明清單(看板)的意義?

————————————————

        在Scrum團隊實現自主、精熟與有目標之前,常常會有一個要素要先實現:透明度。透明度指的是,內部不該有任何秘密的地下計劃、隱藏的議程,或是任何暗地進行的事。公司裡的每個人在忙什麼?他們每天做的事對推動公司的目標又有什麼貢獻?團隊通常自己就會處理個人的績效問題;團隊最知道每個成員在做什麼、誰在幫助團 隊、誰在傷害團隊、誰讓這個團隊變得出色,以及誰又讓這個團隊痛苦不堪。

      陽光法案要求所有公共會議都要對外開放、所有紀錄對大眾公開,也不能有任何事關起門來偷偷進行,絕不隱藏任何事。正因為如此,在 Scrum中才會讓任何人自由參加會議、讓任何利害關係人旁觀每日立 會,或參與衝刺檢視會議。

        開會超過十五分鐘,你就是開錯方法了。每天開會的用意在於讓整個團隊的成員清楚知道,在這一段衝刺期裡每件事的進度。是否所有事項都能在時間內完成?是否可能協 助其他團隊成員克服阻礙?主管不分派任務。團隊是自主的,他們主動做事,也無須向上級做詳盡報告。任何管理階層的人或另一個小組的人只要走過白板,看看有關Scrum公告欄,就會清楚知道每件事目前的狀況。

       這也是每日會議的運作方式,它存在一些規則。每天都要在同一時刻開會,每個人都必須參加。假如無法全員到場,就等於是沒有溝 通。一天中的任何時刻都可以,只要是在同一時刻就好,重點在於給 團隊一個固定的節奏。

       第二個規則是,會議不能超過十五分鐘。我們希望會議乾脆、直 接並且切中重點。假如有些事需要進一步討論就記錄下來,在每日會 議之後再深入探討。這麼做的用意是希望在最短時間裡找出最多用於 採取行動的珍貴資訊。

      第三個規則是,每個人必須積極參與。為了促成此事,我要求每個人都站著開會。這可以讓大家積極交談、持續聆聽,也有助於維持會議的簡短。正因如此,這樣的會議才會稱為「每日立會」或「每日 Scrum」。你要怎麼稱呼它其實都不是那麼重要,只要每天在同一時 刻召開、同樣詢問那三個問題、每個人都站著,而且把開會時間控制在十五分鐘以內就可以了。Scrum大師,也就是負責執行流程的人,會詢問團隊成員三個問題:

昨天你做了什麼事協助團隊完成本階段衝刺?

今天你準備做什麼事來協助團隊完成本階段衝刺? 

有什麼阻礙團隊前進的因素?

       Scrum的功能在於改變你對時間的看法。在參與衝刺和立會一段時間後,你就不會再把時間看成一枝只會往未來直飛的箭,而是某種周期性的東西。每一次的衝刺都是一次嘗試全新做法的機會;每一天都是一次改善的好時機。Scrum鼓勵大家採取全方位的世界觀。任何承諾參與Scrum的人都會珍惜每一刻,因為時間是一個由呼吸與生活構成的循環。

       白板劃分為幾個欄位:待辦事項清單、進行中、已完成。有一個重點是,除非已經到達客戶能使用的狀態,待辦事項才能 移至「已完成」。每一段衝刺就是大家常說的「時間盒」,其長短是固定的,你不 能把這段衝刺設為一個星期,下一段卻設為三個星期,前後必須一 致。你應該建立工作節奏,好讓每個人都容易掌握自己在一段時間內能夠完成多少事,而最後的成果通常會讓他們自己感到訝異。

         找出最優先的改善事項後,就把它設定為下一段衝刺中最重要的任務,而且要制定衡量的標準──如何才能證明已完成改善?大家必須用具體、可行動的字句定義出足以提供判斷 「已完成改善」的標準,這樣在下一次的衝刺回顧會議中才能很快就判斷出「是否已完成改善」。

        每一段衝刺還有一個重要元素,就是一旦這個團隊承諾要完成某些事項,他們的任務就鎖定了,團隊以外的任何人都不能再加入任何事情。

         事業單位、大企業是否會開會呢?應該自省一下開會的能力。

        每家公司都必須想想這張圖的概念。就算你充滿熱情,假如只是把心力集中在自己能創造的事物上,最後可能會做出沒人想要的東西;假如你只是把心力集中在自己能推銷的東西上,可能會承諾顧客做出你根本做不出來的東西;假如你只打造雖然能推銷、自己卻缺乏熱情的東西,最後你只會做出平庸的產品。但在這張圖的正中央,也 就是三方交會的甜蜜點,是一個「建立在現實上的願景」,一個真的很可能創造出卓越成果的願景。

         Scrum的真正威力在於它的「待辦事項清單」,不但預先擬妥、排好優先順序,還列出事情的相對價值。就是因為這樣,創業公司是否導入Scrum應用,也才會認為S是一種重要的競爭優勢。

       當你在建置Scrum時,第一件要做的事就是建立待辦事項清單。它可能長達數百項,也可能只有少數幾件你要先處理的事。當然,你必須清楚知道,在作業的最後希望得到什麼,它可能是一種產品、一場婚禮、一項服務、一種新疫苗或一棟油漆好的房屋,它可能是任何東西,但是一旦你擁有願景,就必須考量如何才能讓它實現。

       Scrum的能耐就在於,能幫找出如何先建置那已清楚顧客真正要的其中20%。困難之處不在於設想你想要實現什麼,而在於找出你能實現什麼。

——————————————

為何要專注一件事?

——————————————

         人們對於自己多工能力的認知有嚴重自我膨脹的情形。事實上, 大部分的受測者都認為自己的多工能力在平均水準以上。自我評估幾乎沒有事實根據,因此多工做事及最愛在開車時打電話的人,過於高估自己的能力。

      「人們之所以多工,並不是因為擅長多工,而是因為容易分心,難以克制自己去做另一件事的衝動。」換句話說,那些多工得最厲害的人沒有辦法專心,他們無法自制。Harold Pashler的科學家,在1990 年代早期證明了這件事,他稱為「雙重任務的幹擾」(Dual Task Interference)。他先要求一群受測者做一件非常簡單的事,像是在燈 亮起時按下按鈕;接著他又要另一群受測者做同樣的事,但是又加上 另一件簡單的任務,像是根據閃燈顏色的不同來按下不同的按鈕。在增加第二項任務後,無論任務的內容再怎麼簡單,花費的時間照樣加倍。推論是,其中出現了某種處理瓶頸,人們因此一次只能想一件事。他猜想,有某種程度的心力是花費在把一個程序「打包」 放到記憶中,再把另一個程序拉出來執行工作。每當人們在不同任務間切換時,就是這樣的過程在耗費時間。

      近年來,還有一些研究運用功能性電腦磁振造影(fMRI)記錄大腦實際在思考時的情形。資料顯示,唯有在大腦的左右兩個半葉各處理一個程序時,人們才有可能同時做兩件事。但掃描結果證明,即使是在這樣的狀況下,人的兩種思維依舊並非同時出現,而是由大腦在不同任務間切換而已。基本上,大腦有它的控制功能在,所以人無法自己和自己過於激烈地爭奪主導權。

        2005年,有一項由倫敦大學所做的研究,測量多工可能讓人變得多笨。精神科醫師Glenn Wilson找來四男四女,分別在安靜與令人分心 (電話響起、電子郵件寄達)的不同環境下測量其智商。他在實驗中測量受測者的皮膚導電狀況、心跳及血壓。有趣的是,處於令人分心的環境時,受測者的平均智商下降10%以上。更有趣的是,男性受測者下降得比女性還多(或許在某種程度上是因為女性比較習慣分心。)

——————————————————

浪費是什麼?

——————————————————

         Scrum的設計就在於不擾人卻又能讓人集中心神工作的架構。讓我們集中努力去除部分在工作裡似乎已成為必要的無謂浪費。

       第一種浪費是「自我矛盾」。你一方面很希望給自己的團隊一些有挑戰性的目標,促使他們成長,但是你也不希望他們追求太過超乎現實而不可能實現的目標。

      人類非常不善於預估事情,但是幸好我們倒是很擅長設定相對規模,也就是比較兩件事之間的相對大小,像是在 一堆T恤中挑出S尺寸、M尺寸、L尺寸。這就是設定相對規模,只比較任務的大小。這些數字有種規則:1、3、5、8、13。8是前兩個數字的總和,13也是前兩個數字的總和,這種數列稱為「費氏數列」(Fibonacci sequence)。研究顯示,即便花費好幾個月規劃,預測值與實際值之間還是可能有上下四倍的落差。所以,我才會認為做事時若採用瀑布法規劃真的是蠢得可以。

        第二種浪費是「不合理期待」。你是否常聽到有人炫耀由於自己的英雄行徑才挽救了某個專案?別人往往會用拍拍他的背、歡呼或祝 賀來示意。我認為這是流程中一種很基本的瑕疵,經常仰賴英雄出手,趕在截止日期前把專案完成的團隊,就等於平常沒有依照應有的方式運作。一直在從一個危機進入下一個危機,會讓人感到精疲力盡,也無法讓人推動合理而持續的改善。兩者之間就像是牛仔騎馬出 現、把女孩從壞人手中救走,以及訓練有素的海軍陸戰排把殲滅區清 空的差別。

      第三種浪費為「過勞」。Scott Adams常在作品中諷刺的就是這樣的行為,包括影 響員工做事的複雜規定、因為非必要的報告而導致員工為了填表格而填表格,醫生大量時間用在手寫填表、電腦錄表存檔的瑣碎裡,以及公務員、國企事業單位花時間召開卻又沒有創造任何價值的無意義會議。

      第四種「情感面的浪費」。當公司裡出現一個渾球,某個喜歡激怒別人、造成別人情緒激動的傢伙,就會造成這種浪費。渾球們常會以「我只是試圖敦促別人把工作做得更好」,來合理化自己的行為, 但其實他們只是在放任自己性格中負面的部分而已,沒有什麼比這更損害團隊追求卓越的能力。

——————————————————

怎樣去預估?

——————————————————

         德菲法的優點在於可以廣徵意見,也能儘可能去除偏誤, 接收匿名但有充分資訊可供參考的專家意見,還能縮小不同意見之間 的歧見,最後得到大家都能接受的預估值。至於它的缺點,對我們來說在於曠日廢時。當團隊坐下來討論時,並未花費任何 時間做匿名的意見調查,希望能在幾個小時內就估算完數百個工作項目,不是幾天,當然更不是幾個星期。

     「規劃撲克牌」(Planning Poker)的原理很簡單,每個人都有一副牌,上面寫著本於直覺而耐人尋味的費氏數列,也就是1、3、5、8、13等。把每件需要評估的事在桌上攤開後,大家就從自己的牌中抽出一張認為最符合其複雜度的牌,牌面向下覆蓋在桌上。大家同時翻牌,如果牌與牌的數字差一個級距以內(像是一張5、兩張8、一張13),只要把這幾種牌的數字加 總,再取平均值即可(本例來說是6.6),然後繼續討論下一件事。請 記住:我們是在講預估值,不是嚴謹到不容更動的計劃,而且我們要估計的是專案化整為零後的小片段。假如大家的牌上數字相差三個級距以上,牌上的數字最大與最小 的人就要說明一下自己為何會如此判斷。說明完畢後,大家再重新執 行一次,或是可以直接計算平均值,這會近似於蘭德公司的統計學家算出來的預估值。這種方法簡單到不可思議,卻能避免任何種類的定錨行為,像是從眾效應或月暈效應,還讓整個團隊彼此分享關於特定任務的知識。不過,還是有一個關鍵,就是你必須讓實際著手做事的團隊自行預估,而不是找一些專家來擔任「理想」的預估者。只有負責執行的人員才知道任務要花費多少時間與心力。或許專家團隊真的很擅長做某種事,但是做起另一種事就很糟糕。或許某位專家在特定領域的助益很大,但是對於另一個領域的事,這個團隊就沒有人懂了。團隊都是獨立而獨特的,每個團隊都有自己的步調與節奏,逼迫一個團隊照著安排好的流程走就等於是自取滅亡。

——————————————————

為何用故事式敘述任務?

——————————————————

         曾經有過別人把工作交辦給你,但是你卻不懂為何得做這件工作的狀況?有人要你查出在A範圍內,在月與月之間的銷售變化狀況,要你列出賣場面積在六百平方以上的店面,你照做了,但是你卻不明白為何必須做這件事。而且因為這樣,你還可能會提供錯誤的資料、誤解問題,或是對於有人指派給你這種似乎很忙碌的工作而感到憤恨。如果你是管理者,你可能會訝異自己的部下未能馬上理解 你正打算關閉小型店面,並且開設大型店面。

        問題就出在你沒有取得或給予把這件工作做好的足夠資訊。人們都是用情節、故事在思考,大家都是這樣來理解這個世界。我們比較能掌握人物、欲望及動機這些東西,當我們試圖把個別區段從主線結構中抽離、在原本的情境以外處理它們時就會發生問題。所以,當你在考量一項任務時,會希望思考的第一件事是人物或角色,例如顧客、新娘、讀者、員工等。這項任務是為「誰」而做 的?在打造這樣東西、做這項決策、呈交這個部分時,我們應該從誰的角度出發?

        再來必須考量「什麼」,思考我們起初希望完成的是什麼。這通常也是我們的出發點與終點,但它只是我們該進行流程的中段而已。

         最後,還必須考量動機。「為何」這個人物想要這個東西?成果 為何能服務這名顧客、讓他開心?從某種角度來看,這是最重要的一 步,動機會讓每件事染上色彩。

         描述任何故事必須符合「INVEST」的標準才算完備:

獨立(Independent)——故事必須有採取行動的可能,而且本身是 「可完結」的,不能與另一個故事有所牽扯。

可修改(Negotiable)——只要還沒實際完結,故事必須可以重 寫,要預留修改的餘地。

有價值(Valuable)——故事必須實際為顧客、使用者或利害關係 人傳遞價值。

可估算(Estimable)——必須能掌握大小長短。規模小(Small)。故事必須小到能夠預估、小到易於規劃。如果故事太龐大,就看是要重寫或拆解成多個小故事。

可測試(Testable)——故事還得有一個必須通過的考驗才算完整, 在執行故事前要先設定好考驗。

        我們在實際的專案裡發現,如果故事真的寫得夠完備,團隊的執行速度將會加倍。另外, 如果故事在一次衝刺後真的已經完成,團隊的速度又會再次加倍。這是得以實現我講的「用一半的時間做兩倍的事」願景的其中一招。

       實施Scrum時,每段衝刺都會有這樣的規劃,稱為「衝刺規劃」 (Sprint Planning)會議。所有人齊聚一堂,檢視必須完成的故事清單,然後說:「好了,我們在這段衝刺中能完成什麼?這些故事已經完備了嗎?在衝刺結束時能完成它們嗎?到時候能對顧客展示出實際 價值嗎?」回答這些問題的關鍵就在於,團隊的速度能有多快。

——————————————————

為何快樂是種高效的生產力?

——————————————————

       人人都想要快樂(或稱滿意、滿足),不是那種自我滿足、安於現狀般的快樂,而是更為積極有活力的快樂。美國第三任總統傑佛遜 就是一位鼓勵大家多追求目標來贏得快樂的人。追求目標似乎真的能 讓我們快樂。事實上,Scrum只要執行得宜,也能讓員工、顧客、管理者及股東都快樂(通常是依照我講的順序發生)。

       我們要如何讓自己、員工及團隊的同事快樂?我們要如何把那種 快樂轉換為更高的生產力與營收?要回答這些問題,首先要把各位帶回豐田與大野耐一去除浪費的那場聖戰裡。為了去除浪費,他們想到的做法是「持續改善」。目標並不在於達成某種程度的生產力並加以維持,而在於時常檢視自己的 流程、追求不時的改善,還要永遠繼續。當然,完美的境地永遠不可 能實現,但任何朝向完美邁進的小小進步都是值得的。正如工作必須分為可管理的區塊,以及時間必須切分為可管理的 片段一樣,改善的作業也必須分解為一次一個步驟。以日文來說,用的字眼是kaizen,意指「改善」。有什麼能馬上著手進行、足以讓事態變得更好的小改善。

       在實施Scrum時,每段衝刺結束時會透過「衝刺回顧」(Sprint Retrospective)評估這件事。要讓衝刺回顧會議有效率,需要的是某種程度的情感成熟度與信 任的氛圍。回顧會議就相當於戴明的PDCA循環中「檢核」(C)的部分。重 點在於進入「行動」(A),也就是改善的部分。唯有如此,才能真 正改變流程,讓它在下一段衝刺裡變得更好。只分享自己的感受是不 夠的,還必須採取行動。採用滿意指標可以讓團隊協助成員成為更棒的人;它可以系統化、細膩又一點一滴地去除導致不快樂的原因;它賦予人們自我改變的力量,也給予這麼做的動機。

「滿意指標」 (Happiness Metric)

在每段衝刺結束時,請所有團隊成員回答以下幾個問題:

1. 你是否滿意自己在公司裡扮演的角色?請以1分至5分打分數。

2. 同樣以1分至5分打分數,你對公司整體的滿意度如何?

3. 為何你會那麼覺得?

4. 在下一段衝刺中,有哪件事能讓你感到更滿意?

      在下面這張圖中, 在速度或生產力下跌的幾個星期前,滿意度就會先下跌。如果你只看生產力,就不會在它無量下跌前注意到問題的存在。但是,如果你看到整個團隊都有滿意度下跌的現象,就算目前的生產力仍在向上攀升,你還是知道已經存在自己必須處理的議題了,而且動作要快。

       Zappos的營收由2000年的160萬美元成長到2008年的10億美元 以上,這相當於八年來每年都有124%的成長率。我不清楚你公司的營收成長率如何,但是我想上述的實例應該很能說明,讓員工感到快樂與滿意的好處。Scrum正是一項讓你可以用來做到這件事的工具。Zappos還有另一種用來讓大家快樂的方法:讓員工有機會學習與成長。團隊成員希望能成長、希望能把自己的工作做得更好,也希望找到其他自己能做得更好的事,這種想法是精熟的欲望可以帶來的工作動機。這種給員工機會找出自己適合什麼位置的做法,也有助於讓員工保持在快樂、躍躍欲試而且投入的狀態中。要使大家喜歡上班,是思維上的一種轉變,從「為公司工作」轉變為「為我的公司工作」。在一般公司裡,會看到許多工作內容維持神秘、不想和別人合作的管理者。他們會創造出一種「我們是我們,他們是他們」的氛圍,他們會畫出「互不侵犯」的界線,你往往會看到不同部門間彼此勾心鬥角.我在很多團隊身上都看過同樣的狀況。其中一個成員或許擁有專業的知識或技能,卻像守財奴一樣地把這些知識藏私,他們認為這是能確保工作無虞的私人財產。但是,透過衝刺後的回顧與透明度的落實,Scrum幾乎可以馬上揪出這種行為。Scrum可明確點出路障何在、浪費何在。Scrum給了大家一個做到這件事的框架,它提供一個讓全組織朝向共同目標邁進的架構。這個架構的基石包括透明度、團隊作業及合作。許多企業現在都在擁抱,未能這麼做的企業也註定要輸給這麼做的企業。

        自我感覺良好是種快樂泡沫,通常會在一個團隊透過Scrum實現空前的成功或大幅提升生產力後出現, 團隊的成員自我組織得很好,也對自己的進步深感驕傲。

       Scrum的做法是推廣一體化且富有激勵性的思維。透過大家的共事,團隊可協助享樂主義者往前看、讓虛無主義者知道光明的未來還 是存在,也告訴那些陷入忙碌之中的管理者,其實有更好的做法。

      還記得基本歸因錯誤嗎?當你的身旁全是渾球時,你該做的不是挑出壞蛋,而是要找出鼓勵壞蛋們做出這種言行的不良系統,再用滿意指標加以校正。阿里員工不時爆出的PUA事件,還能修正嗎?

        馬斯洛的「需求層次理論」(hierarchy of needs)以金字塔形式呈現出人類不同層次的需求,從人類最先關心的最底層需求,乃至於底層需求滿足後會變得更迫切追求的更高層需求。在需求金字塔的最底層是生理需求:空氣、水、食物、穿衣及住所。如果我們缺少這些東西,根本不可能再想別的東西。第二層是安全需求,不只是身體與財務,還包括確保身體健康,能夠取得某種程度的醫療資源。有趣的是,很多人的需求只滿足到這裡而已,即便下一個階段談的是我們身為人類絕對需 要,但社會卻經常忽視的需求:愛與歸屬感,再往上一層是自尊及贏得別人尊敬的需求。金字塔的最頂層則是發揮潛能,自我實現的需求。馬斯洛最感興趣的是最頂層的需求,而這也是Scrum關注的焦點:協助大家成長與實現自我。在金字塔中,位居較高層次的人不但比較快樂、比較滿足,做事也更有效率、更有創新性,還能創造卓越。對比一下阿里VS亞馬遜、騰訊VS網飛、百度VS谷歌、拼多多VS Zappos、聯想VS戴爾的企業文化,不言自明。從新冠疫情到鄭州暴雨洪水、從食品安全到躺平主義,現實的殘酷難道使人已喪失了自我詮釋的能力?矢內原忠雄曾說,「理想雖然是無形的,卻不是無力的。現實雖然可以歪曲理想,卻不能消滅理想。」  「愛的反面不是憎恨,而是冷漠;藝術的反面不是醜陋,而是冷漠;誠實的反面不是信口雌黃,而是冷漠;生命的反面不是死亡,而是冷漠。」冷漠,是因為我們遠離了愛與公義的源頭;在荒涼的世代,油蒙了心、耳朵發沉。冷漠,使我們無法體會真正的快樂。

        前美國總統老羅斯福於1910年在巴黎索邦大學的演說「民主國家的公民權利」 (Citizenship in a Republic):榮耀並不屬於批評的人;亦不屬於指出勇者如何失敗,或點出別人哪裡應該做得更好的人。榮耀屬於實際身處在競技場中、臉上沾滿塵土與血汗,仍英勇奮戰的勇者;他們會犯錯,而且一錯再錯,因為錯誤與缺失必會伴隨著努力而來;但是他們都確切地知道要奮戰不懈、知道要充滿熱誠、全心投入;獻身於崇高的志業。他們最好的結局是終於功成名就;就算失敗,最差的下場只不過就是在勇敢奮戰後落敗。他們的定位,絕非那些冷漠懦弱、不知勝利與失敗為何物的人所能相提並論。

      錢永祥老師在其《縱慾與虛無之上:現代情境裡的政治倫理》裡說到:在我看來,人的尊嚴,正是靠熱情與懷疑的適當配合而支撐起來的。尊嚴繫於擔當,可是沒有懷疑與熱情,豈有餘地發揮坦蕩蕩的擔當?在這個脈絡裡,庸俗無聊的心態特別需要提防。庸俗者沒有懷疑,所以無所擔當;無聊者缺乏熱情,所以不求擔當。庸俗者以為意義與價值的問題業已解決,生命不過是隨著主流逐波弄潮;無聊者則根本不識意義與價值的追求包含著徒勞的悲劇成分,以為生命本身原是輕鬆幸福的盡興一場。只要讀過一些韋伯,就知道這整套問題是何等驚心動魄、振聾發聵。在各種政治壓制、文化侵蝕,乃至於整個庸碌世界的扭曲消耗之下,如何維持一份做人的尊嚴?」熱情、懷疑、同情、反抗如何結合成一種尊嚴的處世態度,抗拒這個時代的庸俗與無聊,維護「基本的做人道理」,我無法帶著憨憨傻笑認同這個時代的任何價值。「用出不得聲的同情看周邊人們,用凌厲的批判精神喊出「我不分享這個時代的價值!」

        任何人都有夢想,只是夢想並不相等。夜晚在滿是塵埃的心靈深 處作夢的人,白天醒來會發現只是虛華一場;但白天作夢的人則是危 險人物,因為他們可能會目光灼灼地推動夢想,讓夢想成真。T. E. Lawrence,《智慧七柱》(Seven Pillars of Wisdom)

從何著手?

1. 挑選產品負責人

他必須對於準備要做的事、要開發的產品、 要完成的事項懷抱願景。他必須把風險與報酬、可供運用的能力、可 完成的事項,以及自己的熱情所在都納入考量(更多資訊詳見第八章 「優先順序」)。

2. 挑選團隊

實際完成工作的人員是誰?團隊必須擁有足以滿足 與實現產品負責人願景的所有技能。成員不要多,三人至九人最適當 。

3. 挑選Scrum大師

這個人要負責教導團隊的其他成員遵照 Scrum的架構行事,並協助團隊去除任何會拖慢速度的因素。

4. 建立產品待辦事項清單,並安排優先順序

這份清單概略列出所有必須打造或完成,才得以實現願景的事項。這份清單在產品的生 命周期中會一直存在,還會加以進化;它是產品的發展路徑圖。

在任何時點,想要知道「團隊所能做到的所有事項,依優先順序 排列」,產品待辦事項清單都要充當唯一且具決定性的資訊來源。產品待辦事項清單只會有一份;這意味著產品負責人從頭到尾都必須不 斷安排與調整優先順序。產品負責人應該與所有利害關係人及團隊商 量,以確保產品待辦事項清單既能反映使用者需求,又能顯示出團隊 可打造的項目。

5. 修正與評估產品待辦事項清單

交由實際完成清單中待辦項目 的人員來估算預計耗費的心力多寡是很重要的。團隊應檢視清單中的 每個項目,研擬其可行性。是否具備充分的資訊完成該項目?該項目 是否已經小到足以估算?是否有「已完成」的定義,也就是每位成員 都認為應該符合才能稱為「已完成」的標準?該項目是否能創造可見 的價值?各項目在完成後必須是可被展示與示範的,若有出貨的可能 性會更好。別用耗費多少小時來估算單一項目,因為人們很不擅長做 這件事,而是要以相對大小估算:小、中或大;或者更好的方式是使 用費氏數列估算各項目的分數高低:1、2、3、5、8、13、21等(更 多資訊,詳見第六章)。

6. 衝刺規劃

這是第一場Scrum會議。團隊成員、Scrum大師及 產品負責人要坐下來規劃衝刺的內容。衝刺的時間長短是固定的,不 要超過一個月。大多數的團隊都是訂在一周至二周。要從待辦事項清 單的最上端看起,估算在這一段的衝刺中可完成多少。

假如團隊已執行過好幾段衝刺,應該把上一段衝刺中完成的分數 列入考量。該分數就是團隊的速度,Scrum大師與團隊成員應努力在 每一段衝刺中提高其數值。這也是另一個好機會,可以讓團隊成員和 產品負責人確保所有人都已精確理解,這些待辦事項將如何協助完成 願景。會中,所有人應該對於衝刺目標(Sprint Goal)要有共識,也 就是大家希望在這一段衝刺中完成哪些事項。  

Scrum的基石之一在於,一旦團隊已承諾要在某一段衝刺裡完成 自己認為可完成的事項就確定了,不能改變,也不能再加入東西。團 隊必須在衝刺期間自主工作,以完成自己預測可完成的事項(更多資 訊,詳見第四章與第六章)。

7. 工作透明公開

在Scrum中最常見的做法是弄一張列有三個欄 位的Scrum板:待辦、進行中、已完成。便利貼代表等待完成的事 項,在團隊一件一件完成的過程中,同時也會在Scrum板上把便利貼 移動到相對應的欄位。

另一種讓工作公開透明的手法是製作燃盡圖。其中一軸是團隊在 這一段衝刺中尚待完成的分數,另一軸則是天數。每天,Scrum大師 都會記錄待完成的剩餘分數,而後畫在燃盡圖上。在理想狀態下,燃 盡圖會呈現一條陡直地朝向最後一天的「零」而去的斜線(更多資 訊,詳見第七章)。

8. 每日立會或每日Scrum

這可說是Scrum的活力泉源。每天在同一時間,最長不超過十五分的時間裡,團隊成員與Scrum大師見 面,並回答以下問題:

昨天你做了什麼協助團隊完成這一段衝刺的事? 

今天你打算做什麼來協助團隊完成這一段衝刺?

是否有任何因素阻礙你或團隊實現衝刺目標?

這就是完整的會議內容。假如召開這場會議的時間超過十五分鐘,就是開會的方式有問題。這場會議的用意在於,協助整個團隊精確知道在這一段衝刺中每 件事的狀況,是否所有任務都能準時完成?是否有任何幫助其他團隊成員克服阻礙的可能性?高層並不會分派任務,因為團隊是自主運作 的;工作是由他們自行安排的,不必向管理階層呈交詳細報告。 Scrum大師有責任排除阻礙團隊前進的障礙或阻礙。

9. 衝刺檢視或衝刺展示

團隊要在這場會議中展現自己在衝刺中 的成果。任何人都能與會,不僅限於產品負責人、Scrum大師及團隊 成員,利害關係人、管理階層、顧客均可參加。這是一場公開會議, 由團隊展示在該衝刺中得以移動到「已完成」欄位下的作業項目。

團隊應該只展示符合「已完成」定義的項目,也就是已經全部完 成,不必再施加任何作業就能直接推出的東西。它或許稱不上是完整 的產品,但應該是一項完整的功能。

10. 衝刺回顧

在團隊已展現他們在上一段衝刺中的成果後(也 就是納入「已完成」,而且足以提供給顧客換取回饋意見),要坐下 來思考先前有哪裡做對了、有哪裡其實可以做得更好,以及在下一段 衝刺中有什麼可以改善的。在流程中還有什麼是團隊馬上可以著手改善的?

為了讓這場會議更有效率,出席者在情感上必須夠成熟,彼此之間要具備互信的氛圍。更重要的是,開會不是要找人出來譴責,而是 要檢視過程。為何某件事會變成那樣?為何我們會疏忽?怎麼樣可以 加快作業速度?身為團隊的一員,每個人為自己的流程與成果負起責 任是很重要的,同時要一起找出解決方案。

此外,大家必須有勇氣提出真正幹擾團隊運作的議題,並且要以 找尋解決方案的角度切入,而非指控他人。團隊的其他成員也必須有雅量聆聽回饋意見,並在吸取意見後設想解決方案,而不是自我辯護。會議結束時,團隊與Scrum大師應該對下一段衝刺中準備改正的 流程具有共識。這種有時候會以「改善」(kaizen)稱呼的流程,應 該列入下一段衝刺的待辦事項清單中,並擬定「驗收測試」 (acceptance test),讓團隊到時候得以簡單判斷出改善是否已經落 實,以及這項改善對團隊速度的效應。

11. 馬上展開下一個衝刺循環

把團隊的經驗,和針對阻礙與流程所做的改善加以反映。

「We are debtors to every man to give him the Gospel in the same measure in which we have received it.」 — P.F. Bresee

相關焦點

  • 規模化敏捷:SAFe和LeSS同於不同,不要撕逼
    兩者的核心基礎理論很多相似之處,比如都強調精益開發、系統思考、質量內建、透明、排隊論等。兩者都是以Scrum作為基礎,SAFe的團隊層其實就是按照Scrum去運行的;而LeSS更是直接在原則中宣稱「規模化的Scrum也是Scrum」。
  • scrum master隨筆
    之前在我們squad擔任過一段時間的scrum master,於是想把當scrum master期間的一些職責和想法記錄下來,當然不同的組織有不同的
  • Scrum Pattern | 每日Scrum會
    Bob Warfield當時正在運作該項目,並提供了以下反思:這是我們生產力的一個關鍵部分,今天它是敏捷/Scrum的基石,在這裡它被稱為「Standing」會議或「Stand Up」會議。顯然,有些人按照字面意思理解,開始在沒有椅子的情況下開會。那很好,我想我會在會議上保留椅子,但我會讓會議足夠短,沒有椅子應該不是問題。
  • Scrum Pattern | 每日Scrum站會
    本文轉載自我的敏捷導師徐東偉教練,歡迎大家關注他的公眾號:我們假定Scrum團隊已經相聚在一起,準備開始或已經開始了Sprint。
  • 敏捷開發的根本矛盾是什麼?從業十餘年的工程師在思考
    有一次其中一個team的一位中籍工程師私下找我做溝通,提出要個title,比如team leader、scrum master什麼的,哪怕給個更小的頭銜也行,甚至說不用給他漲年度工資、只要給個title都願意。工作好多年了,因為沒有一個「官銜」,他自己會被父母數落,遇到親戚朋友同學問起來更會很丟臉!
  • 什麼是敏捷以及中小銀行如何打造敏捷組織
    對於不同層次的敏捷要求,中小銀行須適配不同的敏捷組織形式。 在推動敏捷逐步向更大範圍實施的路徑上,業界出現了很多概念,比如團隊級敏捷、交付敏捷、規模化敏捷、產品級敏捷、產品線級敏捷、企業級敏捷、組織級敏捷等等。不同的銀行會因其既有的使用習慣和已經推動的各種轉型導致在概念的理解上會有諸多差異。
  • 《打造敏捷開發模式》第二章:什麼是Scrum
    什麼是ScrumScrum作為敏捷的落地方法之一,用不斷迭代的框架方法來管理複雜產品的開發
  • 《用leangoo做Scrum敏捷開發》成都站實戰課
    Eric Liao 廖靖斌Leangoo和Scrum中文網創始人兼CEO中國敏捷聯盟副秘書長,中關村智聯聯盟理事CSM,CSP(Scrum聯盟認證Scrum專家)實戰派Scrum和敏捷顧問及教練·      廖先生是中國Scrum和敏捷領域的先行者、實踐者,擅長Scrum敏捷開發、網際網路產品研發, 2006年開始實踐
  • 敏捷組織的「入坑」與「填坑」
    敏捷組織如果能推行成功好處良多。我也看到很多組織還是不免會踩到幾個坑。以下,是我過去幾年觀察到的敏捷組織推行的幾個坑和避免入坑的布局,以供有想法推行敏捷組織的公司做前車之鑑。坑:敏捷和戰略脫節 為了敏捷而敏捷有一些客戶看到身邊很多同行在推行敏捷組織、創新型組織覺得特好,於是也想在公司內推動。
  • 氪分享 | 敏捷組織的「入坑」與「填坑」
    — 氪空間,讓辦公更美好 —最近幾年,被好多客戶找上門來要做敏捷組織。好像無論大小公司,聽到敏捷兩個字,都無一例外就可以打起精神來。是的,因為外部市場變化太快,讓我們需要在最短的時間之內作出最快的決策,因此敏捷組織就成為了炙手可熱的名詞。為什麼要打造敏捷組織?
  • 美國陸軍直升機用北美原住民命名探源
    Why Army Helicopters Have Native American Names美國陸軍直升機用北美原住民命名探源
  • 《刀塔傳奇》敏捷英雄推薦 實用敏捷英雄
    單點爆發非常高,但是弱點也是顯而易見的:1、害怕減速,依賴普攻的英雄一旦攻速被減基本輸出大打折扣;2、吃命中,害怕被致盲打出MISS或者天生閃避奇高的英雄;3、急火困難,目前分身流行,會因為單點輸出手段單一而造成無效輸出;  3、AOE輸出型——飛機 月騎 美杜莎  內射隊的成員核心,飛機是繞過前排打中後排,月騎通過前排濺射中後排,一姐則是無差別一打五。
  • 識別真正的敏捷組織
    在採用敏捷的方式後,許多企業發現:員工更有激情和主觀能動性;促進了相互溝通和團隊凝聚力;有助於業務創新和單點突破。這也是為什麼,現在越來越多的企業都在選擇建設敏捷組織的原因。什麼是敏捷組織?敏捷組織轉型的動因:敏捷組織轉型通常來講有兩大動因:1、業務突破2、加強Ownership。
  • 薩維尼:歷史法學派與近代法學方法論的創始者
    堅持均衡中道的立場,這種均衡感讓薩維尼的作品得以顯示高度「省略(不重要、不相關者)的藝術」;他對周遭環境保持距離的態度,則促使他在所有學術性、政治性與人事上的爭議尋求超越黨派的立場。而最能夠適應他取則古代、古代生活風格之內在傾向的莫過於羅馬法。因為這些素質,他選擇研究與教學作為他的生命事業,從事培育思想與提高學術風格的工作。
  • 敏捷組織 2.0 | 掌握組織設計的要素、敏捷組織的特點和效能
    本次內容根據第二期直播課後半部分整理,圍繞「組織設計的要素」、「敏捷組織的特點」、「敏捷組織的效能」三部分內容展開。對於企業而言,組織的進化和升級就是人才升級。因此,與之對應的人才能力模型、關鍵崗位上的OKR指標也不一樣。> 要素二:關係流程目標標準出來之後就會形成關係流程,業務部門也會產生招聘目標,與之相對應的業務團隊的崗位職責和崗位能力就會產生。
  • 人物誌 鮮為人知的中國坦克之父——徐庭瑤
    各位玩家老爺好上次給各位說了咱們下月公測的消息可把小明緊張的啊夜以繼日的進行版本優化~在這期間就讓連連給各位傳播一些知識吧~今天就介紹這位中國坦克之父但是在二戰時期的亞洲戰場——中國,也有這樣的一支坦克裝甲部隊,在抗日戰爭期間發揮了巨大的作用,提起這支部隊,則不得不要提一個人,那就是被稱為中國坦克之父的徐庭瑤。
  • 敏捷組織:有組織 vs 無組織
    雷軍說的沒有戰略並不是真沒有戰略,而是戰略的敏捷化,敏捷地響應用戶需求。而這樣的公司就不能用「工具人」了,領導者必須指望在一線奮鬥的員工自己有想法、能給公司戰略提出建議,甚至敢直接調動資源指揮行動才行。這樣的人才不是螺絲釘,管理這樣的人得像職業足球俱樂部管理球星一樣。
  • 敏捷組織:組織未來運營的法則
    敏捷代表的是對傳統組織架構的一種根本性轉變,它提供了一種完全不同的公司經營方式。麥肯錫對敏捷組織的定義是:能夠以高成效的運營模式,快速靈活地適應環境,抓住機遇、創造價值,並凝聚員工能力的組織。敏捷組織的核心特點是:剛柔相濟——既要有穩定的基礎,也要有動態的能力。一方面,要確保敏捷組織的穩定基礎,包括流程、架構的穩定性以及文化的穩定性。
  • 麥肯錫系列-敏捷組織的五大標誌
    然而,雖然只有不到10%的受訪者在公司或業績單元層面完成了敏捷轉型,但大多數公司對未來抱有更高的期望。四分之三的受訪者表示,組織敏捷性是最重要的或重要性居前三位,近40%的受訪者目前正在進行組織敏捷性轉型。高科技,電信,金融服務,媒體和娛樂似乎領先於最多的組織進行敏捷性轉換。超過一半尚未開始敏捷變革的受訪者表示他們已經有計劃開始進行敏捷變革。
  • 核潛艇之父竟遭「律師」惡毒侮辱!
    律師侮辱"核潛艇之父"被拘留來源:觀察者網、人民日報聲明:本文轉載僅僅是出於傳播信息的需要,並不意味著代表本網站觀點或證實其內容的真實性