[討論] 再論專案管理
在軟體工程上，最麻煩的往往不是技術問題。
是 schedule。
我的 schedule 到底該怎麼達標？如何不過度承諾，又能確保團隊如預期交付？
這是一個亙古的問題，牽扯的面向很多。
───────────────────────────────────
◆ 需求：50% 以上的問題來源
在工作上，有【50% 以上的問題】是來自於需求追加跟處理。
這裡我會建議引入「最小工作時間」的概念。就跟汽車引擎啟動需要暖機吃油
一樣，團隊投入評估也是一個暖機啟動的過程，中間變更方向是非常浪費的。
我往往會抓【3-5 天】作為暖機的最基本單位，由 2-3 個主要的 PM 收集需求
，讓暖機動作在他們身上完成，產出需求。
一旦暖機完畢，要再變更？要嘛直接丟棄，要嘛等下一個週期。一旦進入機器
裡面，大原則上就不給臨時變更了。
說真的，這件事能做到的團隊，需要非常有紀律，需要有足夠信用，也需要有
一定的能力。但如果做不到這件事？你談準時，基本上都是不負責任，而且緣
木求魚。
──────────────────────────────────
◆ 修改成本的迷思
很多人會擔心：一開始做錯了，後面修改成本會很高。
但其實要看事情。有些事情修改成本確實很高，但有些事情修改成本低到靠北
。所以每件事情都要 micro control 到極致，是非常浪費成本的。
至於哪些事情可以變更、哪些不能變更，這在需求討論時必須由 PM 給出【邊
界定義】。這個邊界寫得好不好，直接影響整件事情的關鍵成敗。
但現實世界最大的問題是，很多時候 BD 根本搞不懂客戶要啥，我們自己當然
就跟著亂了。
這種時候就只能採取保守策略：一次步伐小一點，但多步伐，客戶驗證週期留
長一點。用這種方式做小步快跑來因應。如果明知道市場是這種模式，還要用
大型瀑布流，基本上就是自殺了。
不同的條件要使用不同的工作流，但台灣很多時候我們都期待以不變應萬變，
那當然就是卡死團隊也卡死自己。
──────────────────────────────────
◆ 團隊怎麼動起來
知道要做什麼之後，下一個問題是：怎麼讓團隊動起來。
這是一個很大的問題。我們都知道一個團隊可能有幾十個人，但管理者其實就
那幾個。
訓練良好的團隊，當然可以動得很快。但多數團隊哪有辦法訓練得很好？很多
時候大家都是臨時這邊招一個、那邊招一個，這邊是小菜鳥、那邊是資深工程
師，大家混在一起，光團隊磨合可能就要花上一段時間。
況且團隊可能又有人離職、有人進來。在中小企業來說，團隊其實常常處於一
個有點混亂的狀態。就算是已經成熟的團隊，工作方法也可能受限於過去累積
下來的模式，很難去做調整或轉換。
──────────────────────────────────
◆ 傳統分工的極限
過去的工作方法論，通常是職務分工：前端、後端、UI 各有人帶。這種方式
是利用工作分工，讓大的指令被分切成小的指令。
可是在多模組的情況下，當你的系統複雜度已經到了每個領域知識都需要用模
組切開來分工的時候，狀態就會變得非常複雜。
你會發現這些人已經沒有能力掌握所有事情，他們會進入下一個狀態：
【當你問他任何問題時，他都必須回去問他的 team member 才有辦法回答。】
當你發現一個小主管，哪怕是最基層的小主管，已經進入到這個狀態時，表示
你的管理已經開始失靈了。
這種時候，就需要考慮是否把團隊縮小。
我個人一向相信：越小的團隊，溝通成本越低；越大的團隊，溝通成本越高。
──────────────────────────────────
◆ 齒輪團隊
這些事情都已經是老問題了，這麼多年我們也反覆在挑戰。那為什麼今天要再
談一次？
主要的核心問題在於：我們現在面臨的問題是有十幾、二十條不同的工作鏈，
而且具有相依性——可能前面要先做完，後面才能做；或者大家都要一起做完
，才能上驗證、上整合。
這就牽扯到整合的強度，也就是這些「齒輪」的磨合。
我在 2023 年的 Modern Conf 講過「齒輪團隊」磨合這件事：
1. 【齒輪磨得準】：大家浪費的時間最少，速度可以跑得超級快
2. 【齒輪磨得不準】：產生的 Gap 會很大，光是一件事情的往返可能就三個
禮拜不見了
這一來一往是好幾倍的差距。
台灣在做這種「齒輪化」、「任務分工化」這件事上，其實有很多值得討論的
地方，但我們檯面上基本上都沒在討論，這蠻可惜的。
──────────────────────────────────
◆ Scrum 的迷思
很多時候我們在討論的，其實都是什麼 Scrum，你要寫 Story、要寫 Point，
讓大家一起參與討論。其實大家迷信的一件事情就是：只要每個人都有講到話
，這件事情就是對的。
但這他x的屁啦！
一件事情能不能被完成，重點在於：
1. 要有知道該怎麼做的人
2. 用對的方法，以及團隊能夠接受的方式把流程推出去
3. 讓團隊按部就班地把流程的每個環節都做出來，穩定完成上線
這跟有多少人參與討論、提供意見或負責，其實沒有直接關係。重點是你有沒
有適當的 idea 在討論中冒出來。
很多人會以為人多就一定會有好的意見，並沒有。人多更多的時候只是浪費你
無限的會議時間，讓大家更沒辦法專注自己的工作。
本來的執行工作做得不好，連規劃工作也要進去插一腳（尬一咖），結果本來
可以做好的執行工作根本做不出來，規劃工作也是一團亂局。
這才是台灣多數職場的現況。
──────────────────────────────────
◆ 找對的意見
今天我們要談的事情是，我們到底要怎麼去看待一個團隊分工的討論。
首先，團隊必須要有能力找到：
1. 誰的意見是重要的
2. 誰的意見是對的
3. 誰的意見是建設性的，是可以讓團隊前進的
然後，我們要讓有建設性的意見一直處在領導團隊的位置。同時，讓那些沒有
建設性、或者對進度有害的意見，可以被抑制、緩和掉，讓團隊可以減少浪費
時間。
──────────────────────────────────
◆ 害怕不能阻止決策
很多時候，意見是來自於害怕。我們會擔心如果在這個地方太武斷，做了一個
太強烈的決策，會不會被人指指點點，或者以後要修改會變得很難。
這時候，我們要回來問自己一個問題：我們知不知道這個東西以後會不會被改
？
如果沒有資訊，我們可以再問一下客戶。如果客戶沒有想法，我們也沒有想法
，那就關起門來問我們自己：我們覺得客戶在接下來這半年到底會怎麼改？
如果答案都是不確定的，那我們為什麼不做決定？
【就做啊！】做了決定就往前走。
你要在對的時間點做對的決定，然後讓事情 move fast，這才是我覺得團隊管
理中最核心的事情。
──────────────────────────────────
◆ Buffer 的惡性循環
下一個問題是，我們很常會碰到工程團隊面臨的一個老問題：大型功能怎麼拆
。
在這種情況下，工程師會很害怕，他會覺得：「我要跟那麼多系統整合，這肯
定很難。當別人叫我預估時間的時候，我是不是應該抓得保守一點？」
所以這時候你就會碰到一個情況：大家都在抓 Buffer。
其實抓 Buffer 並不是錯的，我覺得這是負責任的行為。但問題是，抓 Buffer
隱含著一個惡性循環：
1. 團隊越沒有效率，大家抓的 Buffer 就越長
2. Buffer 抓得越長，團隊成員就越認為彼此沒有效率
3. 這種認知會導致大家把 Buffer 抓得更長
──────────────────────────────────
◆ 先拆素材，不管時間表
所以理想情況是，我會跟做介面的說：你先不要管對接，把這些欄位全部挖出
來。對接的部分，我們等欄位做完之後，再排一個完整的工作來處理。
大家先把彼此的素材整理好，先不用管時間表。我們有 3 到 4 天的時間處理
前置工作，先把所有素材攤開，到時候我們再看著素材來討論。
如果介面非常龐大，比如有四五個 step，我通常會建議：我們不要一次做完
全部，先做第一頁。一個 Sprint 接著一個 Sprint 地把東西做起來。如果總
共有四頁，那就分四個 Sprint，四次之後我們就有完整的東西了。
如果你現在抓不準時間，沒關係，我們就拆 Sprint。我可以用最寬鬆的方式
拆給你，但是你必須事先告訴我你要怎麼分解，每一個 Sprint 你具體要幹什
麼。
──────────────────────────────────
◆ 為什麼團隊不願意估準時間
我跟你講，很多團隊之所以不願意估準時間，或者會估一個很長的時間，是因
為他們真的沒有動腦筋想過 Sprint 到底該怎麼切。
他想的只是先把程式碼全部刻完，然後看 QA 能測出什麼屁事，等 QA 把問題
都測出來後再全部修完。
但一個正常的軟體工程絕對不該是這樣子的。我們應該是：
1. 一個零件一個零件地打造
2. 一個零件一個零件地驗證
3. 最後只是把零件拼裝起來而已
這樣我們在最後整合的時候，就不會突然噴出幾百個鳥問題。一個正常的軟體
工程團隊根本就不應該那樣做事。
──────────────────────────────────
◆ 信任感與責任歸屬
所以你怎麼去拆解這些工程師的 Bullshit？你怎麼去處理好每個角色彼此之
間對時程的害怕？
你怎麼讓大家相信，反正東西交出來到我手上，我就是個魔術師，我可以把這
些東西都拼裝起來？
你怎麼讓大家相信他交出來的東西，即使他看不懂全貌，但他可以相信後面有
個人會 pick up，把邏輯接起來，不會掉球，不會事後過來靠北說是他沒做好
？
你怎麼讓團隊有這種信任感？
【責任的歸屬、時間的歸屬、時程的歸屬，這些就是考驗你 Product Owner
的職責、設計與規劃。】
──────────────────────────────────
◆ 台灣很少人在討論這件事
在台灣，有認真在做這整個結構思考的人其實真的非常少。你看文章有多少人
在談這件事情？我覺得幾乎沒有吧。
所以我自己很喜歡寫這一段，因為我覺得這才是值得討論的事情：
1. 【團隊整合】：你怎麼讓團隊裡面有大有小、有老有少、各自都很有個性
的人，可以揉成一個團隊？
2. 【流程優化】：如何讓他們變成一個生產線，一兩個禮拜就可以上一次軌
道？
3. 【協作默契】：讓大家跟流水線一樣，各自安分守己地拼裝自己的生產線
這不就是管理工作嗎？這不就是我們該追求的事情嗎？
──────────────────────────────────
◆ 為什麼我要寫這些
我今天寫這些內容，是因為大家都在 bullshit 地講我們要用 A 方法，還說
A 方法要思考 5W1H。去你x的，問題真的是我們不知道那 5W1H 嗎？
不是。
問題是我們沒有真的去思考團隊與團隊之間的隔閡，沒有想過這個人可能就是
沒有能力的。我們只是覺得老闆交代一件事情下來，我這件事情就一定要派一
個人出去；他沒有做到是他的事，不關我的事。
當我們每個人都用「是他的事，不關我的事」這種心態在處理團隊的事，進度
當然會走得亂七八糟。
───────────────────────────────────
◆ 每個人都必須有產值
真正的情況是：
1. 團隊既然花了這筆錢，哪怕招募了一個領六七萬月薪的人，他實際上只能
做三萬的工作，你還是至少要讓他發揮出三萬的貢獻。因為他如果沒有發
揮出貢獻，價值就是零。
2. 你可以之後再用績效考核去處理他，讓他離開；但是在此之前，你不可以
讓他完全沒有產值。每一個人只要進了團隊都必須要有產值，最起碼不能
是負數。
───────────────────────────────────
◆ 管理的本質
所以管理的本質應該是：
1. 思考如何把每個人的產值用到最好
2. 讓產值沒達標的人可以慢慢離開這個團隊
3. 讓產值達標、做得很好的人，能藉由獎金或獎勵，讓他們心裡覺得自己的
付出是有被看見的
可是在台灣，永遠都是你管理得好是應該的，你做得好也是應該的；然後你做
得不好就罵你一頓，痛罵你一頓，把你罵到離職。
每一個團隊都在找替死鬼、背黑鍋，這有什麼意思？這根本就不是管理的本質
。
【管理的本質是要讓大家心甘情願地為你賣命。】
──────────────────────────────────
◆ AI 時代的管理
所以我寫這些文章，是因為看到很多人在談方法論，特別是 AI 出來後，大家
還在談這些。
其實我覺得本質上，AI 就是一個員工。在我眼裡，AI 大約就是一個價值 3
萬的員工，你最多可以養兩個，再多你就指揮不動了，因為目前的 AI 指揮負
擔成本比較重。
以我為例，考慮到成本和管理負擔，我平常可以一管八（人），但在 AI 時代
，一管二到一管三就是極限了。對我來說，你可以完全把真人跟 AI 員工放在
同一個平面看待。
如果他們堆疊 AI，把自己變成更強的人，我就會把他們視為「有外骨骼的人
類」，可以做更多事情。但本質上，我們還是一個團隊，核心目標是：
1. 把需求池裡的東西做得穩定、順利
2. 準時上線，讓客戶能準時使用功能
這才是整體核心的戰鬥，最終還是回歸到對需求、分配以及知識交換的妥善設
計。所有的方法論，都是為了協助解決這些事情。
──────────────────────────────────
◆ 我們真的沒有認識自己的員工
可是最奇怪的地方在於，我們真的沒有認識自己的員工。我們不了解每個人：
1. 他會什麼，不會什麼
2. 強項在哪裡，弱點在哪裡
3. 什麼事情他不該碰，什麼事情他做了會搞砸
4. 什麼事情他做起來超強
其實管理團隊很單純：讓他做他做起來超強的事情，不要讓他碰他做得非常爛
的事情；或者只在安全、可以磨練的時間點，才讓他碰那些他不擅長的事。
如果每個人都只做他們擅長的事情，其實真的沒那麼多（瑣碎的）事情可以做。
───────────────────────────────────
早上看了一篇文，覺得應該要來講一下。
這篇文章全部都是用語音轉換，再加上我自己寫的一個語氣 Skill 讓 AI 幫
我整理完成的。試試看這樣的寫作流程，我覺得蠻有意思的。
方法論可以談，但真正的管理從來不是方法論。
是認識你的團隊，認識你的員工，然後讓對的人做對的事。
僅此而已。
───────────────────────────────────
* 人工補註1
本篇採用語音輸入+ ai 潤稿，我覺得確實有幫助我，
把本來一些已經講到懶得講的東西再講一次。XD
* 人工補註2
發現他漏掉我談 產品分工的那一段 懶得重補了 XD
總之 職務分工的問題是 事情過了門檻就會 overhead 變超高，
產品分工則是產品不夠大就會很浪費，兩個各有他的問題。
本質上還是要回到對產品跟員工能力的理解。
--
I have a dream, it's silly but beautiful.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.34.27.1 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1770177295.A.0BB.html