【分享本文原因】我在帶團隊或做顧問的過程中，最常聽到主管抱怨：「為什麼事情都已經交代下去了，大家還是會拖延？就算交回來，也常常不能用？」但很多時候，這不一定是夥伴能力差，而是我們在一開始交代任務時，沒有把目標、標準跟檢查節點說清楚！這篇文章想跟你聊聊，當團隊開始拖、交付成果不如預期時，主管可以怎麼調整帶人的方式，讓專案真的往前推進～
-內容目錄-
交代下去的事情總是拿不到想要的結果?
想像一個很常見的職場情境，今天專案負責人小明，在會議上把專案拆解成三個任務，分別交代給不同的夥伴，等到deadline 快到的時候，小明發現東西不但沒交回來，就算交回來的資料也完全無法使用
這時候多數的主管一定會暴跳如雷，心裡想著這群人到底在幹嘛，但如果你身為專案的推進者，遇到這種讓人傻眼的狀況，第一個該反省的其實是自己
你必須靜下心來回想一下，當初在下達指令的時候，是不是真的有把『專案背後的真正目的』給講清楚？
很多時候主管在發布任務，只是單純地把動作交辦出去，卻沒有讓大家對齊在同一個目的上，當團隊成員對專案全貌沒有共識時，自然無法產出符合你期待的結果
除了目的之外，你在交代任務時，有沒有明確給出「驗收的標準規格」？你希望收回來的東西必須滿足哪些規範？這點常常被許多領導者給忽略了
只有把規格制定清楚，才能幫助團隊成員在有效的時間內，交出真正能夠共同使用的產出
團隊愛拖延其實是因為害怕出錯
把目的跟規格都講清楚之後，你可能會遇到第二個問題，就是有些人依然很會拖延，明明時間到了，對方卻遲遲不把東西交出來
如果你是領導人，你要理解多數人拖延的深層心理。很多時候大家不敢交件，是因為害怕交出來的東西不是你要的，或者是害怕不夠完美而被主管責罵
面對這種情況，你反而應該展現柔軟的姿態，告訴團隊成員：「我們先把東西交出來就好，先求有，再來慢慢修正」
我在經營IMV團隊的過程當中，最常掛在嘴邊的一句話就是：「我們先執行再來迭代」
迭代這個概念，原本是程式開發裡常用的語言。它的本質就是承認『世界上沒有完美的初始版本』，我們是透過版本一、版本二、版本三的推進，最終達成想要的目標
你要把這種思維植入到團隊的腦袋裡，打破他們想要一口氣做到位的完美主義。你要讓大家知道，推動與推進，永遠遠大過於完成
如果規格講清楚了還是做錯怎麼辦
好，那如果今天你把共同目的拉齊了，也把交付的標準規格訂得非常明確，結果團隊交回來的東西，依然有很大的問題，這時候該怎麼辦？
這時候有一個很高的可能性，就是你自己對這個專案的目標根本就搞錯了
就像我們在設定OKR的時候，常常會發生目標開始執行了，最後的成果卻跟原本的OKR完全搭不上邊。這往往是因為你在最一開始，就把「目的」跟「關鍵成果」給想歪了
當源頭歪掉，後面整條執行路徑自然跟著全歪，所以如果交代事情下去，大家怎麼做都動不了，或者產出一直有落差，專案領導人請務必反過頭來省思
你必須重新檢視自己針對這個專案所定制出來的關鍵成果，到底是不是正確的，這是在帶領專案時，非常重要且容易被忽略的一個環節
遇到雷隊友先別急著指責別人
當然，我們在職場上難免會遇到另一種極端情況，那就是協作對象特別不負責任，或者對方根本就是擺明了在跟你作對
如果真的遇到這種硬槓的狀況，你要先去釐清，到底是他天生個性如此，還是你們過去的合作曾經發生過沒有處理好的磨合？如果是後者，他現在可能只是單純討厭你這個人，這時就必須把問題攤開來，解決根本性的心結
如果對方真的是因為過去的經歷，養成了一種不想把事情做好的工作態度，那身為主管，你該做的就是果斷地更換專案成員囉XD
但無論遇到多糟的情況，我始終堅持一個原則：遇到問題，絕對不要先去指責別人
當你伸出一根手指頭指責別人不好時，其實有四根手指頭正指著自己，比較成熟的做法是，先反省自己在這次事件中，可以怎樣做得更好
為了讓這個反省過程具體化，我自己在寫自我成長心得時，都會使用一套很簡單的覆盤邏輯，為了方便理解，我把它整理成一個簡單的模板範例
自我覆盤與迭代空白範本
這是我平常在檢視自己專案推進狀態時，一定會問自己的四個核心問題，可以直接拿去運用在工作上
| 覆盤維度 | 具體思考問題 |
|---|---|
| 正確的事 | 在這一個專案當中，我做對了哪些事情？我是怎麼做到的？ |
| 優化的事 | 這次做對的事情，下次我要怎麼做才能更好？ |
| 不足的事 | 這一次我做了哪些不夠好的事？有哪些地方是可以修正的？ |
| 改正的事 | 這些做不好的事情，我下次要透過什麼具體行動把它做到好？ |
專案卡關時的已填寫範本
以「團隊交不出符合規格的報告」為例，當你遇到這種狀況時，你的覆盤內容可能會長得像這樣～這能幫助跳脫情緒，專注在解決問題上
| 覆盤維度 | 具體思考問題的實戰填寫 |
|---|---|
| 正確的事 | 我有設定明確的死線，也確實把任務拆解給 A、B、C 三人。 |
| 優化的事 | 下次除了拆解任務，我要在第一時間把「專案最終要達成的商業目的」跟所有人說清楚。 |
| 不足的事 | 我沒有規定交件的格式，導致大家交回來的檔案亂七八糟無法彙整。 |
| 改正的事 | 下次派發任務時，我會直接提供一個公版表格，請大家照著欄位填寫，降低雙方認知落差。 |
為什麼第一步一定要問自己「做對了什麼」？因為很多人做對事情其實是瞎貓碰上死耗子，如果你不檢討自己為什麼能做到，下次很容易又做錯了
而承認自己「做得不夠好」，並不代表你很差，我的思維模式是，每件事情都可以修正，這次做得不夠好，代表下次我有極大的空間可以發揮得更好
當你每天都用這四個問題去反問自己，其實你就是在實踐『每天比昨天好一點點』的生活哲理，這也是成為職場高績效者的秘密～
讓推進成為習慣勝過追求一次到位
今天分享了這麼多關於專案推進的思維，其實核心都在講同一件事情：要建立一套系統性的做事方法
很多時候我們在職場上遭遇的困難，都是因為我們面對問題時「直覺式的反應」所創造出來的，當團隊表現不如預期，你直覺去罵人，不但解決不了問題，還會讓團隊更不敢做事
真正的領導者，遇到困難會先停下來，思考自己該用什麼反應，才能真正把事情往前推動，而「階段性完美主義」的思維，是需要刻意練習的
知識停留在腦袋裡是沒有用的，知道與做到之間，存在著「執行」的巨大鴻溝，透過一次又一次先執行再迭代的過程，你才能把這些觀念內化成你專屬的好習慣～～
如果想更系統地建立職場思維
這篇文章跟你聊了很多我在帶團隊跟做專案管理時的心法，如果你覺得這些觀念對你有幫助，我想跟你分享幾個我整理出來的延伸資源
這些資源都不是什麼魔法，而是我過去這十幾年來，實實在在摔過跤、除過錯之後，整理出來的系統路徑
首先是我的著作，書名叫做《關鍵思維：解除焦慮，成為不凡的關鍵人物》
這本書其實是我當初為了IMV團隊內部教育訓練而寫的教材
我把那些看似抽象的系統思維與人生法則，轉換成可以落地操作的框架。這本書想告訴大家，其實每個人都有潛力，往往只是缺少一把能看透局勢的關鍵鑰匙
另外，如果你在職場上常常遇到卡關，需要一些實戰經驗來突破盲點，可以看看我做的 線上品書～
這不是一個單純講書的地方，而是我把過去解決各種管理、溝通問題的實戰過程，搭配一本書的理論知識整理出來的內容
品書的核心是實戰，重點不在於你有沒有看過那本書，而是如果你不知道怎麼把理論用在工作上，這裡面有我拆解出來的具體步驟
最後，就像我前面提到的，知道跟做到之間需要跨越障礙。很多人之所以無法把知識迭代出來，是因為沒有掌握對的學習方式。如果你正在找一個能真正幫助自己建立學習迴圈的方法，這堂課就是在教你如何透過不斷的 try error 讓知識真正內化到你的骨子裡
關於專案推進我常被問到的幾個問題
Q1：為什麼我們在交辦任務時，總會不自覺地預期團隊能一次做到好？
這其實是多數人在職場上最容易掉入的思維盲點！當我們腦袋裡有一個清晰的最終畫面時，我們會預設別人的腦袋裡也有同樣的畫面～
但現實是，每個人接收資訊的頻率跟過去的經驗都不同，自己以為的常識，對別人來說可能是完全陌生的領域
這種預期心理，往往來自於我們想要節省溝通成本，但反而會在後期付出更大的除錯代價。所以，接受「一定會經過迭代」這個事實，才是成熟專案管理的第一步～
Q2：如果團隊一直處在「先求有再求好」的迭代狀態，會不會反而拖慢整體的專案進度？
這個問題非常犀利。很多人誤以為迭代就是隨便亂做交差了事，但其實真正的迭代，是建立在「有明確的標準規格」之上的
當你把最低門檻的規格定清楚，大家交出來的東西就算不完美，也具備了初步的可用性
比起大家因為害怕出錯而卡了兩個禮拜交白卷，三天就交出一個 60 分的版本，然後再花三天修改到 80 分，整體的推進速度絕對是更快的
Q3：文章裡一直提到要給出「標準規格」，具體來說到底要給到多細？
所謂的標準規格，不是要你把每個細節都寫死，而是要確保『產出物可以直接銜接下一步』
舉個例子，如果你請夥伴去整理一份競品資料，你的規格不應該只是「幫我找三家競品」，而是「請用 Excel 表格列出這三家競品的價格、主打功能、以及他們的客群，檔案要在禮拜三下班前放到雲端資料夾」
只要把這幾個明確的邊界畫出來，對方不管怎麼發揮，交回來的東西都不至於完全不能用
Q4：如果在專案推進的過程中，我發現自己的 OKR 真的定錯了，中途應該直接改掉嗎？
這要看你發現的時機點。如果你才剛啟動不久，發現目的跟關鍵成果完全對不起來，那我會建議你立刻喊停，重新對齊目標
但如果專案已經執行到一半以上，這時候硬改 OKR 反而會讓團隊無所適從
比較好的做法是，把這次當作一個迭代的過程，先盡力把現有架構下的產出做到最好，然後在專案結束後的覆盤會議上，好好檢討為什麼一開始會把目標定歪，確保下次不會犯同樣的錯
Q5：如果我想把這種「先執行再來迭代」的思維導入到現在的團隊，第一步該做什麼？
第一步絕對不是去開會宣導這個口號，而是主管自己要先以身作則，改變對待錯誤的反應
當下次夥伴交出不夠完美的東西時，不要再急著生氣或指責，而是告訴他：「很好，我們已經有了第一個版本，接下來我們來看看怎麼把它優化」
當團隊發現，交出半成品不會被罵，而且還能得到實質的指導時，他們的心防就會放下，整個團隊的推進節奏自然就會帶起來。這也是我過去在輔導企業時，一直在推廣的領導力心法
聽聽影片裡比較隨性的閒聊
這篇文章其實只是整理我自己的一些經驗筆記，挑了幾個我認為在專案推動上最核心的觀念來跟大家聊聊
但在原始的影片裡面，我其實分享了更多關於面對團隊狀況時的心境轉折，語氣也比較輕鬆自然。影片裡面其實談得更完整，包含一些我在日常中如何調整自己情緒的小細節
如果你剛好有興趣，或者想理解整個思維的脈絡，可以看看下面這支原影片，或許能帶給你更多不同視角的啟發喔～
