轉載自 http://36kr.com/p/5043427.html

編者按：本文作者老萬，36 氪經授權轉載自其個人微信公眾號“老萬”（ID：laowanweixin），歡迎關注討論。

昨天中午發生的一件小事兒，引發了我的一些思考。所以想聊一聊這個話題。

我跟項目組的一個同事說：這周五晚上我們項目組一起去公司旁邊的『滬茗軒』聚餐，算是今年的開工飯吧。大家一起坐下來吃吃飯、聊聊天。你來統計一下具體人數。午休結束剛一上班，該同事就在項目群里面發了一條消息，內容為『周五晚上吃飯，統計一下 有誰有事兒不去的嘛？』 過了大概 10 分鐘仍然沒有人回復他『項目組大概 20 人左右』，我知道這個事兒他可能搞砸了。那么這個事兒如果我來執行，我會怎么做呢？以下是我寫的一個腳本：

項目組年后開工聚餐，參加人數統計：

時間：本周五（16.02.19）晚 具體開餐時間待定

地點：滬茗軒 (出公司南門，向南走 800 米，馬路右手邊)

請大家在看到消息后及時給予反饋。如果確定去，請回復數字 1；確定不去，請回復數字 0。

回復截止時間今天下班前。

下班前十分鐘，對于沒有回復的人單獨『電話或微信』確認一下。

最終輸出統計結果。

從最終的執行結果來看，第二種肯定是更加有效的。那么我們可不可以通過學習，掌握如何更加有效地執行呢？

執行必須要基于故事化場景

其實，熟悉 GTD 的人應該可以很清楚的認識到：上面我寫的腳本只不過是按照 GTD 的核心原則『收集、分類整理、拆分、執行和回顧（輸出）』這五個步驟來具體把事情做完。我個人喜歡把 GTD 的這五個步驟進一步通俗化，稱之為『故事化場景』

1、收集：這里面任務包含的信息有『項目組』、『吃飯時間』、『吃飯地點』、『需要確定多少人參加聚餐』

2、分類整理：『項目組』、『吃飯時間』和『吃飯地點』屬于一類；這些是這個任務的輸入，也可以稱之為『因』。而『需要確定多少人參加聚餐』這個則是輸出，也就是這個任務的『果』

3、拆分：拆分就是對上一步『分類整理』之后的每個元素進行進一步細化。細化必須要達到一個原則：參與輸出的人（項目組的每一個成員）必須對你細化后的結果沒有任何歧義或將歧義降低到你能控制的最小程度，而且參與者可執行。只有這樣，拆分才是成功的、有價值的。我的拆分是這樣的吃飯時間拆分：

明確周五的具體時間，并交代了一下具體開餐時間待定，因為這個雖然暫時未定，但是對大家可能比較重要。

周五晚 → 本周五（16.02.19）晚

具體開餐時間待定吃飯地點拆分：有些人可能不知道滬茗軒在哪，不知道周五下班后怎么過去。所以有必要查一下，詳細說明下怎樣才能到那邊。

滬茗軒 → 滬茗軒（出公司南門，向南走 800 米，馬路右手邊）

項目組拆分：首先，需要確認一下項目組的成員列表；哪些今天在公司，哪些今天不在公司。然后，將項目組所有成員拉一個多人會話，通知聚餐事宜。對于特殊情況還沒有來上班的同事，通過電話或微信等單獨確認。

項目組 → 在公司的同事和不在公司的同事

確定參加人數拆分：首先，需要有效的統計方法，可以通過『軟件投票統計』、『0 和 1 簡單選擇投票』。然后，需要對投票的結果進行跟蹤。會不會有些人不在座位上或者根本沒看到消息？想辦法建立一種『提醒機制』。注意：這里的投票截止時間其實就是留給自己的一種『提醒機制』

確定參加人數 → 建立投票機制和最終確認提醒機制

4、執行：以上三個步驟都是為高效執行做的準備。執行才是至關重要的。

5、輸出結果：將最終得到的統計情況進行整理，并最終輸出。任務完成。整個事情的執行過程其實就是：任務的下發者講訴了一個故事「任務」，并告訴了你故事的開頭「輸入」和結尾「輸出」。而具體的執行者就是要把這個故事基于現實這樣一個場景把它講出來。而且故事講的越好「高效執行」，大家也就越喜歡聽「樂于參與」。

看來會講故事還是真的挺重要的。

執行最終要關注效果，而不是效率

現代管理學之父彼得·德魯克先生在談到他是如何認識到效率和效果的區別時，講訴了他和夫人 Doris Drucker 相識相愛的一個小故事。

德魯克曾經暗戀一個女孩子 Doris，兩人認識有六七年的時間，彼此印象深刻。后來，德魯克去了倫敦并和這個女孩子失去了聯系。突然有一天，他在倫敦的一個很長的地鐵里面，突然看到了這個女孩子 Doris。 他鄉遇故知，他們兩個都是欣喜若狂。兩個人這時都在扶手電梯上，德魯克在上去，Dorish 在下來。然后德魯克上來電梯以后，馬上就掉頭轉到往下的那個電梯。而 Dorish 則在下了那個電梯之后，馬上就掉頭轉到往上的那個電梯。這樣他們就再一次擦身而過、失之交臂。因為兩個人還都沉浸在相逢的那種狂喜當中。這種情景又重復了一次。最后，德魯克終于意識到了：必須有一個人停下來，兩個人才能真正的見面。所以他就停下來，等 Dorish 過來，他們才真正的擁抱在一起。這就是效率和效果的區別。電梯只是解決了效率的問題。但是，無論電梯多快，它只能解決從上到下或從下到上的問題，它不能保證你有效果，即：兩個人能夠最終擁抱到一起。

我們再想一想剛才聚餐的那個例子。

想象一下：如果項目組只有 5 個人，而且大家都坐在一起。那我剛剛寫的那個故事場景的腳本肯定就要變了。『同事可以站起來，大聲吼一聲！而根本沒必要碼字、拉多人群等等。就可以高效的完成任務』。如果仍然采用我的那個腳本，無疑就是低效率的。

再想一下：如果是整個項目組有 50 個人呢？那可能我這個腳本也不一定合適，可能他需要寫一封郵件。

如果是整個公司呢？他可能要發個廣播消息或者在 OA 辦公系統上發個通知。因為，這個時候，我的那個腳本注定無法產生最終的效果了。當然，我們根本就沒有那么多活動經費，操這個心干啥呢...

執行必須要形成閉環，不斷的輸出和反饋

現實生活中，我們接收到的任務肯定比『聚餐統計人數』這個任務要復雜得多。形成執行閉環就是讓事情有始有終，任務從啟動到結束，形成一個完整的鏈條。

CTO 給你安排了一個技術預研任務，你應該定期反饋的工作包括：技術選型，遇到的困難，解決的辦法，最終的預研結果等等。這些工作你都可以基于『故事化場景』來進行收集、分類整理、拆分、執行和輸出。任務的最后，你應該提交一份技術預研報告，并針對這樣一個結果發起一次評審。可惜的是，很多技術人員只對技術有熱情，對反饋毫無概念。接到任務之后默默預研，完成之后默默等待下一個任務的降臨，只要沒人問，就一直牙關緊咬，目光堅毅，打死也不說。如果分配任務的人疏忽了，這個任務可能無疾而終了。

還有些技術人員，對任務的產出結果根本沒有理解透徹，就立即開始執行。執行起來倒是非常迅速，看起來很努力、很高效。殊不知，這樣的情況下，你做的越多，錯得就越多。離最終的任務達成也就越來越遠。這也就是傅盛所說的『不要用戰術上的勤奮，來掩蓋戰略上的懶惰』這句話的一種真實寫照。

近幾年來，互聯網行業、軟件開發管理為什么一直在強調『敏捷』和『迭代』的原因。通俗來講，就是要把一個較大任務的執行過程進行分解和拆分，形成若干個可以迅速執行的小任務。而每個迭代的產出都會是一種輸出和反饋，用來驗證這個迭代是否是朝著最終的目標更近了一步。一旦發現偏離了方向，一切的調整和改進都還來得及。

總結

總結一下，如何有效的執行。

首先，一定要明確執行的目標，執行的效果「而不是效率」決定了執行的最終意義和價值。

然后，具體執行時，一定要將任務進行『故事化場景』輸出。這會幫助你有效的梳理清楚執行的方法，保證執行的過程更加有效率。

最后，在執行的過程中，一定要不斷的迭代輸出和反饋，不斷地修改執行腳本。這個過程會幫你發現執行過程中出現的問題，及時作出調整。避免做很多毫無意義的努力。

希望這篇文章能夠對我的那位同事有所幫助。也希望他能不斷的學習和進步，執行更加高效，為項目和公司作出更多的貢獻！

本文來自讀者投稿，不代表 36氪 立場，如若轉載，請注明出處：http://36kr.com/p/5043427.html

“看完這篇還不夠？如果你也在創業，并且希望自己的項目被報道，請戳這里告訴我們！”