这个世界的互联网行业内本来是没有运营这个角色的，以视觉、产品、研发为核心结构的组织形态主导了互联网行业很长一段时间，以最简单的可用产品和功能实现来看，这三个角色确实能够闭环的进行生产。然后互联网进入了伟大的中国，由于国内互联网行业的快速发展，互联网业务的边界越来越广泛。一个业务的成功与否不再单纯取决于产品的体验和价值，产品承载内容的丰富性，营销触达用户的效果、广度和精准度，资源的整合和有效利用等对业务成败的影响开始越来越重要至于等同甚至超过产品的体验和价值。
在传统的三角结构中，产品作为唯一的非技术岗位，承担了主导用户产品体验和链接另外两个技术岗位的义务。而新出现的非技术领域的工作成为了一个空白，于是运营的角色从产品当中剥离出来，打包承载了所有这些非技术工作。所以运营的本质我们说难听一点确实是打杂的，但由于其价值的重要性，我们用更酷的方式来描述运营工作的本质就是解决问题。这个是我国互联网行业工种发展的第一个阶段。
同时又由于运营岗位承载义务的复杂性，部分工作开始逐步有了更明确的定义和边界，于是运营岗位又开始进行细分：数据运营，产品运营，用户运营，活动运营等。每一个细分领域都逐步形成了自己的方法论体系。这个是我国互联网工种发展的第二个阶段。
现在我们来到了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方法论都在介绍模版，但模版并不重要，这些大部分的方法论已经等着大家去用了。不过，这些表面的理论有价值的地方在于，如他们所教授的添加一些变更日志确实会让你的需求文档看上去更专业。
了解了如何把业务语言转化到产品需求语言之后，我们在下一篇更近一步，了解一下产品需求语言转化到研发语言的过程，附带了解一些最入门的研发知识。完整掌握之后你就有了和研发同事直接对话的能力，就能帮助你从一开始带着可实现性，成本最低的意识去策划一个业务，同时帮你极大的拓展可使用的业务手段。