PGC(Professional Generate Content)即專業產生內容，具體就是指文字編輯人員撰寫的內容。

UGC(User Generate Content)即使用者產生的內容，通過篩選，從使用者那裡得到優質的內容。

OGC(Occupationally-generated Content,職業生產內容)通過具有一定知識和專業背景的行業人士生產內容,並領取相應報酬.

 

DAU(Daily Active User)日活躍使用者數量。

曾經需要寫產品相關的文件時總是不知道從哪裡下手需要表達出什麼，主要還是商業需求文件和市場需求文件，

 

根據情況，總結一下：

文件型別	需要做的工作	提綱如下	要達到的目標
BRD階段	一、 市場分析； 二、 銷售策略； 三、 盈利預測； 四、 （注：不出現產品細節）	一、客戶價值； 1、我要服務哪些客戶？這些客戶是什麼樣子的？ 2、我可以滿足他們什麼樣的需求(提供什麼樣的價值，核心價值是什麼)？我要滿足他們什麼樣的需求？我(暫時)不打算滿足他的哪些需求？ 二、商業價值； 1、我可以為企業創造什麼樣的價值？ 2、這些價值是否符合企業的整體戰略目標？ 三、路線規劃； 1、我先滿足什麼需求？再滿足什麼需求？為什麼？ 2、每個階段的核心價值是什麼？ 3、執行計劃(時間…)？ 四、歷史回顧； 1、客戶價值和商業價值是否發生了變化？ 2、二期產品的路線規劃和原規劃是否一致，（如有調整）調整原因是什麼？ 3、之前的實際運營效果和計劃的差異是什麼？為什麼？ 五、成本估算； 1、整合各類資源所需要的運營成本、營銷成本。 2、研發和維護所需要的人力成本。 3、同時，還需要對未來的風險進行預估，並給出合理的預案。 六、評估方法  1、為什麼指定這個目標？這個目標是如何顯現出來的？  2、如何顯現這個結果資料？  3、憑什麼可以做到這個目標	向公司申請需要的費用、資源得到各級領導支援；
MRD階段	一、 更細緻的市場與競爭對手分析； 二、 通過哪些功能來實現商業目的； 三、 功能/非功能需求分哪幾塊； 四、 功能的優先順序；   ——可能產出物有Mind Manager的思維圖，Excel的Feature List	一、產品介紹； 二、使用者描述； 1. 使用者/市場統計； 2. 使用者剖析； 3. 關鍵使用者需求； 4. 替代品和競爭品 三、產品輪廓； 1. 產品前景； 2. 產品定位 四、功能需求； 五、非功能需求； 六、 附件：使用者需求調查報告	收集、分析、定義主要的使用者需求和產品特性 ——不用考慮系統如何滿足這些需求以及需求的技術和資源侷限
PRD階段	一、 功能使用的具體描述； 二、 Visio版功能點業務流程； 三、 介面的說明； 四、 Demo (注：可是dreamweaver、ps、畫圖板的簡單版，有時也會有UI/UE支援)	一、專案邊界； 二、驗收標準； 三、業務流程圖； 四、用例說明； 1. 用例總圖； 2. 單個用例說明 五、效能需求； 1. 響應時間； 2. 空間使用量等 六、維護性需求； 七、質量需求； 1. 安全性； 2. 可操作性； 3. 可靠性； 4. 相容性； 5. 移植性 八、介面需求 外部介面需求； 內部介面需求	對MRD中的內容進行指標化和技術化；明確產品的功能和效能
FSD階段（類似概要設計）	產品UI確定; 業務邏輯的細節確定; 表結構設計

 

DMP(Data Management Platform)資料管理平臺

7.0

Android 7.0Nougat（牛軋糖）：2016年8月22日 [10]  [12] 

8.0

Android Oreo （8.0）：2017 年 8 月 21 日

產品實耗工時統計

以各種原始記錄為根據的產品實耗工時統計

以現場測定各為基礎的產品實耗工時統計

倉庫流程分為入庫，生產，出庫，入庫包括，收貨組，複核組，上架組，理貨組，訂單問題處理組，退貨組，還有個高值組和內配組，生產包括，揀貨，複核，打包，出庫包括分揀和發貨。

SKU=Stock Keeping Unit（庫存量單位）。即庫存進出計量的基本單元，SKU是物理上不可分割的最小存貨單元

RDC：分撥中心，用作物流運輸節點上，彙集貨物，然後按照合理的運力再次分配；
FDC：轉運中心，二級倉庫類似，用做暫存貨物，用以拼整車、正線路發運；只是為了攢貨用。

PCB是一塊空的板子，在板子的表面什麼東西都沒有；而PCBA是在空的PCB上加工，安裝電阻、電容、晶片等元器件，形成有一定功能的板子，所有電子產品的核心部分都是由PCBA組成的。

物料清單（Bill of Material，BOM）

 

一般先有BRD，決定是否要開發一個新產品；其次是MRD，決策如何開發這個產品；最後是PRD，決定這個產品開發成什麼樣子。

 

CNZZ中文資料分析平臺

讓產品往正確的方向上持續前行。

軟體開發中的完成測試環境所包括的環節包括：UT、IT、ST、UAT

UT  = Unit Test                  單元測試

IT  = System Integration Test    整合測試
ST  = System Test                系統測試

UAT = User Acceptance Test       使用者接受測試(俗稱:驗收測試)

1      軟體專案測試過程

測試階段從橫向看有以下活動：

1.1   需求分析

測試從需求分析開始介入，測試人員參與需求的分析活動，確定測試的需求。需要了解測試需求及測試進度，即需要驗證什麼功能需求點，採用什麼測試策略，描述目前在進行哪一階段的測試（單元測試、整合測試、系統測試）以及每個階段內在進行的測試種類（功能測試、效能測試、壓力測試等）。詳細閱讀分析需求文件，進行邏輯梳理並勾勒出功能的大概流程圖；與產品經理等相關人員探討表述不清楚的地方，細化業務流程；考慮正常流程中的測試難點；考慮與其他功能的關聯；考慮非正常流程；考慮版本資料相容。

 

目標：

（1）      理解產品的設計意圖和設計思路。

（2）      功能確認，充分理解個功能的細節。

（3）      根據功能的大小、複雜預估測試需要的工具、環境、時間

1.2   專案整體計劃及評審

測試計劃在需求分析完成後，程式修改完畢前準備。測試計劃要描述測試活動的範圍、方法、資源和進度。

 

目標：

（1）          為測試各項活動制定一個現實可行的、綜合的計劃，包括每項測試活動的物件、範圍、方法、進度和預期結果。

（2）          為專案實施建立一個組織模型，並定義測試專案中每個角色的責任和工作內容。

（3）          開發有效的測試模型，能正確地驗證正在開發的軟體系統。

（4）          確定測試所需要的時間和資源，以保證其可獲得性、有效性。

（5）          確立每個測試階段測試完成以及測試成功的標準、要實現的目標。

（6）          識別出測試活動中各種風險，並消除可能存在的風險，降低由不可能消除的風險所帶來的損失。

輸入：

專案計劃和測試需求

輸出：

《專案測試計劃》

《專案測試計劃評審會議紀要》

 

1.3   測試用例設計及評審

內容：使用各種測試用例設計方法進行用例設計。測試用例的基本要素包括測試用例編號、測試標題、重要基本、測試輸入、操作步驟、預期結果等。

         測試用例文件是“活的”，測試用例在形成文件後也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟體交付使用後反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟體自身的新增功能以及軟體版本的更新，測試用例也必須配套修改更新。

目標：

（1）      使測試用例反映不同的場景、條件或經由產品的事件流

（2）      測試用例必須要能完整覆蓋測試需求

 

輸入：

測試計劃

輸出：

《專案測試用例》

《專案測試用例評審會議紀要》

 

1.4   測試執行

當測試用例編寫完成通過評審後，並已提交的可測試的系統， 然後按照測試計劃和測試用例搭建測試環境，開始測試執行。對修改的bug進行迴歸測試。

測試的具體步驟：

（1）             建立測試系統，搭建測試環境

（2）             準備測試材料、測試工具

（3）             執行測試

（4）             驗證預期結果，測試不通過，反饋回給編碼人員修改。程式碼修改重新提交後，返回2繼續

（5）             記錄缺陷

（6）             評估測試需求的覆蓋率

（7）             分析缺陷

 

測試開始標準：

（1）          測試計劃評審通過；

（2）          測試用例已編寫完成，並已通過評審；

（3）          存在已提交的可測試的系統；

（4）          測試環境已搭建完畢。

 

測試退出標準：

（1）          測試用例全部通過；

（2）          存在的問題已得到合理的處理。

 

測試停止標準：

（1）          近半數以上測試用例無法執行；

（2）          測試環境與要求不符；

（3）          開發中需求頻繁變動。

 

目標：

（1）      所有的測試用例都被執行，並每條用例至少被執行一遍。

（2）      存在的問題已得到合理的處理。

 

輸入：

測試用例

測試環境

測試指令碼

輸出：

《測試執行記錄》

《系統bug清單》

1.5   測試評估

測試報告是對測試過程和測試結果進行分析和評估，確認測試計劃是否得到完整履行、測試覆蓋率是否達到預定要求並最終在報告中給出測試和產品質量的評估結論。

輸入：

《測試執行記錄》

《系統bug清單》

輸出：

《測試報告》

 

1.6   產品試用及客戶培訓

軟體部署後，給客戶提供產品試用，給客戶做相關培訓。

輸出：

《使用者手冊》

《客戶培訓PPT》

 

2      軟體測試階段

軟體V模型結構圖如：

2.1   單元測試

主要是測試程式程式碼，為的是確保各單元模組被正常編譯。有具體到模組的測試，也有具體到類、函式的測試等。——一般是由開發來完成

2.2  整合測試

單元測試後，將各單元組成完整的體系，測試軟體單位之間的介面是否正確，資料能否正常傳遞。——比如註冊和充值這兩個功能能否連通

2.3  系統測試

把軟體系統搭建起來，按照《軟體規格說明書》中的要求對各項功能進行測試，看是否符合需求、在系統執行是否存在漏洞等——根據測試用例，進行完整的系統測試

系統測試主要包括功能測試、介面測試、可靠性測試、易用性測試、效能測試。功能測試主要針對包括功能可用性、功能實現程度（功能流程&業務流程、資料處理&業務資料處理）方面測試。

 

2.4   驗收測試

按照專案任務書或合同、供需雙方約定的驗收依據文件進行的對整個系統的測試與評審，決定是否接收或拒收系統——使用者對軟體進行驗收

 

2.5   迴歸測試

迴歸測試是指重複以前的全部或部分的相同測試。新加入測試的模組，可能對其他模組產生副作用，故須進行某些程度的迴歸測試。

 

3      附錄

3.1  測試文件清單

階段	活動	產出物	模板
設計	系統設計	測試計劃
		測試計劃評審會議紀要	無
開發	測試用例設計	測試用例
		測試用例評審記錄	無
		需求跟蹤表	無
測試	測試執行	測試用例執行記錄	無
		測試工作階段報告	無
		測試日報
	缺陷管理	缺陷bug清單	無
驗收	系統驗收	驗收測試報告
	系統釋出	使用者手冊	無

 

3.2   缺陷管理流程

缺陷狀態一般分為：新建、開啟、已分配、已修復、關閉、重新開啟

中間會有：延期、重複、拒絕等狀態

缺陷管理流程：

3.3   缺陷等級劃分

A類--嚴重錯誤，包括以下各種錯誤：

1、由於程式所引起的宕機，非法退出

2、死迴圈

3、資料庫發生死鎖

4、因錯誤操作導致的程式中斷

5、功能錯誤

6、與資料庫連結錯誤

7、資料庫通訊錯誤

B類--較嚴重錯誤，包括以下錯誤：

1、程式錯誤

2、程式介面錯誤

3、資料庫的表、業務規則、預設值未加完整性等約束條件

C類--一般性錯誤，包括以下各種錯誤：

1、操作介面錯誤(包括資料視窗內列名定義、含義是否一致)

2、列印內容、格式錯誤

3、簡單的輸入顯示未放在前臺進行控制

4、刪除操作未給出提示

5、資料庫表中有過多的空欄位

D類--較小錯誤，包括以下各種錯誤：

1、介面不規範

2、輔助說明描述不清楚

3、輸入輸出不規範

4、長操作未給使用者提示

5、提示視窗文字未採用行業術語

6、可輸入區域和只讀區域沒有明顯的區分標誌

E類--測試建議

 

艾瑞APP指數提供海量資料實時查詢

阿里指數是定位於”觀市場”的資料分析平臺,旨在為中小企業使用者、業界媒體、市場研究人員,瞭解市場行情、檢視熱門行業、分析使用者群體、研究產業基地等

騰訊移動分析|免費移動應用APP統計| H5統計|渠道統計|使用者畫像

 

Scrum是迭代式增量軟體開發過程，通常用於敏捷軟體開發。Scrum包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。雖然Scrum是為管理軟體開發專案而開發的，它同樣可以用於執行軟體維護團隊，或者作為計劃管理方法：Scrum of 

角色

產品負責人 Product Owner： 負責維護產品訂單的人，代表利益相關者的利益。

Scrum主管 Scrum Master： 為Scrum過程負責的人，確保scrum的正確使用並使得Scrum的收益最大化。一般不翻譯。

開發團隊 Team: 由負責自我管理開發產品的人組成的跨職能團隊。

 

一張圖說起，標註紅色的為今日輸出部分。

洋蔥圈圖

就軟體產品和專案領域而言（包括網際網路，當然還有其他領域），敏捷其實就是一種方法論，無非就是這種方法論較其他而言，相對節奏更靈活，資訊更透明，產出更高效，風險整體更小，對各種反應更快，當然對人的要求也更高。

沒有對比就沒有傷害，關於傳統專案全生命週期，言簡意賅的說個我曾經作為PM專案經理來跟進的專案交付方法論。背景為財富五百強TOP10的某國企，專案體量千萬級別，週期8個月左右。全生命週期流程為：1專案需求挖掘→2專案立項申請→3專案投標競標→4專案組成立→5專案規劃（顆粒度到周）→6專案實施（每週週報+週期成果演示+需求變更+提交變更流程+反覆研發+測試+再彙報）→7專案階段性交付驗收→8重複專案實施*N→9專案驗收→10專案轉運維。

作為傳統專案實施方法論來講，需要PM的前瞻能力值基本跟上帝平級，望眼欲穿到一百天以後是常有的事情，那麼問題來了，隨著外部環境變化，周邊政策變化，以及資訊化高度發達的今天，諸如此類的專案真的可以實現資訊化先進生產力嗎？

答案是需要思考的。但從概率角度來講，傳統方法論較為低了一些。

而敏捷套路用我所理解的一段話概述即為：驅動自組織跨職能的人員團隊，用高頻率短週期的持續迭代交付方式，快速得到有效使用者反饋，並針對過程和結果進行持續優化和改進，由產品負責人掌控整體方向，由敏捷教練SM來引導方法論，實現整個團隊的高度資訊透明+高效溝通，用漸進明細的方式來交付最終成果。

敏捷價值觀▼

（洋蔥圈最裡層）

個體與互動高於流程和工具

可工作的軟體高於詳盡的文件

客戶協作高於合同談判

響應變化高於遵循計劃

敏捷原則▼

（洋蔥圈第二層，自己總結的簡潔版）

也是衡量方法論是否為敏捷的標尺

-目標是滿足客戶

-時刻擁抱變化（後期也一樣，技術支援重構）

-持續交付（短週期）

-跨職能相互合作

-充分信任激發個體

-面對面交談

-可用的軟體是首要度量標準

-可持續開發

-不斷完善追去卓越

-簡潔，夠用就好

-自組織團隊

-及時覆盤

敏捷實踐▼

（洋蔥圈第三層）

最後基於價值觀和原則之上的第三層洋蔥圈，就是各實踐通過敏捷技術百家爭鳴的區域，這裡面有各種各樣的方法，有適用於大型組織的SAFe，有適用於單團隊單迭代，又可以融入組織級方法裡的Scrum、XP等，有適用於整合起來按需使用的敏捷方法， 如使用者故事、重構、持續整合等等。

說Scrum之前需要說一個承載需求的載體，也是實踐其中之一，即使用者故事。可以理解為說白話的需求說明書，核心是從使用者的角度出發，用一句話在卡片上來描述需求：我作為xx角色通過實現xx功能從而達到xx價值，卡片背面描述該故事具體的測試場景，用這個方式來描述需求對於使用者、產品負責人Product Owner（以下簡稱PO）、敏捷教練Scrum Master（以下簡稱SM）、研發團隊（以下簡稱開發Team）都比較淺顯易懂，從而使資訊更透明。而使用者故事也是分顆粒度，分別是史詩級故事＞特性故事＞具體故事＞圍繞故事拆分出來的任務Task，整體團隊是從充分理解使用者故事的角度來開展具體任務工作，從下往上，逐層彙集。

進入正題，開聊Scrum▼

下面從最流行的方法論Scrum說起，一句話描述，就是3個角色、3個工件、做5個活動。（還有5個價值觀，參考以上就好）

3個角色即PO、SM和開發Team。

3個工具即得產品待辦事項清單、迭代待辦事項清單、可交付的產品增量。

5個活動即迭代執行、迭代計劃會、每日站會、迭代評審會、迭代回顧會。

整體流程如下

（偏實戰乾貨，每條控制在100字左右）

1-團隊組建，宣揚方法論

目的：組建好用的團隊，灌輸結果導向以及敏捷方法。

成事在人。敏捷方法裡對於個人和團隊的技能要求有三點，一是跨職能，即在懂研發的基礎之上，可以跨到測試甚至設計甚至更多；二是主觀能動性要高，都是為了解決問題而不是賣騷秀工作量；三是認同結果導向，即我們用此方法，可以更快更高質量的輸出可用產品。

（這條是加戲，不在正式的Scrum方法論裡面，各類實踐都假設團隊已成立）

2-建立產品待辦事項列表

目的：輸出有排序的，有故事點估算的使用者故事列表。

此環節裡PO進行產品梳理，排序現有使用者故事，同時幫開發Team理解需求。開發Team根據理解的使用者故事來進行故事點估算，產出可輸入至迭代計劃裡的使用者故事。SM來繪製燃盡圖，表示產品進度，在每個迭代後進行更新。

備註：使用者故事也分顆粒度大小，排序就是優先順序越高的故事越具體。

3-通過迭代計劃會議產出【迭代週期+事項列表】

目的：通過會議產出本輪迭代的任務。

迭代週期：根據交付要求進行評估後產出產品迭代週期，一般為15天-30天不等。週期太長不靈活。

PO與團隊從產品待辦事項列表中選取待完成的使用者故事。開發Team負責將這些使用者故事拆分成任務，給出任務估算，任務一般可在8小時內完成的，可量化。SM繪製針對迭代的視覺化圖，表示迭代進度，在每個立會進行更新。最後將本輪迭代的任務放置在To do（準備做）一欄。

4-通過每日立會【溝通及領取、交付任務】

目的：保證整體團隊每天高頻的溝通，瞭解每個任務的進展及大家進度情況。

整體團隊每天花15分鐘快速的勾兌昨天做了什麼、今天準備做什麼，需要什麼問題。

每個人主動在To do（準備做）一欄中的選取今日要完成的任務放入Doing一欄並且開工，第二天立會繼續按此勾兌，同時將已完成的任務放入Done（完成）一欄

備註：只有PO、SM、開發Team能發言，其他人旁觀，有事兒單獨聊。

5-通過評審、回顧會議【評審本次迭代的成果和輸出改進項】

Scrum方法論裡是兩個會。

評審會是邀請客戶等利益攸關者一起針對本次迭代的成果進行評審（可交付的產品增量）。團隊進行演示，PO來講解整體產品情況。

回顧會是團隊內部針對本次迭代內發生的各類做的好的、可以改進的、存在問題的輸出改進項， 改進項作為單獨的任務為下一輪迭代做輸出，也就是持續改進。

6-會後更新產品待辦事項列表

整體過程中：

SM需要確保開發Team不受外界干擾，作為敏捷教練更多的是確保會議執行、確保大家理解方法、遵循時間盒規則。

PO把控整體方向及對接外部需求，只有PO可調整產品待辦列表優先順序，另有權中途取消迭代。

開發Team負責任務的同時還需要遵循敏捷的核心方法，同時按需運用如持續整合、自動化測試、結對程式設計等元件級方法。

Scrum流程圖

（附事項+角色+負責事務）

Scrum思維導圖

最後總結一下精華：

前期貼合需求，淺顯易懂的說明（使用者故事）

價值觀一致(褒義方向)

自組織跨職能團隊(人&技能)

資訊發射源(視覺化看板+燃盡圖)

高頻短時溝通(每日立會)

高頻迭代及優化機制(持續改進)

週期性評審及回顧(交付增量＋下一輪改進)

始終認為，敏捷只是達成目標所使用的方法，而Scrum、XP等諸多實踐只是提供了一種驗證過的可行的參考，而是否適用於本團隊，以及團隊裡每個人具備的技能和方法認知，還需要管理者自行斟酌和思考。

永遠不是為了敏捷而敏捷，而是為了更高效的交付更高質量的可用產品。通往羅馬之路放眼望去遍佈腳下，選擇以及實踐出最適合自己的為好。

以上為自我學習及結合實踐的總結，如有不當之處還請指教，相互進步。最後也印證了一句話，適合自己的才是最胖的。

從管理的角度講,專案經理是縱向的,而產品經理是橫向的

產品需求文件包括：

1. 業務背景
2. 產品功能概述
3. 產品前景分析
4. 產品功能整體流程
5. 產品邏輯關係
6. 面向物件
7. 應用物件
8. 名詞解釋
9. 參考文件
   業務背景描述：
   這裡，你必須將業務提出方描寫出來，並且細緻到業務方為什麼將這個需求提出來！為什麼？一方面，你要告訴研發人員，你為什麼設計這個產品或功能，這個需求從來源到設計是有原因的。另一方面，拉上相關業務部門，你至少不是一個人在戰鬥。
   產品功能描述：
   對當前功能進行概述，所設計的產品或功能的功能模組，新增、完善、優化那些產品功能；
   產品前景描述：
   本產品或功能，希望對那些轉化率指標或實現那些目的；
   產品的整體流程：
   Visio、Axure（Axure畫的流程圖好醜）。
   通過而言，簡單的需求將主業務流與邏輯關係流表達出來便可以；但涉及複雜的業務，便將產品或功能涉及的主要流程繪製出來；而流程目的，主要是清晰的將前後臺的邏輯關係與資料結構表達出來；一方面方便開發理解業務與資料流，另一方面也方便產品人員梳理自身需求的業務邏輯；利於後續與研發進行溝通。
   具體的流程數量，根據業務的複雜程度決定，一般只需要將核心的流程繪製出來便可；
   前臺：主要是互動、資料流程；
   後臺：主要是業務邏輯判斷、資料流；
   前後臺的流程湊在一起，能清晰的看到前後臺的模組之間，是如何進行耦合的，資料儲存、提取、處理、分析。
   功能框架：
   Mindjet Minmanager、Xmind畫的框架圖好醜。
   框架圖的意義在於，能讓檢視或瞭解業務的人，全方位的瞭解功能之間的功能點的邏輯關係。同時，一份優秀的框架圖，能讓PM站在全域性的基本面上，對個人所負責的產品進行全域性的規劃，對前後臺的功能進行把握，達到支撐平臺業務。
   產品架構：
   對前後臺的各個系統與管理模組的邏輯關係，一般是對業務極其熟悉的業務構架師與資深的產品總監搭建，裡面涉及每個介面如何進行對接耦合。
   功能架構：
   所負責的產品或功能的前後臺功能的邏輯關係，簡單點的就是一個產品或功能的前後臺，大一點就是一個系統涉及的功能點之間的耦合。
   功能框架：
   功能點所涉及的邏輯關係。
   功能結構：
   功能點所涉及的邏輯關係。
   而“架構、框架、結構”區分在於，所負責的業務究竟有多大。但不論如何，它們的表現的原理是一致的。將分解的功能點，之間是如何聯絡的功能結構關係清晰、簡練的表達即可。
   關於架構，包含“功能分解、面向使用者”就夠用了。若再深入，可將分為：“應用物件、BI分析（BI需求也寫上去）、系統整合….”。後續可根據BI資料，對產品進行版本迭代與優化。
   面向物件
   表達產品或功能主要是為那類使用者服務的。將面向使用者是誰，擁有哪些許可權清晰的表達出來即可，對個人進行功能設計也有很大的幫助。
   應用物件
   本功能需要在那些應用端或版本進行上線，清晰的描繪出來，方便後續進行業務交接。
   名詞解釋
   將本次文件涉及一些奇葩的明詞進行解釋，這點很重要！有些PM喜歡將一些非常簡單的內容包裝成非常牛逼，讓人看起來很難懂，而事實上也就做哪些一件簡單事，但是看的人會很痛苦：看PRD時會想：“這玩意，究竟想表達什麼。
   參考文件
   將所做的本次功能，所參考的那些文件，附屬上來；目的的在於，方便後續的業務方、研發方進行檢視。
   三、功能描述功能描述能否描寫清晰，描寫清晰，開發找茬都不怕了。如何才能完整的對功能點進行描述呢？圍繞三個點“功能是誰？功能來自哪裡？功能要到哪裡去？
   同時，功能需求主要分為核心功能、其它功能。不論是核心功能還是其它功能，都可以由以下元素構成：
   功能名稱
   面向使用者
   用例圖（Axure、mocking（適合移動端進行敏捷性開發）)
   前置條件
   後置條件
   功能簡述
   詳情描述
   而具體的功能描述內容，則根據業務（功能點）的複雜程度，進行篩選描寫。可以全寫，也可以不全寫。但務必記住：不論何種方式，目的在於將業務價值完整、清晰、有條理的傳遞給檢視文件的參與角色。
   功能名稱
   （我是誰）
   本功能在系統裡的命名。
   面向使用者
   本功能的使用物件。（在前臺，功能的參與者是少數的；但後臺與企業級應用裡，功能的參與者是多個的）
   用例圖
   表達功能在表現層的邏輯圖；可以是傳統意義上的用例圖，或者是簡化版的原型圖、流程圖；
   前置條件
   （我來自哪裡）
   使用該功能的前提、邏輯關係說明；公司大了後，每個開發都只寫個人所負責的業務，所以一定要將每個模組來源都清清楚楚的表達出來，方便開發之間的銜接。
   後置條件
   （我要到那裡去）
   使用該功能後，對業務、資料功能，產生的影響與結果；
   功能簡述
   描寫本功能需要實現的商業價值或目的；
   詳情描述
   將功能”我怎麼來，我怎麼去“清清楚楚的表達出來。變成計算機邏輯便是，頁面佈局、操作邏輯進行詳細的說明。常規而言：
   前臺：
   主要是欄位、互動邏輯組成；
   後臺：
   主要是判斷邏輯、列表表單、查詢條件、互動邏輯組成；
   四、其它功能其它功能目的在於，功能描述針對於本次產品功能的核心業務，而其它功能針對於觸發或需要其它功能變動的業務。功能描述清晰的讓開發瞭解核心，而其它功能便讓開發清晰的瞭解非核心。
   而其它功能，主要由以下內容組成
   其他介面
   對其它系統產生“欄位、業務流程”進行說明；本次產品或業務，對前後臺那些非主流程模組產生影響；
   系統風險評估
   當前設計的功能存在哪些缺陷、注意事項與後期的功能拓展如何解決這些問題；
   其它需求
   對一些非核心的功能點進行詳情描述。如：一些需過濾的關鍵字、新增某個欄目欄位。
   五、綜述通過上述內容，能以通用版的形式，清晰的將所負責產品與功能表達出來，而業務描述、功能描述、其它功能。是產品需求文件重要的組成部份，將產品需求較為全面、有效的描述出來。
   同時，能訓練PM邏輯思維，提升文字表達能力、業務理解能力，從整體上讓PM在需求管理上，明顯更加專業，所負責功能的邏輯關係、資料流的來與去都能很好的把控。
   六、附語不論是什麼格式，倒爺堅持一個觀點，適合團隊才是好的模板。當前很多的公司在進行MVP迭代的時候會使用Axure 內容描述的形式。雖然，這種形式，是很難將邏輯關係表達清晰，同時會有非常多的思維漏洞。在進行文件歸檔時，也很難對根據關鍵字進行檢索。但，確實挺適合進行MVP迭代，出現問題修改起來也方便，這種方式比較適合專案流程完善的企業平臺使用。
   而在敏捷性開發彙總，倒爺習慣流程圖 功能框架（功能點） Axure（原型圖繪製），從核心的業務流開始，逐漸迭代至功能完善，這個過程也將文件補齊。
   但有些公司會在EXCEL裡進行需求文件撰寫，進行版本管理（這個也不錯）。
   但，作為新人，需要記住：你能寫複雜的東西，簡單的東西也能能寫；但當然一開始只寫簡單的東西，那你一輩子只能做簡單的東西。
   大道至簡，簡難而繁易；經歷過複雜的訓練與要求，才能簡化再簡化。
    
   產品需求文件是將商業需求文件（BRD）和市場需求文件（MRD）用更加專業的語言進行描述。該文件是產品專案由“概念化”階段進入到“圖紙化”階段的最主要的一個文件。當然，這個定義針對的是一個全新的產品。廣義上來講，產品需求的描述，應該包含有產品的戰略和戰術，戰略是指：產品定位、目標市場、目標使用者、競爭對手等。戰術是指產品的結構、核心業務流程、具體用例描述、功能&內容描述等　PRD的主要使用物件有：開發、測試、專案經理、互動設計師、運營及其他業務人員。開發可以根據PRD獲知整個產品的邏輯；測試可以根據PRD建用例；專案經理可以根據PRD拆分工作包，並分配開發人員；互動設計師可以通過PRD來設計互動細節。PRD是專案啟動之前，必須要通過評審確定的最重要文件。
    
   OKR是Objective & Key Results的縮寫。中文意思是目標與關鍵結果。
   OKR是在一定週期內為企業和團隊設定的戰略和目標。在每一個週期結束的時候，OKR能夠幫你評估團隊目標的執行和完成情況。
   高績效的OKR系統一般有3個共同點：

• 目標和結果可以被量化。
• 個人或者團隊的OKR必須在每一天、每一週、每一個月都有露臉的機會。說白了就是持續性，OKR的使用者必須時刻將目標和結果銘記於心，這樣才會時刻將自己的行動與之匹配
• 目標要設定的有野心，最好超出能力範圍。一個百分百被完成的OKR幾乎沒有任何推動作用，而一個70%完成度的OKR卻近乎完美——它能讓你知道你這一階段你和你的團隊的極限在哪裡，這樣你才有更多的上升空間
  —-廣告指標—-
  不同時期產品的宣傳必要要選擇合適的投放媒體和渠道，這就需要我們瞭解基本的廣告相關資料指標。
  CPM
  cost per impression，按千次展示付費，指通過某一媒體投放廣告，聽到或看到此廣告的人達到一千人平均所要花費的廣告費用。
  CPM=（廣告費用/到達人數）×1000，比如投入廣告費用200元，有10000人瀏覽過此廣告，則CPM=（200/10000）×1000=20元
  CPM取決於產品的印象，不是評價廣告效果的單一指標，是對不同媒體