To G产品初体验及复盘

to G是从to B衍生出来的一种特殊划分，面向的企业为政府或相关事业单位，主要是根据每年政府投入的财政预算，然后去做的一系列信息化项目。本文从作者自身工作出发，结合具体项目实践中的所思所想，根据自己第一次所经历的to G项目，分享总结了自己的一些心得体会，仅供大家一起参考和学习。

一、to G 产品的定义

1. 行业现状

目前市面上对产品类型，如果按照用户群体划分，普遍按照to C、to B、to G这样几个大类来分的，国内目前互联网行业的产品经理也基本上分布在这几个领域中。

但在互联网这个圈子里，自带光环属性的还是做to C 产品的，毕竟这一块才是大神聚集的领域，以至于现在的产品人没做过to C产品都不好意思对外说自己是产品经理。

但现如今的互联网行业，头部效应越来越明显，非头部公司的生存空间越来越小，留给从业人员的坑位越来越少。

如今的to C的产品人员过度饱和，已经远远超过需求了。对于从业人员来说，to B 和to G 产品还是存在不少机会的，人才需求还是比较旺盛。

因此，也有不少产品经理在往这方面转型。

笔者从误打误撞进入产品经理这个坑开始，一直做的是to C产品，如今也是由于行业原因，开始接触一些to B和to G的产品，本文此次主要是针对最近做的一个to G产品做阐述和分析，算是对本次项目的一个复盘。

2. 什么是to G 产品

所谓to G，即面向ZF机构，使用这些产品的人员主要是任职的ZF相关工作人员。

至于to G产品的划分，其实并没有一个严格意义的定义。

比如也有些公司，直接把to G产品划为to B产品。此类产品的需求来源相对来说比较特殊，例如政策性业务需求、ZF领导指派的任务等。

二、项目介绍

1. 项目背景

此次接到的项目，主要是涉及农村产权交易方面的。主要目的是希望通过该平台的建设，以金融科技力量实现基层政府G端连接，协助ZF完善农村产权交易服务体系。

服务串联村集体、合作社、涉农企业、农户等B端C端涉农群体，有效解决农村产权交易过程中的信息壁垒和信用缺失，突破交易难、抵押难、融资难、融资贵的问题，从而激活农村生产要素市场，实现农业生产增效、农民生活增收、农村生态增值。

简单的说：就是通过该系统建立一个中间平台，把农村的的一些产权要素（如林权、土地经营权）盘活，实现线上的产权交易，与此同时提供对应融资服务。

对于没接触这类行业的人来说，要理解农村产权这些专业名词就比较困难了，要去理清里面的业务，更是难上加难。

本人之前做的一直是消费金融相关的产品，当接到这个项目时，说实话是有点懵的。毕竟之前从来没有接触过这类的产品，连农村产权交易是什么意思都不知道。

但对于一个产品经理来说，快速了解一个行业，快速学习业务的能力，是必备的技能。

现在都在说往“T”字型人才方向发展，其实对于产品经理来说也一样，也需要在行业知识方面往“T”型方向去发展，即既需要在某个行业的深度，也需要有接触和了解不同行业的广度。

尽管这个项目与我之前工作经历和接触的行业大相径庭，但是对于我来说也不失为一个学习的机会。

2. 项目介绍

如前文所述，这个产品的主要功能是用于建立一个中间平台，把农村的的一些产权要素（如林权、土地经营权）盘活，实现线上的产权交易。因此它的核心是创建产权项目，以及交易流程的管理。

系统使用对象是涉及农村产权交易的各级ZF机构（包括省、市、县、乡）工作人员。

系统核心功能主要有6个大的模块（如下图），主要用于发布资讯（如地方新闻、政策法规之类的）；产权交易项目的创建、审批和发布；以及竞价项目的管理。

三、项目存在的问题

其实这个项目在接手的时候，是已经有一个初版的产品。但仅仅是一堆功能的集合，无论是使用体验上，还是业务逻辑都存在许许多多的问题。

而我要做的:一是重新梳理业务逻辑，让系统的的功能划分更明确，逻辑更清晰，形成业务上的闭环；二是优化用户使用体验，使系统更简便易用。

接手项目后，梳理了一下当前系统的问题，发现问题远比自己想象的多，可以用千疮百孔来形容。

1. 业务逻辑问题

系统核心功能主要有6个大的模块，最核心的功能是项目线上发布、挂牌、竞价和交易（如下图）。但是通测下来，发现连主流程都没办法走通。

2. 6个功能模块分别也存在功能划分不清晰，权限划分不清晰，流程混乱

举一个简单的例子。项目列表展示，给每一个操作系统操作人员展示的都是一样的，即展示全量的信息。但从实际业务上来说，不同权限的操作人员是不需要看到所有信息的。

比如一个市级的操作人员，是不需要看到或者操作另外一个市的工作人员创建的项目的，同时也不应该有权限去对该项目进行增删改操作。

3. 用户体验的问题

原来的系统存在非常多的反人类设计，在实际体验中，有时会让人抓狂。

后来了解到，很多ZF项目，由于特（国）殊（情）的原因，需求提出者和实际使用者并不是同一批人，因此做出来的产品是不care使用者好不好用的，重要的是功能全不全，boss喜不喜欢。

这也是为什么，跟ZF相关的系统总是被吐槽难用。但对于习惯了做to C产品的人来说，真的是很难容忍这些反人类的设计的。

当你在竞争激烈，视用户为上帝的toC行业浸泡几年后，对用户体验的重视已经深入骨髓，就很难再回得去了。就像当你习惯了视网膜分辨率的手机屏幕后，再看那些普通屏幕的大果粒，会油然而生一种厌恶感。

四、我所做的一些优化

鉴于系统存在的种种问题，在和项目组负责人沟通后，我们决定重构系统，保留基础功能的基础上，对业务逻辑重新进行梳理，流程进行全面优化，以实现流程清晰，用户体验大幅提升。采取的措施主要有：

1. 合并同类项

原先的系统中，不同功能模块内的子功能有些是没有太多关联的，而属于一条主线的业务却又分散在不同的功能模块中。

这样导致的一个问题是，用户在进行业务操作是，需要在系统不同板块中切换，无法形成一个连贯的操作。

例如，报名、竞价、成交、退还保证金是一条业务线，那么放到系统中一个大的菜单中，就更清晰明了，而不是报名管理在一个菜单中，竞价又是在另外一个菜单中。

2. 简化操作

以业务审批流程为例，原来的系统，当提交一个审批任务进入审批流后，系统会提示操作成功。

但是实际上，这个任务仅仅是跑到了待办任务列表中去了，并没有进入审批流，而是需要再次到待办任务中，再点击一次提交，并且选择审批人，然后才算真正提交成功。

这是一个非常反人类的设计，并不符合操作习惯；同时也可能会导致流程中断后，忘记去待办任务列表中再次提交，从而导致没有进入审批。

类似这样的优化还有很多，篇幅有限，这里不一一介绍。

3. 业务逻辑优化

这个涉及比较多的业务上的内容。

例如：所有创建的项目（包括资讯、供应项目、需求项目、抵押登记项目）展示和查看均采用向下兼容模式，即登陆账号所展示和查看到的项目为所属行政区域及其下辖区域所发布的项目。

又如：不同项目的审批流程的驳回路径，会根据项目不同，分成一次驳回和逐级驳回。

五、一些待解决的问题

由于是整个系统重构，整个项目前期的需求编写其实花费了不少时间，并且由于to G产品的特殊性，对PRD和原型的要求会更加细致和规范，需要花费大量的时间消耗在文档编写上面。

仅这一个系统的文档，就写了将近10万字，写完不由得感叹比自己当初写研究生毕业论文还累。

同样，原型图也是要求高保真，光是给页面做交互就花了将近一周的时间。尽管前期工作已经结束，个人觉得还是存在一些问题并没有很好的解决，主要如下：

1. 无法接触一手需求

在对系统进行设计时，虽然对原系统做了比较大的改动，但是由于无法接触到一手的需求。

因此很多业务逻辑遵循了原有的设计，但个人认为还是有不少点存在模糊不清的地方，如果能和用户直接沟通，相信能对业务有更好的理解。

2. 由于种种原因，系统迟迟未能上线

因此，对于改造后的系统究竟是否贴合用户的需要，有哪些地方需要进一步的优化，是完全未知的——这与to C 产品”小步快跑，快速迭代”的理念差异是非常大的。

尽管做to G产品还是有许多不适应的地方，但是对于自己来说，经历了这个项目，也还是收获颇多。无论是从需求文档撰写规范性，还是开拓自己的视野，都有一定的帮助。

另外自己有还有一点小感悟就是，to G这一类的产品，对产品经理的项目管理能力也会有一定的要求。

由于整个系统的功能相对庞杂，因此与各干系人的沟通必须要非常充分，对工期进度的把控，后期测试的质量把控，均要比to C 产品耗费更多的精力。