保持思考 —《啟示錄》讀書筆記

05-09

周末重新擼了一遍《啟示錄》，工作中的實踐，讓自己對書中提到的很多場景有了更切身的體會，這篇文章既算是讀書筆記，也是對自己工作的階段性小結。

?? 產品經理的職責

產品經理的本質工作到底是什麼？

雖然這個崗位看起來似乎是「零門檻」，但對於這個問題的答案，每位產品經理都會隨著經驗的不斷積累而不斷刷新自己的認知。

產品經理的主要職責分為兩部分：

評估產品機會
定義要開發的產品

產品經理需要在最短的時間內把握複雜的市場/用戶需求，評估出正確、有價值、可行、符合公司發展要求的產品機會。

接下來產品經理需要：

制定產品戰略
構思產品生命周期
設計產品形態
競品調研

如果說以上是產品初期的一些準備工作的話，那麼接下來就需要產品經理開始詳細定義要開發的產品。

產品的定義包括以下幾個方面：

產品特徵
產品功能
產品的用戶體驗
產品的發布標準

隨著進程的推進，團隊的其他角色開始在不同階段介入與產品經理一起完成產品實現方案的具體設計，並基於既定協作流程完成評審、開發、測試等不同階段的工作，直至產品上線，並跟蹤上線後的產品效果及反饋。在此期間，產品經理需要保證整個團隊的信息對稱，並對最終的產品負責。

很多產品經理在起步階段的工作大部分都是寫文檔以及畫一些原型圖，需求一般都是上級或者老闆直接分配，這個階段因為對於產品的認知很淺，制定產品戰略這樣看起來很"玄"的工作其實也很難做到，此時不妨靜下心來做好這些基礎的執行工作，除此之外，讓自己持續保持學習和思考的狀態，根據產品經理的職責標準來要求自己，當有一天你發現自己有能力思考並完成職責中的大部分工作時，你已經從初級進階了。

?? 產品原則

在公司，每周產品內部會有一次例會，每一位產品經理會向大家介紹自己接下來準備完成或者已經在設計中的產品或功能。一方面便於內部的信息同步，另一方面也可以聽取其他人的建議和想法。

會議形式本身沒有任何問題，但時間久了之後自己發現，會議的效率和效果有時卻無法達到預期，這是因為需求的重要性和必要性經常無法確定，大家各抒己見，導致討論沒有結果，同時因為很多開發資源共享，經常是誰先進行需求評審誰先獲得資源，這就導致有時一些緊急的需求因為開發資源不足只能延後排期上線。

產品原則是對團隊信仰和價值觀的總結，用來指導產品團隊作出正確的決策和取捨。

如果團隊內部有清晰的產品原則，那麼在每次的例會上，就可以快速的定義產品功能的優先順序和必要性，彼此達成共識，快速做出產品決策。

制定產品原則意味著從重要性、原則性、戰略性、戰術性等幾個方面來進行產品決策，它是整條產品線的戰略指南，一套價值判斷的框架，幫助公司作出正確的決策。不過要注意不要把產品原則和設計原則混為一談，用戶的操作路徑和交互形式等並不是產品原則。

?? 產品文檔

除了一些職能劃分清晰的大型互聯網公司以外，相信很多產品經理都是邊寫需求邊畫原型邊做交互，先不要抱怨這些是否都是屬於你的工作，因為產品經理掌握任何一項技能似乎都是理所應當的事情。

Marty Cagan在書中給出了理想的產品說明文檔的幾個要素：

完整地描述用戶體驗：包括需求、交互設計和視覺設計準確地描述軟體的行為
直觀的把產品信息和行為告訴所有人，因為產品文檔的受眾廣泛，開發、測試、市場、銷售等都需要了解
可以修改，開發或者設計中經常會碰到意象不到的細節或者邏輯問題，產品文檔需要隨時修訂
產品文檔會出現很多衍生物：需求列表、線框圖、實體模型等，需要選擇一個主體來代表你的產品

上述的幾個要素中其實也包含了其他團隊角色需要完成的文檔，比如交互設計稿、視覺設計稿等等。作為產品經理，我們經常會問產品文檔如何寫才最好，模板可以給我們提供參考，但一定要適合自己的團隊並保證每個人可以快速理解並提出問題。畢竟，你寫的不是日記，只要自己看得懂就行。

?? 又要重寫代碼？

最後談一個跟管理有關的問題，也是自己這段時間感受比較深的一個現象。

因為之前的開發節奏緊張，連續很長一段時間為產品增加了幾個大且邏輯複雜的功能，因為沒有太多時間對代碼結構進行很好的設計，導致後續的一些產品功能出現了維護困難，且問題頻發的狀況。自然而然的，我們將問題歸咎於開發團隊的技術能力問題，而這類問題的本質其實是產品管理失誤。開發團隊一直處於滿負荷的工作狀態，不停的在開發新功能，無法保證代碼的質量和架構的穩定性。最後技術團隊開始對代碼進行重寫。

Marty Cagan舉了eBay的例子，與開發團隊合作在產品管理上要為其預留20%的自主時間，這個技術能力稱為餘量（headroom），由開發人員自由支配，可以重寫代碼、完善架構、提高系統性能等等。

『產品經理是個看似簡單卻又最難琢磨的崗位，需要時刻對產品保持關注、思考和反省，而這個最耗費時間和作內容，卻往往被我們所忽視』

公眾號傳送門：大喵的設計瓦罐