在做G端产品和项目的时候，我们常常会遇到一些与其他领域不一样的问题。本文总结了G端项目产品设计的相关问题，希望对你有所帮助。

G端（Government）名称其实最初也是由B端演化而来的，相当于B端的分支，G端主要为政府或事业单位开发的产品或服务，因为服务的群体的一些特殊性，因而独立出来的一个名称。

先谈谈G端的相关服务范围和输出形式，服务范围。输出形式主要分三个模式：

1. 公共服务类，就是服务全国或某一地方民众的公共服务类，比如前几年疫情时大家使用的粤康码功能、大家使用的12306购票网站、还有面向深圳的APP：I深圳 等等；我在20年左右就做过面向广东的一个APP，叫粤商通，这是典型的公共服务类。
2. 内部服务类, 不对外服务的，主要服务政府或事业单位内部人员使用的系统，比如内部OA或办公类的系统，我在22年中广核内部服务过智慧工地的一个比较宠大的内部系统，这是属于内部服务系统。
3. 行业监管类，主要起到对各行业的监管效果，如对食品监管、金融监管…, 我在2021年时就做过对金融行业7+4机构的监管平台，这是面向金融行业的一个监管项目。

输出的具体形式包括政务APP、小程序、微信公众号、政务门户网站、管理后台、数据可视化大屏等。这些产品的设计需要考虑到政府和事业单位的特殊需求，所以基本是定制化需求，同时也需要兼顾用户体验和业务需求之间的平衡。

下面我将以问题形式描述G端产品的一些常见问题

一、G端产品需求从哪里来？

先说结果，需求主要从立项文档和客户口头会议（需求调研）。

这个需要注意，G端产品需求来源主要来自招标的需求文档，在文档里面有相关的描述，所以在设计产品之初，文档的内容是要覆盖到产品的设计中的，否则验收时可能会有麻烦。其次在设计前，一般需要和客户沟通即需求调研，一般会有关IT经验的人来和你对接，当然也可能会由线下业务部门对接（完全不懂IT知识的人），需求调研时最好提前写下相关的业务问题，当然最好带个笔记本，把业主的核心要点记下来，如果前期对业务不太熟悉，建议录音，不过录音时最好不要让对方知道。

二、需求调研时要注意哪些？

需求调研时，要提前发起会议邀请，因为需要预订好会议室，一般不同的需求需要邀请到不同业务部门的人员，罗列好参会人员，参会主题，参会时间，参会地点。

在会议之初，当你提了会议的主题时或方案后，你要先让客户发言，咨询下客户的观点或意见，最好给足面子。中间不要插话，更不要对客户说“你说的不对、你错了、你讲得没意思”，类似这样的话。在与客户需求沟通中，大概率会遇到一些问题，比如客户说的不一定对、不一定全、可能会漏，还有客户也不太清楚业务逻辑？针对这些问题，一般不懂G端业务的人可能比较棘手，我们能做的就是提出熟悉相关的业务知识，做后做记录、对客户讲的内容需要确认、有疑问有问题的最好二次再确认。在后期输出原型界面时再进一步明确可能更简单些。至于客户不太清楚业务逻辑，可以你对业务的认知大致提一些相关方案和需求，或者邀请相关懂的人来参会。实在不行该需求调研可延后。

需求调研会议最后，应该总结一下会议的结果，或发一封会议纪要的邮件，以免验收时客户反悔或“赖账”的情况。会议总结归纳要点要罗列清楚，不能客户说了半天，你没有采集里面的关系要素，

需求调研时大概率会出现讨论和需求不着边际的题外话，这时候你得分辨一下，如果讨论的话题不重要，你可以重新注入调研的需求的话题。但如果讨论的问题比较严重，这时候不建议把这个问题提出来，因为人家是甲方，有时候话还不能说的太直，这就是G端的憋屈和无赖。

三、G端产品如何做需求分析和设计？要考虑哪些因素？

需求来源取决于客户和文档上的描述，所以设计时不能遗漏。其他的方法论基本和B、C一样，比如按业务场景频率、痛点、目标用户，以及该需求涉及到的场景。

不过要注意的是，如果规划的功能比较多超出成本，还得简化一下，因为涉及到成本，包括业务如果太难开发也会和你计较。但有一种情况可以忽略，那就是超出成本的功能点在主流程中，那没办法简化。最后再按轻重缓急的顺序确定功能版本，功能点确定好最好列在一个表格或文档中。

如果设计的需求是一个相对新的业务领域，那可能考虑的东西比较多，因为刚刚提过在需求调研时客户说的内容可能会漏，所以在设计时要考虑全面，对业务知识要非常了解。

比如我在驻场国企建筑单位时，有一个安全隐患的需求模块，其实就是协助业主解决工地现场安全隐患需求，通过曝光现场各类承建方的一些施工问题，然后发起整改-再审批-再关闭，每月需要有各施工单位数据统计。当时我的大概思路，先梳理业务闭环流程，谁来发起隐患，谁来整改，整改时要考虑分支，比如没整改时如何处理，已整改时如何处理，延期整改如何处理（这些研发时需要着重考虑）。整改后是否需要通知相关人或领导，什么形式的通知，需要汇总哪些周期的数据报表，报表怎么设计领导一看就懂。操作流程怎么让大老粗操作。最后注意给领导看的内容一定要设计的美观和简约，有些甚至比功能实用更重要。

设计好后最好还需要和相关业务人员明确一下，因为有些内容是他们需要明确和取舍的，比如查看方式邮件还是PUSH，因为不同的方案成本不一样，给客户沟通时最好引导（最好先站在我们的利益上去引导），而不是把问题抛给客户：这个怎么处理？那个怎么处理？你问得多了别人觉得你不够专业。

四、G端产品走敏捷开发还是瀑布开发？

一般来讲是瀑布开发，当然也得看业务的紧急程度，有时候很急的内容需要敏捷开发上线。比如线上的一些重要的数据统计功能。还有包括新上线的设备终端，需要维护线下的一些重要工作。

五、G端产品上线前谁来验收？

内部首先还是产品的把关，确定没问题后再上线，上线后可能生产端没有账号，需要客户线上支持，一般是晚上上线后次日对应业务部门的客户进行验收，验收时主流程和实用方面没有太大问题可能会验收通过。当然可能会反馈一些优化上的问题。针对这些问题，如果不是文档上描述过，或重要领导提过，可以完全忽略。

六、G端功能上线后客户不认怎么办？

针对这些问题，其实碰到也是自然，但要分析背后的原因。发生这种情况有可能有其他原因，比如验收方和需求方不是同一人。因为G端经常会出现这种问题，业务方领导提需求，验收是他部门下的小员验收。

如果需求方和验收方是同一人，则要分析是沟通时和验收后反馈是否一样，如果不一样可能需要拿出你之前的笔记或会议纪要，因为有时候可能客户忘记了，或者后面为了掩饰自己的问题就做了一些需求变更，这是典型的赖账行为。