C端、B端、G端产品，虽然产品流程大体都是一致的，但还是有各自的行业差别。这篇文章，作者分享的G端产品流程，我们来看看和常见的C端相比，有哪些差异呢？

G端中往往是项目居多，产品偏少，能够打造一款普适性的产品非常难，因为各地的业务要求不同，客户偏好不同，导致G端很难像B端那样，开发一套系统，基本功能可以满足几十上百的企业，G端基本上都是定制化的内容。那在G端，一个好的产品是如何诞生的呢？

G端的产品一般都始于一个项目，项目建设好，可能会有不同的客户资源，同一场景下，客户70%的需求都是相似的，我们可以拿出具有普适性的内容建设成为产品内容，一个产品的诞生就是好项目的延续，我将G端产品建设简化为如下流程图：

一、需求调研

G端项目的开始往往都是商务（售前）跑好关系之后，产品经理直接去现场和客户面对面进行交流。一般在产品经理介入之前，公司领导会提前告知我们要建设什么系统，描述大体的方向和内容，有利于产品了解实际情况。客户觉得还可以的情况下，去现场进行初步需求调研，客户会找个会议室，有的客户可能给你倒杯茶，然后就开始描述他们对于系统建设内容的需求，或者实际工作中需要解决的问题。

作为产品需要详细记录需求调研的情况，回来之后整理形成会议纪要然后进行存档。

在需求调研阶段，有的客户可能会给你三四次的需求调研的机会，但是大部分客户基本上就是一到两次，需求的整体描述已经说明，很难再多次对接把握更多细节，因为G端客户的想法就是“做出来再说，现在提也提不出来什么细节”

二、原型设计

根据前面零散调研到的需求，我们就开始进行原型设计工作：

1. 定框架：原型设计之前，我们根据需求调研的结果，和公司领导对于这个产品的定位和想法，综合一下，整理出产品大概的框架图，把握产品的开发内容和建设规划，再根据建设框架梳理功能清单，可以不必特别详细，能够概括的罗列二级、三级的功能点即可，此时原型设计的准备工作已经完成。
2. 定细节：原型设计时，根据功能清单，规划好页面布局，可以开始细致的原型设计工作。（G端公司里面角色和权限很重要，与此配套的是一套能够兼容的后台管理系统，大点的公司会自己开发一套能够普遍适用G端业务的后台管理系统，小公司可能就采用开源的后台管理架构来满足需求，此处提这个是因为G端业务的后台管理往往是重要但是容易被忽视的地方）。我们想好页面采用的布局方式（可以结合百度、花瓣网、政务网站等内容），就可以开始进行原型设计
3. 画原型：一般一个星期左右，初版的原型就可以完成，如果没有强制要求高保真，可以设计低保真的原型。原型需要提供基本的功能菜单，页面跳转等内容和交互（不建议做的特别简单，可以没有好看的色彩，但是基础简单的交互建议绘制）
4. 定汇报：原型设计完成之后，可以拉上与你们对接的售前或者领导对一下，看看有没有什么建议和优化空间，如果领导觉得没有问题，就可以找客户进行第一轮原型汇报。在汇报过程中，此时产品有了大致的框架，客户的要求和灵感就会源源不断，原型中的细节可以不断的调整和完善，在一到两轮汇报之后，原型V1.0版本基本上可以定稿

三、评审开发

原型评审：原型评审之前，编写系统页面的设计逻辑，在原型中标注逻辑说明，准备需求说明文档，都准备完成后，拉上UI设计、测试、前端、后端、领导（看领导要不要参加）一起参与原型评审。原型评审过程中先讲解项目的背景，客户对象，整体的系统规划，以及详细讲解V1.0版本的开发功能和开发逻辑。评审中团队成员会提出很多关于需求的问题，要进行记录，如果有回答不上来的情况，会议结束思考后进行补充。如果原型评审没有通过，可以再组织第二次原型评审，直到评审完成

UI评审：原型评审通过之后，UI会开始进行设计，设计之前可以咨询一下客户的偏好风格，审美是各不相同的，很多我们认为流行的审美，在客户看来很可能就是不好看的，所以建议首页和登录页设计完成之后，给客户先看看，确定配色和风格是否合适，避免返工

开发技术评审：原型评审通过之后，开发要开始根据设计内容编写系统架构文档，确定开发逻辑，数据库建库，系统采用框架等内容

测试用例评审：测试根据功能点编写测试用例，说明测试前后逻辑、输出结果等内容

开发迭代：前三步准备工作都完成了，就可以开始迭代开发，G端系统普遍采用敏捷迭代的项目管理方式。产品经理将功能点拆分，确定开发人员和完成时间，有功能模块完成，就开始测试，重复评审开发的各个环节，直到V1.0版本完全开发完成

四、项目上线

系统V1.0开发完成，在项目现场进行上线，期间客户会提出很多需要优化的问题，根据实际开发难度和功能情况，按照排期稳定开发即可，后期系统稳定之后，客户提出的需求也会减少，直到系统建设完成，具体项目上线准备内容可以参考我之前发表的另一篇文章，“如何做好项目上线工作”

五、项目招投标

G端项目招投标视项目实际情况而定，但是普遍是开发过程中，有的甚至开发之后才会进行招投标，有的公司会要求产品经理编写投标文件，配合商务完成招投标工作。

产品迭代

项目上线完成，稳定运行半年一年，可能有的其他省份也需要这个样子的产品，我们依靠出色的系统和商务资源，拿到了其他省份的合同，这个时候我们可以开始考虑进行产品规划，产品规划分为以下三个部分

1. 产品迭代：不同省份需求肯定有差异，我们的工作就是从不同的差异中找到核心业务的相似点，并且把核心业务打造成为通用业务。我们需要从不同省份的需求中，寻找相似点，提炼出相同的需求，评估需求的可行性，最终决定是否成为产品功能。也可以放在项目中进行开发，开发完成后直接合并到主分支中，处理冲突代码即可
2. 项目迭代：项目需求很难完全一致，最能体现出来的可能是前端的视觉界面，所以特定场景下， 或者某些客户的特殊要求，直接在项目中进行开发即可，或者可以从主分支中拉项目分支进行开发
3. 分支管理：这个产品卖的好，有三四个不同地方的客户，与之对应的就是分支管理。主支就是我们的产品，分支就是其他省份的项目。将痛点需求一起在主支进行开发，一些特定的需求就根据项目情况放在各地的分支中进行开发。

最终经过3-4个项目的需求打磨出一个好的产品，在各省市有复用的空间，一个好的产品就此诞生。产品的出现是非常不容易的，G端项目事情多且杂，很多时候为了响应项目现场的情况，都是急匆匆地开发完成就部署到现场，回过头才仔细推敲需求，进行后续迭代，所以在日常工作中，处理好项目和产品之间的关系，分配好工作精力也是产品必须具备的能力