寫作本文的驅動，在於發現身邊太多這種例子：入職職場3年的產品經理，仍然處於專業的邊界之外，從而有所思。
一、前言
本文重點不在業務，在產品知識體系。業務非常重要，卻只是產品知識體系中的一塊。作為互聯網產品經理，如何保證業務需求到IT軟體形態產品的 保質保量一次性可靠性的落地，知識體系非常重要。全文共1萬字，自己留出時間閱讀。
入行前5年，特別愛寫東西，或許是因為對於行業的新鮮感、也或許是出於求知或職場壓力的驅動，5年時間竟然積累下一個3G大的純文檔知識庫。如今越寫越少、卻越寫越長。不可否認的是，寫作確實是進行深入思考的一種最佳方式，不寫出來，自己都不知道自己對於某種事物的理解到何種程度。在寫作中，不斷促進思考，不斷促進改進，在思考與改進中就不斷進步。當然，寫作不是空想，而是基於自己實際工作的積累與總結。
寫作慾望的產生，往往有一個激發點。基於某個事物產生了某種想法，便可以抓住並進一步思考，不要單純的停留在腦子裡。
這次寫作，另一個目的也是想對2017年做個體系性的總結，或者說對過去8年的職場歷程做個體系性的總結。2017對我來說，是職業生涯中很特殊的一年，歸零中總結與反思，關於職業、關於專業、關於人生。為了做這件事，從原來過勞的環境跳出到相對平緩的環境，便騰出了一定的時間。
從初入職場進入傳統行業、到進入互聯網行業，從不適應到逐步的進入佳境，有些經歷，或許對於職場新人來說，有些幫助。
因此，在此強調一句，如果你選擇繼續往下看，請以堅持獨立思考的態度，大膽懷疑小心求證，筆者一家之言不代錶行業標準。
這是一個商業世界，商業的本質就是基於人的需求進行供給以獲利。而人卻是一種極其複雜的情緒化動物，充滿善惡貪嗔痴喜怒哀樂怨。精明的商人便會利用人的種種人性與慾望進行商業化產品設計以獲利——以此引出對於當下火熱的知識付費的一些看法——不是對花錢買知識這件事、而是所看到的一些誤解的看法。
正如知識管理專家 田志剛先生(微信公眾號KMCenter)在他的文章中《如何真正搞定一個領域的知識》所說：「在互聯網上有了許多知識資源，大部分內容都唾手可得，然後許多人就認為自己聽了一下、看了一眼，然後就掌握了！其實是你想多了。別人家的知識，跟你的知識是兩碼事。「付費購買或加入各種知識圈，有助於你了解行業的新動態、了解新思想新方向，但是方向性的東西往往是很粗的，要成為某個領域的專家，非得下苦功夫不可。沒有一種知識是可輕而易舉獲得的。只有靠自己去大量閱讀，深刻思考，然後再加上實踐驗證，這個過程不斷循環轉化，你才可能獲得真知。以及筆者自身的成長經歷，對此深為認同，下文會有專門介紹。（文章http://mp.weixin.qq.com/s/O_TlL4Vwkvo-msAc9PP3wg）
建議關注田志剛先生的知識公眾號，對事物認知的廣度與深度，會直接決定人的行為模式的產生與選擇。哲學有助於建立個人的認知體系，對於世界、人生、價值的認知，助你擺脫因認知局限造成的種種困擾。
以此引出職業的話題。
如今BAT國內職場人、尤其是互聯網行業的人吸引程度，不亞於10年前歐美外資企業對於職場人的吸引程度，HR每天收簡歷都收到手軟。作為早期從外企進入到互聯網行業的我來說，有一點卻尤其有感悟和體會：對於職業生涯的規劃。
伴隨著外企在國內的風行，也颳起了關於職業生涯的很多觀念。而伴隨著互聯網的成長，卻是普遍的浮躁與焦慮，變化太快了，往往一個新的辭彙還沒消化卻又產生了另一個新的辭彙，職場人好像都在忙於追熱點、炒概念，卻忽視了對事物本質更深入的理解，這是不正常的。變化快不是問題，而是炒作與賭博的性質是問題，尤其是年輕人深受其害。新概念需要被認真思考，理解本質，而非單純的炒作概念。
作為個體的職業人士，必須更加關注個人職業生涯的規劃與發展，而「專業」是基礎。讓自己在某個行業里成為專家、依靠終身學習的動力，持續的更新知識以滿足行業發展的需要才是根本。所謂中年危機，大抵是因為自身知識體系無法滿足行業發展的需求而被行業淘汰，人才與年齡無關，所謂70后與90后無法在一起工作的文章，都是炒作。
分割線————以上皆為虛的。
二、關於專業
專業是一個很抽象的辭彙。有一個普遍性適用於各行業的關於專業的模型。
三個維度看：
1）工作理念(價值觀)：
工作理念(價值觀)具有行業特徵，不同行業對於從業者的工作理念是不一樣的，但也都包含三個方面—工作動力的驅動來源、工作過程的模式選擇、工作結果的認知。理念會影響你工作動力的產生、責任感成就感、執行過程、工作結果等方方面面。理念無形、卻展現於各個方面。
2）方法與工具：
無新方法與新工具的發明，超級工程根本無法實施。掌握行業內的先進方法與工具的應用，對於成為行業專家是必不可少的一個環節。
3）領域知識：
對於細分行業的業務知識的掌握，是最終價值實現的必要保障，是你與團隊成員溝通與合作的基礎。
分割線————以上皆為虛的，下文才是實的。
三、關於產品經理
建立對一個事物的認知先從它的定義開始。理解定義是建立認知的基礎，定義即基礎。
互聯網是一本巨大的百科全書，有疑問互聯網搜索一下，但要能區分真偽。產品經理（Product Manager）是企業中專門負責產品管理的職位，產品經理負責市場調查並根據用戶的需求，確定開發何種產品，選擇何種技術、商業模式等。並推動相應產品的開發組織，他還要根據產品的生命周期，協調研發、營銷、運營等，確定和組織實施相應的產品策略，以及其他一系列相關的產品管理活動。(百度上的詞條解釋有些還是靠譜的https://baike.baidu.com/item/%E4%BA%A7%E5%93%81%E7%BB%8F%E7%90%86/11013391?fr=aladdin)
基於定義，也就能明了產品經理所需要掌握的專業技能。以下也僅為筆者基於自己的知識體系所提煉，請堅持獨立思考、大膽懷疑小心求證的態度閱讀。具體的方法及工具，筆者基於行業通用標準學習吸收，沒有[原創方法論]，行業通用規範均為諸多前輩苦心沉澱積累並實踐驗證，學習吸收靈活應用即可。
關於理念，只簡單介紹：
1）用戶：是需求的來源，是產品發展最原始的驅動。
對於用戶的正確認知，是做產品的第一步與基礎。一旦產生偏差，後果確實極其嚴重。產品的用戶是誰、你的產品該如何去更好的服務你的用戶，這些都會極大的影響到你的產品最終落地的形態與效果。筆者曾經極其嚴肅的火爆過一位產品經理，因Ta這句話「我們怎麼做業務就怎麼用，不需要業務的建議「。關於[用戶]的基礎介紹，筆者推薦一篇文章，這裡不多累贅，因為這篇文章更全面，騰訊的8分鐘產品課系列之一（文章http://mp.weixin.qq.com/s/7WmihKiq8pouzDBR90oz2g）。
與用戶理念相對的，就是功能思維。功能思維就是關注功能的實現而忽視用戶體驗，早期軟體工程盛行的時候這種思維尤其盛行，隨著商業環境的變化迫使企業必須關注用戶，否則只會死亡。
2）迭代：是過程模式的選擇，產品發展過程的選擇。
直接影響對於業務價值最終兌現的效果。過程模式，也在逐步的迭代中完善，從早期軟體產品研發的瀑布模式、到RUP統一過程模式、到SCRUM敏捷模式，過程模式的選擇，依據不同的產品需求，靈活選擇應用，但在互聯網行業敏捷迭代模式已經成為主流，從目前應用狀況看能最佳匹配行業的變化。
3）商業價值：是最終結果的兌現。
企業存在的核心目標為盈利，所有的產品結果基本都為更好的促進這個目標的達成。
關於方法/工具，學習應用行業標準規範並吸收消化靈活運用即可，不需要自己去總結和創造一套「我的方法論「，既四不像也不具有普遍應用性。基於軟體產品的特性，結合互聯網行業的特性，筆者提煉以下6大方法域。
3.1軟體產品通用方法與工具：
不能只談業務不談基本功。在專業性強的領域成為專家，意味的是在該行業建立了體系性的知識。從業務需求到IT軟體形態產品的落地，是一個極其複雜的過程，無專業的方法體系與工具的應用不足以保質保量高效的一次性落地。接一兩個小需求可能用不到，如果要從0到1讓你去搭建一套完整全流程的複雜IT產品呢？無體系不足以言。
作為互聯網產品經理，必須掌握透徹軟體工程常用分析方法體系以及常用工具。具體在面向對象的系統分析方法 和 面向過程的系統分析方法。面向對象與面向過程，是兩種不同的方法體系，兩派之間的爭論不多說，但就筆者的觀點：只要有助於解決問題，都可以靈活應用。整體而言，還是以面向對象為主、面向過程為輔。下圖為面向對象方法體系與面向過程方法體系的主要方法。而支持這些方法的應用的常用工具就是微軟的Visio。也就是說：這些方法和工具必須深刻理解其內涵、並能靈活應用，主要就表現在：理解這些方法及工具的應用場景，在分析什麼的時候該用什麼方法最佳。拒絕機械化的學習方法，而要去理解方法的應用場景，以及把方法整合成體系。
上圖中，綠色底色標註的就是常用的方法，要求能深刻掌握，並且依據嚴格標準高效繪製，每種圖形均有其嚴格的繪製規範，這就是標準化與專業度。其它了解即可。
下文重點介紹面向對象的方法體系。並在[3.3文檔寫作與產出規範] 章節會參入介紹面向過程的方法體系的應用。
什麼叫面向對象？概念性問題不多糾結，以免為概念困擾，關鍵去理解其內涵與本質。有興趣了解的同學可以去讀譚雲傑老師的《大象》這本書，算是國內目前對面向對象方法體系闡述的最完整與體系的。以及徐峰老師的《軟體需求最佳實踐》這本書，了解完整的軟體過程。想要電子版的可以加我微caiziqing3282.
這裡引入[場景]的概念。面向對象方法體系的核心就在對於場景的分析，以及如何應用每一個具體的方法、去對應分析場景中的哪些或哪個要素。省去對於概念的解釋，而直入主題。也盡量採用大白話的方式，去解釋這些生硬的方法，因為理解是學習掌握的第一步。場景分為業務場景和系統場景。兩者之間的區別，一個在於對純業務的分析、一個在對人在系統上完成某個任務的分析，後者基於前者衍生，前者粒度大後者粒度小。分析的方法是通用的，只是分析指向不一樣。
一個場景包含四個維度：人、事、物、規則。我們去分析一個場景，也就是運用具體的方法展開對於這四個維度的分析。
人：即場景中的參與者，可以是現實的人、也可以是擬人；
事：即人做的事，事不能單獨存在，一定是人產生的；
物：即人在做事時用到的物，物是名詞，是動作的指向對象，例如吃蘋果，蘋果即為物；
物是業務實體的核心來源，也是信息與交互設計中信息的核心來源；
規則：人做事所要遵循的規則、或者物本身的存在的規則；
場景的四大維度中，人是核心，所有的一切都是圍繞著人展開，所以，面向對象的方法體系本質來說就是以人為中心的方法體系。
自己想想，你做任何一件事，是否均包含這四個維度？結合實際生活的案例去理解。
對應上文說的必須掌握的方法：
用例：對於場景的全面分析，包含對於場景的人、事、物、規則的全方位分析；包含用例圖與用例規約說明；用例規約說明是核心，主要包含這8個方面的分析。不要去糾結概念，理解本質與內涵。
具體應用：用例提供了一種完整的、結構化的思考的模型，當你要去分析一個場景的時候，你該從哪幾個方面去完整的思考——思考這個場景是誰主動發起的、發生的前提條件、以及什麼時機會觸發，以及發生后的正常流程是什麼，異常流程是什麼，以及場景的運行規則、運行中所涉及的物，以及運行結束後會影響到其它什麼。
具體，自己可以去隨便拿生活中的某件事，應用上述模式進行仿照分析，以便理解。
活動圖：對於場景中人、事，以及做事的規則的分析；
範例，僅供參考圖例，業務不精確：
繪製規範，規範促進對於場景的思考：
具體應用：繪製前需要對場景中的各個參與者做詳細的調研、梳理、整理，然後形成規範的圖形模型。筆者應用活動圖用來繪製業務流程圖、系統交互流程圖、以及其它各種流程圖。一幅圖可以鳥瞰整體業務的運行狀況，規範標準也便於其它人理解。
狀態圖：對於場景中的物的分析，分析物的狀態流轉；
範例，僅供參考圖例，業務不精確：
表的形式整理 [狀態——操作/條件——轉化狀態]：
具體應用：狀態圖的核心在於，一個實體的全生命周期的狀態流轉，從最初的原始狀態，到因為什麼動作或條件，導致向另外一個狀態變遷。我們研究狀態的核心在於：除了有多少狀態外，還在於研究對應狀態下的操作及條件；
實體關係圖(類圖)：也是對於場景的物的另外一個維度的分析，分析物與物之間的關係，以及實體屬性的規則；
圖形更抽象，理解幾點，不多介紹：
1） 數量關係：是1對1，還是1對多，還是多對多？…
2） 語義關係：關聯關係、依賴關係、擴展關係、包含關係、聚合關係、組合關係…
3） 實體屬性提取與規則定義：實體屬性是開發資料庫建表的核心參考，也是信息與交互設計環節中信息的核心來源；對於屬性提取的完整性，直接影響從業務到系統功能落地的完整性與可靠性；
規則分析：規則是一種特殊的存在，它依託於人事物，卻非常核心；單獨拎出來介紹；
具體應用：業務規則依託於業務流程；內稟性規則依託於實體屬性；交互規則依託於操作；先理解，也不多介紹；
人的分析：通過用戶畫像了解，人的基礎屬性、交互屬性、業務屬性、社交屬性；這裡不多說了；不同業務環境下對於人的了解是不一樣的；會影響很多非功能性需求的考慮；
這就是為什麼必須掌握這幾種圖像方法的原因。
3.2信息與交互設計：
限於篇幅，這個章節只介紹一些核心模型與核心方法。多玩產品，多思考，為什麼人家要這麼做？是否可優化？人人都是產品經理是不靠譜的，但是人人都是用戶是可以的，基於體驗提出幾個問題，基本都可以做得到。
推薦幾本書：
《用戶體驗要素：以用戶為中心的Web設計》，Jesse James Garrett著，書雖然很早，但是核心理念卻非常好；
《交互設計指南》Dan Saffer著，也挺早的，但很值得學習；
其他限於篇幅，暫略。
信息與交互設計的專業程度，直接影響的是你產品的是否好用，從而可以放大或者縮小產品最終商業價值的兌現。
兩個模型：
1、 筆者自己總結的模型：
2、《用戶體驗要素》一書中所提的五層模型：
3.3文檔寫作與產出規範：
做一個優秀的IT產品經理，寫作是你最基礎的能力。但溝通的兩種媒介：[文字]與[語言]，你都需要精通。
3.3.1五個方面全方位理解產品寫作及產品文檔
3.3.2寫作的目的
你寫作產出的文檔，是與協作對象之間進行溝通和傳遞需求的載體，語言是對產出的必要性的再解讀。
產品經理一般溝通與協作對象，見下圖。當你的溝通與協作對象很多的時候，光靠語言來傳遞信息是非常容易導致信息丟失的，所以文字是非常必要的。
3.3.3寫作的原則
1） 金字塔原理：
整體內容的組織需遵循金字塔原理，形成明晰的由總到分的內容類目結構。
2） 文不如表,表不如圖：
在內容的組織上，當文字很多時需要考慮將大段的文字進行表格格式化，如果能用圖形表達的，最好採用圖形化表達；
A. 如SA結構化分析方法中的數據字典、決策樹、決策表，也是常用來對邏輯分析的圖形
化 或表格化的呈現；等等
B. 如OOA面向對象的分析方法中的活動圖、狀態圖，也是常用來對業務進行分析的圖形化
的呈現；等等
3） 結構化語言：多用1、2、3這種結構化組織形式；以及基於數據字典的結構話描述；
對於產品的文檔來說，可以更進一步結構化的常用模式是【如果…則…】的if else的結構化語句，這也是SA結構化分析方法中，結構化語句的經典模式。
3.3.4寫作的工具
產品的寫作產出， 最常見的就是PRD （Product Requirement Document），即產品需求說明書。PRD的文檔模板有很多種，其實模板類型倒不是關鍵的，不管哪種模板類型，最終目的都為服務於文檔的目的—傳遞需求。但就所見到的一般軟體公司的文檔來看，生澀難懂、閱讀體驗差，動輒幾十上百頁、第一眼看上去-哇-好規範，但規範不是目的，規範的目的也是為了傳遞好需求，不能達成這個目的，再規範也是個純粹的看物。
就寫作PRD的工具來說，其實個人很推薦Axure，Axure不單純只是一個原型設計工具，作為從5.5版本一直用到目前的8.5版本的骨灰級用戶、也用過其它各類工具、模板產出PRD來看，Axure寫作最佳、傳遞需求最佳。
第一步：編製完成的金字塔形的內容結構。Axure的Sitemap功能。這一點非常關鍵，因為編製好后，Axure導出規範的結構化文檔就是基於此。在Sitemap中，可以將各類流程圖等等都放在裡面。
第二步：單個產品功能需求的描述。這裡舉個後台系統的功能需求描述的格式化方法及基於Axure的寫作。一般後台功能分為【增加、查詢、列表數據、操作】四大類，快速逆向簡單的寫了個例子，僅供參考，非筆者業務：
1、【新增】實例介紹，一般針對新增的功能需求描述可以結構化為：
1）欄位規則；
2）操作校驗；
2、【查詢】實例介紹，一般針對查詢的功能需求描述可以結構化為：
1）查詢條件；
2）查詢操作；
3、【列表數據、操作】實例介紹，一般針對列表數據的功能需求描述可以結構化為：
1）列表數據的排序規則；
2）列表數據的分頁規則；
3）列表數據的數據許可權；
4）列表數據的初始化呈現；
5）列表數據的呈現欄位及其規則；
6）狀態及操作（涉及狀態及操作，後面會有專文分析介紹，太核心太重要！！）；
Axure中，我們直接基於其所提供的【Widget Interactions and Notes】中的【Notes】功能就好，非常實用。在【Shape Footnote and Name】中定義好欄位名稱，然後在【Description】中基於上述規則去描述即可。
沒必要這麼寫？寫多了？自己反思去。寫文檔從來不會耗費時間，關鍵是：你對於業務理解的完整性、是否透徹。
3.3.5寫作的產出
在產品經理的產出中，最常見的為BRD與PRD。
BRD用來定義業務需求，即需求的業務背景、需求的原因、期望達成的目的、以及所需資源投入與產出的分析、基於需求來源的業務領域的業務模型（如業務用例、業務流程圖、實體狀態圖等等層面的）的分析。
而PRD則用來定義需求轉化為功能后的功能需求，一般包括系統用例、功能樹、角色與許可權定義表、用戶界面與交互規則，但也不必刻板。如上節針對【培訓需求單列表】的功能需求描述，實際整合了系統用例 與 用戶界面與交互規則，讓功能需求的描述更容易被各協作對象理解、傳遞。
當你在Axure中寫完后，導出Html或 標準模板的Word文檔，會非常便捷於規範。個人更喜歡使用直接使用【Generate HTML Files】，直接導出網頁，在閱覽的時候更方便，Word因為文檔過長時瀏覽非常不便，只作為存檔用。
具體操作，自己去實踐吧，不累贅。
【GenerateSpecification】導出Word，注意下：在WidgetTables中只要選擇[Footnote、Name、Description]三項即可，導出的類似數據字典的欄位表格不至於太多東西。多試幾次你就可以上手，越用越偏愛。
3.3.6寫作的實例
實例已經參夾在上文，自己去琢磨。多去寫，寫著寫著，你的思維就豐盈與深刻了。
3.4項目管理：
項目管理知識體系具有普遍性應用特徵，不管什麼行業、無論什麼做什麼事，都可以應用項目管理，從建築行業、到律師行業、軟體行業……甚至可以這麼說，如果你能掌握項目管理知識體系，你做事、無論在專業度的體現上、還是在效率的提升上，都具有顯著的效果。
PMP作為國際項目管理的職業資格認證，其所定義的項目管理知識體系具有絕對的標準意義。也就是說，兄弟、別自己去總結什麼[我的項目管理經驗]了、學標準化專業知識體系即可。從來不是專業知識沒用、而是你學不會、本質上來說、不是PMP沒用、而是人沒用。
本文先介紹一個通俗易懂的項目管理概念，以便於簡化PMP專業性、理論性過強導致的理解性障礙。確實，專業技能的掌握從來都不是容易掌握的、尤其是對於應用性專業知識來說，你不僅要掌握理論，更要在實際工作中應用。但是，即便再難、你想入行、就必須去學習、而且是深入的學習。
PMP項目管理8大領域
所謂「事事皆項目」。項目管理也可以廣泛的應用到你的日程生活中，管理自己的事項。舉個簡單的例子：去超市買菜。
1、你計劃要購買白菜1斤、牛肉2斤、胡蘿蔔1斤——這是範圍，功能範圍基於需求產生和定義；
2、你計劃要在1個小時內完成買菜——這是時間；
3、你計劃購買菜的預算為50元以內——這是成本預算；
買回的菜質量如何？你跟你家人以及賣菜的人之間如何溝通的？你去還是你和誰去買？採購時的詢價、選擇哪家買、達成交易及簽訂合同？
限於篇幅，也暫略。學習后靈活應用是根本。
3.5數據分析：
限於篇幅，數據的介紹也簡單扼要。
數據分為用戶行為數據、業務結果數據。
行為數據是過程性的，主要是用戶在網站的交互行為產生的數據，對於分析用戶行為路徑、改善產品流程及用戶體驗有重要參考意義。舉個簡單例子，僅供參考：
用戶在網站的操作交互行為，都會有時間先後順序，依據用戶操作交互的時間先後，便可形成對用戶訪問路徑的畫像，從而進一步分析流程與體驗的改進點。自己思考。
而結果數據，是業務運行后的數據，用以分析業務目標的達成狀況。對業務數據進行各個維度的分析，觀察業務運行結果對業務目標的達成狀況，為過程的改進提供策略制定的決策依據。
可視化是數據分析的一種重要方法，運用各種可視化的圖形模型，對數據進行直觀的呈現，例如看佔比的餅圖、看趨勢的折線圖、看對比的柱形圖等等。基於具體業務數據，進行圖形模型的選擇，是很重要的。例如：
3.6產品運營：
限於篇幅，產品運用也簡單扼要的介紹。產品運用的目的，在於獲取更多用戶、或者獲取更高收益。為了達成目的，從而衍生出各種運營模式與策略，例如用戶運營、內容運營、活動運營等，例如產品的交叉銷售、增值產品售賣、針對不同生命周期客戶的不同精準營銷策略等等。
4、業務領域
對於業務領域知識的學習和掌握是非常核心的。換句話說，對於業務不熟，就會導致在進行產品設計時，因為對於業務場景理解的漏失，導致最終系統功能落地時對應功能模塊的缺失，從而影響產品最終落地的完整性與可靠性。
但是，對於業務知識的積累非一日之功，要善於運用上述方法與工具去梳理業務、對業務進行領域建模，並持續的維護與完善。經常跟業務方溝通，了解業務的運行狀況，是非常必要的，這也是你產品發展的核心驅動。
你能構建你所處領域的業務模型嗎？領域模型的搭建，就是基於對領域中人事物規則的全面分析，運用對應的分析方法進行模型的梳理與產出，再持續的維護與完善。
好的產品經理，都是善於觀察世界的，理解領域知識，一定要細緻，大的流程都容易理解，關鍵是能否深入，簡單的說，能否去理解每個業務欄位的業務含義與規則。
5、后語
無需職場焦慮，持續的構建自己的知識體系，才是作為職業專業人士的必修課和解除焦慮的根本之道。
本文不對細分領域做更進一步的深入講解，否則太多要寫。有心人自會主動去深入學習。
開放與謙虛的心態，是保持持續學習的基礎。封閉與自我，往往會成為井底之蛙而不知足。