整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
老板跟你說：“你做個需求分析”的時候，有沒有想過自己如何下手呢？這篇文章，告訴你詳細的步驟。
【目錄】
要講解需求分析，比較簡單的方法，是按照流程講需求分析的全過程——比如：收集、整理、分析、匯報等等。
但是有意思的是：你可能會發現流程中至少有一個步驟，不管是難度還是重要性，都遠遠超過了其他的步驟；占了整個需求分析過程的60%-80%，寫文檔之類的步驟與之相比根本不在一個量級上。比如：“明確真正的需求”、“找到背后的原因”、“深入挖掘用戶心智”等等。這種“重量級”的步驟搞不定，前前后后的事情就都白做了。
所以我依舊從邏輯上推通：為什么要做需求分析？它僅僅是產品經理的必備工作技能之一嗎？又或者它對產品的設計確實有所幫助？那么幫助又體現在哪里呢？了解需求，是不是就代表了解用戶了？還有最最最最重要的，怎么做需求分析？
“需求分析是為了設計更好的產品。”嗯，這是一個比較常見的、中規中矩的答案，但它有三個更嚴重的問題：
舉個簡單的例子：現在眾多App都采用了底部標簽欄（如下圖，iOS系統的設計樣例）的設計。
為什么這樣設計？滿足了什么需求？
其實這個問題無論怎么回答都是不恰當的——因為問得有問題。
首批采用底欄設計的App和后續采用類似設計的App，做的事情本來就不一樣。
“抄”不僅是降低試錯成本，更重要的是迎合用戶習慣。
雖然設計看著是一樣的，但解決的問題卻不一樣的——首批App是在引導用戶，而后續App是在迎合用戶，需求已經變了。
既然需求不同，我們又怎么能籠統的回答“為什么這樣設計”這個問題呢？
那么為什么要迎合？
從結果導向來看，因為放置底欄，我能想象用戶看到時的反應，我也知道用戶會點擊；如果放在別處，我真的不知道用戶會拿它當什么，也不知道用戶會不會點擊，這需要額外的實驗來驗證。
也就是說：放置底欄，我能夠大致預測用戶的操作；如果不這樣設計，我不知道用戶會怎么操作。
所以，需求分析，本質是動機的分析，目的在于預測用戶未來的行為。需求分析階段的產出物，需要回答用戶要什么、為什么要，還要回答以后什么情況下還可能要類似的東西、這種情況有什么特點、如何人為的制造這種情況、……
例如：
今天用戶買了一個蘋果（不是又貴又不能吃的那個），可能是因為饞；明天用戶不饞了，“解饞”的需求就沒了。如果我今天因為用戶買了蘋果，就去再進一批蘋果，明天就會滯銷。這是從“行為表現”的層面做需求分析的必然后果。看起來，“買蘋果”并不是我們心目中的那個“用戶需求”，似乎“饞”才是。
但是，又過了一天，用戶因為餓肚子又買了個蘋果。怎么辦？此時我們已經分析到“動機”的層面了，但是遇到了兩個完全不同的動機，“偽需求”可能就隱藏在其中，哪個才是真的呢？
假設我們能看透用戶的內心，那么根據已知條件，可能有兩種方法分別應對：
選哪個呢？
再一次，選哪個都不合適。
理想的情況下應當用不同的產品（或功能）打不同的市場，因為不同的市場代表了不同的需求，這就是市場細分。
也就是說：最大最好的蘋果放在最顯眼的地方饞人，同時在“飯點兒”處理賣剩下的那些不太好的貨色——因為“解饞”的需求一般不會明說，而且可以忍，所以“便利”變為重要的客觀條件；而“吃飽”的需求忍不了，不滿足會直接提要求，但體驗差一點無所謂。
像這樣，當我們確實發現根本的動機是不同的，就應該將這些用戶分成兩個“市場”（或“用戶群”），分別對待。
總結一下這部分的內容：
那么，真正的需求怎么找？
做需求調研和分析，最尷尬的結局就是：用戶以為自己說清楚了，我們以為自己聽清楚了，結果兩邊就這樣整差了。
相比之下，需求驗證倒是件容易的事情——只要看用戶買不買單，不買單自然是因為需求分析錯了。
但是“為什么錯了？”“錯在哪里了？”這樣的問題可就太難了。
大到宏觀經濟周期，小到用戶彼時彼刻的心情，可能是周圍有蒼蠅惹得用戶心煩，就給了蘋果差評，我們又怎么能知道呢？
就像前面的那個例子——表面上是用戶買了兩次蘋果，但兩次的動機截然不同。
為了研究動機這個事，前輩們也是操碎了心。
我們選擇兩個切入點不同的模型，用來構建矩陣：
在前一節提到過，用戶的需求是分層的，說出來一個樣，做出來一個樣。“用戶說出來的未必是真正需要的”，這句話在產品圈子中已經快被說“爛”了。但這背后的原因是什么呢？在產品上線之前，甚至在進入產品設計階段之前，我又怎么能知道我做的需求分析已經足夠深了呢？
行業給出的一般方法是MVP（Minimum Viable Product），利用MVP收集線上實際數據。但MVP只能告訴你，你是錯了還是對了，依然解決不了“為什么”以及“應該怎樣”的問題。況且MVP還有覆蓋度的問題，怎么設計才能讓MVP覆蓋所有“應該”被測試的場景呢？
在這一節我們就來說說這個問題。
說到需求想起馬老師，這幾乎變成了條件反射。
馬斯洛在《動機與人格》（1954）書中提出了廣為流傳的需求的五個層次，由低到高分別為：生理需求、安全需求、社會需求、尊重需求、自我實現需求。其中，前四個層次被稱為“缺失性需求”，要求就是起源于對于“缺失”的感知，所以需要向周遭的環境尋求可以滿足需要的東西，包括物質、精神、人際關系、社會地位等。
可見，“缺失性需求”完全依賴于外部環境提供滿足。而最后的自我實現的需要被稱為“成長性需求”，其中由第4階段到第5階段的過程，就是“成長”的過程。這個階段的馬斯洛需求層次理論，其根基是“人本主義心理學”（并列的還有大名鼎鼎的行為學派和精神分析學派），關注每個個體。
注意這里的用詞：雖然國內大量的翻譯采用“需求層次理論”，但是英文原文為“Need-Hierarchy Theory”，用的是“Need”（需要），而不是“Demand”（需求）。在馬斯洛的需求層次理論中，各個層次都是“需要”。
按照前面給出的需求拆解，在這個階段用戶只知道自己的需要，不知道用什么東西來滿足，更不知道怎么評價購買力。所以馬老師的理論，更適合用來發現需求的根本來源，而不是對于具體產品或服務的需求。
另一個需要注意的是：馬斯洛需求層次理論中的各個層次，指的都是最根本的需要，而不是那些用戶直接告訴我們的，或者我們直接觀察到的。那些我們直接得到的，需要深入挖掘之后，才能套用到馬老師的框架之中。原引馬老師的《動機與人格》中的兩段，這兩段表明了這一點：
如果我們仔細審查日常生活中的普通欲望，就會發現它們至少有一個重要的特點，即它們通常是達到目的的手段而非目的本身。
我們需要錢，目的是買一輛汽車。因為鄰居有汽車而我們又不愿意感到低人一等，所以我們也需要一輛，這樣我們就可以維護自尊心并且得到別人的愛和尊重。
當分析一個人有意識的欲望時，我們往往發現可以追溯其根源，即追溯該人其他更基本的目的。……
這種更深入的分析有個特點，它最終總是會導致一些我們不能再追究的目的或者需要，這些需要的滿足似乎本身就是目的，不必再進一步地證明或者辨析。
在一般人身上，這些需要有個特點：通常不能直接看到，但通常是復雜的有意識的特定欲望的一種概念的隱身。也就是說，動機的研究在某種程度上必須是人類的終極目的、欲望或需要的研究。
關于這一點，我們在營銷的需求層次部分，會再次提及。
到了1959年以后，馬斯洛認為“人本”的導向會產生“自由主義”傾向，從而產生自私、不負責任、不顧他人、自我放縱等自我中心傾向。于是，馬斯洛于1969年發表了論文《Z理論——兩種不同類型的自我實現者》，并依照“超人本心理學”（Trans-Humanistic Psychology）將需求層次理論拆解為三個次理論：X理論、Y理論和Z理論。
依次為：
Z理論
Y理論
X理論
這段內容就沒有5個層次的理論框架流傳廣遠了。包括在科特勒老師的《營銷管理》中，引用的仍然是經典的5各層次的理論框架。這也就難怪，寫到Z理論的文章，有些會用“需求層次理論已經過時了”之類的標題來吸引眼球。
其實不只是框架的升級，而是根本觀點的改變。
框架的改變只是為了滿足新的視角。
在馬斯洛的框架里，我們知道了根本的需求是從哪里來的。但是這還不夠。這就像：如果我們只是探測到了一個大油田而不去開采，它們就不能為我們所用。
所以，接下來我們就要研究，這些根本性的需求是怎么表達出來了。抓住這些表達，再一路追查下去，才能發掘真正的需求。
營銷學專門研究了這個方面。在營銷學中將客戶（用戶）的需要分為5個類型，分別是：
在科特勒老師的《營銷管理》（15th Global Edition）中，給出了這樣一個案例：
發現了嗎，一直追查到了“秘密的需要”這個層次，才多少能夠套用上前面馬老師的需求層次理論，差不多應當算得上“尊重需要”。前面的那些都是在社會、市場、心理等眾多方面的因素共同影響下，而在根本需要之上產生的。假設這個分析是正確的，那么一個可供分享和炫耀的H5頁面，其效果就要好過一項購車優惠政策，或者保養打折券。
這五個分類怎么用呢？這個框架可不是讓我們，在拿到一個需求的時候對號入座，看看它到底屬于哪一類。用戶根本就不會提某一類的需求，每一個需求中，都會同時包含這五個類型的需求，只是你能不能想到的問題。
所以這套框架的用法，是在聽到用戶表達的需求之后，同一時間將需求拆分到這五個類別中，或者是同時從這五個方面來評判用戶的一個需求。
就像上面的例子：用戶會問“你家的汽車便宜嗎”？如果你回答“便宜”，那么用戶會提出第二個需求“旁邊那家比你家更便宜”。然后我們就跨過了品牌戰、服務戰、產品戰，直接打到了價格戰。
但是，如果你回答“內行人都到我們家來，內行的消費者不會上來就看價格的”，這樣的回答便正中下懷。
那么問題來了：秘密是用戶心理想的，我又怎么知道呢？
這就是經驗了，不然經驗的價值在于什么？
經過多次溝通、多次實戰，總有一些共通的東西會變成自己的經驗，這個確實是“干貨”，但不是學好了上來就能用的，因為到了實戰中你根本想不起來。
因此，這套框架的另一個優點，就是在框架上“承認”了：確實有些用戶需求我們是不可能直接獲知的，當然也就不可能有意識的滿足。就像一些分類方法，在最后總會放上一個“其他”的分類。這相比于泛泛而談的需求理論更加嚴謹。至于原因，可能是行業整體的認知不到位，也可能是我們自己的能力還差了那么一點兒。
而泛化的需求分析理論，首先假設我們能夠獲知所有的用戶需求，并做出完全滿足用戶需求的產品。甚至將這種“神化”的能力具象到一些“牛人”的形象和具體的產品上面，認為他們已經100%地挖掘了需求，所以才那么牛。
但這種理想狀態受時間、空間、成本、能力等等很多障礙的影響，我們是不可能達到的。所以，我們應當關注的，是那些可以獲知、可以滿足的需求，并且不斷優化滿足的方式（也就是用戶體驗問題）。
有了前面兩套框架，我們就守住了需求的來源和表達過程。但是兩套框架的用法正好截然相反：馬老師的框架是“5:1”——從五個層次里選一個當前所在的層次；但營銷學的需求理論是“1:5”——拿到一個需求從五個方面來分解。
我們用前面賣蘋果的例子還原一下需求分析的過程：
用戶說：“我要買一個蘋果”。此時千萬不要直接就套上馬老師的需求層次了，因為這根本就不是一個“根本性”的需要，而是一個結合了具體產品——蘋果的具體需要。
這時應當用的是營銷中的五個分類：
好了，雖然我們只有第一類需要能確定，其他都是猜測，但是至少我們知道接下來有限的時間里應該說點什么、做點什么了吧？
看看用戶的神態像不像有低血糖的癥狀，看看著裝穿戴像不像上班族，觀察下用戶的注意力是在蘋果上還是神色匆匆的看手表，又或者還在看其他的水果……為什么看這些？經驗使然。（我沒賣過蘋果）
直到我們能夠確定，用戶就是趕時間，需要快速解決饑餓的問題。我們才將這個需求，定位到馬老師的“社會需要”或者“尊重需要”一層——餓，確實是餓，但是是趕時間的餓，不是那種能夠坐下來踏踏實實解決的餓。
那么這個時候，“尊享外賣”服務才是完美的解決方案，一個蘋果起送、包裝精美，將你的用戶包裝成“懂得節省時間”又“生活精致”的“職場精英”形象，才是制勝的關鍵。
所以，下次再有用戶直接找你要什么，可別再直接搬出馬老師的需求層次理論了。說出來的，真的不一定是心里想要的。
需求的定位幫助我們找到了需求，但是在實際擼袖子開干之前，我們還要知道這其中的“操作空間”有多大——也就是需求的量，它決定了實現需求的ROI。
在一定范圍內，需求的量越大，也就越有可操作的空間；相反需求的量太小了，產生的價值不能填平成本，也就沒有操作空間了；還有如果量太大，大到可能對用戶有害的地步，那我們也要小心的操作。
這部分說的就是“量太小”，還不夠我們可以操作的地步，或者操作的成本太高了，不值得。當然，我們可以看到一些占領了“垂直領域”的公司，對于這樣的“小需求”也在做，那么他們一定是找到了恰當的撬動需求的辦法，能夠控制好成本。這就像對于大量用戶的潛在需求，有些實力雄厚的公司就是能夠投入足夠的資本做實驗，一旦實驗成功便能帶來巨大的回報。
3.1.1 無需求（No Demand）
無需求是指目標市場顧客對某種產品毫無興趣或漠不關心，如許多非洲國家居民從不穿鞋子，對鞋子無需求。
一般人們對于廢舊物資、特定場景沒有用的東西，以及不熟悉的東西（比如新產品）沒有需求。我們可以把產品利益同用戶的自然需求及興趣結合起來，從而“創造需求”。（想起喬幫主了吧）
3.1.2 負需求（Negative Demand）
負需求是指市場上眾多用戶根本就不喜歡某種產品或服務，比如老年人不敢吃甜食和肥肉，怕得“富貴病”。
對于這樣的情況，我們只能考慮改變顧客對某些產品或服務的信念，比如宣傳老年人適當吃甜食可促進腦血液循環等等。
總之，成本還是很高的。
3.1.3 潛在需求（Latent Demand）
這是指現有的產品或服務不能滿足，但是確實存在的強烈需求。例如，國內的中老年市場，就是一塊充滿未知數的潛在需求市場。
但是對于這樣的市場，公司還是要開發新的產品或服務來滿足，存在不小的風險成本。
到了這里，我們就已經進入可操作的范圍了。
下面這些需求的狀態，多少都是有個“抓手”的，可以據此進行進一步的需求分析和產品或服務的優化。
3.2.1 下降需求（Falling Demand）
用戶對產品或服務的需求出現了下降趨勢，這個在互聯網領域并不少見，而尤其容易出現在那些可替代性強的產品身上。
對于這樣的情況，無非有兩種辦法：要么根據用戶的變化，優化產品；要么根據產品的變化，尋找新的用戶。
3.2.2 不規則需求（Irregular Demand）
就是產品或服務收到外界因素的強影響。原來的商品領域，經典的例子就是夏天吃的冰淇淋；而到了互聯網領域，到了“飯點兒”擁擠不堪的外賣、刮風下雨“一車難求”的滴滴，都是不錯的案例。
當然，說起來方案也簡單，就是針對不同的情況制定不同的策略。
但是設計起來就難了，要結合具體的業務場景。
【劃重點】注意哦，這些特殊情況，最容易出現在面試題中哦~
3.2.3 充分需求（Full Demand）
指的是產品或服務目前的需求水平和實現，剛好等于期望的需求。這當然是所有的情況里最好的一種。但用戶需求會不斷變化（注意，是具體的需求，套上了馬老師的層次框架的根本性需求，變化得不會那么快），競爭也會日益加劇。
所以在這個狀態下，就要對可能出現的變化未雨綢繆。
3.2.4、過度需求（Overfull Demand）
是指用戶對產品或服務的需求，超過了企業供應能力。在商品領域，供不應求比較好理解；但是在互聯網領域，可能就具體到了人力效率跟不上業務自動化的發展、風控能力跟不上資金量的發展、計算能力跟不上數據規模的發展等等。
如果這真的是不可抗拒的現狀，那么企業要么放棄一部分利潤，優先服務好有限的用戶；要么加大投入做產品或服務升級，來應對過度的需求。
3.2.5 有害需求（Unwholesome Demand）
有害需求指的是有害的產品或服務，諸如煙、酒、毒品等。對于這樣的需求，企業有責任通過提價、傳播恐怖及減少可購買的機會或通過立法禁止銷售，因此又被稱為“反營銷”。其目的就是通過采取措施，消滅有害的需求。
前段時間，關于有害需求還有一批很好的案例，就是各種“P2P雷暴”事件。
普通百姓認知中的金融產品，普遍還停留在“銀行存款”的層次——保本保息，多存多得，根本不需要擔心什么。
對于財富的積累和增值，人民大眾始終有強烈的需求。
另一方面，保有金額越多，對于各種P2P平臺來說也是件天大的好事。所以，“拉交易、促保有”成為P2P平臺的主要運營目標。
但是問題就在于：金融產品不像商品，倉位是直接與風險掛鉤的。如果你買5個冰箱，最多在家放著占地方。但是如果你持有的金融產品翻了5倍，你需要承擔的風險就遠遠超過你能承受的范圍了。
但是，P2P平臺明知風險在不斷積累，還不斷的以“拉交易、促保有”為目標引導大眾“一投再投”，有意的強調收益而弱化風險，這就是對有害需求的放任不管。
在這里特別點出有害需求，也有特殊的用意。前面幾種“需求的量”，都是為了“正向”的滿足而被拆分出來的，唯獨有害需求，是為了“反向”的不滿足而被拆分出來的。阻止情況走向惡化，盡可能的避免用戶受到傷害，也是一種不錯的定位，能夠廣得人心。
到這里，前面的內容基本的需求分析說完了。但是，問題在于市場上不只有我們一家，也不只有我們一幫人這么想。如果我們只關注自己做的而不管別人，做得再好也會被市場淘汰。
這就是需求中的競爭性，也就是標題中的“競爭性需求分析”。需求中的競爭性，說白了就是結合三方面，這在之前的文章中（http://www.woshipm.com/pmd/1396178.html）簡單地提到過：
這三方面分別對應用戶的需求、我們的能力、市場的機會。用戶需求絕不能跟市場機會直接畫等號，那些經過博弈之后剩下的、還屬于你的用戶需求，才是真正的機會。這就是很多在用戶需求的部分已經做到完美的需求分析根本無法落地的根本原因。
我們在前面三節中，分別講解了兩個經典模型。而講解這兩個經典模型的目的只有一個——把需求切碎，切得再碎一點，再碎一點，……為什么要把需求切碎呢？因為用戶需要的越是類似、我們能滿足的越是類似、市場上還剩下的越是類似，競爭也就越激烈，競爭性也就是這么來的。而差異性越強，競爭也就越小。
用戶需要的差異性，就依賴于前面講到的兩個需求分析框架，能將框架運用得好，也就能將需求拆的越碎，從而發現別人沒有發現的點。找到一塊別人沒有滿足的用戶需求，那么我們就可以使用最簡單、最直接的辦法滿足，這就對應了生產觀念（參考：http://www.woshipm.com/pmd/1396178.html）。但是可想而知，工具是同一套工具，隨著行業的發展也會有越來越多的潛在需求被挖掘出來，所以找到沒被滿足的用戶需要，也就變得越來越難了。
當用戶的需求被挖掘得差不多了，我們也就進入了滿足方式的競爭，也就是第二個“我們能滿足什么”的比重開始變大。
在這個階段，同一份用戶需求至少有兩個方案可以滿足，用戶理所當然的選擇更好的方案。當然，更好的方案當然依賴于對用戶需求的進一步拆解，只是這時拆解的空間已經不多了。
等到競爭走向白熱化，后來的勢單力薄的公司只能在剩下的空間里扎根了，這個時候第三個“市場上還剩什么”就變得越來越重要了。那些容易想到的、利潤豐厚的、用戶規模大的需求，早已被領先的企業牢牢把控，我們就只能“撿漏”。
那么，市場剩下的是不是用戶的真正需求呢？
是的，只不過它們可能屬于“不可操作”的類型，或者存在“過度”和“有害”的風險，需要謹慎行事而又前途未卜。
那么如何在競爭中找到機會？
這也就是競品分析真正的價值所在，而不是簡單的尋找方案上的差異。“需求的同質化”是將競爭引向白熱化的根本原因，“方案的同質化”其次。
比較好的辦法，就是把前面的兩個需求分析框架，將不同的競品一一分析出來，如果存在不確定的因素，就通過實驗驗證，逐步了解各種競品之間是如何切分市場份額的。
就像前面說的——這也是經驗積累的過程。
前面我們既講了需求分析的過程，也講了競品之間競爭性需求分析的過程。最后的最后，我們要講講怎么把自己做好的需求分析講別人聽。這是關鍵問題：需求分析作為工作流程之一，必定存在這匯報關系。而搞定這些匯報，也是需求分析真正能走向落地的必經之路，否則再好的方案也得不到資源的支持。
這聽上去，又像是另一起“需求分析”了——我們要對同事、老板、下屬進行需求分析，然后才能把自己的東西“給到他們心里”。
“確實不是每個人都有遠大的抱負”。這句話我從不止一兩個朋友口中聽到，尤其是做人資的朋友。在尊重每個人的選擇的基礎上，對于這樣的同事，確定的利益比遠大的夢想更有吸引力。所以，下次再講需求分析的時候，真的不是“畫大餅”就能搞定的，那些遠大的需求，可能早已被行業“領頭羊”控制了，分析了也沒多大用。
至于怎么講，我們還可以套用前面的框架——老板跟你說：“你做個需求分析”。
那么：
至于運營、研發等等各類同學也都一樣，用這樣的五個分類拆一下，你就知道怎么跟他們溝通了。
本文由 @御豪同學 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
這篇文章中，本文作者分享了他對于產品文檔的看法以及撰寫產品文檔的常用流程。
很多人聽到「產品文檔」這四個字就像吞了蒼蠅一樣，人們通常會認為這意味著又要花幾周寫一個根本沒人看的文檔。如果一個團隊總被產品文檔這種事情拖累，怎么可能「敏捷」得起來，怎么可能高效地產出代碼？
我在過去十幾年創造了多個數百萬人使用的軟件產品之后，越發認為這種觀點是完全錯誤的。根據我的經驗：
在這篇文章中，我會通過一個案例來分享一些普適的建議，這些建議會對大中型（超過二百人的）公司中的產品經理們非常有幫助。
假設你在這里工作：
一家從事在線旅游預訂服務 （就像 Hotels 或者 Airbnb 但是規模更小一些）的公司。目前這家公司的支付轉化率偏低，所以這個季度大家打算嘗試通過在支付環節加入在線客服的方案來提升轉化。
你的工單/用戶故事/路線圖是：
通過在支付環節增加在線客服來嘗試提高支付轉化率。支付轉化率目前僅有 18％，而業內平均轉化率有 30％。我們打算測試下在支付時展示在線客服聊天窗口是否可以提高這個轉化率。用戶運營團隊已經同意了提供 1 人月的客服人力支持。
在你沒有產品文檔時，你會這樣做：
比方說，你覺得行動起來總是最重要的，因此直接開始動手：
搞定了！這么簡單的事情怎么能要我們寫產品文檔呢？如果你是在一個小型創業團隊，你也確實并不需要——因為產品改動相對小，涉及到的人也相對更少。
但如果你是在一個更大的組織之中，或者產品更加成熟/復雜，就會陸續出現下列這些問題，并且相比寫文檔，這些問題會需要更多時間來處理。
例如：
如果這是一個相對簡單的項目，即使沒有產品文檔可能也不至于陷入這樣的災難之中。但是在簡單的項目中你仍然有可能會因為沒有文檔浪費許多時間和機會成本。
為了便于說明，我準備了兩個示例文檔：一篇思路筆記，和一篇完整的產品文檔示例——這樣可以完整介紹產品文檔的撰寫流程。
請在繼續閱讀文章之前，花幾分鐘讀一下這兩篇示例文檔吧。
這是一個根據你已知的信息和想要解答的問題所梳理成的列表。
這會是你需要做的第一件事情，大約需要一個小時來完成這個文檔。這個文檔會成為你和團隊中其他人的一個溝通基礎。
只有和團隊一起評審了你的假設和創意之后（無論是在專門召集的會議上，喝咖啡時，或者桌上足球的休息時間），你才應該真正開始寫產品文檔。
如果已經完成了溝通和評審，整個文檔應該花費你 1-3 個小時的時間。
啊哈！有了文檔之后是不是就感覺踏實多了？寫文檔看起來是額外的工作成本，但是其實并不是，高效的文檔可以幫助你和你的團隊節約時間投入，并且在交付上線時會更有信心。
等等！——你已經讀完示例文檔了么？請務必先讀完它再繼續閱讀下面的文章。
Ben Horowitz
我通過示例文檔詮釋了這篇文章中所講述的思考，在繼續閱讀全文之前，請務必確認你已經閱讀了示例文檔 。
為了以更高的質量、更快的速度和更佳的預判來交付正確的產品。
是的，就是這樣。那么，產品文檔將如何幫助你做到這一切呢？Ben Horowitz 分享了上圖中這個看法，我的示例文檔也是一個很好的例證。明確一下要點：
產品文檔應該明確溝通要做一個「什么」產品，以及「為什么」要這么做。用來說明清楚一個產品的表達方式很多，但最核心的，一定要說清楚這五件事情：
你可以使用我的示例文檔做你的文檔模板，按照你的想法增/刪/改任何章節。只要你能夠清晰并且條理清楚地表述上面提到的這五點信息，文檔形式并不重要。
接下來我會介紹我撰寫和評審文檔的常規流程。根據項目大小，利益相關方的數量不同等情況，流程細節可能會有所變化，但是大體的流程是確定的。
（1）快速完成一個草稿（1-2 個小時）
關閉電子郵件和聊天工具。泡杯茶，坐在椅子上開始思考，然后逐一把你所了解的信息列成清單（見上文中的思路筆記示例）。
（2）安排幾個 30 分鐘的一對一會議 （1-4 個小時）
這個步驟的目的是過一遍文檔中的細節，優化你的方案，并且獲得更多人的支持。盡可能控制這些會議的規模，人越少越好（理想狀態下都應該是一對一會議）。
在本文的示例中，我會和客服部門的負責人，一個財務人員和一個工程師分別安排一次會議。
（3）撰寫和編輯文檔 （0.5-3 天）
此時，你應該對能做，并且應該做什么有了一個明確的想法，但是大腦中塞滿了大量的細節等待著梳理清楚。于是接下來需要將所有這些細節都整理出來，并且逐一梳理斟酌。
在完成第一版文檔之后，需要繼續大篇幅編輯修改，通常最終的文檔可以在你的第一版草稿的基礎上壓縮 30%-50% 的長度，簡潔和清晰的文檔就意味著更加容易閱讀。
大部分文檔都可以在半天到一天的時間里完成，不過實際上也會有一些文檔需要兩三天才能寫完。
（4）群發文檔并且安排一個 1 小時的評審會議（15 分鐘）
將文檔群發給項目的所有利益相關方，并且抄送給其他可能對文檔感興趣的團隊（例如你所在的產品團隊，整個支持團隊等）。
跟進這些關鍵人員是否接受了會議邀請：將會執行這件事情的人，和所有對這件事情有通過/否決權力的人。
（5）評審文檔（1小時）
在開始會議之前，詢問是否有參會者沒有詳細閱讀你的文檔。通常都會有一兩個人中槍，在這種情況下可以說：「沒問題，我們先用 10 分鐘一起來看一下文檔。已經讀過文檔的人可以利用這個時間先放松休息一下」。
這次會議上你需要獲得利益相關方的同意，并且獲得執行方（工程師、支持團隊等）的知曉、認可以及人力支持。
你可能需要開多次評審會議，并且根據評審會議上溝通的信息不斷修改文檔。
（6）通過評審后，及時同步信息和建立工單 （1-2 小時）
會后同步信息的電子郵件需要包含更新后的產品文檔鏈接，和此項目相關的工單鏈接（例如「在頁面上添加 JavaScript 代碼」，「完成數據分析報告」，「測試 Staging 環境」，「和支持團隊預演流程」，等等）。
一般接下來將會有一位工程師完成技術文檔，不過并不總是這樣（文中的示例項目就不需要這一步）。
盡量簡短
沒有比這更重要的文檔寫作建議了。簡潔意味著清晰的思路和溝通，也意味著你的文檔更加易于閱讀和理解——這一點至關重要。
使用平白的語言和簡單的格式
使用簡短而不是花哨的語句，使用列表和加粗強調可以使文章更一目了然，以放松有趣的方式寫作而不是一板一眼，如果你有得體的幽默感就再好不過了。
為開發團隊預留時間
通過評審并且達成一致通過的文檔才是完善的文檔。如果你希望在未來的某一個迭代 Sprint 中開發此項目，就應該提前兩到三周開始這個產品文檔寫作流程。
像工程師一樣思考
在項目得以進入開發之時，常常會發現大量未預料到的邊緣情況——但這種情形其實可以避免。如果你認真考慮過項目進入開發的所有必要條件，你就可以提前發現這些問題（例如，是否在移動設備中可以使用在線聊天功能？）。
確保每一個人都跟上了你的節奏
當我組織產品評審時，會議室里的大部分人都已經大致了解我要講的內容——因為我已經提前在討論會和日常聊天中溝通過這個事情了。既然大家都已經清楚了「做什么」和「為什么要做」的問題，文檔評審會上我們只要關注實施細節就好了。
在圖表中下功夫
流程圖、線框圖等圖表可以通過易于理解的方式提供很大的信息量，同時也需要消耗非常多的時間來制作這些圖表。
在思考和寫文檔上花 0.5-3 天時間
具體時間根據項目大小而定。花費在寫文檔上的時間越長，所帶來的邊際收益就會遞減。特別需要指出的是，沒有人能夠讀的下去超過 5-6 頁的文檔。
指明方向，明晰愿景
你不僅僅是在定義一個功能，也是在解釋「為什么我們要做這件事情」以及「我們的目標是什么」，在文檔中指出這個項目將會對更高層面的規劃造成什么影響，以及接下來會發生什么。
確保你的觀眾閱讀了文檔
如果你的文檔又臭又長，或者從來不分享給對應的人，那你還不如不寫文檔。務必確保你的文檔被對應的人閱讀了，我上面關于評審開始時留時間給大家讀文檔的建議值得大家參考。
獲取真誠的反饋
你的文檔是否是在贅述人盡皆知的事情？或者是文檔缺乏足夠的細節？是否在后續實施中發現了太多的邊緣情況？又或者，是否在制定計劃和文檔評審上耗費了太多的時間？你應該和你的團隊時刻保持溝通。
我知道會有爭議，但是產品文檔和敏捷宣言的原則沒有絲毫沖突，并且在類似于 Scrum 這樣的敏捷方法上得到了充分發揮。
畢竟，用戶故事（Story）許多時候需要詳盡的描述，文檔可以增加溝通中的清晰度和可傳播性，為什么非要刻板地認為僅僅使用口頭溝通和使用白板才算是敏捷開發呢？
「產品文檔會導致發布變慢，過度規劃，通常會浪費時間」的想法完全是無稽之談。
我工作過的多個世界級團隊遵循著一些敏捷原則（例如兩周一個迭代周期），每天（甚至更頻繁地）發布代碼，并且以發布產品（而不是文檔或者會議）作為衡量成功的標準——這些團隊也都仍然認為文檔是他們打造成功軟件的一個關鍵部分。
我是一個技術文檔的支持者。產品文檔通常關注 做什么 ，而技術文檔更多關注在如何做 。這兩種文檔為研發流程中的不同環節帶來同樣的清晰視角，并且都使得工程師（和他們的用戶）身心愉悅。 未來如果大家有興趣的話我可能會寫一篇關于技術文檔的文章。
感謝你讀到這里。如果你認為這篇文章有用，請分享給其他人——特別是你的產品/工程團隊。
如果你想看更多的產品經理內容（例如：規劃產品路線圖），或者想了解其他人如何使用產品文檔， 請用兩分鐘填寫這個小調查（英文）。我會在未來的文章中分享調查結果中有意思的信息。
以上，祝寫文檔愉快！
原文作者：Gaurav Oberoi是 SurveyMonkey 的（前）聯合創始人，曾于 Amazon、Xmarks 先后從事工程師、產品經理等職位，在西雅圖和硅谷有十余年的工作經驗。
原文地址：https://goberoi.com/on-writing-product-specs-5ca697b992fd
翻譯：Tomy
譯文地址：http://zhuanlan.zhihu.com/p/23778590
本文由 @Tomy 授權發布于人人都是產品經理，未經作者許可，禁止轉載。
私信小編01即可獲取大量Python學習資料
首先，我們打開首頁，輸入關鍵詞：女裝。↓↓↓
點擊找一下，后會跳轉到商品頁面，如下圖所示↓↓↓
這個時候我們就可以看到女裝商品分類，和一些推薦商品，
接下來我們不要急著爬這些商品數據，我們要找的是這些商品的分類目錄地址。
谷歌瀏覽器右擊檢查頁面，仔細觀察會發現，每個分類的商品都有對應的地址，例如：連衣裙，對應的地址如下
我們進入連衣裙的href標簽里面的地址，你會發現頁面的標題已經從“女裝”變成“女裝-連衣裙”了，因為我們在這個頁面看到的商品是經過淘寶分類后的，這一頁內容只包含“女裝-連衣裙”。
通過抓包 我們發現，發現這一頁的真實的數據來源地址是：
https://s.1688.com/selloffer/rpc_async_render.jsonp?cps=1&n=y&filtOfferTags=279874&filt=y&keywords=%C5%AE%D7%B0&&categoryId=0&n=y&uniqfield=pic_tag_id&templateConfigName=marketOfferresult&pageSize=60&asyncCount=60&async=true&enableAsync=true&rpcflag=new&_pageName_=market&callback=jQuery172015741463935213496_1555383468519&beginPage=1
聯系上下文，仔細觀察會發現，這是一個可以拼接的url，大致拼接方式如下：???
url='https://s.1688.com/selloffer/rpc_async_render.jsonp?cps=1&n=y&filtOfferTags=279874&filt=y&keywords='+keywords+'&categoryId='+categoryId+'&n=y&uniqfield=pic_tag_id&templateConfigName=marketOfferresult&pageSize=60&asyncCount=60&async=true&enableAsync=true&rpcflag=new&_pageName_=market&callback=jQuery172015741463935213496_1555383468519&beginPage='+str(i)
其中keywords不難看出是關鍵詞，而且是進行url編碼后的，而 i 這個明顯是頁碼數字，categoryId英語好的一眼就知道是“類別ID”
這些參數是從哪來的呢？
回到前面，我們進入“女裝-連衣裙”的頁面，并查看源碼，搜索這些關鍵詞，
找到了：
接下來的事 就簡單了，通過填參數拼接url，我們隨意可以從女裝-連衣裙分類下，獲取幾十頁數據信息，或者從女裝-日韓女裝分類下獲取數據信息。然后通過正則匹配到商品offerid。???
這些offerid代表的就是商品id，例如取出其中一個offerid：556983465623。那么這個商品的完整地址就是：
https://detail.1688.com/offer/556983465623.html
商品的名稱、價格、銷量、大小參數都可以從這個地址獲取到。
下一篇我會教大家如何根據offerid抓取商品詳情。
本篇完整代碼如下：
???
# encoding: utf-8
"""
本腳本 用于根據關鍵詞“女裝”爬取1688全部分類商品的offerid
"""
import requests
import re
import random
from lxml import html
import time
"""獲取頁面內容"""
def get_html(url):
html=''
for x in range(5):
try:
resp=requests.get(url)
html=resp.text
if len(html) < 1000:
continue
else:
return html
except Exception as e:
print('url {0}, throw exception: {1}'.format(url, e))
html=''
return html
"""從女裝首頁獲取全部的分類地址"""
def category_spider():
# 女裝：%C5%AE%D7%B0
url='https://s.1688.com/selloffer/offer_search.htm?keywords=%C5%AE%D7%B0&button_click=top&earseDirect=false&n=y&netType=1%2C11'
htmlstr=get_html(url)
section=html.fromstring(htmlstr)
links=section.xpath("//div[@class='s-widget-flatcat sm-widget-row sm-sn-items-control sm-sn-items-count-d fd-clr']/div[@class='sm-widget-items fd-clr']/ul//a/@href")
return links
"""從數據源中正則匹配商品的offerid"""
def spider(url):
pid_list=list()
htmlstr=get_html(url)
goods_pid=re.findall(r'offerid=.*?(\d+)', htmlstr)
for pid in goods_pid:
pid_list.append(pid)
return pid_list
def main():
# 獲取女裝商品下的所有分類目錄地址：連衣裙、女式T恤、短袖T恤、外貿裙、日韓女裝等等
links=category_spider()
# 遍歷所有分類
for link in links:
sound=get_html(link)
# 類別ID
categoryId=re.findall(r'"categoryId":"(\d+)"', sound)[0]
# 關鍵詞
keywords=re.findall(r'"keywordsGbk":"(.*?)"', sound)[0]
# 每個類別商品，取10頁數據
for i in range(1, 10):
url='https://s.1688.com/selloffer/rpc_async_render.jsonp?cps=1&n=y&filtOfferTags=279874&filt=y&keywords='+keywords+'&categoryId='+categoryId+'&n=y&uniqfield=pic_tag_id&templateConfigName=marketOfferresult&pageSize=60&asyncCount=60&async=true&enableAsync=true&rpcflag=new&_pageName_=market&callback=jQuery172015741463935213496_1555383468519&beginPage='+str(i)
pid_list=spider(url)
print(pid_list)
time.sleep(random.randint(1, 3))
if __name__=='__main__':
main()代碼輸出結果展示：
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
