本文是如何从0到1搭建产品的上篇，全文较长，建议收藏后慢慢消化。

IT行业发展数年，其中出现了多种项目开发流程——瀑布式开发、迭代式开发、螺旋式开发、敏捷开发。将这些思想再细分下去还会有Scrum、XP、V模型等等。但很多时候，似乎在自家项目的开发流程中都能看到上述多种开发方式并存？

有这种情况自然是正常的，方法论只是指导工作的思想，上述的方法适用于某种特定场景下，举例瀑布式开发。
某度词条给瀑布式开发的定义：瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。但在现实工作中，一般会采用这种开发流程的基本只有传统IT行业或外包公司。然而，“不会再改需求”这句话是骗人的，你甲方粑粑终归是你粑粑。

逃敏捷类开发演变了那么多形态，也不是完全适用各种场景。整个互联网行业都小跑前进，而这些方法论的演变速度似乎已经跟不上了。对于这些方法论我的建议就是吸取部分适用于项目实际情况的，放弃那些看上去有用但实际上并没有什么软用的部分，不要做完完全全的“拿来主义”。

就像敏捷开发最核心的思想——拥抱变化。

项目流程

下面笔者将会总结一套可塑性比较强的工作流程。

整体流程

1、前期调研

1.1市场调研

闭门造车总归是不对的，在决定怎么做之前先搞清楚为什么要这么去做，如果你或者其它决策者觉得自己经验丰富，比较喜欢通过“拍脑袋”这种方式来决定一件事情，那笔者建议三思后行。关于市场调研，主要考察的是个大环境情况，在整个前期调研阶段多和市场和运营人员以及其它业务相关人员沟通(如果有的话)。

WHY TO DO > HOW TO DO

主要介绍两种分析法——PEST和SWOT。

（１）PEST

PEST 是一种宏观环境分析模型，所谓PEST，即 Political（政治）， Economic（经济）, Social（社会） and 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分析法则主要切入企业内部，分析自家企业内部状况，做到扬长避短。

（２）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、需求分析

2.1业务逻辑

在一个小团队或创业公司，需求可能直接来自老板或项目经理，这类需求都是二次需求，需要你在听取需求后思考背后的目的。就如本文开头所说一样，在决定怎么做之前先搞清楚为什么要这么去做，不然跟着一起遭罪的还有团队成员，需求总是改动对士气影响很大。

WHY TO DO > HOW TO DO

用户用例简述了参与业务的角色，以及发生这些业务的场景，接下来就要细化各个业务的流程了。C端产品的早期，业务逻辑梳理起来不会过于复杂，但用户的需求，需要不停地去揣摩和研究；而B端产品的需求则会很明确，产品所需要的功能都很清晰，其业务逻辑相对C端产品会来的复杂。一般创业团队在测试市场对产品的接受程度或者验证商业模式的时候，会设计开发一个MVP版本的产品投放市场，或者其它非产品化手段。

举例滴滴打人：

滴滴打人业务逻辑

滴滴打人app作为平台其核心功能就是连接打手和用户，收取中介费盈利。产品经理需要考虑这个订单需要提供哪些信息才能让打手找到目标，打手竞标的机制该怎么设计，什么样的情况打手才算完成任务，用户是先付款还是后付款。每个功能节点的业务需要细化，设计不同场景下的逻辑处理。

2.2商业&用户需求

这两点是大多数C端产品纠结的地方，权衡商业需求和用户需求。举个栗子，还是滴滴打人。

从需求源头上来分析，用户因为个人情感经济纠纷，或者别的情况需要“教育”下对方，因为自己身体素质不行或者没有时间，也可能因为找不到对方，所以需要求助专业人士来处理。这里的需求是接到提案时初步分析的，再用马斯洛需求金字塔来分析需求的层次。

这里假设用户小明因为小白欠债不还，决定使用滴滴打人来要回这笔钱。

从底层需求来开始讲，小白欠了小明钱不还，小明打电话催促了好多次但无果，于是很愤怒，智商瞬间为负数，决定报复对方，获得快感；但小明因为自己块头太小，琢磨下不是人高马大的小白的对手，处于保护自己，他决定思考别的方法；欠债还钱是社会基本规则，小白不还钱似乎显得自己很窝囊，好欺负；再往上走，对自我价值的实现，似乎解释不通了。

马斯洛需求金字塔

各位观众老爷看到这里一定觉得拿笔者拿滴滴打人作为例子显得很蠢，但现实生活中相关产业已经发展的不错了，甚至有的还能拿的上台面。头几年互联网金融中的P2P相较于传统的金融企业像银行和其它小额借贷机构，它的放贷要求的很宽松，比如你向某互金A公司借钱，A公司的业务员只要是你拿出其它同行的借贷证明就能放贷，如此不谨慎的风控机制造成了居高不下的坏账率，也催生了下游催债的行业的发展，某些讨债公司甚至已经挂牌新三板了，也算是“上市”公司了。

继续回到这个假设。

产品解决了用户的需求，还得让自己活下去，这就是商业需求。作为中介平台，帮助小明追回债务，让打手赚到了钱，自然是要收取手续费了。在这之后，向打手推荐专业的培训服务、通过大数据定位目标位置、分析目标用户画像等等面向打手的增值服务，也是需要思考的。一个产品可实现的商业模式还得视产品形态而定，有些产品想要商业化颇有难度，工具类产品如何变现自古以来就是个痛点，行业内有两个典型的例子——墨迹天气和美图。

天气似乎一项高频且刚性的需求，据去年招股书显示，墨迹天气坐拥4.7亿装机量和3000万+的日活，年营收还不到两亿，这净利润更是少得可怜。而美图，虽然一直都在亏损状态，但整体一直处于上升期，财报显示，美图公司2016年总收益15.786亿人民币，同比增长112.8%，2017年1月美图月活总数约5.2亿，同比增长约32%。虽然美图致力于硬件制造，但这其中的差距也有很大一部分来自软件产品本身。

关于两家公司的比对，网络上不乏出色的文章讲解，各位观众老爷可以自行搜索。

强忍着掏出原型设计工具的冲动，冷静的分析一波需求，这时候你会发现，一开始接到这个提案所迸发出的那些“灵感”，似乎有些那么不成熟。

上半篇文章到这里就结束了，下半篇将会讲述如何向团队输出需求，推动项目落地，以及如何应对一些小小的“突发情况”。

我们下次再见。

本文由 @ 水果篮子原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议