从产品经理“甩锅”来看外包项目的开拓流程

“背锅”这个词，对付产品经理并不陌生，身为产品，每天都要背不同的锅。
乃至有些人还会找一些不明不白的锅飞过来，如项目中的收款账号不对，代码涌现bug等等问题，彷佛项目中碰着什么问题，只要甩锅给产品经理就对了。

产品经理能否不背锅，答案彷佛是否定，由于产品经理对产品卖力，产品出了问题都要找产品，这句话听起来彷佛并没有错。

产品经理能不能甩锅，答案彷佛是肯定的，产品经理事情性子决定着须要大量的资源，并且须要各个资源之间的协同，须要各个资源之间的利益平衡。
任何资源之间涌现问题，都会导致项目不能正常进行。
理论上知道找到会涌现问题点，就能甩掉一些锅。

如何找到这些点，或者说如何避免这些坑？最好的办理方案便是流程。
在关键的点确认某件事情，而确认的结果，是开启下一个进程的条件。

流程的是否通畅康健，决定着产品的成败，也直接关系到产品经理的事情成果。
产品经理是流程成是直接管益者。
一个康健的流程实际上是对产品经理最好的保护。
如果一家公司完备没有流程。
那么产品经理须要做的是，建立流程或者离开。

本日聊聊如何“甩锅”给业务，及项目前期的流程。
这里有一个限定，我说的统统都是环绕着外包项目进行的。

抱歉本人只做过外包项目，而且还不担保是否专业。
本文目的在于抛砖引玉，希望听到不同的声音和批评的见地。

一、确认产品形态和业务逻辑，确认我们要“做什么”

在项目立项之初，或者在产品立项之前，产品经理首先要明确项目的产品形态。
什么样的产品形态能够帮助客户办理现有的问题。
这样在需求获取之初就可以确定下来。
有很多项目一开始是做微信"大众年夜众号，结果做着做着，就做成了APP。

确认产品形态可以通过多个维度，如客户须要办理的问题，客户对付产品有无长期的方案等等，但是这些都不是最主要的，最主要的是客户的为这个项目的投入和我们须要开拓的本钱。
这也是确认产品形态的目的之一。
毕竟外包公司是要通过项目来赢利的。

其次便是业务逻辑，无论是官网还是繁杂的业务系统，贯穿全体系统的都是业务逻辑。
通过业务逻辑的梳理，产品经理可以方案出产品的整体框架，模块，乃至产品有哪些页面都可以“推演”出来，可以说业务逻辑确定了，也就确认了全体项目的框架。
确认了想项目的大方向。

如果业务逻辑错了，系统的框架、模块也就错了，那么功能需求理解的再透彻、原型画的再好，UI再完美，这个产品也是失落败的。
并且项目会有推翻重做的可能，不仅工期要比预期延长一倍，本钱也要增加一倍。

产品形态和业务逻辑承载体是BRD或者流程图，或者二者想结合，这个要看项目。

BRD的浸染在于证明我们的思路是和客户的思路同频的，包括项目的目的、帮助客户办理的问题，项目受众群体等。
只管这些是客户在做之前就已经想清楚的，但是还是要有一份BRD作为确认。
尤其在官网，H5等项目时，这份文档可以为设计供应设计灵感及范围。

业务流程图的浸染在于描述繁芜的业务流程时，直不雅观的显示项目全体流程。
这个时候的业务流程不要过于繁芜，只要解释用户从哪进，到哪出，设计到哪些模块，每个模块如何连接即可。
这份文档可以原型设计和开拓文档供应依据。

接下来便是沟通讲解，无论是会议也好，还是线上沟通也好，这个业务的逻辑究竟如何，业务职员是须要知道的。

这里须要解释的是，如果须要客户确认，不建议业务直接将业务流程转发给客户，客户自己研究，而是根据自己的理解去和客户讲清楚，至于能否将清楚，那就要看产品经理的理解能和业务的表达能力了。

二、确认原型，确认我们要“怎么做”

在赞许了产品形态、业务逻辑之后，产品经理进入了最喜好的原型阶段。

之以是确认原型，是奉告客户我们“怎么做”，从功能点，页面的逻辑，页面的设计构造，用户的进入项目，走出项目的动线，用户都会通过原型有所知晓。

制作产品原型，每个产品经理有都有不同的标准。
不过我问过很多开拓产品原型在他们心中地位，开拓回答是，我们只看设计图。

原型究竟要做到什么程度，还是要看项目，有些官网的项目，功能便是为了展示，只要把各个连接点在原型上提现出来就好，页面上包含的笔墨也要和业务确认好就可以了。
乃至有些官网都不会用到原型，只是一个文档就可以办理问题。

但是项目如果是一套系统，那就须要将原型做细一些了，这里说的细并不是说在设计上，而是要考虑的全面一些，各个分支，各个非常情形都要考虑进去，并给与办理方案。
不然在需求评审时，几个问题下来，就会变得灰头土脸。

对付产品原型，实在我没有太多发言权，和我互助过的UI开拓都埋怨我说原型做的不太细，很多字段都是很模糊的。
在这里自我反省一下。

除了原型，还有一份MRD文档，这份文档在外包的项目中，最大的浸染便是用作条约附件，以是用词一定一定一定要准确，只管即便避免“等”这样模糊的字眼，比如说，导航栏包括产品先容、公司先容、新闻媒体等。
如果按照这样写，那么导航栏会包含很多内容。
开拓会为这个坑一直的加班，同时也会一直的骂产品。

在这里我有个建议，业务和客户在确认原型的时候，最好产品经理也在场，这样在碰着关于产品方面的问题是，产品也好解答，毕竟产品原型不是业务设计的。

在业务职员确认了原型之后，产品经理就可以组织开拓职员进行数据库，运营后台的开拓，这须要确认的东西，我会在后面和大家谈论。
UI的设计是产品经理须要和业务职员确认的第三个点。

三、确定UI设计，确认项目“什么样子”

一样平常来说，在外包的开拓过程中，第一次提交设计方案，多是项目的首页，或者是项目的紧张页面，这样的好处在于，客户既能想到产品未来的样子，也能节省设计的韶光。
待首页确认后，再陆续供应其他页面。

客户在拿到UI之后，基本上都会有一些修正。
毕竟大家考虑的角度会不一样，客户更多的是站在自己业务层面上思考这些设计图，而UI设计师则是站在美学的角度来进行设计。
这就造成了很多冲突。
有的设计师设计的很好看，但是客户却说无法突出自己的品牌或者自己的产品。
不过一旦按照客户的哀求进行设计，难免会成为设计师设计生涯的“污点”。

在这里产品经理就该当从这几个方面进行折衷：

听取设计师从专业的角度来给出的见地，理解设计师为什么这么设计。
听取客户的建议，获取客户对设计的需求。
从这两点中找到平衡，与客户讲设计的理念，以及该理念对客户的好处。
与设计师沟通，奉告客户的痛点，让设计师在客户痛点和都雅度方面找到一个平衡。

大部分设计基本上会按照原型进行设计，有些会根据自己的想法改变原型的构造，但是原型的内容不会改变。
UI设计稿一定会比原型设计的要俊秀。
当然也有UI设计的还不如原型的线框图好看。
如果你作为产品经理拿到这样的UI，我的建议是，赶紧换人吧。

UI设计确认完了，业务方面算是搞定了吧，别急，你转头看看，一群开拓在虎视眈眈的看着你。

小结

上面说的确认、甩锅，实则是对产品经理的哀求。
产品经理要在开拓前供应这些东西交给业务职员。
无论是业务职员自己确认也好，还是交给客户确认，都是将项目方在一个框架内，这样在日后的开拓过程中，不会涌现太出格的需求。

开拓前须要确认的：

业务逻辑（也有可能是产品形态），确定我们做什么；原型文档，确定我们怎么做；UI设计，确定未来项目的“样子容貌”。

有了这些，就可以进行开拓了吗？

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

题图来自Unsplash，基于CC0协议