在短短 20 分鐘的車程中，我彷彿上了一堂企業經營的實務課程。

下車後，我忍不住獻出人生第一次的 Uber 打賞（對不起我很摳）；並趁記憶猶新的時候，把這次難忘的乘車經驗透過文章記錄下來。

原本以為網路上的司機經營學都是在編故事，直到親身體驗，才知道原來神人真的存在。

在文章開始前我先澄清一下，這篇不是業配文；而是綜合司機口述與我的乘車體驗。

向下相容的解決方案

因為要跟家中長輩一同前往聚餐地點，所以我在 Uber 叫了一台 6 人座的汽車。

車剛到的時候，我就在心中默默吶喊：「今天賺到了！」

因為這是台 7 人座休旅車，上車後我 1 米 8 的身高坐到第三排雙腿還可以自然伸直，甚至車頂離我還有 30 公分的距離，完全沒有空間上的壓迫感。

連坐在司機旁邊的長輩都直接誇獎：「你這台車坐起來也太舒服了！」

在車子受到認可後，司機開始跟我們聊了起來，並分享他為何挑選這款車來做 Uber:

1. 尚未受到市場關注：他在過去工作中開過 40 多款汽車，但最終選擇了這款法國進口車。除了好開外，另一點是因為法國車在台灣的市場尚未打開，所以 CP 值很高，就算頂配也才 138 萬。
2. 低油耗：雖然是柴油車，但行駛過程中幾乎感受不到震動，且油耗表現極佳。
3. 向下相容：因為是 7 人座的車，所以有非常大的載客彈性；甚至因為空間大，有些行李多的乘客即便人數不多，也會選擇叫 7 人座的車。
4. 舒適體驗：車內空間寬敞，無論坐在哪個位置都有良好的乘車體驗。

在聽完邏輯清晰的分享後，我們不由對他的背景感到好奇，畢竟有些 Uber 司機只是把開車當興趣，平常還是有自己的正職。

如何更快達成 KPI

詢問後，司機哈哈一笑說：「我原本是科技業主管，但因為工作佔據了自己全部的生活；但我又不想錯過與家人相處的時光，所以這才轉行當 Uber 司機。」

繼續深聊下去，發現這位司機真的不簡單，他有明確的經營策略，且持續優化:

1. 制定每天、每周、每月要達成的業績：原則上每天的淨利要超過 5000 元。因為 Uber 會向司機抽 25% 的平台手續費，加上其他雜支，所以一天營業額需要到 7500 元以上。
2. 提高達成目標的效率：他在選車時就有自己的策略，因為 6 人座的車，在 Uber 可以加價 30%，基本上就抵消了 25% 的平台手續費。
3. 提高單趟收益：他選擇在高速公路附近有豪宅的位置，又或是動物園這類的親子景點待機；這樣往往有 700～1200 的單趟收入。
4. 配備 2 套 GPS 系統：一個用比較廣視角顯示塞車路段，一個用來調整最佳路線，這樣可以盡可能縮短單趟時間。
5. 優化乘車體驗：考量到人多時車內空氣悶熱，他加裝了兩台小型循環扇，除了讓乘客有更好的乘車體驗外，還可以節省冷氣費。

綜合以上優點，乘客在有良好乘車體驗的狀況下，有較高機率於旅途中稱讚司機；有交流，收到小費的可能性也大幅上升。

人才到哪裡都是人才

在快抵達目的地的時候，長輩最後問道：「為什麼你可以想到這麼多？」

司機回答：「我在科技業時候每天都要解決問題，所以會盡可能把一切都考慮進去，並持續優化現行策略。」

我不確定這位司機大哥過去是不是科技業主管，但我相信他對自己工作的掌握度、面對問題思考的深度，比絕大多數人都還要更高。

其實我之所以會對這個司機印象這麼深刻，是因為同樣的旅程；上一個 Uber 司機開了 1 個小時，而這位司機只開了 28 分鐘，全程沒有超速，只是選擇了幾乎不會塞車的路線。

對司機來說，他們都完成了一單；但對乘客來講，這是完全是不同的乘車體驗。

持續追求更好的解決方案，才有辦法在同個領域持續成長，並受到他人的認可。

能在假期中遇到這位司機真的是我的幸運，如果看完這篇文章後有任何心得，歡迎大家留言分享。

但其實不管團隊、專案還是作品，都是需要被管理的。

如果一切都靠本能去做，那麼專案延遲交付、團隊缺乏方向、作品四散各地…這些可說是必然發生的悲劇。

就算為了減少自己的加班頻率，我們都該對「管理」有更深一層的認知。

管理是為了降低「意外」發生的可能性

每個人都是獨立的個體，所以有各自的想法、做事的習慣；如果沒有講好合作模式，那專案做到一半撕破臉基本上是家常便飯。

下面先列出幾個減少「意外」的方法：

• 簽訂合約: 不管專案大小，合作對象的親疏遠近，筆者強烈建議有合作就要簽約；簽約是專業的展現，也是對雙方的保障。
• 需求規格: 客戶的需求通常很模糊，不過我們可以透過需求規格，將這些發散的想法收斂成具體、可執行、可驗收的白紙黑字。
• 設計流程: 我們需要設計一套可以重複使用，並不斷優化的工作流程。明確的工作流程可以減少揣測彼此想法造成的誤會，並讓我們在面對不同專案、合作對象時有穩定的表現。
• 會議記錄: 任何會議、談話都需要有明確的文字紀錄，而且記錄要包含「是誰說的、前因後果、最終決議」等，這樣日後遇到爭議時才能釐清狀況。

將複雜的事務結構化，我們才有辦法有效管理，並持續執行。

將模糊的資訊明確化，我們做事才有效率，減少重工的可能性。

搞清楚誰有「決策」的權利

有時專案執行到一半，突然一通電話打來要你砍掉重練，因為公司高層覺得專案執行的方向錯了。

收到通知的你可能覺得很靠北，但這個在業界其實很常見，即便有需求規格、會議記錄佐證，但權力夠大的人就是可以推翻一切。

如果想減少這種狀況發生，就要在一開始搞清楚誰才是最後的「決策者」，並建議每次會議的結論需要由他畫押才算數。

很多時候專案的窗口、PM 甚至是主管，都只是在揣摩「決策者」的想法。

建立文件減少資訊「斷層」

有些專案為了求快，許多細節都是靠口耳相傳；這導致相關人員請假時，你需要重新說明一遍。

最差的狀況是關鍵人物相繼離職，而公司根本沒人知道過去發生了什麼事，然後專案就直接爛掉了。

為了避免資訊斷層，或是全公司只有一個人了解專案脈絡，最好將文件清晰的整合到一個大家都能閱讀的地方。

報價與工時都要有「邏輯」

接案時你要對客戶報價，工作時你要向公司預估時程。

但有時類似的專案、功能，我們會給出不同的報價、估時；此時對方可能會問你：「為什麼跟上次不一樣？」

如果你說不出報價、估時背後的邏輯，就會導致客戶、主管對你的印象大打折扣，甚至質疑你的專業能力。

為了避免這種事發生，建議準備一套報價、估時的邏輯＆公式，當對方有疑慮時，就可以有系統地進行說明。

失敗的經驗很珍貴，但不用親身體驗

寫這篇文章的時候有點感慨，想著自己為什麼在經過社會的毒打後才上到這堂課。

課程中所提到的案例都是在現實生活中會遇到的，相信在社會走跳一段時間的朋友們會很有共鳴。

人的生命有限，透過了解他人經歷來豐富自己閱歷，是更有效的成長方式。

以上是「職涯必修設計管理學」的 Part 1 心得筆記 ，如果覺得我的分享對你有幫助，歡迎 Follow 我吸收更多知識。

這幾年有越來越多的團隊導入「敏捷開發」，覺得只要跟上時代潮流，過去遇到的問題就能迎刃而解。

前些日子跟朋友聚會時，發現大部分的公司都有導入「敏捷開發」；但相比於管理階層的推崇，更多工程師是抱著不情願的心態在參與。

不過在這次的聚會中，有個朋友提出的 Daily Scrum 方案讓大家耳目一新，所以我就特別寫了這篇部落格來分享。

一、真的有 Daily Scrum 的必要性嗎？

Daily Scrum 的目的，是讓團隊成員快速同步彼此的資訊。

但理想很美好，現實很骨感；大部分的人只在意自己要報告的東西，換到其他人報告時，大腦往往處於待機狀態。

當然也是有些人持反對意見，因為他們在 Daily Scrum 時討論的熱火朝天；但其他參與會議的人因為覺得議題跟他們無關，所以陷入休眠狀態。

綜上所述，許多團隊的 Daily Scrum 實際上只是走個形式。

雖然上面這段很殘酷，但可能更符合大多數工程師的心聲。

二、Daily Scrum 背後的時間成本與壓力

原則上每個人在 Daily Scrum 的報告時間都小於 3 分鐘。

但為了這 3 分鐘，許多人要花 10 分鐘以上的時間整理資料，並在會議開始前順一下口條。

我們期望 Daily Scrum 除了可以同步資訊外，還可以凝聚向心力；但對於個性內向的人來說，每次開會都是一場劫難。

就拿筆者舉例，儘管我準備資料的時間通常都在 10 分鐘以內，但在會議開始前的 5~10 分鐘，我是無法做其他事情的，因為我害怕事情做到一半思緒中斷。

也許 Daily Scrum 只花 8~15 分鐘，但對許多人而言可能要付出 30 分鐘以上的時間成本。

三、把 Daily Scrum 改為文字報告有什麼好處？

朋友表示為了改善上面的問題，團隊將 Daily Scrum 改為文字報告，幾個月下來發現大家的效率反而上升了，他說這麼做有以下優點：

1. 文字閱讀的速度遠高於口頭報告。
2. 口頭報告可能會含糊不清，但文字報告因為要附上 Ticket，所以很難打混。
3. 想要討論的人可以私下約，不會打擾到其他人的時間。
4. 除非對專案架構很了解，不然聽別人口頭報告常常有聽沒有懂，而文字就減少了這類情況。
5. 只要在規定的時間繳交文字報告即可，有更完整的時間段可以做事。
6. 對個性內向的人來說是一個福音。

四、我的想法

我聽到這個方案的當下很興奮！因為真的解決了很多實務上的痛點！

而且改成文字後，從管理的角度來看，的確更能了解每個人做了些什麼。

但這個方案也未必適合每個團隊，畢竟文字報告跟實體會議的差異還是挺大的，多互動有助於釐清彼此的觀點；如果只把 Daily Scrum 當成進度報告，沒有後續的話就會失去原有的意義。

不過如果 Daily Scrum 的成員時常處於待機模式，也許可以嘗試推行看看；適合 A 團隊的方案，未必適合 B 團隊；任何的變革的成敗，跟「人」的關係最大，也需要根據「環境」來調整，直接複製貼上容易水土不服。

如果讀者有其他的想法也歡迎留言喔，你的經驗也許能幫助到更多的人。

2022.7.29 補充

有朋友看到文章後跟我分享，對他們團隊來說，早上的 Daily Scrum 更像是一種儀式，從嘴巴說出來要做的東西是一種承諾，會給人完成任務的動力。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？(本篇)
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！