影響工作效率的因素有很多，但不同時期的產品人遇到的都不一樣。作者作為一個入職兩個月的產品新人，總結了自己提升效率的5個小方法，與大家分享。

初入職場的第二個月，主要是從策劃5個效率需求中摸索提升工作效率的方法：“把時間花在能用合適的方法做有結果的事兒上！”

應屆畢業生初為PM，可能時常會在同一個需求中重復返工多次；可能時常會不知道怎么將上一次任務中學到的方法運用到下一個任務中；可能時常會感覺“好像在完成「老師」布置的作業”；甚至會時常感到沮喪…

但是，讓我慢慢磨合和平衡的，正是合適應屆生提升工作效率的方法。因此借此文章，記錄這個月總結出來的效率方法，時刻提醒自己。

什么是效率

我認為，效率是把時間花在能用合適的方法做有結果的事兒上。這里的疑問在于：

1. 怎么花？
2. 什么是有結果的事兒
3. 什么是合適的方法

1. 怎么花

工作時間是需要分配的，個人習慣是完成當日工作+總結當日工作。完成當日工作這一點和「合適的方法」相關，下面闡述?？偨Y當日工作這一點分為組內總結和個人總結。組內總結在我們部門叫做「站會」，目的在于避免重復造輪子的可能性和了解同事的工作內容是否與自己手頭上的任務有關系，以便在有疑問時更好的溝通。

個人總結的時間我通常會用在晚飯后，回顧當日任務進度，細致到自己是如何拆分的、是怎么做的、和誰溝通了什么、是否有結果（若無下一步打算怎么做）、哪些是可以明確今日完成的、哪些是明日的工作計劃…，每日堅持，便可知道自己每天的計劃是否完成，學到什么。

圖1：每日工作review

2. 什么是有結果的事兒

可能會有一些應屆生和我一樣，認為自己做的都是一個個明確的任務，那不就是有結果的事兒嘛。直到有一天，我詢問導師一個完全是出于個人好奇的問題，導師反問我：“這個問題對你工作進度是有幫助的嗎”，那時我意識到如果要提升工作效率，就需要找正確的人去詢問能夠推動任務出結果的問題。

補充一點，并不是說目的為「好奇、只是想知道而已」的問題就不要問，是鼓勵剛入職場的我們去了解和詢問更多的，只是需要明確：要事第一。

3. 什么是合適的方法

這里挺矛盾的?！负线m的」本來就是非常個人的，適合我的方法不一定適合你。在此希望對過去一個月學習到的能夠切實提升本人工作效率的方法進行總結性記錄，以便在遇到效率瓶頸時提醒自己；若剛好讀到這里的你也能收獲一二，那真是太好嘞。

（1）拆分任務至最小顆粒度

通常接收到一個大任務的時候，會不清楚該如何開始。那是因為將任務作為一個整體看，通常會看不全看不懂。所以需要把任務拆分至最小顆粒度，一步一步去完成。拆分的原則是以每步中我能做到最小的點去列list，通常這種方法可以在每日工作review中得以練習和使用。以近期完成的一個提升效率的需求「在套餐活動配置頁新增一鍵復制功能」作為該方法論的沉淀。

圖2：對近期實際需求的顆粒度拆分

以上是對一個業務小功能策劃時的最小顆粒度拆分，大體上就是將自己會去如何完成這個需求策劃的每一步列下來。其實關于第一步——列出使用方使用該功能的場景，就可再拆分為如下圖所示。任務拆分能夠讓目標更明確，任務項更清晰，更明白自己現在應該做什么、應該思考什么。

圖3：個人沉淀如何做「需求分析」

（2）多做一步

一則小故事能夠更好地理解為什么及怎么多做一步：「老板讓員工去買橘子。A員工直接買了一袋橘子回來；B員工在買橘子的過程中，詢問不同類型的橘子特點；價格；味道等，最后將這些信息帶回來給了老板，并詢問老板買橘子的目的且根據目的提出了自己認為選擇哪種橘子的建議」。這個小故事里老板并沒有讓員工去詢問橘子的信息，只是B員工考慮到了老板為什么要買橘子，買來的橘子會產生什么影響。

在進行數據口徑統一整理這個效率需求時，其實是一個繁瑣但結果能夠提升業務方提取數據進行分析和開發讀取數據來源的準確度80%以上的任務，因此過程中需要十分仔細和反復確認。當時在開發同事記錄實際取數來源時，一并將自己對于該數據口徑定義的理解及應該是以哪張報表為基準也記錄下來了，后者即這位開發同事「多做一步」的體現。當考慮到這份數據口徑統一表最終測試會進行最終的基準表確認，這位開發同事提供了多一種口徑定義參考的對象，以便測試做出更準確的決定。

所以至于我而言，這個任務我需要多做一步——整理出數據字典。目的在于分類不同的模塊，制定口徑和定義修改的模板，便于日后其他同事調取和修改。這也是提升工作效率的方法，提升的雖然不是即時效率，但是從長遠來看，提升的是更多同事對數據管理的效率。

（3）一個模塊解決一個問題

一個頁面由很多個小單元模塊組成，搜索框、導航欄、內容列表等。盡量達成模塊的單一性，即一個模塊只解決一個問題。在分類單元模塊時，也是辨別這是一個頁面還是一個頁面的其中一個模塊。例如用戶在拼團時支付成功，進入到「拼團詳情頁」；那么拼團中、拼團成功、拼團失敗時，是一個頁面還是一個小單元模塊？

圖4：拼團「訂單狀態頁」的小單元模塊組成

梳理過后，其實拼團狀態區為該頁面中的一個小單元模塊。這個模塊里根據用戶行為又可以拆分成3個小模塊，即文案提醒、拼團進度、功能按鈕。綜上來看，一個模塊可以解決用戶不同行為下模塊內容長什么樣子這一個問題，但是實際上已經包含了拼團多個流程。希望在今后的任務中，也能學會通過模塊拆分去解決一個一個問題，提高現有組件的可復用性。

（4）問問題的效率

問問題，是找誰問什么問題，目的是得到你想要的結果。

找誰。如果有導師的我（我們），會想著第一時間找導師問。但是反過來想，為什么要問導師呢？是因為這是他負責的業務，或只是因為這是快捷、方便的做法？如果是后者，那其實是在自己的舒適圈里“遨游”而已。突破舒適圈，可以從找對的人問問題開始。

圖：找誰問問題

問什么問題。第一是先要克服害怕起爭執的心理。因為害怕爭執，就會拐著彎兒問問題，問著問著迷失了目的，導致溝通時長增加和效率降低。

第二是問核心問題。如果不知道怎么去詢問，那就直接將自己的目的告訴對方。上周做的關于APP展示課時明細查詢的需求，需要對現有贈課進行分類、取數、最后展示在APP頁面里。為了得到接近家長的用戶體驗，我直接找了5位班主任溝通。告訴正在做什么需求+我找你要問什么（目的）+將原型給他看/提出AB方案讓他選擇，最后得到了修改思路和一些新的場景，平均耗時5分鐘。但遇到復雜的問題，不知道下一步怎么做時，直接告訴對方目的（我要得到什么），在彼此的溝通中或許就能找到下一步的思路了。

（5）積累做事情的底層方法

每天都會記錄很多場景，提出需求意見然后落實；在做不同需求中也會積累很多方法。但是等這個需求上線后，這些方法應該如何運用到下一個需求中，這是應該去總結的–做事情的底層方法。自己在做拼團需求的一個反思就是，我只總結我怎么做拼團的，那以后別人就會認為我只會做拼團；如果我總結在做拼團過程中，怎么進行模塊復用、怎么和開發溝通、怎么獲取場景、怎么提高需求文檔編寫能力…，這些做事情的底層方法，是可以大大提高做其他任務的效率。

在做方法復盤時，應該更加具體的描述通過什么努力，得到什么結果，自己進行了什么修改，還有哪些問題可能需要借力；例如：「我通過將做好的APP課時查詢明細原型給5位班主任和相關業務負責的同事看，得到了一些反饋結果，分別是1、2、3…；然后我修改了獲取課時明細為總課時明細，因為用戶對于總課時更能理解是什么意思；最后參考了花瓣網的一些交互設計修改了tab的交互?！?/p>

以上便是我這個月來，通過做大大小小的需求，總結出來的一些做事情的底層方法，會繼續在下一個需求中努力運用、繼續探索、提高效率。

本文由 @莫琳 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議