這篇文章我們就來說一說，產品經理在保證產品“價值”之後的第二大重要任務：保證組織“效率”。
拋磚引玉
優秀的產品經理不僅要確保產品對於企業的商業價值、用戶的功能價值，還要確保產品的用戶的體驗價值和共鳴價值。可以說確保產品的諸多價值是產品經理的第一要務，我對這一點也是深信不疑的。但是不是保證了價值後，產品就定能突出重圍獲得成功？我相信大家的答案一定和我一樣：“不是的！”。
產品從點子到知名產品的道路上充滿荊棘，至少需要經歷三個大階段，設計->生產->銷售。對於互聯網產品來說，可以翻譯為設計->開發->運營。即使產品的商業價值論證做得再好，功能和體驗價值設計得再完善。低效的開發、運營過程都有可能毀掉你“完美”的設計。
有幸經歷過幾家不同類型的企業（外企、國企、創企、民企），尤其是最近一段經歷，在十幾歲的民企的“創新業務”事業部伴隨著部門基本從“0”到“1”的成長，在領導的帶領下，我收穫了不少在組織效率上實踐和思考的機會。產品成長的過程，其實也包含了組織成長的過程。
隨著產品及組織的成長，管理工具和手段也在不斷的變化：
- 需求管理從Email、Excel到Web工具，如：JIRA、Wiki。
- 會議管理從全臨時會議到逐步增加重點會議。
- 文檔管理從純PRD、接口規範到操作手冊、功能發佈說明書。
- 項目管理從早期的趕工到現在地向敏捷靠攏。
- ……
這篇文章我們就來說一說，我認為產品經理在保證產品“價值”之後的第二大重要任務：保證組織“效率”。
如何洞察效率問題
在我自己工作經驗裡，洞察組織效率問題的工作往往是深入在日常工作過程中的。有被動的發現，也有主動探索，在實際工作過程中，我更多思考和處理的是被動發現的效率問題。
1. 被動發現
自己的效率：當自己被同一類困難困擾時
在一個坑摔一次是沒經驗，在一個坑摔兩次是不長記性，在一個坑摔三次那就不可被原諒了。重複被同一類困難困擾時，這個困擾便極有可能是效率待提升的點。
例如：
- 場景一：每週都需要進行本週需求處理情況彙總，Excel記錄的需求，多部門難以聯合維護，狀態轉換過程難以記錄。想要一個本月從“待驗收”轉變成“已上線”的需求的數量特別困難，需要耗費大量時間整理，而且每週一次。
- 場景二：接收來自多個項目針對本產品的需求時，來自不同項目，不同背景的人書寫的需求描述各不相同。即使提供了Word版本的需求溝通模板+填寫示例，依然有很多人不照常理出牌，導致重複進行電話確認，影響效率。
這類組織效率問題，較容易發現，最重要的是產品經理需要培養起自己的效率意識！
同事的效率：當同事提出工作優化需求時
產品經理是一個在產品過程中影響力較為廣泛的角色，許多的產品過程都會被引入其中，無論是早期的商業論證、線框設計、UI設計、評審、宣講到後期的驗收和運營策略設計。如果產品經理樂於與不同的協作角色討論工作過程，並且你遇到有豐富經驗又追求高效工作的同事，他們往往會向你主動提出協同優化工作效率的需求。
例如：
場景三：產品早期，因為產品資源相對研發和測試資源少，並且產品未大範圍推廣所以需求變更數量也不多，所以往往需求都可以在1、2個迭代週期內消化完畢。研發、測試資源不會有太大沖突，項目平穩前進。
到了產品中期，隨著需求數量，產品研發資源調整，研發和測試資源開始遇到瓶頸，需求已經無法被及時消化，時而會形成多個產品經理的需求多頭管理。這時有經驗的研發和測試就會主動提出問題，希望產品團隊可以統一管理需求，避免多頭管理的情況，以儘可能減少研發測試切換上下文時間而提升團隊效率。
場景四：產品中期，產品需求與設計的複雜度逐漸增加，一個需求可能涉及2、3個研發團隊協同開發，而測試也會有提前準備完備測試用例的需求。因此為了更好的完成需求與設計的傳遞工作，研發和測試團隊提出了開展固定需求周例會的工作。
通過例會梳理、澄清需求，確定每個需求研發主責任人，並通過會議“通氣兒”，達成任務上的一致。
這類組織效率問題，其實也不難發現，重要的是：
- 產品經理要善於和樂於溝通組織效率問題，讓同事願意對組織效率暢所欲言。
- 儘量讓自己在組織過程中扮演更重要的角色，例如：由產品負責搭建JIRA系統，配置工作流。
- 遇到有主人翁意識的同事。
別人眼中的效率：當別人不知道你有多高效時
互聯網產品往往誕生於項目，有項目就有干係人。你的直屬上司，你的大老闆、你的對口客戶，客戶的老闆，推廣你產品的運營銷售團隊，實施你產品的實施部署團隊，甚至對你加班埋怨已久的媳婦。
你在一個迭代做了15件事情，干係人可能只關心他的那一件，即使他是優先級最高第一個完成的，他也會在質量、範圍、時間等各種維度產生不滿。
用最近看的一本書《項目管理心理學實踐》裡的一句話（大概是這麼說的）來解釋：
“結構使然，與人品無關”。
身居其位謀其政，我們能做的是增強溝通、緩解氛圍。短線看，花了更多時間去做溝通，降低了工作效率，但長遠看團隊協作氛圍及凝聚向心力的提升，會為後續各種合作帶來“好處”。
例如：
場景五：做為一個產品化產品（與定製化產品對立）的產品經理，你會收到來自各個渠道的需求反饋。有一些是定製化的，有一些是確實有價值的。對於確實有價值的需求，適時會開展設計工作，對於有技術基礎、相對強勢的需求方往往會吐槽需求實現耗時長，尤其在To B產品中較為常見。例如：一個要求在業務操作頁增加新字段或者業務約束，以匹配客戶管理訴求的需求。
對定製化開發來說，一個字段，一個邏輯檢查可能1~2小時開發、測試加部署就可以上線。但是落到產品化產品中，如果原先產品設計假設裡假設這部分不會有定製化需求，那麼設計架構、數據庫字段就不會對這部分做靈活支持。
為了實現產品化的通用支持，往往是一組配置項或者一套配置模板來適配不同客戶的需求。這樣一套配置項或者模板的設計就不是1~2個小時可以輕鬆解決，更不用說開發、測試了。
場景六：又或者，對於To B產品，你千辛萬苦按照需求的價值（即使已經涵蓋了客戶價值和商業價值）為產品開展設計並安排開發。需求干係人仍然可能認為你效率低下，因為干係人有他自己內心的優先級衡量標準，每一個項目的實際情況可能因為客戶關係及競爭對手的變動而在隨時變化。
這類組織效率問題，只要產品經理願意“換位思考”（產品經理其實擅長這個），其實也不難發現，重要的是：
- 洞悉產品項目干係人，干係人的“痛點”。
- 理解“結構使然、與人品無關”，願意傾聽，不害怕埋怨，樂於尋找組織效率的原因。
2. 主動探索
（1）從產品質量角度
在從產品質量角度探索組織效率時，我會從功能質量、體驗質量、共鳴質量及文檔質量四個方面，來考量組織是否有效溝通和傳遞信息，以使得生產的產品滿足質量要求。
思考產品功能設計是否滿足用戶需求，產品的體驗設計是否讓用戶愉悅，產品設計是否可能在情感上與用戶共鳴，以及產品相關文檔的質量是否可以滿足用戶及協同部門的訴求。
例如：
- 如果功能質量出了問題，可能是產品經理做需求調研或者設計時除了差錯，最後可能導致產品無法滿足上線要求，整個產品-開發-運營鏈條做了很多無用功-極度低效！
- 如果體驗質量出了問題，可能產品經理給UI團隊傳遞信息失真，或者UI團隊設計出差錯，又或者UI設計在給研發宣講時出差錯，最後可能導致產品體驗受到影響，使用阻力增強，降低用戶轉化率-低效！
- 如果共鳴（情感）質量出了問題，可能是市場、營銷和運營團隊與產品經理沒有溝通好營銷策略，沒法將產品與品牌更好的融合和表達給用戶-降低了產品的品牌及情感效應，無形中降低了用戶粘性和品牌溢價空間。
- 如果文檔質量出了問題，很可能來自於主要撰寫人疏忽了閱讀角色及經驗背景，遺漏了本該書寫的文檔或內容。這將給產品價值的傳播、產品的落地帶來極大阻力。原本可能光芒四射的功能在一層一層溝通中消失殆盡。
（2）從產品範圍角度
在從產品範圍角度探索組織效率時，我會從產品是否缺失了範圍內的功能和產品是否【超出範圍內的功能】來考量組織是否高效地實現了產品。功能少做勢必是組織效率低的一個重要特徵，但功能做多了也不可小視。
因為多做會影響產品價值上線時間，並且如果多個團隊同時開發同一個功能，一個團隊的多做可能會導致與其他團隊代碼的不兼容，引發更大的效率問題。
（3）從產品時間角度
在從產品時間角度探索組織效率時，時間超長、超短可以幫我們洞察到組織效率的問題。可能是實際過程出現了效率問題，亦或者估算辦法本身就有問題。無論是哪個問題，為了提升效率都應該關注。
（3）從產品成本角度
產品成本相對於產品時間來說較容易忽略，因為用時間來換算效率看起來更直觀，而且資源成本也並不是產品經理很直觀能考慮和控制到的。但如果想把組織效率做得更精細，“成本”確實是一個值得考慮的角度。
完成同樣一件任務，使用相同的時間，用了成本不一樣的資源，那成本將是不一樣的。尤其初創公司，不僅分秒必爭，而且還需要分文必“省”（花在最合適的地方）。所以成本是時間維度上，另一個挖掘組織效率的重要考量點。
儘管省錢這個事產品經理不一定能管理到，但是如果把成本換算成資源，那這個問題就很明顯了。例如：研發資源本身在產品視角來看其實也是有區別的，A適合做X事情，B適合做Y事情。那麼將資源合理安排在他最拿手的地方，將可能在最大程度上優化組織效率。
Tips：當然關於以上例子，還有另外一個思考效率的維度，就是讓A做B能更快完成的事情。這種時候往往是在培養A/B角，讓團隊能力可以複製，減少未來人員調整的風險，這站在長遠角度看其實也是另一種“效率優化”。
以上探索方向看起來雖然都是按產品結果導向的維度來考慮的，但是實際上在追溯原因時都需要回到過程中去。從過程視角去思考形成結果的原因，無論做得好的，或者不好的，都可能幫助我們找到效率優化的機會。
這類組織效率問題，答案比較開放，往往有許多綜合要素需要考慮（這些要素會在下一小節介紹），面對主動探索效率問題，幾個要點是：
- 用心積累產品質量、範圍、時間、成本案例，橫向將當前項目和其它項目對比，縱向將本期項目與前期項目對比。
- 瞭解與你合作的夥伴的習慣、特長和能力水平。
- 適時適度開展回顧會，回溯效率問題。
- 更為強勢的主動探索手段，可以考慮給團隊的下一期工作制定計劃，通過設計協同，對協同進行A/B測試的形式優化組織效率，慎用。
7個優化效率的著力點
在發現效率問題後，如何解決這些問題呢？
以下是我慣常考慮的7個提升效率著力點，分別是：文檔、會議、工具、流程、組織結構、人和文化。
1. 從文檔下手
文檔是組織協作過程中，面對面溝通的一個重要補充，也是工作流程中記錄和追溯的重要手段。恰當的文檔管理可以減少重複溝通，減少責任推諉，增加責任感。
如果企業內部管理要求不高，“敏捷”團隊可以將“文檔要求”和“內容框架”做成自檢工具，而非必須死板恪守的“規矩”，只要自檢保證自己所歸檔的內容滿足高效溝通要求即可。
例如：隨著產品用戶增加，產品實施部署團隊及客服團隊在新功能上線時時常收到用戶對於新功能的提問，大量的解答工作及問題的傳導無論對實施、客戶或者產品都十分影響效率。適時提出《功能發佈說明文檔》並安插在系統上線流程中要求完成，將大大優化這個新功能解答的過程。
優化方式示例：
- 構建合適的“文檔規劃”，將需要文字明確說明，長期可複用或者需要持久保存的溝通內容， 適度設計成標準文檔，落入“文檔規劃”，並安插到工作流程中。
- 為每一個文檔建立標準“內容框架”，把溝通中容易疏忽的點規範有條理的設計到內容框架中，在組織過程中不斷優化。
2. 從會議下手
會議曾一度盛行而後又進入提倡少開“會議”的階段。其實會議是一個工具，並不是無所不能的發起，它有它擅長解決的問題，例如：快速決策、多人討論、複雜討論、預約關鍵人物時間、面對面衝突緩和與承諾、促進交流。
例如：產品團隊每個迭代開始都需要確認上一個迭代開發任務的情況，以及接下來兩個迭代的任務安排。在這些任務安排的過程中，可能涉及到研發細節、涉及細節的澄清和溝通，並且與會者往往是不同團隊的Leader。這種情況下通過JIRA、郵件都難以及時，高效的完成這樣的協同工作。
因此建立了迭代溝通與排期會，專門就以上工作進行統一討論。討論過程中往往可能針對某個具體功能細節帶偏，這是需要主持人快速反應並將話題拉回主線。
優化方式示例：
- 組織可以為日常需要集體決策或者集中商討的複雜議題，適度建立固定的“會議規劃”。
- 組織還應為每一個會議建立基本的“會議框架”。
備註：注意培養提升與會者的會議“主持人技能”，會議本是為了解決效率問題，可是會議本身如果管理不當容易低效。
3. 從工具下手
市面上已經有一系列工具可以被用於提升組織效率，例如：軟件項目管理常用的JIRA、禪道、文檔與內容管理工具Confluence或者團隊協同工具明道、Teambition等。重要的是找到團隊遇到的問題，然後選擇適合團隊的工具去提升那一塊的效率。
例如：前述場景一、二：原先通過Excel和郵件來管理和溝通需求，在製作產品彙報統計數據和記錄，反饋前端需求時就遇到了效率低下的問題。原先進行彙報要用過Excel各種篩選公式去計算不同狀態變化，並且繪製出圖形展示給領導。
原先進行需求溝通，通過郵件收到需求，翻譯成Excel內容格式錄入進Excel，需求處理狀態有變動，例如：上線時，還可能需要通過郵件通知干係人。
引入JIRA之後就大不一樣了，統計數據通過JIRA查詢語言可以很好組合，需求錄入由干係人自己創建，處理狀態JIRA系統自動郵件通知。
實施方式示例：
- 根據效率問題發生的業務環節，適度引入適合組織的效率提升工具。
- 儘可能統一工具，例如腦圖工具、文檔工具、圖片工具等。
4. 從流程下手
流程往往是公司統一認可的工作順序和輸入輸出標準，完備的流程可以確保工作完成的質量、效率。
例如：前述場景五、六：原先由產品根據不同需求干係人的需求描述，結合需求價值評估的方式，來進行需求排序和處理，這樣的方式往往不一定能很好契合整體“干係人集合”的要求，往往人們容易偏向於覺得自己的需求最著急。
為了處理這個問題，我們增加需求處理流程，要求干係人們在提交需求時對“干係人需求集合“進行統一排序，將全力和責任交由最應該對這個需求集合排序的人。不僅解決了產品與需求干係人的矛盾，讓需求干係人知道產品團隊的工作量及難度，並且提升了需求交付對干係人來說的“效率”。
優化方式示例：
- 根據公司實際業務需要，刪除或者合併意義不大的流程，減少流程鏈條提升業務效率。
- 根據公司實際業務需要，增加或優化意義重大的流程，避免因流程缺失帶來的產品質量、範圍、時間、成本等效率問題。
5. 從組織結構下手
組織結構決定權責分配也決定決策流程，是影響組織效率的關鍵，但正因為是關鍵因素，所以並不是輕易可以受到影響和變化的。
例如：前述場景三、四：新產品的產品、設計、研發團隊往往方向明確（開發具體產品），大家按部就班開發未曾上線的產品。到了中期，產品在探索和擴張期，來自銷售、客戶、實施、內部新功能等各種需求變得多種多樣。
而在團隊內部，不同的同事間因為陸續的合作存在不同的默契度和自己所擅長的功能領域。為了最大可能優化組織效率，我們提出了組建細粒度小分隊的建議，通過默契度組建小分隊，每個小分隊擁有基本可以覆蓋開發需求的技能（前端、後端）。
並且為每個小分隊打上功能標籤，先讓每個小分隊擁有1~2個拿手的產品功能。以這樣的形式，在團隊內建立起處理各種功能需求的Queue，以期實現效率提升。
當然隨著團隊組建成熟，可以考慮犧牲一部分效率培養能力的相互備份，從而也能幫助團隊接觸新知識提升綜合能力，並且加強各功能模塊間的優秀經驗共享。
優化方式示例：
- 組織結構橫向調整，增加或減少部門或者團隊數量。
- 組織結構縱向調整，增加或減少組織層級。
- 職能型結構與項目型結構的組合運用，如增加臨時項目團隊、組建PMO等。
6. 從人下手
組織的效率來自於每個人效率以及人與人間協作效率的聚合，如果組織內的每個人都有極高的效率，相互之間也樂於和善於協作，那組織的效率勢必會很高。
優化方式示例：
- 增加培訓和職業規劃引導提升員工個人能力、自驅力從而提升工作效率。
- 保持良好的團隊建設 ，促進團隊協作效率。
- 抓穩人員的“入”和“出”，在入口嚴格篩選有助於組織效率的人員，對對組織效率還有重大影響人員進行及時妥善的調整。
7. 從文化下手
企業文化並非一朝一夕可以建成，在我看來成立10年的企業都未必可以創造出自己的企業文化。這幾年的工作經驗體會到的是，企業文化需要創始人/團隊的傳導，同時還需要在一定程度控制人員流動性的基礎上來培養。
如果人員流動性強，凝聚力渙散，文化就不知從何談起了。當企業培養起共同價值觀、願景及員工主人翁精神後，很多決策、工作的推動就會變得輕鬆。因為它們有價值觀做標準，有主人翁精神做動力。比起沒有培養起企業文化的公司會大不一樣。
例如：我曾經聽說過定製化To B產品企業轉型產品化To B產品的例子。定製化產品的文化和思維，和產品化產品的文化和思維本身就存在一定衝突。這種衝突還會來自於人力資源的分配，也來自於產品的收費模式。
產品化產品一般沒有項目專項支持的資源，也不是全靠定製化開發賺單個用戶的錢。它一般通過實現通用功能將開發成本，分攤到多個客戶身上，來給客戶提供性價比極高的功能。這種變化讓傳統定製化產品的銷售、實施和需求分析師都措不及防，以至於在一段時間內都沒切換過思路，產品文化衝突內耗。
優化方式示例：
- 促進公司價值觀、願景、使命和定位，並傳導到公司各個部門。
- 促進公司形成適合公司和產品的工作文化。
- 適當樹立標杆員工，控制好人員流動。
細心的讀者可能會發現：這七個著力點我是按照實施的難易程度來進行排序的，文檔調整較為容易，而文化的調整就很困難了。但是它們可以解決的問題也一般是由易至難的，如果文檔能解決的問題就不要隨便考慮用文化解決，那樣的成本就太高了。
如何優化效率問題
知道如何發現效率問題，以及提升效率的7個著力點後，優化效率問題的過程其實很容易可以規劃處理，基本過程可以參照：發現效率問題->確定提升方案->實施提升方案->回顧方案效果，四個步驟。
關於效率優化的一些Tips
（1）循序漸進，尋找適合組織的最佳模式
沒有一個既有項目管理模式是完全可以搬來就最合適的，例如：即使SCRUM再被推崇現在也很難適配每一個團隊。我推薦的是找一個產品類型、團隊組成接近的管理模式，套用後逐步優化。遇到一個問題，“迭代”一次，敏捷地對項目進行管理。
（2）讓別人知道你有多高效。
當你知道你自己足夠高效，並且你也真的很高效了，但並不代表別人覺得你高效。及時共享你的工作任務，告訴別人你真的高效。
（3）沒有職權、威望，就等那個Driver出現。
有時你發現了問題，也找到了解決方法，但是你不一定是那個最合適推動的人，並且最可怕的是別人不知道現在的效率有問題。如果這真的是個重要的問題，我相信很快就會凸顯出來，彆著急，誰最“痛”，誰就會成為這個優化方案的Driver，這時候找到他，推薦給他，你的成功幾率應該會大許多。
（4）把干係人引入過程。
別人說你效率低，而你確實已經努力了。如果探索也沒有探索出其它問題，可以嘗試把提出的干係人引入處理過程中。或許你正是缺了他的參與才效率低下，又或者他參與後發現你其實很高效。
最後
讓我們用腦圖回顧一下文章主要內容：
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
