想要做到高效，那麼必須要掌握方法。本篇文章作者通過高效的思想和高效的實踐兩方面建立了自己的高效產品循環，給各位產品經理作參考。
記得有一篇文章寫道：
產品經理是一個很瑣碎的崗位，沒有兩把刷子請不要隨意入坑。
誠然，邏輯上並沒有問題，產品經理工作瑣碎的這個痛點肯定是存在的，那麼我們的方案是什麼？
我想用自身的案例來和大家探討：如何通過梳理和總結，讓我們的工作走向高效？
接下來我會分2部分：
- 高效的思想；
- 高效的實踐。
那不廢話了，我們開始吧。
一、高效的思想
高效的思想，是指能讓我們工作變得高效的指導思想。舉個例子來說：
「讓專業的人做專業的事」
就是高效的指導思想，這句話讓PM更多去思考產品上下游整體邏輯而不是沉迷在交互圖裡畫一天。如果你把這句話套用在工作中，你就會發現很多人因為團隊合作不到位，免不了去參與他人的工作，但往往這樣下去都會讓團隊更亂。
我們要做的是培養每個崗位的專業性，把精力用在刀刃上，這是一種分工協作的高效方式。
所以想高效工作，我總結了5條指導思想如下，大家可以自己體會一下：
1. 讓專業的人做專業的事
不要把時間浪費在自己不專業的事上，不專業只會帶來更高的成本。如果有同事不專業，請讓領導重新調整架構，而不是隨便干預別人的工作。
術業有專攻，不但要給與別人專業性的尊重，也要珍惜自己的專業性。
2. 沒有解決不了的問題
如果遇到一個困難，停滯不前，可能是你的思考沒有到位。任何事情都是性價比和優先級的衡量，這個世界沒有不可能。
任何困難都是可以量化的，請用量化來檢驗自己是否清楚認識了困難。
比如，你可以跟領導彙報，這個需求需要開發1年，但儘量不要說這個需求做不了。
3. 數據比道理更直接
如果團隊無法達成共識，請用嚴謹的數據向大家表明事實。同時，自己提出決策的時候，也要有數據支撐，否則後續被別人挑戰的時候，永遠都會措手不及。
4. 先想好再做
越緊急的項目，越要想好。緊急項目之所以緊急，就是因為之前規劃的時候沒有想好。
我曾經急急忙忙上線過一個項目，1個月後，項目下線了，原因並不在我，而是領導改變了方向。所以我認為，起碼要用MVP思維把邏輯跑通，而不要急於向用戶展現些什麼。這種挫敗感對於整個團隊都是很難消化的。
5. 時刻檢視優先級
完成一件事之後，坐下一件事之前，請務必檢視優先級。做事恰到好處，不僅僅在於程度，更在於時間。
時過境遷，很多時候你再回頭看你的GTD列表，你會發現有些需求不必做了，有些事情本來不重要，現在緊急了。這就是動態調整的必要性，不要無腦做事。
下面我們看看我是怎麼實踐的。
二、高效的實踐
我是怎麼做的呢？我想用時間線來展示一下我的日常。
首先，當我接到一個需求、或產生一個想法的時候，我會大概評估一下這件事的優先級、我大概什麼時候做，然後把它記錄在我的GTD工具上。
比如下方是我在agenda創建的project，主要是總結我近期要研究的東西。那麼每一個小項目內部代表著我對這件事的疑問和研究重點。這樣可以保證我一閃而過的念頭不會流逝。
當我評估完畢準備開始做事時，我會把當前要做的東西放進我的需求池，跟進進度。需求池這個東西用很多工具都可以實現，只要適合自己就行。
比如我個人而言，需求點比較多，容易忘記彙報、通知，所以我需要當前狀態字段來幫我一目瞭然看清楚進度。
同時因為對接業務部門，為防止扯皮，我也會記錄下來初次溝通的時間，來避免背鍋。
最方便的是，總結、週報、通報的時候，你直接可以把需求池略作修改粘貼上去，會很有條理。
需求池展示如下：
當我開始做需求的時候，我會掏出我的備忘表，這個表是根據項目要求不斷優化的。大概長下面這個樣子。
有了這個表，我可以一目瞭然看到我在做的需求點，有哪些環節沒做。這個可以保證我工作流程的完整性和條理性。同樣，對於不同層次的需求，可以進行酌情處理。但有這樣一份備忘給我指引方向，讓我不至於陷入不知道該做什麼的狀態。
需求做好了，該寫PRD落地了。我會用盡量貼切於開發思維的語法來行文，而不是隨心所欲的講故事。開發並不想看故事，講完背景之後，請直接告訴人家需要做什麼。
這裡的語法，我是借用了cucumber的思想，這裡簡單介紹一下：
cucumber是一種可以使用文本描述語言來執行自動測試用例的工具，使用的語言叫做Gherkin。
Gherkin用於描述軟件的行為而不需要了解具體的實現，使用Gherkin主要有兩個目的文檔和自動測試用例（我們希望能夠和手工測試用例也統一）。
Gherkin支持超過40種語言，包括英文、中文。
Gherkin可以在任何地方新增註釋，註釋以#開頭，每一個文件都是已.feature結尾，在feature文件中輸入功能描述、場景、步驟，當執行這個功能時每一個步驟都需要編寫ruby代碼塊來實現具體的功能，當前cucumber支持多種語言，除了ruby還可以使用java、javascript來編寫具體定義層的實現。
總而言之，就是一種描述框架，他建議我們把場景分清楚，然後用given、when、then的方式來梳理案例，讓開發、測試一目瞭然我們的需求。
基本語法為：此處舉例兩種區別一看即知
（1）簡單一點
Scenario
Given
When
Then
（2）複雜一點
And
（3）釋義
Feature：用來描述我們需要測試的模塊，模塊1，2，3……
Scenario：用來概述功能測試點 如：add/delete
Given：前置條件，比如用戶在哪個頁面進行操作？
When：描述用戶操作的執行動作，比如click/save
Then：斷言 表示執行的結果
But一個步驟中如果存在多個Then操作，第二個開始後面的Then可以用But替代（注意是可以，也可以用Then）。
這樣我們大概形成的PRD會長下面這個樣子：
完成之後，我們就要跟進開發落地了，我會梳理出日程表、建立站會機制加到自己的日曆中，定期碰頭。
在閒暇的時候，就繼續檢視自己的GTD列表，來進行下一個事項。如果遇到打斷等情況，沒關係，直接放下手頭的工作去處理即可。因為我們有這一套工具和方法，足以讓我們可以隨時繼續且高效不迷茫。
至此，我的高效產品循環就完成了。請各位參照自己的情況來建立上述流程。
以上，感謝。
#專欄作家#
花生醬先生，人人都是產品經理專欄作家，微信公眾號：產品之術。金融業資深產品經理，對職涯規劃與個人發展有豐富經驗，產品涉獵廣泛，ERP、金融領域較多。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議