以「滴滴打人」为例，如何从0到1搭建产品？
作者：水果篮子
全文共 13163 字 40 图，阅读需要 17 分钟
———— / BEGIN / ————
IT行业发展数年，其中出现了多种项目开发流程——瀑布式开发、迭代式开发、螺旋式开发、敏捷开发，将这些思想再细分下去还会有Scrum、XP、V模型等等。
但很多时候，似乎在自家项目的开发流程中都能看到上述多种开发方式并存？
有这种情况自然是正常的：方法论只是指导工作的思想。上述的方法适用于某种特定场景下。
举例瀑布式开发：
某度词条给瀑布式开发的定义：
但在现实工作中，一般会采用这种开发流程的基本只有传统IT行业或外包公司。
然而，“不会再改需求”这句话是骗人的——你甲方粑粑终归是你粑粑。
敏捷类开发演变了那么多形态，也不是完全适用各种场景。整个互联网行业都小跑前进，而这些方法论的演变速度似乎已经跟不上了。
对于这些方法论，我的建议是：吸取部分适用于项目实际情况的，放弃那些看上去有用但实际上并没有什么软用的部分，不要做完完全全的“拿来主义”。
就像敏捷开发最核心的思想——拥抱变化。
项目流程
下面笔者将会总结一套可塑性比较强的工作流程：
前期调研
1.1 市场调研
闭门造车总归是不对的。在决定怎么做之前，先搞清楚为什么要这么去做。
如果你或者其它决策者觉得自己经验丰富，比较喜欢通过“拍脑袋”这种方式来决定一件事情，那笔者建议三思后行。
关于市场调研，主要考察的是个大环境情况，在整个前期调研阶段多和市场和运营人员以及其它业务相关人员沟通（如果有的话）。
WHY TO DO > HOW TO DO
主要介绍两种分析法——PEST和SWOT。
1.1.1 PEST
PEST 是一种宏观环境分析模型。
所谓PEST，即：
Political（政治）
Economic（经济）
Social（社会）
Technological（科技）
从四个维度分析大环境。
PEST四象限
政治环境
政治环境包括一个国家的社会制度，政府的方针、政策、法令等。
不同的国家有着不同的社会性质，不同的社会制度对组织活动有著不同的限制和要求。
即使社会制度不变的同一国家，在不同时期，由于执政党的不同，其政府的方针特点、政策倾向对组织活动的态度和影响也是不断变化的。
比如之前如火如荼的，和区块链经济相关的ICO（Initial Crypto-Token Offerings，首次公开加密代币发行）。9月4日，央行、网信办、工信部、工商总局、银监会、证监会、保监会等七部门联手叫停ICO融资。
监管部门将ICO定性为“非法公开融资”并且一刀切，根本不留余地。这次法令出台似乎是猝不及防，但“韭菜们”却是真的要被一刀割完了，谁都不信自己是接盘的那个。
事实上，ICO在发行代币这个环节使用了部分区块链技术，而这部分连区块链的1%都占不到。
韭菜，是等不到花开的时候。
图片来自网络
经济环境
经济环境主要包括宏观和微观两个方面的内容。
宏观经济环境主要指一个国家的人口数量及其增长趋势，国民收入、国民生产总值及其变化情况以及通过这些指标能够反映的国民经济发展水平和发展速度。
微观经济环境主要指企业所在地区或所服务地区的消费者的收入水平、消费偏好、储蓄情况、就业程度等因素，这些因素直接决定著企业目前及未来的市场大小。
“消费升级”一直都不是新鲜概念，这个过程是持续的。
举个老套的例子：
从改革开发以来穿衣要保暖，都后边要时尚，再到现在的个性化搭配和定制，能很明显感受经济发展带来的变化。从x宝、x东到xx有品、xx优品、xx优选，电商越来越垂直，蛋糕分到后面变成了分裱花。
社会环境
社会文化环境包括一个国家或地区的居民教育程度和文化水平、宗教信仰、风俗习惯、审美观点、价值观念等。宗教信仰和风俗习惯会禁止或抵制某些活动的进行。
前阵子某团的“清真箱”事件已经达到了一定的影响力——其实在大学城的食堂都会有清真窗口，大家都习以为常；56个名族都是一家人，相互谅解下还是正常的，不要再说“56个名族，55个VIP”这种骚话了，咳~。
也许这次事件的始作俑者可能不太能接受同胞有特殊待遇，想搞事情，又也许是随口一说引发的舆论热潮，谁知道呢？
不过让人深思的是：某团公关处理危机的效率相较于其它同行，是不是有那么点慢了？
相似事件，图片来自网络
科技环境
科技环境除了要考察与企业所处领域的活动直接相关的技术手段的发展变化外，还应及时了解国家或者地方对该领域的扶持情况。
虽然有技术专利这么一说，但产品同质化的现象依旧阻挡不住；互联网史上“百团大战”的情况不只是历史，现在依旧在发生，未来也规避不了。
上面讲到的也是政策对科技环境的影响。
外部大环境看起来容易分析，但要想深入研究，怕是有点难度，影响大环境的因素太多，需要一个专业的市场分析团队来分析，尤其是数据来源的不确定性，数据被污染等干扰的情况。
比如下面TalkingData2016年移动游戏行业白皮书显示，云贵疆(川)地区用户付费情况相对较高。
TalkingData2016移动游戏行业白皮书
Exm？
是不是很不科学？为什么APA（Active Payment Account 活跃付费用户数）反而是西北内陆地区高于江浙沪等沿海城市？
讲道理，不是黑。
抛开经济状况不谈，沿海地区人口数都要远高于内陆地区，难不成是这个数据源被污染了？
图片来自网络
嘿嘿~，如果你经历过二十一世纪初“斯凯王朝”的崛起，或者对那个时期的故事略有耳闻，那你可能会知道其中的缘由（这是题外话，也不能乱写，不然会被利益相关者吊起来点天灯的）。
大环境的因素大多属于不可抗力，除非你的项目带来的影响力已经能达到一定规模，这是后话不展开。
而下面的SWOT分析法则主要切入企业内部，分析自家企业内部状况，做到扬长避短。
1.1.2 SWOT
SWOT即：
S（strengths）是优势
W（weaknesses）是劣势
O（opportunities）是机会
T（threats）是威胁。
清晰地把握全局，分析自己在资源方面的优势与劣势，把握环境提供的机会，防范可能存在的风险与威胁。这是SWOT分析法的目标所在。
SWOT四象限
谈及自家产品的优势，很多产品负责人会说出一长串引以为豪的论点，但对于一个从0到1的产品，似乎优势就很有限。
没有数据来支撑好看的dashboard，也没有什么产品壁垒一说，核心竞争力似乎只能是团队或企业的背景、人脉、渠道以及其他隐性的资源优势。
而劣势就相对更可见一点。团队人力资源短缺，团队没有相关经验，资金预算短缺，数据孤岛现象严重等等。
所以一个创业团队，或者企业内部孵化新项目所要经历的都是重重困难，一个产品从demo到release也许靠着开发团队可以正常上线，但在上线之后想要发展起来，外界条件是非常重要的。
这时候就要把握好机会（opportunities），应对各种威胁（threats）。
机会这种东西可遇不可求。
马云认为，生意难做的时候才能诞生了不起的企业和企业家——话是这么说，但马云只有这么一个。
大家在日常工作中将各种细节亲历躬行，努力将所有事情做到最好，不就是为了减少运气在创业成功中所占的比例么？
关于威胁（threats）这点可能用词言重了，正确的解读应该是外界的不利因素，或者挑战。
VR/AR在前几年被炒作的要上天了，但行业冷静下来后不还是一地鸡毛。
归纳下，大致原因有如下几点：
VR/AR成本较高，还没有达到消费级产品的价值(谷歌Cardboard那样的纸板真的不能叫VR…)
行业生态还很雏形，下游的相关服务性质的产业还不能撑起客观的市场规模
相关从业者借助媒体炒作风口，妄想把产品从to c到to vc。关于这点各领域的都有这种现象，典型的就是互金。
分析完这大环境和企业内部的情况，该来分析下友商的产品了。
1.2 竞品分析
部分产品按照服务受众分to C和to B，两种产品的侧重点全然不同。
前者注重用户需求和体验，出发点就是解决用户的需求，实现商业价值，所以用户才是爸爸。
而后者基本都是工具型产品，为了解决业务需求，提高工作效率，出发点就是商业价值。
to B的产品如果没有相关从业经历，可能会无从下手，因为to B类产品的业务逻辑错综复杂，没有经历过一个成熟产品的搭建设计，想要开始规划会有些难度。
这时候，你可以尝试下搜索市面上是否已经有此类to B的产品服务，一些ERP、CRM或其它SaaS，都会有Demo可以体验试用。
也可以找这类产品的客服或者商务要求体验下产品，甚至索取使用说明书。
如果这类产品服务掌握在少数企业手里，而你所在公司有这个业务，那笔者的认知也没法帮助到你了。
而to C的产品基本都是可以接触到的，可以从用户体验五要素来分析，即：
战略层 –> 范围层 –> 结构层 –> 框架层 –> 视觉层
图片来自网络，用户体验五要素
其中战略层基本只能靠揣摩和推测，在上述分析外部环境的时候就一起研究，结合整个大环境来分析。
一个企业的战略方针，保密级别必定是S级的。企业通过各种媒体渠道发布的内容都得经过包装，如果将老底全盘托出，那竞争对手就会调整战略，对其进行针对性的打压。
除了上市公司Qn财报的数字相对可信，其它的新闻发布会之类的真的只能听听——这种真假参半的讯息如果当真的拿来分析，那势必会造成分析结果的不准确。
关于用户需求和商业需求的权衡，这点众说纷纭。
产品岗的面试的时候也总被问到用户利益和商业利益取舍，这个问题仁者见仁，智者见智了。
范围层，介绍该产品所包含的功能范围，简而言之就是用户能通过产品能做哪些事情。
在项目早期会议中，一个产品的核心功能就被决定了，产品无论日后迭代成什么样子，它的核心功能是不会变的。
如果产品经过大改动或者干脆研发了新产品——这可能是产品盈利出现了大问题，要么干脆换人接盘了。
从框架-结构-视觉，这三层基本会混在一起拿来分析，像流程进行中的交互体验，一个页面上承载的信息量和整体信息架构，是没法完全拆解开来分析。
举个栗子：
在移动端做一个用户信息填写的表单，一份单页的长表单可能会造成用户认知压力，这时候就会把表单拆解成多个页面，并且控制每个页面的信息量。
单页—>多页
而这页表单的切换方式设计贴近自然交互的划页效果，相伴而生的是整个界面轻柔的风格。
加载—>划页
为了加强多个页面的相关性，将一些元素在多个页面复用，并在页面流转时体现出来。
在底部加上进度条，告知用户他处在哪个阶段，类比web上的面包屑。
元素关联
初步眼动测试发现表单文字的位置没有思考到位，导致视觉移动路径过于崎岖，并且发现导航效果过于明显，干扰了用户使用，决定弱化导航。
优化调整
最后，还要做一轮“减法”，去掉没必要存在的元素，减少信息干扰。
图片来自网络
所以哪怕一个小小的表单，也会有UED团队的反复斟酌，从框架到结构再到视觉，都是无法分离的，用研、IxD和GUI设计师还有产品经理需要相互协作，还有需求提出人也需要介入其中的过程，不然到最后可能就变成"丁公凿井"了。
丁公原话：吾穿井得一人
翻译：我要挖井，需要一个人帮忙。
路人版：丁公挖井，挖出一个人。
光靠流水线式工作，交付文档和设计稿——能对接成功就有鬼了。
1.3 用户用例
用例全写Use Case，标题是硬凑四个字的，怎么翻译就不去深究了，原意是基于多场景的，有目标序列的行为交互。
对于新加入项目的同学，看UML用例图是最快能理解项目业务的方式。
在实际工作中，可能有的同学会觉得多泳道的流程图已经把业务流程讲的很详细了，再多个UC图会赘述，浪费时间。
但实际上，UC在产品需求整理前期可以更清晰的理顺思路，尤其是需求还没有确认下来的时候，一份简单的UC和项目成员沟通可以节约更多成本。
还有一点要注意的是：use case和use story的区别。
引用下一位同行的解释：
从概念上，用例包括了业务用例和系统用例；user story更多的是一种业务用例，而软需描述的更多的是系统用例。
从粒度上，user story的粒度特别是在敏捷开发的时候往往比用例的粒度更细化；用例中的基本流，扩展流，业务规则都可能是转换为user story。
从层面上，user story更加关注业务场景和用户故事，更加偏向于用户能够理解或看懂的内容；user story是能够产生核心业务价值的单位——业务用例能够达到这目的，但是系统用例就不一定了。
从详细程度看，user story偏用户需求或业务场景，重点把业务需求和场景说清楚即可，比较简单。而用例建模比较复杂，涉及业务流程，业务规则，输入，输出，界面，交互等各个方面的内容。
如果一个产品的用户类型过多，或者产品功能过多，则切忌只在一张用例图上绘制，这时候可以选择按照几个维度来划分：功能，场景，角色。不然用例出来会和蜘蛛网一样混乱，让人没法阅读。
正确示范，图片来自网络
上述三点前期调研分析，都是同步进行的，从一各不经意的点子到着手实现一个demo或分析市场，都没有前后之分。
其实在这个时候，整个产品的布局已经跃然纸上了，接下来要做的就是细化细节，这也是大多数产品经理和需求分析师主要工作内容。
需求分析
2.1 业务逻辑
在一个小团队或创业公司，需求可能直接来自老板或项目经理，这类需求都是二次需求，需要你在听取需求后思考背后的目的。
就如本文开头所说一样：在决定怎么做之前先搞清楚为什么要这么去做，不然跟着一起遭罪的还有团队成员，需求总是改动对士气影响很大。
WHY TO DO > HOW TO DO
用户用例简述了参与业务的角色，以及发生这些业务的场景，接下来就要细化各个业务的流程了。
C端产品的早期，业务逻辑梳理起来不会过于复杂，但用户的需求，需要不停地去揣摩和研究；
而B端产品的需求则会很明确，产品所需要的功能都很清晰，其业务逻辑相对C端产品会来的复杂。
一般创业团队在测试市场对产品的接受程度或者验证商业模式的时候，会设计开发一个MVP版本的产品投放市场，或者其它非产品化手段。
举例滴滴打人：
滴滴打人业务逻辑
滴滴打人app作为平台其核心功能就是连接打手和用户，收取中介费盈利。
产品经理需要考虑：这个订单需要提供哪些信息才能让打手找到目标，打手竞标的机制该怎么设计，什么样的情况打手才算完成任务，用户是先付款还是后付款。
每个功能节点的业务需要细化，设计不同场景下的逻辑处理。
2.2 商业&用户需求
这两点是大多数C端产品纠结的地方，权衡商业需求和用户需求。
举个栗子，还是滴滴打人。
从需求源头上来分析，用户因为个人情感经济纠纷，或者别的情况需要“教育”下对方，因为自己身体素质不行或者没有时间，也可能因为找不到对方，所以需要求助专业人士来处理。
这里的需求是接到提案时初步分析的，再用马斯洛需求金字塔来分析需求的层次。
假设用户小明因为小白欠债不还，决定使用滴滴打人来要回这笔钱。
从底层需求来开始讲，小白欠了小明钱不还，小明打电话催促了好多次但无果，于是很愤怒，智商瞬间为负数，决定报复对方，获得快感。
但小明因为自己块头太小，琢磨下不是人高马大的小白的对手，处于保护自己，他决定思考别的方法。
欠债还钱是社会基本规则，小白不还钱似乎显得自己很窝囊，好欺负；再往上走，对自我价值的实现，似乎解释不通了。
马斯洛需求金字塔
各位观众老爷看到这里一定觉得笔者拿滴滴打人作为例子显得很蠢，但现实生活中相关产业已经发展的不错了，甚至有的还能拿的上台面。
头几年互联网金融中的P2P，相较于传统的金融企业像银行和其它小额借贷机构，它的放贷要求的很宽松。
比如你向某互金A公司借钱，A公司的业务员只要是你拿出其它同行的借贷证明就能放贷。
如此不谨慎的风控机制造成了居高不下的坏账率，也催生了下游催债的行业的发展，某些讨债公司甚至已经挂牌新三板了，也算是“上市”公司了。
——继续回到这个假设。
产品解决了用户的需求，还得让自己活下去，这就是商业需求。
作为中介平台，帮助小明追回债务，让打手赚到了钱，自然是要收取手续费了。
在这之后，向打手推荐专业的培训服务、通过大数据定位目标位置、分析目标用户画像等等面向打手的增值服务，也是需要思考的。
一个产品可实现的商业模式还得视产品形态而定，有些产品想要商业化颇有难度，工具类产品如何变现自古以来就是个痛点，行业内有两个典型的例子——墨迹天气和美图。
天气似乎一项高频且刚性的需求。
据去年招股书显示：
而美图，虽然一直都在亏损状态，但整体一直处于上升期，财报显示：
美图公司2016年总收益15.786亿人民币，同比增长112.8%，2017年1月美图月活总数约5.2亿，同比增长约32%。
虽然美图致力于硬件制造，但这其中的差距也有很大一部分来自软件产品本身。
关于两家公司的比对，网络上不乏出色的文章讲解，各位观众老爷可以自行搜索。
强忍着掏出原型设计工具的冲动，冷静的分析一波需求，这时候你会发现：一开始接到这个提案所迸发出的那些“灵感”，似乎有些那么不成熟。
这个阶段的产出物已经有了UML用例图和简单的流程图（当然竞品分析报告还是得留档）。如果高阶职级需求，MRD和BRD也在这个时候输出了，讲述产品潜力和价值，为你的产品争取更多资源。
而在这个阶段，该确定的需求已经确定了，没确定的需求被搁置，到最后估计就这么不了了之。是时候大干一场了。
少年，亮兵器吧！
需求输出
3.1 业务流程
承接上文所讲的业务逻辑，这里复述一次：用户用例简述了参与业务的角色，以及发生这些业务的场景，接下来就要细化各个业务的流程了。
关于流程图工具的话，win用Visio，mac用Omnigraffle，也可以用在线的Processon等等——什么用着顺手用什么，也有见过有的产品岗的同学用Axure之类的原型设计工具。
举个例子，还是滴滴打人。
以核心功能的流程展开。
用户填写需求表单，表单内容包含目标的相关信息，比如常驻地址、身高体重、衣着相貌等，设定任务到期时间，并在提交表单后支付费用，订单生成后投放到订单池中，打手可看到订单池中的订单，并进行竞标，用户可查看打手的历史战绩和自我介绍。
关于费用，在早期可设置固定的活动价；但在产品运作了一段时间后，可把支付动作放到挑选竞标打手时，打手可以按照需求情况定期望价格，用户也可以挑选性价比高的打手，保障双方的利益。
由于需求性质特殊，打手有可能无法顺利地执行任务，此时打手可以选择放弃任务，并说明原因，订单状态变更为关闭，用户可以选择重新发布此项任务。
如果打手按时完成了任务，此时需要提交相关证明，用户在确认后，解冻资金打入打手账户，同时可以评价该打手。
如果由于需求没有说明清楚，打手没有按照要求完成任务，则订单进入特殊流程，售后介入，调查实情，并调节纠纷。
其间发生的多种情况，都应当考虑到：早期实施MVP时部分发生特殊的问题，可以通过线下处理来解决，等到流程规范时可排期设计加入到产品功能当中。
在这之前的工作流程中，主要参与的人员有商务、运营、用研还有产品，在下述流程中，交互设计师、视觉设计师还有开发和测试都会加入。
可能有的同学会觉得，这个时期技术人员加入会不会早了些？因为还没涉及实际的开发。
但实际情况是：技术人员加入后，可以协同进行一些业务功能上初步的思考。
部分功能可能会因为开发难度较大，需要一些研究时间或者短时间内根本难以实现，这时候可以及早的驳回需求，避免在后续开发过程中补救，产品结构改动过大。
3.2 信息架构
一般来说，一个正常规模的产品，光靠一个页面是解决不了用户需求的；如果MVP版本的产品确实功能比较单一，也应该考虑日后迭代的功能增加，使得MVP可塑。
这时候就需要梳理信息在整个产品中的分布。
那么，信息架构设计到底该怎么做？
《用户体验要素》中，给出了信息架构分类的方法：自上而下或自下而上。
自上而下
从产品的战略目标出发，按照满足目标的功能出发，按照分析出的细化需求分级，一层一层地将每个模块拆解。
本文讲述的工作流程比较适用这种方法实施的。
这种思考方式有明显的优点：产品从整体到落地，都不会脱离最初的目标，而拘泥于细节。
自下而上
此类方法关注的是具体的功能点，使用此类方法将会需要小组头脑风暴来思考功能点，并整合归类，组建功能模块。
产出的产品更加细腻，但可能会失去产品的根本目标，导致产品定位不准确，功能杂糅琐碎。
有一点要注意的是：在输出思维导图时要清晰干练，不要把所有功能点都罗列出来，不然就失去了思维导图的意义。
下面这张图是在早期研究网易LOFTER时绘制的一张信息架构图，作为反面例子；如果一个产品的架构较大，可以按照功能板块逐个分析。
3.3 交互设计
关于交互设计，在产品设计中从信息架构的布局开始，就包含了交互设计，比如在电商类目导航设计时，同类的或可相互搭配的商品会分为一类，这样分类更符合用户的预期。
企业实际招聘时，会要求产品岗能力范围包含了改善用户体验并做出有效的交互设计。
产品设计早期，要保障产品基本的可用性。
大致包含了一下几方面：
高效：帮助用户高效的完成没目标任务，减少流程中的步骤。
有效：用户需要完成的任务对于用户是有帮助的。
易用：减少认知和使用成本，使产品好用好记。
容错：允许用户犯错，并设计相对应的补救措施。
交互设计大师尼尔森层发布过「十大可用性原则」，比笔者分析的更具体，观众老爷可自行搜索查阅。
相关书籍推荐《About Face4交互设计精髓》，该书讲解了多种产品形态的交互设计，涵盖范围非常广，几乎适用全场景，可作为工具书使用。
这个阶段最重要的就是产品需求文档的撰写和原型的设计，在敏捷开发中，大多数产品岗同学都会选择原型图+标注的形式来输出。
但对于要和甲方或者老板的沟通的时候，可能会设计一个高保真原型，和产品需求文档分离开。
无论哪种方式，看具体工作情况来选择，最理想的状态还是文档和原型一起设计，如下图概览和客户端模块：
产品落地
4.1 项目管理
一般互联网公司的项目负责人会身兼数职，产品经理兼项目经理，技术负责人兼项目经理，或者干脆是老板。
如果产品岗没有实权也应该把握项目进度的节奏，在前期产品规划中，考虑到项目实施的难度，量化项目进度，也就是大多数产品经理会说的“节奏感”。
首先会有一个明确的运营目标，要在一个阶段内达到什么样的一个指标；这点决定了产品早期的功能是有限的，早期项目盈利状况可预计但不可见，项目配备人员也有限，尤其是开发人员，要把握好产品迭代的节奏。
前文说道：在早期运营、商务、市场人员已经介入到项目需求分析中来在，这时候他们可能会提一些对于产品未来的运营方针，要求在早期版本的加入更多可盈利的功能需求——这可能会因为一些利益问题导致团队内部矛盾，下面团队协作和需求管理会讲到。
还有一点要注意的是，关于项目延期，有些时候可能不是执行团队内部的问题，也可能是决策者规划的失误，所以不要乱扣锅子，扰了士气。
图片来自网络
4.2 团队协作
一个项目能否成功，和团队协作有着密切的关系。大家从五湖四海而来，为了一个目标奋斗，总归是斗志满满的。
但身而为人，都是有缺陷的——不光是来自职业技能上的，还有性格这类相对隐性的属性。
作为产品经理，应该好好了解团队成员的履历，擅长做什么，不擅长做什么，性格怎么样，这点很重要。
从工作流程上来讲，产品岗的工作处在开发、设计还有运营的上游，前期没有过多思考导致需求总是变更，而且是本可以避免的的需求变更，会消耗同事们的斗志——尤其是开发老哥们，半夜被叫起来改BUG本身就疲惫了，第二天来上班还被告知需求变更，之前的努力都白费了，这种心情观众老爷应该也会理解。
运营为了完成KPI，可能会提出一些需求；比如一个复杂的社会化分享功能，导致产品定位模糊。
这时候需要好好沟通，如果可行在版本迭代式加入验证想法；如果不可行，也不要当面回绝，可以和运营同事一起思考找出替代的方法。
产品经理的同理心不光要用在产品受众身上，还要用在你同事身上。
世事洞明皆学问，人情练达即文章。
这点，没法分享具体的经验。
不到万不得已，别怼。
4.3 需求管理
需求管理直接影响到项目的排期计划，多数执行型产品经理没有话语权，经常会被需求牵着走，导致自己工作很累，还经常背黑锅。
这时候就要好好管理需求，这和前文团队协作也分不开，拿到需求的时候先分析，从以下几点思考：
用户体验：在产品早期，这类需求基本会被无视，只保障基本的可用性。
技术难度：现阶段技术支持直接影响一个需求能否做。
商业价值：对于C端产品而言，这点会和用户需求冲突，典型的问题就是广告。
ROI：即投入产出比，需要估计项目投入成本以及能带来的价值
然后根据这几点来排列需求优先级——需求评估说到底就是价值评估。
有很多突发的情况就是：老板一拍脑袋想出了一个好点子；这种时候，私下里找老板沟通，问清该需求的来源；如果老板执意要做，那就按照老板的想法来吧（逃）。
需求管理需要纳入需求池，一些被搁置的需求如果不做好记录，可能会被遗忘。
下面图表为业内比较通用的需求池模板：
在主动采集需求的时候，做好需求来源的记录，分析具体情况，深挖背后的需求。
在被动接收需求的时候，也尽量让需求提出者描述需求；可能需求提出者在填写表格的时候，思考清楚了这个需求有没有存在的必要，这个方法能节约产品经理分析垃圾需求的时间。
4.4 用例测试
把测试环节单独拿出来讲，是因为产品经理在写产品需求文档的时候可能考虑不到很多细节，或者一些特殊场景——一般思考的是单元用例，而集成测试时会发生很多突发问题；比如一些删除操作引发的关联变动。
测试人员作为专业挑毛病的人则会思考的更缜密，技术出身的测试人员逻辑思维也要强于一般产品经理。
早发现，早治疗，趁着产品开没进入开发环节，赶紧补充细节需求。
比如，一般运营后台或者B端产品，会有系统使用者权限管理，日常使用中总会出现各种情况，总有一些是产品经理遗漏的——这时候就要泡杯咖啡，虚心请教下测试同学。
下列图片例举了部分特殊情况，没有提供解决方案。
经过了一轮轮的任务对接，改完了一堆bug，也美化产品UI，验收了产品，终于到发布产品这令人激动的时刻了。
但在正式发布前，还有准备工作要做。
发布上线
5.1 灰度发布
灰度发布常用于验证产品是否符合用户心理预期，观察市场对产品的接受程度，只向少部分目标用户发布产品，并根据反馈在短时间内做出快速调整——游戏行业的公测就是典型的灰度发布，是一种常规化的流程。
有些时候部分不能确定的功能会选择在这个时候做AB测试，甚至是ABCDE的测试——一些空白市场的创业者常使用这种方式，用MVP低调地验证商业可行性。
还有一点就是：产品在开发环境和测试环境经过了多轮测试，也不可能保证产品完全没有BUG。
灰度发布在某种意义上，是用线上环境做测试。
5.2 使用说明
B端产品在产品上线前需要需要对商务、销售、运营和客服进行集中培训，光靠PPT讲解和产品演示还不够，需要撰写用户使用说明书；不光是内部人员要了解，还要让目标用户理解产品的操作。
一些面向农业等目标用户受教育水平低的SaaS产品，则会在产品设计时最大化产品的易用性，使得用户能够快速上手产品。
而对于C端产品，撰写的用户说明手册则不会是面向用户的，需要用户查看使用说明书来使用的C端产品基本就可以宣判死刑了。
如果产品一些功能是创新的，史无前例或者有一定的使用成本，一般都会选择加入引导流程，来引导用户使用。
移动端产品则可以在开屏页加入新特性说明或者功能说明。
图片来自网络
5.3 运营策略
互利网发展了数年，产品运营的方法论层出不穷，AARRR模型的运营方法论在业内比较受认同，这里着重介绍。
AARRR模型为：
获取（Acquisition）
激活（Activation）
留存（Retention）
收入（Revenue）
传播（Referral）
的首字母缩写。
获取用户（Acquisition）
运营一款移动应用的第一步，毫无疑问是获取用户，也就是大家通常所说的推广。
如果没有用户，就谈不上运营。
提高活跃度（Activation）
很多用户可能是通过终端预置（刷机）、广告等不同的渠道进入应用的，这些用户是被动地进入应用的。
如何把他们转化为活跃用户，是运营者面临的第一个问题。
当然，这里面一个重要的因素是：推广渠道的质量。
差的推广渠道带来的是大量的一次性用户，也就是那种启动一次，但是再也不会使用的那种用户——严格意义上说，这种不能算是真正的用户。
好的推广渠道往往是有针对性地圈定了目标人群，他们带来的用户和应用设计时设定的目标人群有很大吻合度，这样的用户通常比较容易成为活跃用户。
另外，挑选推广渠道的时候一定要先分析自己应用的特性（例如是否小众应用）以及目标人群。对别人来说是个好的推广渠道，对你却不一定合适。
另一个重要的因素是：产品本身是否能在最初使用的几十秒钟内抓住用户——再有内涵的应用，如果给人的第一印象不好，也会“相亲”失败，成为“嫁不出去的老大难”。
此外，还有些应用会通过体验良好的新手教程来吸引新用户，这在游戏行业尤其突出。
提高留存率（Retention）
有些应用在解决了活跃度的问题以后，又发现了另一个问题：“用户来得快、走得也快”。
有时候我们也说是：这款应用没有用户粘性。
我们都知道：保留一个老客户的成本要远远低于获取一个新客户的成本。所以狗熊掰玉米（拿一个、丢一个）的情况是应用运营的大忌。
但是很多应用确实并不清楚用户是在什么时间流失的，于是一方面他们不断地开拓新用户，另一方面又不断地有大量用户流失。
解决这个问题，首先需要通过日留存率、周留存率、月留存率等指标监控应用的用户流失情况，并采取相应的手段在用户流失之前，激励这些用户继续使用应用。
留存率跟应用的类型也有很大关系。
通常来说，工具类应用的首月留存率可能普遍比游戏类的首月流存率要高。
获取收入（Revenue）
获取收入其实是应用运营最核心的一块。
极少有人开发一款应用只是纯粹出于兴趣，绝大多数开发者最关心的就是收入——即使是免费应用，也应该有其盈利的模式。
收入有很多种来源，主要的有三种：付费应用、应用内付费、以及广告。
付费应用在国内的接受程度很低，包括Google Play Store在中国也只推免费应用。在国内，广告是大部分开发者的收入来源，而应用内付费目前在游戏行业应用比较多。
无论是以上哪一种，收入都直接或间接来自用户。
所以，前面所提的提高活跃度、提高留存率，对获取收入来说，是必需的基础。
用户基数大了，收入才有可能上量。
自传播（Refer）
以前的运营模型到第四个层次就结束了，但是社交网络的兴起，使得运营增加了一个方面，就是基于社交网络的病毒式传播，这已经成为获取用户的一个新途径。
这个方式的成本很低，而且效果有可能非常好；唯一的前提是：产品自身要足够好，有很好的口碑。
从自传播到再次获取新用户，应用运营形成了一个螺旋式上升的轨道。
而那些优秀的应用就很好地利用了这个轨道，不断扩大自己的用户群体。
通过上述这个AARRR模型，我们看到获取用户（推广）只是整个应用运营中的第一步，好戏都还在后头。
如果只看推广，不重视运管中的其它几个层次，任由用户自生自灭，那么应用的前景必定是暗淡的。
不同产品每个环节需要做的工作差别很大，本文主要讲述产品岗工作流，关于运营相关工作不详细展开。
反馈分析
6.1 用户反馈
用户反馈是采集用户需求的重要来源，一般直面用户的是运营和客服，这类二手需求在解读时需要考虑具体情况，这时候上文提及的需求采集表就发挥了大作用。
然鹅日常工作中，运营和客服都不愿意写这么繁复的表格，每天需要解决这么多用户的各种问题已经很心累，还要加上额外的需求采集的工作，可能会造成情绪问题——如果发生这种情况，可以适当的调整信息采集的内容格式。
作为产品设计者，产品经理应不定期的轮岗到用户运营或客服，如果公司业务是做B端产品的，那应该和BD去拜访客户，了解最真实的需求——这种一手的需求会给产品经理培养同理心带来很大的帮助，也防止在需求转述的过程中造成偏差，影响产品设计。
对于运营策略，笔者没有做过具体的运营执行，没有建设性意义的建议帮助各位观众老爷。
搭建运营支撑系统的数据分析模块可以参照几款大厂的数据统计系统，Google Analytics、Mixpanel、腾讯分析、百度统计、GrowingIO等。
笔者会在后续文章中详细描述如何在数据BI系统中减少开发成本，提高运营参与度。
说在后面
到这里全文就结束了，复盘了从业这几年的经验，抽时间写了这篇心得。
笔者才学疏浅，若观众老爷有什么高见，还请猛烈拍砖。
双击666，订阅走一波~
我们下次再见。
———— / END / ————