整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
老板跟你说：“你做个需求分析”的时候，有没有想过自己如何下手呢？这篇文章，告诉你详细的步骤。
【目录】
要讲解需求分析，比较简单的方法，是按照流程讲需求分析的全过程——比如：收集、整理、分析、汇报等等。
但是有意思的是：你可能会发现流程中至少有一个步骤，不管是难度还是重要性，都远远超过了其他的步骤；占了整个需求分析过程的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小时内与您取得联系。
