這個世界的網際網路行業內本來是沒有運營這個角色的，以視覺、產品、研發為核心結構的組織形態主導了網際網路行業很長一段時間，以最簡單的可用產品和功能實現來看，這三個角色確實能夠閉環的進行生產。然後網際網路進入了偉大的中國，由於國內網際網路行業的快速發展，網際網路業務的邊界越來越廣泛。一個業務的成功與否不再單純取決於產品的體驗和價值，產品承載內容的豐富性，營銷觸達用戶的效果、廣度和精準度，資源的整合和有效利用等對業務成敗的影響開始越來越重要至於等同甚至超過產品的體驗和價值。
在傳統的三角結構中，產品作為唯一的非技術崗位，承擔了主導用戶產品體驗和連結另外兩個技術崗位的義務。而新出現的非技術領域的工作成為了一個空白，於是運營的角色從產品當中剝離出來，打包承載了所有這些非技術工作。所以運營的本質我們說難聽一點確實是打雜的，但由於其價值的重要性，我們用更酷的方式來描述運營工作的本質就是解決問題。這個是我國網際網路行業工種發展的第一個階段。
同時又由於運營崗位承載義務的複雜性，部分工作開始逐步有了更明確的定義和邊界，於是運營崗位又開始進行細分：數據運營，產品運營，用戶運營，活動運營等。每一個細分領域都逐步形成了自己的方法論體系。這個是我國網際網路工種發展的第二個階段。
現在我們來到了2019年的1月18日，也就是寫下這些文字的當下，網際網路行業正在默默進行著新的演變：行業大中台、大數據、巨頭產業網際網路格局崛起，傳統的技術和非技術解決方案開始形成服務包和標準化解決方案。關聯著網際網路業務組織形態也開始了演變：在基於人口紅利期帶來的業務快速拓展模式下，極細分的工作種類（背後是每個工種的工作螺釘化）可以幫助快速抄襲現成的業務形態和功能。當人口紅利消失，市場業務同質化嚴重，巨頭基於品牌流量優勢可以快速切入任何現成的市場，創新和創造成為了唯一的出路。這個時候，筒倉結構（市場-用研-產品/數據/活動運營-產品-視覺-研發）之間的割裂體現出了在創新環境下的劣勢，因為沒有一個角色可以通盤考慮一個用戶從始到終的體驗（市場打造的產品認知和引入的新用戶往往不會被業務完整的承接），而在這之前有大量現成的模式可以抄襲。
至今沒有運營崗位的美國網際網路界開始興起了一種新的組織形態浪潮，強調打破筒倉結構，聚合各專業崗位角色形成綜合團隊，由一個更加綜合能力的非技術崗位角色帶頭，進行快速的創新驗證和增長探索。這個就是增長黑客的基礎概念。其實這個趨勢在國內網際網路也有產生的跡象，為什麼全棧運營概念的火熱開始替代掉了前幾年同樣火熱的專業產品運營、用戶運營概念也是來源這個趨勢的變遷。
非技術崗位的綜合性能力提升是下一個階段所有產品、運營、營銷崗位都需要面對的一個轉變，這是第三個階段。也是我更傾向以解決問題來解讀運營工作的目的。
講了這麼多鋪墊，還是為了讓活動運營們理解，趨勢要求我們要開始回歸網際網路最開始的本質，我們應該是網際網路行業里那個唯一的非技術角色，也就是一開始的產品經理的角色，你們也是最有機會進行這個轉型的角色。做好這個準備能夠更好的幫助你跨越到下一個網際網路時代，這個也是本書從始至終想要強調和引導的。
本書的其他部門介紹了非技術崗位從用戶洞察、需求分析到策劃再到項目管理等各部分的能力模型，那麼這個部分，我們專項來探討一下產品經理工作的本質，把缺失的一環補上：
關於如何從一個業務運作的本質來思考業務實現，以實現策劃的效率及可靠性的提升，同時也幫助你拓展策劃的思維。
即如何把業務描述語言轉化為產品需求語言，做好與另外兩個技術關鍵崗位的對接準備。
當然也許你會有專業的產品經理與你配合完成這個部分的工作並不需要去替代掉他，產品經理領域也有大量的不局限於產品需求規劃的更深入的方法論，但我們這裡只實現兩個最基本的目的：
1.理解業務描述語言轉化為產品需求語言的基本原理，讓你能夠基本把握一個產品需求實現的過程，這是增長團隊負責人的必要條件。
2.給出引子，感興趣的可以進一步深入研究。
把業務描述語言轉化為產品需求語言是圍繞著一個核心的工具PRD（產品需求文檔）來進行的，所以接下來的內容是對於一個基本完整的PRD模塊原理的拆解，做到能夠撰寫一個靠譜的PRD也就意味著你掌握了把業務描述轉化為產品需求的基本能力，也不會再愚蠢的去拋出一個完全不合理的想法。
//PRD的核心結構
~1.需求描述~
首先業務描述語言我們在前期項目管理文章中有提過，一個典型的句式就是「通過XX達成XX」，更強調策略和目標。需求描述語言和業務描述語言最大的差別在於，需求描述語言是帶有邏輯性拆解和推導的，目的和需求之間帶有更嚴謹的對應，與「事情」的關聯性更大而不是「目標」，保證包含了「事情」的方方面面。
- 業務描述的對象是業務人員、領導、合作業務方，目的是約定一致的目標和策略。
- 需求描述的對象是研發、交互視覺、實現方，目的是為了說清楚要實際落地的事情是什麼。
要完成業務描述到需求描述的轉化，一個最有效的工具就是從【業務】到【用戶】再到【功能】去進行嚴格對應的邏輯需求拆解。
1. 業務需求描述
本質是需求背景的描述，即為什麼要做這個需求。在項目管理的部分（見前文），我們已經完成了把一句從領導處領導的模糊的「做到1000萬銷售」拆解成為了一個各團隊分工協作的業務策略列表，把其中需要產品落地的部分剝離出來就是你需要進行需求描述轉化的部分。經過方案策劃之後，這部分業務需求就成為類似：
- 通過XXX形態的頁面實現XXX的轉化率
- 通過XXX功能實現XXX的用戶點擊率
- 通過XXX模塊實現XXX的用戶參與率
這些業務需求清單構成了最基本的業務需求描述，但是基於需求描述的目的是讓需求處理方理解要做什麼的目的，我們還需要進行一些完善，主要是為了解決以下兩個問題：
1.讓需求處理方感知需求的目標效果
2.讓需求處理方明確需求的邊界
關於明確目標效果
首先不太客氣的說，由於大部分產品經理脫離KPI綁定的關係，很多產品文檔在這個部分只能夠講清楚了業務的需求背景（為什麼要做這個），並沒有從業務目標的本質拆解明確這個部分要做到的效果到底是多少，而這個是活動運營作為業務一線的主導方具備的優勢所在。
為什麼要讓需求處理方感知到需求的目標效果，因為需求處理方一般是與前端業務場景脫離的，他們並不清楚什麼樣的處理手段能夠帶來什麼樣的業務效果，只能夠基於有限的需求材料進行處理，模糊地帶只能無目標自由發揮。
只描述業務背景，需求處理方只能知道這個需求確實必要，但再無更多有效信息。進行需求目標效果的描述能夠讓處理方更明確的感知到，這個需求不僅必要，而且需要達到必要的效果，對需求落地的規範會更加有效。那麼怎麼進行需求目標效果的描述：
- 完整描述需求的目標指標，現狀對比，提升預期。
- 可能的話儘量羅列一些可參考案例，過往的落地手段達成的實際效果是如何的。
以上步驟形成完整的需求目標效果描述，幫助需求處理方真正理解業務策略、背景和為什麼要這樣做。
關於明確需求邊界
其次，在明確需求目標效果之後，我們還需要對需求邊界再進行一定程度的約定。進行這個約定的背景在於，對於需求處理方，實現你的業務訴求可能有很多種辦法（一個互動遊戲的機率計算可以放在前端進行或者後端均可），部分手段可能並不符合業務的一些基本要求（活動互動發獎是有成本的，前端運算中獎機率極大可能性被刷獎）。當然，你不能保證知悉所有的研發細節，不懂的研發邏輯也不應當過度干預，給到一個基本模版從業務角度來進行基本的需求邊界描述，根據不同的業務形態可能會有更多元素，可以求助配合的資深研發或者產品來幫助你完善你的常用需求邊界描述清單：
- 用戶狀態描述：主要用戶群體的屬性：新用戶/老用戶/網絡性能不佳的用戶/薅羊毛用戶。
- 產品狀態描述：這裡說的產品是你要銷售和轉化的對象，描述產品的：實物產品/虛擬產品/限量產品/高價值產品。
- 頁面狀態描述：你的活動頁面是否長期在線/階段上線/流量狀態（持續進入還是爆髮式推廣以及量級）/是否需要定時下線（精確的控制用戶操作時間）。
以上兩個步驟幫助你實現真正完整的業務需求描述，基於以上信息需求處理方才能夠完整確定的了解你的需求背景是什麼。同時提前明確這些必要的信息也可以減少很多不必要的溝通成本甚至是BUG。
2. 用戶需求描述
用戶需求描述是從用戶角度進行的業務需求對應，幫助需求處理方更深刻理解為什麼這個需求能夠達到目的，更重要的是用戶需求描述的對應也幫助你檢驗了業務需求的有效性（真的符合用戶需求嗎）和必要性（真的需要做這個需求嗎）。
完整的用戶需求的描述主要分為三個部分
用戶場景描述：用戶在什麼場景（從一個廣告進入）和什麼狀態（從一個異常狀態進入）下使用這個產品的描述，傳遞了需求處理需要考慮的兼容性、適配性和狀態處理等要求。
用戶需求描述：核心部分，說清楚這個需求解決用戶的什麼問題。完整的梳理所有的用戶問題和需求，與業務描述進行一一對應，解決的用戶問題是不是帶來對應的目標，提供的需求是不是既定的業務方案。這個過程並不只是一個描述轉化的過程，更重要是在這個過程中進行需求的二次驗證和整合。帶著優先級描述把用戶需求羅列下來，你就能清楚的看到核心的用戶問題是否有可靠的需求去解決，在不重要的用戶問題上是否投入了成本過高的一個需求。
需要強調的是在我們經常要進行的需求評審會上，業務、研發和產品三方主要探討的本質就是以上的這個優先級清單，通過這個優先級清單進行需求的提煉整合以及投入產出最大化優化。項目管理部分提到的三方各自明確角色和立場是有效PK的保證，業務要明確業務訴求的立場，研發要對投入效率進行把控，產品來從用戶角度挑戰任何不合理的解決方案。如果脫離了以上兩個原則，需求評審會往往會陷入無效和混亂的大討論。
用戶任務描述：用戶需求描述明確後，就需要進一步把用戶的需求推進到前端，去描述用戶是如何進行哪些操作來完成解決以上羅列出來的問題，這些用戶任務（動作）描述構成了以下業務流程的基本元素。
- 用戶需要通過一個分享動作來完成傳播
- 用戶需要通過一個領券操作來完成優惠券領取
- 用戶需要通過一個註冊操作來成為會員用戶
3. 功能需求描述
用戶需求描述的進一步推導，為了保證達成用戶的需求，我們需要對應提供哪些核心功能（或者頁面）來滿足以上用戶的任務。這個是業務流程的骨架。
- 需要一個分享引導模塊以及關聯狀態頁面來讓用戶進行分享
- 需要一個領券模塊以及關聯狀態頁面來讓用戶進行領券
- 需要一個註冊介面以及會員引導頁面來讓用戶完成註冊
至此，通過業務需求-用戶需求-功能需求的邏輯推進我們就完成了一個完整的需求描述，但這個僅是需求，還無法保證落地。接下來我們就要進入實現部分的工作。
2.業務流程~（產品功能邏輯）
是一個產品最核心的邏輯圖，完整描述了一個產品和用戶之間的運作機制，其主要構成元素就是以上需求描述中的用戶任務部分和功能需求部分描述。將用戶的操作（流向）和關鍵功能（頁面）進行串聯，即是這個產品最基礎的模型。
一個最簡單的被廣泛運用的邏輯圖原則是
- 線條即代表用戶操作和流向
- 方塊或者圓形代表功能/頁面/模塊
- 菱形代表判斷狀態
以此搭建出來完整的產品邏輯圖大概就是（實際這個工具可以運用於任何有複雜運行機制的系統梳理）
同樣，業務流程梳理的價值不僅在於把需求進行可視化，更重要的在於構建邏輯圖的過程實際上也是又一次的業務整體邏輯檢驗和優化的過程：你能夠通過這個圖判斷出來哪些流程是不必要的、哪些用戶流程沒有合理的功能承載、哪些用戶流程過於複雜有太多跳失風險。
3.交互原型~
產品功能邏輯之後，通過和專業交互崗位的合作（交互部分我們介紹了基本的交互原則，但在熟練使用之前還是更多借鑑現有案例和藉助專業交互崗位來完成），我們就要把產品邏輯轉化為用戶視角的真正的產品交互原型。主要有以下幾個元素及作用
- 頁面交互樣式：傳遞給視覺同學必要的頁面結構、信息主次，同時也可以標註視覺效果的一些需求（顏色使用，風格，動態效果等）。
- 頁面前端邏輯（是邏輯圖的用戶操作流量對應）：傳遞給前端點哪裡跳轉哪裡、出現什麼、產生什麼變化的邏輯。
- 頁面備註信息：由於交互圖太複雜干擾信息較多，還需要對每一個頁面進行背景、功能、邏輯的背景描述以方便前後端需求處理過程中完成與邏輯圖和需求項目的對應。
如果你想要挑戰自己完成這個步驟，記得幾個關鍵點：
1.交互文章裡面提到的核心理念：儘量利用大眾熟知的交互形態，少無目的的創造。
2.很多產品文檔喜歡把所有信息放在交互原型當中一份文件搞定，包括產品邏輯圖和功能需求描述等。雖然交互原型是邏輯圖一一對應的延展，但是把太多大量的信息放在一起反而會過度的相互干擾，影響到對一些核心邏輯的評估和優化，根據實操經驗來看，很多沒有預計到的BUG都是由此產生的（遺漏了很多用戶異常流，異常流在交互原型下表達成本很高往往會被遺漏）。所以邏輯圖和原型最好同時進行完善，各自扮演好各自的角色。
- -邏輯圖：保證所有用戶流向的順暢，保證所有用戶流向有對應的功能承載，保證功能核心機制描述的完整（用戶的什麼操作帶來什麼結果）。
- -交互圖：保證必要的交互效果要求，與邏輯圖的一一對應，前端邏輯描述。
3.學習一些專業的交互工具，其實這些工具非常簡單幾乎沒有上手成本（要求是你能熟練使用window作業系統），axure（使用最廣泛）或者sketch（功能更多做出來的東西感覺更酷一些）。一方面能夠極大提升你的效率，幫助你準確描述你的想法。另一方面也讓你顯得比較專業，減少和專業的交互或者產品崗位工作交接的成本。不要再覺得畫交互不是自己的義務，只會用Excel或者PS來表達自己的想法，低效又愚蠢。
4.其他規則~
完成交互原型的生產後，一個產品/頁面/功能的主體需求描述基本完成，但是一個能夠經受大量流量和各種特殊用戶（黑產刷子等）檢驗的需求，還需要從以下兩個角度再進行梳理和檢查，把內容整合進入邏輯圖和交互原型後才算完整。
1.邊界規則：關於產品和功能的臨界狀態，保證一個普通的用戶體驗完整的情況下避免掉極端的情況。網際網路黑產和刷子用戶的力量相信大家都感受過，這些並不是我們想要服務的用戶，所以需要約定好你的產品中所有涉及用戶操作的邊界到底是哪些。當然在成熟的業務當中研發團隊一般都會有一套標準的邊界規則標準，但是作為業務方的負責人如果你不希望你定義的正常用戶被太嚴苛的邊界標準限制住或者有新的業務形態可能存在漏洞，你就必須要自己思考這些問題：
- 用戶操作次數：上限和頻次是多少，超過需要用操作頻繁提示來承接。
- 獎品的領取上限：優惠券每小時、每天、每個帳號領取的上限。
- 風險控制邊界：大量註冊的殭屍號是否要阻攔，並不是平台目標用戶的薅羊毛黨是否要阻攔。
- 其他專業邊界規則：例如用戶註冊的密碼位數限制等，這個涉及更具體的業務場景。
2.異常流規則：考慮再完善的產品，再強大的伺服器，都會有用戶的異常流。雖然在網際網路上操作遇到幾個BUG和操作死路用戶已經司空見慣，但你總是希望儘量減少因為異常操作而流失的用戶，所以你需要考慮每一步用戶正常操作對應的異常操作是什麼，應該怎麼引導。異常流的處理一般也會在產品團隊和研發團隊有一套基礎的標準，但是這些基礎標準只能讓用戶感知到我進入了異常的狀態（比如提示系統繁忙），而並不能合理的引導他走向更有效的步驟（比如說系統繁忙的提示之下是否可以加個按鈕引導他進入目前正在熱賣的能夠最有效轉化的一個賣場）。如果業務能夠介入任何異常流的梳理和制定中，這裡其實可以挽回很多有價值的待流失流量。
記住，每一個用戶操作一定會伴隨著異常操作（原因有伺服器穩定性問題，網絡問題，用戶操作速度問題等等無法窮舉），都是你挽回流量的機會。
以上便是從一個活動運營的角度和一個基本產品經理工作的層面，解讀了一個完整PRD的元素以及核心，理解這些原理並找機會嘗試一下自己撰寫一個完整的PRD模版，能夠給你的業務策劃有效性和專業性帶來非常大的幫助。
大部分PRD方法論都在介紹模版，但模版並不重要，這些大部分的方法論已經等著大家去用了。不過，這些表面的理論有價值的地方在於，如他們所教授的添加一些變更日誌確實會讓你的需求文檔看上去更專業。
了解了如何把業務語言轉化到產品需求語言之後，我們在下一篇更近一步，了解一下產品需求語言轉化到研發語言的過程，附帶了解一些最入門的研發知識。完整掌握之後你就有了和研發同事直接對話的能力，就能幫助你從一開始帶著可實現性，成本最低的意識去策劃一個業務，同時幫你極大的拓展可使用的業務手段。