产品研发外包，外包产品经理工作流程

BRD 的作用是证明我们的想法与您的想法一致：项目的目的、我们帮助您解决的问题以及项目的受众。这些都是客户在这样做之前已经考虑清楚的事情，但仍然需要BRD 来确认。特别是对于官网、H5等项目，本文档提供了设计灵感和设计范围。

业务流程图的目的是在解释复杂的业务流程时提供整个项目流程的可视化表示。此时的业务流程并不是很复杂，只要说明用户从哪里来、到哪里去、设计了哪些模块、每个模块如何连接就足够了。该文档可以为原型设计和开发文档提供基础。

接下来就是沟通和解释，但无论是会议还是线上沟通，业务人员都需要了解业务的逻辑。

这里需要说明的是，当需要客户验证时，不建议公司直接向客户沟通业务流程，客户可以自行调查，而这意味着你需要向客户明确，他们需要验证。由产品经理来明确，提高理解能力和业务表达能力。

2、检查原型并确认“怎么做” 在产品形态和业务逻辑达成一致后，产品经理进入原型设计的主要阶段。

我们之所以检查原型，是为了从功能方面到页面的逻辑、页面的设计结构、用户如何进入项目、用户如何移动，告诉客户“怎么做”。在项目之外，用户将通过原型了解一切。

每个产品经理在创建产品原型时都有不同的标准。然而，当我们在心里询问许多开发人员他们的原型的状态时，我们得到的答复是他们只看蓝图。

原型的完整性水平因项目而异。部分官网项目功能仅供展示。您所需要做的就是在原型上显示各种连接点。您还应该检查页面内的文本。商业。即使在官方网站上，您也可以仅通过文档来解决问题，而无需使用原型。

但是，如果项目是一个系统，就需要更详细地创建原型，而且这里的细节并不是指设计，而是更全面的考虑，每个部门、每个异常情况都必须考虑到。所有异常情况都应与解决方案一起考虑。不然在需求评审的时候问了一些问题你会很尴尬。

其实我对产品原型没有太多发言权，但是每一个和我一起工作过的UI 开发者都抱怨他们的原型不是很详细，而且在很多方面都非常模糊。我就是这么做的。在这里检查一下自己。

除了原型之外，还有一个MRD 文档。该文件在外包项目中的主要作用是作为合同的附件，因此措辞必须准确，避免含糊不清的语言，例如“请稍候”。导航栏目包括产品介绍、公司介绍、新闻媒体等。这样写的话，导航栏就会包含很多内容。开发人员不断加班来应对这个陷阱，并不断批评他们的产品。

这里建议一下：公司和客户评审原型时最好有产品经理在场，这样如果产品遇到什么问题，可以很容易从产品方面得到答案。是的。它不是由商业设计的。

业务人员确认原型后，产品经理组织开发人员开发数据库和运营后端。产品经理要和业务人员核对的第三点是UI设计。

3、确定UI设计，确认项目会是什么样子一般合约开发过程中提交的第一个设计方案就是项目主页或者项目主页面，有很多东西。这也节省了设计时间，因为客户可以思考他们未来的产品会是什么样子。一旦首页确定，我们将依次提供其他页面。

客户拿到UI后，基本上都会做一些改变。毕竟，每个人思考的角度不同，当客户从业务层面思考这些蓝图时，UI设计师从美学角度进行设计。这造成了很多冲突。有些设计师的设计很漂亮，但顾客却说他们无法推销自己的品牌或产品。然而，设计师一旦按照客户的意愿进行设计，就成为设计师设计生涯上的“污点”。

这里，产品经理需要从以下几个方面进行调整：

从设计师那里获取专业意见，了解他们为什么这样设计。我们倾听客户的建议并了解他们的设计需求。在这两点之间找到平衡，并与您的客户讨论设计理念以及它将如何使他们受益。通过与设计师沟通，让他们了解客户的痛点，设计师可以在客户的痛点和审美感之间找到平衡点。大多数设计基本上都是基于原型，但有时你可能会用自己的想法改变原型的结构，但原型的内容保持不变。 UI设计方案会比原型设计漂亮很多。当然，有些UI 设计看起来不如原型线框好。作为产品经理，如果你遇到这样的UI，我们建议尽快更换它。

UI设计已经定型，业务端也已经固化，不用担心，当你回头看的时候，开发者正在用心注视着你。

总结上述的确认和责任转移实际上是对产品经理的要求。产品经理在开发之前需要将这些东西提供给业务人员。无论是我们自己检查还是交给客户，我们都会将项目放到一个框架中，避免在以后的开发过程中出现任何异常的需求。

开发前需要检查的事项：

业务逻辑（也许是产品格式）决定做什么，原型文档决定如何做，UI 设计决定未来的项目“是什么样子”。现在准备好开发了吗？

本文最初发表在@okumacc 的《人人都是产品经理》上。它禁止未经授权的复制

标题图片由Unsplash 根据CC0 协议提供