簡介：工作中經常遇到這樣的場景，老板交給了你一件事，這件事是一件橫向的，需要其他人參與，時間跨度可能會比較長的。遇到這樣的事，很多人上來就埋頭苦干，渾渾噩噩到最后都不知道自己在做什么，尤其作為一個一線的小兵，不帶人，這個時候，你需要一些成事的方法來加持。

作者 | 永度
來源 | 阿里技術公眾號

工作中經常遇到這樣的場景，老板交給了你一件事，這件事是一件橫向的，需要其他人參與，時間跨度可能會比較長的。遇到這樣的事，很多人上來就埋頭苦干，渾渾噩噩到最后都不知道自己在做什么，尤其作為一個一線的小兵，不帶人，這個時候，你需要一些成事的方法來加持。

一 舉個栗子

小明是今年剛入職的新人，工作經驗也五年有余，做了一段時間的業務需求，今天老板交給他一件事情，就是推進大家完善項目代碼的文檔，好讓以后來團隊的新人，能更快的了解項目代碼。程序員很多不愛寫文檔，尤其是項目有了變動以后主動去更新文檔。小明作為一個新人，來團隊這一段時間也發現不少問題，很多自己通過問其他老人解決了，但依然覺得這個過程挺難的。所以這件事讓他來做是最好不過了。

老板讓他整理一個標準化的文檔模板讓大家來套用。過了兩天，小明因為忙于業務并沒有顧上這件事，過了 4 天了，小明終于整理了一個模板文檔放在了自己的文檔空間里，但一直沒有發給老板。此事后來就忘記了，過了一周以后，老板問起來，這件事做的如何了，小明說文檔寫完了，但是應該有很多不完善的地方，希望大家提提意見。于是在周會上，大家提了一些意見，其中最主要的一件事是要把一些公共的部分，用單獨的文檔詳細說明，其他項目的文檔來引用他的。這些公共的部分可能包括腳手架如何使用，國際化怎么做等。

時間又過了一周，老板問小明事情的進展，他說自己正在寫其中一篇國際化相關的文檔。

我們看到上面的案例，小明都暴露了哪些問題呢？

二 什么是靠譜？

大家在做事的時候，可能都想留給別人一個靠譜的印象，于是習慣性的接受，而不拒絕。想著自己一定要做到，只有做到才是這件事唯一的結果。如果自己還沒做完就不會有任何的反饋，因為反饋會自我感覺難堪，因為并沒有做完。但其實，在這其中我們忽略一個重要的問題，就是什么是靠譜？

靠譜不是不拒絕，說到做到。靠譜其實是量力而行，做自己有把握的事，即使沒有在預期的時間內做完，也要積極反饋。所謂「凡事有交代，件件有著落，事事有回音」。答應別人的事，一定要積極的反饋，頻率可以是每天，每兩天都可以，切記不要耗著，沉默著，等有結果了再反饋，也不要攢一個驚喜給老板。因為這樣的驚喜往往是驚嚇，因為每一次反饋和溝通都是對焦的過程，可以保證整個事情不會變形，符合起初的預期。

上面的例子，小明就有這樣的問題，一是沒有積極的反饋，即使自己有很緊急的其他事情，很忙沒有時間做，也要跟老板說，自己最近在忙別的事，你交代給我的事，可能最近沒有時間做。二是總想著做完再說，自己多加班來彌補，而這些苦勞，只是在苦自己，并不能改變事情的結果和別人對你的印象。

三 什么是你的事？

當你心甘情愿答應了這件事由自己來做以后，這件事就是你的事了嗎？事實并不是這樣的，因為這件事你可能沒時間做，后來就又轉給了別人，或者你讓別人幫你做，別人做了大部分，最后結果被別人拿了去。其實更多的情況是你沒有做出結果，事情也被你拖沒了。所以判斷是不是你的事，最重要的只有一點，就是「這件事是不是你設計的」。

不論是老板安排你做的事，還是你自己發起的事，更甚至是別人的事，只要是你設計的，那這件事就是你的。

四 如何設計一件事？

設計并不是一件簡單的事，他需要更為深入的思考，不是單純的埋頭苦干，是要站的更高，看到全局，看到周邊，理出主線，確定關鍵，組織群眾，解決難題，控制節奏，拿到結果。拿上面小明的例子，我們詳細分解下這個問題。如何完善每個項目的文檔？我們可能要先回答這樣幾個問題：

1 做這件事的目的是什么？

整理文檔最核心的目的一定是讓新手更容易了解當前的項目，所以內容一定要全，且要結合自己的使用感受，文檔還要包含主內容和擴展閱讀，主內容是新手完全可以按照這套流程操作，就可以使用項目的，還有擴展閱讀則是一些概念介紹，擴展知識，不用當下消化，而是慢慢看的。

可能上面只是表面的或者重要且顯然的目的，別人讓你做的每一件事，其實對自己來說都是一次很好的鍛煉自己、表現自己能力的機會。所以千萬別草草了事，或者不當回事，或者把他想成是一件消耗體力的苦差事。思考先行，你會覺得他并不耗費你多少時間。當你把這件事從全局到細節都想清楚了，那種油然而生的掌控感會讓你感覺很輕松。

所以，分析目的要看兩方面，一個是表面的顯而易見的，一個是自我的成長相關的。這兩方面也就夠了，切記不要想太多，不要過多揣測，也不要把一件小事，非要升華到人際斗爭，宇宙本質的高度，那樣就有點心累了。

2 這件事要分為幾個步驟？

把大象裝冰箱總共分幾步？三步，把冰箱門打開，把大象裝進去，把冰箱門關上。這個原本大家以為是笑話的東西，其實才是解決問題最為關鍵的方法。很多人習慣在遇到一件事的時候，立馬把關注點聚焦到這件事最難的部分，一直在想這個最難的部分怎么解決，而過去了很久都沒有行動。與之相反，上面的這種步驟思維，不僅可以為我們解決問題提供可行的思路，還讓我們馬上行動了起來。

解決小明的問題，我們要看看分成幾步：

• 確定范圍：了解一共有幾個項目，畫出表格。
• 關鍵內容：寫項目文檔要確定哪些是核心內容，哪些是擴展閱讀。列出核心內容大綱和擴展閱讀文檔目錄。
• 組織群眾：這種事情千萬不要想著自己一個人來做，尤其作為一個新人，有著得天獨厚的優勢，請教同事和請求幫助，會得到非常友善的響應。文檔里你比較熟悉的部分可以自己來寫，不熟悉的部分可以初始化好文檔，然后讓同事去補充，或者請教同事后自己補充。也許你可能會發現之前已經有很多文檔了，只是沒有很好的整理起來。
• 提供工具：解決問題的過程中，工具思維很重要，如果想讓別人幫你，你就一定要提給別人趁手的工具，盡量讓他不怎么思考就能幫你解決問題，只做那些勞動密集性的事，這樣的事一個人做就非常耗費時間，多個人做就會很快。你提供的工具就像一個流水線，把你的同事想象成流水線的工人，只要機器啟動，就可以坐等產品產出了。所以針對上面每個項目完善文檔的事情，你就可以先整理出一個通用模板，然后把每個項目的不同點做成參數插入，你可以做一個表單頁面收集這些參數，或者使用命令行工具，采用問答的方式收集參數，最后自動化把合成好的文檔提交到項目的 ReadMe 中。
• Check 進度：這個步驟我們下面討論。
• 展示結果：做事有始有終，可以在團隊周會上展示最終完成的結果。

3 如何把握進度？

只要多人做事，就會有做的快的，做的慢的，和壓根不做的。你需要一個機制或者工具來 Check 進度。看上面小明的問題，我們就可以產出一張進度表，進度表也要非常講究，要涵蓋做一件事的每個關鍵點，也叫做檢查點，檢查點是行動指南，也是判斷結果完成度的指標。每一行都有明確的哪個項目，什么地址，誰來負責，是否完成，有何困難。然后把這個表格，嵌入到團隊集體工作流當中，比如在每周的團隊會議上過進度，或者建立釘釘每日的提醒，或者把每兩日的進度總結到群里。常態化的提醒和暴露問題，是推進事情的有效方法，當然還可以獎勵完成速度快的同學。方法很多，關鍵是建立自動化的機制。

4 最終產出什么？

有了最終的產出，就代表這件事有了結果。我們依然要從兩方面看，一個是表面的結果，看小明的例子，就是每個項目都有了完善的 ReadMe 文檔。但是還有一個結果，就是工具和方法論的沉淀，比如一套自動化生成文檔的命令，可以為后面新的項目提供更快的初始化文檔的方法。當然你不必為了沉淀而沉淀，非要搞出一個可復用的輪子，能解決當下的問題，就是一個好工具了。另外，對自身成長的提升也是一個很好的潛在結果。

最后，還要把產出展示出來，給這件事畫上完美的句號，感謝幫助自己的同學，同時拿到結果。

五 總結

大家都在做事，那同一件事你來做，和別人來做會有什么不同。你做的那些事是否都深深的刻上了你的烙印，你所在的組織是否有受到你的影響，而變得不同。我上面所講的內容，是最基礎的做事方法，是區別于混日子和做實事的一大要素，是變被動為主動的法寶，也是建立成長型人格的有效方法。個人拙見，希望對你有所幫助。

原文鏈接：https://developer.aliyun.com/article/783624?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的如何把事做成的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。