To 新手产品：若何担保快速上线v1.0同时避免无限改需求？

我有很多年轻的产品同事及朋友，每次和他们聊起来，都会和我抱怨，说自己的项目操持2个月，但是现在都远超两个月了还没上线，都怪那些业务、运营乃至老板一直改需求不断加需求。

但是从来没有谁和我说项目延期，需求不定的问题源自自身。
难道真的问题都在别人身上吗？实在不然，所有类似问题，紧张还是出在我们这些产品经理身上。
为什么呢？

我用倒推法来举证：

这张图是我归纳了所有与我有所互换的产品经理所遇问题往后总结出的。

我在每一个步骤的流程中都加了一句话。
这每一句话都代表一个看似平淡无奇，实则是相称致命的缺点行为，而这些“小细节”也正是导致全体项目延期的罪魁罪魁。

当然，也有朋友和我说：“我不去做需求评审，不做设计评审，不做XXX都是为了节约韶光加速工期，但谁知道那些业务方不靠谱，他们连自己要什么都不知道？一贯提需求改需求，导致我们开拓延期。
”

可是！

正是由于我们这些产品经理没有去做这些评审，才会导致业务方不清楚自己要什么！

为什么那么说呢？

如果业务很明确知道自己要什么，还要我们产品经理做啥？（开个玩笑）

首先，我们要明确业务是做什么的

无论项目是ToB还是ToC，业务职员，大多是处在第一线的职员，发卖、运营、市场等等，那他们有什么共性吗？有！
而且很明显！
他们的事情面对的都是用户，因此“人”为单位的。
而人的不愿定性特殊大，这就导致了业务方的事情大多都是凌乱无章的，再加上事情岗位问题或者事情习气问题，从而导致业务方在利用系统时碰着困难，常常不能及时做记录，末了导致业务方供应到产品的需求大多都是常见问题，而且是最近碰着什么就提什么，过段韶光碰着其余一些，然后又提一些。
从此循环反复，无穷无尽。
（这也是为什么总有产品同学说业务方都不知道自己要什么，我们只能随着他们说的改。
）

既然现在我们知道了为什么业务总会循环反复提一些“很有道理，且无法回嘴”的需求，那我们是否该当去做些什么，去堵住他们的嘴，不让他们如此肆意妄为？是的，而且很大略。

详细办法如下：去理解业务，而且要比业务还理解业务。

是不是以为说的很废话，很没必要？如果以为很废话，我赞许。
但是如果以为很没必要，那只能说：你错了！

理解业务，是产品经理迈出第一步的主要条件

有多主要呢？主要到决定了产品接下来的走向！
举个不太恰当的栗子，就犹如两条公共端点射线形成的夹角，哪怕起初角度只是一点点的偏差，但射线到了一定长度往后，差距会变得非常明显！

那该怎么做呢？实在也很大略，便是问问问，化身为十万个为什么！
千万不要以为不好意思问，不然等项目交付的时候，有你酡颜的时候。

现在知道要去问了，怎么问，这个方法也很主要。

我这里有四个步骤可以参考：

问前：去理解业务流程，即正常事情流。
理解他们业务从哪开始，到哪结束，以及中途经历的正常的流程。
（先不去考虑非常流程）提问：在理解事情流的条件下，针对性提出问题，问业务分别每一步都会碰着什么问题，且目前是如何处理的。
（一定要目前！
！
不要去管他们期望的办理方案）反问：在前两步都理解的条件下，提出自己的反问，可以针对现有的办理办法，可以针对他们提出的期望办法，也可以针对其他你想到的。
记住，一定要反问，一可以加强影象，二可以化被动为主动，避免业务提出过多无用需求。
（当然，业务提的所有需求都要记下，不要当场回嘴，节省韶光）根据以上三点，画出业务流程图，即正常的业务流+每个环节可能涌现的非常流，并附以业务方现有办理方案。

如果很完美做到这四步的同学还是被业务无情追着加需求，那么你可能还欠缺下面这一步。

需求整理及反馈

需求整理我想不须要多说，但是反馈这个行为，在我身边的年轻产品中很少有人做得到。
可能是对业务方太有信心，也可能是产品太含羞，总之便是需求只确认过一次。

实在大可不必去考虑太多，我们是产品经理，目的是做一款大家夸的产品。
现在为业务方做做事，便是希望得到他们的认同，而对他们来说，他们也很希望我们能做出一款他们用着顺心的产品，因此，他们是会竭力合营我们的事情，而不是找我们茬，故意给我们使绊子。
以是只管放心去做反馈吧，哪怕业务近期没韶光，也要等到他们有韶光，乃至让他们挤韶光。
比较起将来需求反复改的韶光摧残浪费蹂躏来说，这点韶光还是等得起的。
大不了这个项目不做了，缘故原由也是业务方不合营（轻松甩锅）。

需求反馈往后，肯定少不了一波补漏，这个时候，千万不要抱怨业务没有一次说清需求。
由于换成你，你也不一定一次记得全。

以是一定要把他们提的需求按照之前的四步再走一遍，但是有一个小条件，如果这次对接的需求与第一次总结后得出的业务流程图不符，一定要问清楚为什么不一样，详细以哪一次为主，而不是一味听取他们的建议，还是那句话，业务自己也很混乱。

这一次反馈后，得出的需求以及业务流程图，才是有参考代价的。

然后再根据整体业务走向去划分可能存在的系统模块，并用四象法则去判断需求紧急度及主要度。

有了模块，就有了系统的大致框架；有了需求，就有了功能，如何只需把功能添补到各个模块中即可。
当你将全体系统的大致框架搭出来，并将内部功能添补完时，你就会创造。
做个别系真的好大略。
不是吗？

现在有了一条清晰的业务流程，也有了一个明确的系统雏形，接下来是什么呢？当然肯定不是画原型图啦！
远远没到这一步呢！

接下来要做的是与业务的功能评审！
！
！

这时该当拉上业务卖力人，拉上一线业务代表，对你的模块划分，你的模块内拥有的功能进行评审，去理解是否短缺功能（即不做就影响业务正常流转的需求），是否有多余的不必要功能（大多是产品经理单方面以为很有必要的伪需求），当然如果此时业务方提出一些期望性需求，记录下来，但要和他们明确表示，这一期是不做的。

如果与业务方的需求评审没过，请连续上述过程。
当然，如果前期根本打得好，基本上不须要太久的调度就能搞定。

再然后该当怎么做呢？原型？别慌！
快了，但还没！
这时该当是再去找业务聊，不过这一次不须要开会，只须要当面确定一下之前的内容即可。

等需求都完备确定下来往后，我相信，如果你按照上面的步骤走过来，你心里已经知道自己要做什么东西了。
这时，该当是把你整理出来的功能都梳理一遍。
以业务流为核心，以模块为单位进行梳理。
等打好这些根本往后，再去画原型图才是最得当的。

但是！
！
！
到了原型图，就有朋友开始考虑什么用户体验，什么交互设计。
千万别！
！
牢记！
！

由于到末了你会光彩，还好一开始没有想那么多！
！
！

精确该当怎么做呢？画几张大略的图，附上该当包含的功能即可，最多最多也便是轻微排得好看点，显得态度比较端正的低保真，怎么交互怎么跳转都不须要画出来！
！

然后下一步，便是

拉上你项目组内的设计&开拓，来一波功能评审

在功能评审之前，你要知道一个条件，他们不是业务，但他们要理解业务，要让他们知道接下来要做什么，为什么而做。
大家是一个项目组的成员，有同一个目标，只不过是用各自不同的专业技能去互助，共同实现这个目标。

有了这个条件往后，你就知道，你不能对他们有任何遮盖，把自己知道的关于这个项目的业务内容完完备全见告大家，让大家一同参与到项目中。

那么问题来了，评审会上，除了产品经理，其他人完备不理解业务，如何让他们迅速理解业务呢？很大略，拿出你之前做好的项目流程图，随着流程图和他们逐一先容流程，并先容现在业务是怎么做的，我们该当怎么实现去为业务提高效率（或者其他），只有这样，大家才会站在一个角度去思考同一件事。
先容完业务往后，把你的系统架构拿出来，把你的功能列表拿出来，把你的原型图拿出来（实在整理在一起就差不多是PRD雏形了），让他们知道你是怎么去考虑的，让大家看看你考虑的是否完好，并鼓励大家群策群力。
去参考大家的建议，在会议上，把有争议的点记录下来，然后把没有争议的点进行分工，先一步安排下去，让后台开拓先开始搭架构、准备数据库等。
至于那些有争议的点，可以转头去问业务，确认往后回来与设计&开拓针对性的开一个小评审会，办理这些问题。
然后便是让设计去准备素材（竞品截图等）。

那接下来产品经理要做什么呢？这时候才是真正的原型图，中低保真+交互流程。
等产出交互流程图往后，第一韶光丢给开拓和设计，同时将PRD中一些不合理的地方进行修正，天生一份完全的PRD，发给组内所有成员，包括自己领导和业务方领导（管他看不看，只是一个反馈）

那到了这里，产品就要开始催设计催开拓了吗？并不是！

这时候产品经理该当拿着交互流程图屁颠屁颠去找业务方，去和他们领导，和他们的一线代表开个评审会，当然，这个会便是产品经理的个人演出秀了，和业务先容我们根据之前确定的业务流程，做出点交互流程，分别有哪些模块，模块有哪些功能等等。
如果业务以为没问题，那么恭喜，这个版本一贯到测试阶段以前你都会很顺利。
如果有问题怎么办？也不要紧，和他们谈，只要不是有悖于业务流程图的，都谈，至于一些业务的奇思妙想去不去实现，那已经是我们一句话的事情了！
当然，常日来说，为了知足业务的操作需求，产品们常日会答应做一些微调，但这些微调根本不会影响到后台的架构开拓和设计的设计规范，以是随他们去吧！
！

二次业务评审结束往后，第一韶光将反馈内容关照给项目组内所有成员，包括存在感特低的前端，和他们说我们改了哪里，哪里没改。
说实话，哪怕是大改也不要紧，项目初期这些坑还是能承受的。

再然后，产品经理该当怎么做呢？

完善文档，跟进设计，一定要让设计做2-3个风格的demo

为什么是demo而不是全部呢？由于怕挨刀子……（开个玩笑）由于要提高效率就要少做。
只须要把几个特定页面做出2-3种风格即可。
（风格自己把控）

等出图往后，纠集业务方领导、我方领导去挑风格，只有他们自己选的，才是他们喜好的。
（当然也可能都不符合他们哀求，那就重复该操作）。
等风格确定往后，再由设计去按照这个风格去全面设计，同时把UI图定期打包反馈至业务，当然，如果他们认为很满意不须要看，那另说。

等UI全部完成往后，考试测验做一套以UI图为根本的高保真交互稿，拿去与业务方领导及我方领导做确认，认为没问题，就全部丢给前&amp后台两组开拓。
别问为什么还要给后台开拓，他们写接口有用的。

再然后，产品须要做什么呢？闲着没事干啦？实在不然，这个时候才是真正产品展现实力的时候了。
要担保这个项目准期上线，不是说前面做的好就搞定了，还须要持续的项目管理。
毕竟不能虎头蛇尾。

项目管理是产品经理必须的技能，但也是很多年轻产品经理的短&amp硬伤。
没有学过干系知识的产品可能很难节制，但是我可以给大家提一个大略的方法，可以应急。
比如说，不理解工期如何去判断，那就去问干系职员，让他们自行给出工期，然后拿着工期去请教领导or履历比较足的其他同事是否合理。
当然，这种方法比较局限，就不细说了。

那如果实在弗成怎么办，可以跳过干系职员，直接请教项目组内的资历比较深的开拓，请他们指示一二。

项目管理这一块不建议自学，随意马虎给自己挖坑，还是多多请教有履历的大牛或者多看看人家写的文章吧！
！
可以参考这篇文章《在高等产品经理眼中，好的项目管理流程是若何的（上）》

项目管理只是一项把控项目进度，并担保项目在一定限度内不会延期的能力。
除此之外，很有可能导致项目延期的另一成分，那便是测试。
哪怕前期方案得再好，项目管理得再好，终极逃不过存在BUG得命运。

那如何能担保开拓在开拓过程中只管即便快地写出更多功能，而产生更少的BUG呢？

用我个人不专业的话来说，便是只要担保他们的开拓逻辑不要乱，基本上的BUG都是小BUG，无伤大雅且不会占用太多工期（分外情形不议），基本上是不会涌现致命性的BUG。
那如何做到担保开拓逻辑没问题呢？只须要担保开拓架构不要乱，只须要担保产品方案不乱，只须要担保需求方案清晰。
说到底，还是前期的铺垫很主要。
切忌不要前期为了所谓的“快”，而不去梳理逻辑，导致开拓末期，很多需求以补丁形式临时加上，末了涌现一点点问题，造成无法轻易修正或者直接大改，导致几个小BUG花费大量工期。

当一款产品经历过了创造需求 → 需求网络/整理 → 需求转化为功能 → 功能开拓完成 → 测试确保无误 → 上线的过程，才算是从0-1的过程。
也是产品经理真正迈出第一步的过程，接下来，道阻且长，但是做到事情不过便是这些循环，至于考虑一款产品往后的趋势，走向，只有等产品经理到了一定高度才会去考虑，在这篇文章中就不赘述了。

本文由 @RonT 原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自 Pexels，基于 CC0 协议