产品经理在工作中如何避免背锅？先做好这三方面：业务逻辑（也有可能是产品形态），确定我们做什么；原型文档，确定我们怎么做；UI设计，确定未来项目的“模样”。

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

产品经理能否不背锅，答案似乎是否定，因为产品经理对产品负责，产品出了问题都要找产品，这句话听起来似乎并没有错。

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

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

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

今天聊聊如何“甩锅”给业务，及项目前期的流程。这里有一个限制，我说的一切都是围绕着外包项目进行的。

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

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

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

确认产品形态可以通过多个维度，如客户需要解决的问题，客户对于产品有无长期的规划等等，但是这些都不是最重要的，最重要的是客户的为这个项目的投入和我们需要开发的成本。这也是确认产品形态的目的之一。毕竟外包公司是要通过项目来赚钱的。

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

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

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

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

业务流程图的作用在于描述复杂的业务流程时，直观的显示项目整个流程。这个时候的业务流程不要过于复杂，只要说明用户从哪进，到哪出，设计到哪些模块，每个模块如何连接即可。这份文档可以原型设计和开发文档提供依据。

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

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

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

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

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

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

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

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

对于产品原型，其实我没有太多发言权，和我合作过的UI开发都埋怨我说原型做的不太细，很多字段都是很模糊的。在这里自我检讨一下。

除了原型，还有一份MRD文档，这份文档在外包的项目中，最大的作用就是用作合同附件，所以用词一定一定一定要准确，尽量避免“等”这样模糊的字眼，比如说，导航栏包括产品介绍、公司介绍、新闻媒体等。如果按照这样写，那么导航栏会包含很多内容。开发会为这个坑不停的加班，同时也会不停的骂产品。

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

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

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

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

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

在这里产品经理就应该从这几个方面进行协调：

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

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

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

小结

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

开发前需要确认的：

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

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

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

题图来自Unsplash，基于CC0协议