好的領導者在開會時最重要的事:讓大家誠實回答「這個問題」

好的領導者在開會時最重要的事:讓大家誠實回答「這個問題」
Photo Credit: Corbis/達志影像

我們想讓你知道的是

為什麼集結眾人的智慧會犯錯?因為有兩種原因,導致這四種失敗。

文:凱斯.桑思坦(Cass Sunstein)、雷德.海斯蒂(Reid Hastie)

當經理人和其他的領導者要決定事情如何進行時,通常會把問題先解釋清楚。但為什麼把問題先說清楚會對事情有幫助呢?這到底是什麼原因?審議在什麼時候會很重要,甚至是理想的情況呢?

答案裡有一大部分的原因是,如果大家彼此對話,就會出現更明智的判斷,結果一定會更好。但審議真的有這種效果嗎?這個問題很重要,而且跟經驗有關,沒辦法用直覺或故事傳聞來回答。藉由彼此施壓,群體成員能達成共識,可能是因為虛假,而非根據事實。一群想法類似的人就容易犯錯,因為成員的態度有類似的傾向,這時會特別容易出現這種問題。如果一群人認為政府複雜的計畫將會立即奏效,或是一個未經試驗的新產品將會大賣,可能就是好聽話的負面案例。

群體審議之所以會出錯,有兩種情形需要解釋,因為這些情形會影響群體成員:

第一種是「資訊型信號」(informational signal),如果他人早一步先公開資訊,反而會讓人不好意思再揭露自己所知的事。舉例來說,在聯邦政府,大家閉口不言,可能是因為以為官員之所以不透露想法,是因為官員有自己的消息,而且一定是正確的。如果國防部部長確信軍事入侵是個好主意,部長的下屬就可能會閉嘴不發言。這不是因為他們同意部長的看法,而是他們以為部長應該知道自己在做什麼。

在私人和公共部門,領導者常常似乎有著光環,讓他們顯得格外敏銳和聰明,他們說的笑話比較好笑、才智更高、觀點更完整、問題更深入。在政府裡,桑思坦注意到確實有這種現象,公僕有時候會高估自己的假設和資訊不全的判斷,以為自己比實際情況更高明。但這是一個很實際的問題,特別當你自尊心很強時,經歷光環是一種很棒的感覺。而這樣更會鼓吹大家說好聽話,讓群體更容易犯錯。焦慮的員工能提出重要的糾正,因為員工們願意去思考領導者是否正確。如果領導者自己會擔憂,儘管嘴臉上掛著微笑,讓人感到溫暖,但是心裡確有小小不安的疑問,「我有沒有疏忽了什麼地方?」這種領導者就會讓他們的群體更好。

第二種影響力和「社會壓力」(social pressures)有關,人會為了避免各式各樣的處罰,選擇閉口不言。在很多群體案例,決策的重點是會不會遭到他人否決,如果不贊同你想法的人位居高官,那你可能會倒大楣了。在企業裡,大家常常不願發表看法,避免揭露他們知道的事,不是因為事情不重要,而是因為他們不想顯得愚蠢或龜毛。如果領導者或是群體裡大部分人似乎都很確信,這時候,成員更是不可能大膽說出自己的看法。因為他們心裡會想,說出來會讓老闆難過或生氣,這樣值得嗎?

從老闆的觀點來看,答案應該是值得的,因為這樣才有機會學到其他東西。但有些老闆不是這樣看事情的,所以很多員工知道最好別多嘴,這樣才是上策。再次強調,正確的擔憂長遠來說,可能會大有幫助,因為會擔憂的員工不會太在意社會壓力,而且會擔憂的老闆才會廣納不同的見解。

由於有這兩種影響力,群體會出現四種個別的問題:

  • 群體不僅無法糾正成員的錯誤,實際上,他們還會「放大」那些錯誤。
  • 群體會犯了「模仿效應」(cascade effect)的毛病,先發言或先行動的人的言論和行為,會導致其他成員群起效尤,就算那些言論和行為會導致群體走向不幸、糟糕或悲慘的結果。
  • 群體變得更極化,常常變得比討論前的立場還要極端。例如:當一群人有過度樂觀的傾向時,因為經過內部討論會變得更加樂觀。
  • 群體專注於共享的資訊,也就是大家已知的消息,這樣反而阻礙到尚未分享的資訊,雖然單一或少部分人持有棘手的關鍵資訊,卻無法發揮效用。

因為這些問題,群體常常無法達到糾正個體錯誤的最低目標,也無法整合成員真正持有的資訊。群體信心滿滿、向心力強,但是容易出錯,絕非好事。相反地,這對群體本身和其他人都可能非常危險。前途看好的新創公司可能因此失敗;政府機構可能會浪費納稅人的錢;新的聯邦計畫可能會失敗。大公司可能繼續進行嚴重錯誤的做法,儘管老早就應該喊停了,還繼續做下去。律師事務所可能堅持一項注定失敗的訴訟策略。當群體做出錯誤或是自我毀滅的決策時,失敗的原因通常可以歸咎於上述四種問題。

為什麼會導致知道資訊的人保持沉默?

為什麼在知道別人的觀點之後,可能會讓人不去揭露或採取所知的資訊和行動呢?

群體強壓過個人

人們會保持沉默的第一個原因,是跟其他人所說和所做的資訊有關。假設群體裡大部分的人都相信某項提案,那麼你就有理由相信提案事實上是正確的,就算你私下單純地認為提案不對,但群體的想法可能比自己的想法來得有分量。同理,如果大部分群體成員不同意你的看法,你可能會捨棄自己的資訊。群體的資訊訊號會強到壓過你個人的資訊訊號。

由於這個因素,每當群體成員被隔離或是意見屬於少數時,大家可能就不會講出想法來,只單純聽從他人的說法或行為而來的資訊訊號。舉例來說,在法律事務所裡,大部分的成員可能會認為在法庭裡相當有機會勝訴,因此過分樂觀(我們已經發現,人們普遍會有不切實際的樂觀傾向)。這種樂觀的態度可能導致企業裡懷疑的聲音自動消音,理由是認定自己的消息不靈通或判斷錯誤。問題是,如果存有疑慮的人悶不吭聲,不把看法說出來,群體可能因此喪失重要的資訊,然後就根據情況行事。這可能導致嚴重的結果,甚至釀成大禍。

美軍攻占古巴豬玀灣失敗就是一例,這個事件非常有名,具有啟示意義。攻占計畫是要推翻古巴卡斯楚所領導的革命政府,失敗的原因是,甘迺迪總統的顧問沒有提出看法,甚至他們是有理由相信這個任務會失敗。在這個事件中,美國有兩艘補給船被古巴軍隊擊沉、兩艘船逃之夭夭、四艘船沒有及時抵達;而古巴的流亡分子約有兩萬人受到美軍的良好訓練,有不少人遇害,倖存的一千兩百人被捕,對被捕的流亡分子,古巴政府取消其公民,並以此做為人質向美國索賠。最後,美國以五千三百萬美元的對外援助做為交換條件,才讓古巴釋放人質,但也連帶引發國際社會對美國的譴責,反倒還強化古巴和蘇聯兩國的關係。


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡