G端产品的工作流程和B端、C端还是有一定得差异。比如正文作者分享的这种零散性需求，其流程和方法，都与大家认知的有很多不同。

在G端项目中，根据项目需求的大小、复杂度和涉及对象的不同，往往可以大致划分为几种不同的类型。

新项目：需重新搭建并规划产品

如政府部门的全新电子政务系统、大型企业的ERP（企业资源计划）系统建设等。这类项目通常是从零开始，需要进行全面的市场调研、需求分析、产品规划、系统设计、开发实施及后期运维等全链条工作，并伴随着长期的战略规划，其中的技术选型、架构设计、未来扩展性等都需要考虑长远。在系统的搭建上，可能需要跨部门、跨团队甚至跨公司的紧密合作，包括项目管理、产品设计、开发、测试、运维等多个环节。

针对政策的新模块需求或零散性需求，涉及不同公司负责的不同模块

如税务系统的年度更新、社保政策的调整导致的相关系统模块升级等。这类需求往往由政策变化或新政策出台引起，需要快速响应并调整现有系统，需求可能以模块化的形式出现，每个模块可能由不同的公司或团队负责，需要高效的接口对接和协同工作，且系统需要具备一定的灵活性，以便快速适应政策变化带来的需求调整。

针对后台或前端的零散需求或自用需求，只涉及自己公司的开发内容

如公司内部OA（办公自动化）系统的功能优化改进等。这类需求通常来源于公司内部用户或特定业务部门的直接需求，不涉及外部合作。往往要求快速响应和迭代，以满足业务发展的需要。可能更注重提升系统性能、优化用户界面使用效果等。

本文主要介绍第2种，针对新需求涉及到不同公司负责不同模块，其中第3种需求其实也包含在第2种需求中，属于最为简单的一类，此处我将会后续主要的流程及能力做个罗列，并且后续内容将围绕展开：

1. 需求了解
2. 需求前期边界沟通
3. 了解接口文档
4. 业务流程串联及原型输出

一、需求了解

通常，G端项目产品的模块新需求会有2种形式文件下达。

1. 政策文件及上级负责人（或者业主）的主需求信息
2. 具体的功能文档

但无论是哪种需求，本质都要求产品经理拥有快速高效理解文档的能力，此处针对不同的文档需求进一步讲述理解思路。

对于政策文件

• 宏观把握，明确背景：仔细阅读政策文件，理解政策出台的背景、目的和预期效果。这有助于把握整个项目的宏观方向，确保产品设计符合国家或地方的政策导向。
• 提炼关键信息：从政策文件中提炼出与本次产品模块更新直接相关的关键信息，如需要解决的问题、期望达到的目标、优先级等。这些信息将是后续需求分析和产品设计的核心依据。
• 沟通确认：与上级负责人或业主进行深入沟通，确保对政策文件的理解准确无误，并进一步明确他们的具体需求和期望。通过面对面的交流，可以捕捉到文字之外的意图和关注点。
• 需求分解与细化：将提炼出的关键信息进一步分解为具体的需求点，并考虑如何在产品中实现这些需求。这包括功能设计、界面布局、交互流程等多个方面。

特别要注意的点，阅读这件事也是需要一定积累的，想要快速读懂提炼有效信息，不要忘记日常的积累，也能够帮助快速理解自己所在的行业。

具体的功能文档

如果是明确的文档内容要求，几乎所有的功能需求，文档都有记录。所做重点就是全面阅读，理解框架，对关键的功能点、约束条件、技术要求等进行重点标注，同时梳理功能之间的逻辑关系。需要注意尝试从用户的角度出发，模拟使用场景，思考这些功能如何满足用户的需求和期望，并且从自己的角度出发，考虑是否有缺失情况，若有的话，可以及时和对方沟通或者做好内部反馈。

在理解功能需求的基础上，评估实现这些功能所需的技术难度和资源投入。同时，规划出合理的实现路径和时间表。

二、需求前期沟通边界

文档需求内容理解后，整理该需求所涉及的功能清单，为防止不同团队/企业之间的任务责任不清晰，事先进行需求沟通边界确认非常重要。

功能清单整理及内部梳理

在文档需求内容理解透彻后，产品经理整理出一份详尽的功能清单，清单包含所有需求点，以及每个需求点对应的功能描述、预期效果、优先级等信息。针对此清单组织内部会议（包括项目经理或熟悉技术的同事），对功能清单进行逐一讨论。重点分析每个功能的实现难度、技术可行性、资源需求等要点。同时，识别出哪些功能是其他公司负责的内容，哪些是需要自行开发的。

多方协作与边界确认

内部梳理完成后，产品经理应准备一份详细的沟通材料，包括功能清单、责任划分初步建议、可能的合作方式等。同时，邀请G端技术负责人共同参与其他公司技术人员的会议，再次确定彼此直接负责的事情，并处理会议过程中的疑议，对于难以达成一致的问题，可以记录下来，会后进一步研究和讨论，直至找到满意的解决方案。

为了确保合作过程中各方都能遵守既定的责任划分，明确记录各方负责的功能模块、时间节点、质量标准等关键信息，以便在后续工作中作为参考和依据。

在需求沟通前期多公司合作的项目中，确定不同公司负责的内容事项，此过程非常重要，整体沟通范围可由大到小直至实现，防止边界不清晰，导致后期实现效果有出入，彼此之间扯皮的情况发生。

三、了解接口文档

如医保系统中，公共服务部分与省份后台经办系统可能是不同公司承办的，每个公司可能只是负责某一个模块的设计。在彼此边界沟通清楚后，可能负责其他模块的对方公司会开始设计自己的接口文档，而我们所对接的模块又需要对方进行对齐，以免自己设计的原型最终实现上对方接口不支持，这样会导致后续反复修改的问题。

正因此就要求产品经理拥有阅读接口文档的能力，能够在已有的框架里，针对接口文档中的出参入参提炼出自己能获取的字段，进行串联业务流程和用户体验。

在接口文档查看之前，产品需要在前面的需求背景下，在不考虑接口文档文档的情况下进行设计字段排布构思，想好自己需要哪些字段进行展示，并通过对比接口文档的字段，取出需要展示接口字段。梳理设计思考，是因为有时候接口文档不一定符合我们的的设计需求，这时候可以提出质疑，要求对方补充。同样的，自己设计的时候，很有可能对这个业务其实理解不足够，这时候，接口可以用来查缺补漏。并针对已经梳理好的最终字段，串联流程后，产出原型。

对于接口的查看方式，可以关注以下几点：

1. 关注必填字段及出入参
2. 一般InDto为入参（具体可以询问开发，不同的开发或许有不同的命名方式），可以用来设计筛选，因此在原型设计的时候，要对比下自己设计的原型筛选字段接口是否能支持
3. 一般PutDto为出参（具体可以询问开发，不同的开发或许有不同的命名方式），可以用来设计页面展示字段，比如查询之后，出现哪些字段。

此处对于接口查看方式的描述较为简单，但是个人感觉基本简单的字段查看是足够的，如果想要深入了解，建议阅读一些更为专业的文档进行知识补充。

四、业务流程串联及原型输出

本质上，业务流程串联流能力，更多的是指对业务的理解能力，对需求中的业务理解透彻之后，就能把所需的页面字段之类的进行串联，将通过接口文档和需求文档得出的字段页面进行梳理，每个页面能能串起来，实现业务上的逻辑完整性。

在进行流程串联后，将所有的流程和字段进行梳理并绘制原型，原型绘制完成后，先行检查每个逻辑完整性，是否实现闭环，后续原型经由业主确认无误后，进行内部评审，此处业主的确认很重要，得到业主的认可，意味项目不会偏离主要需求，同时后续若有相关需要调整的内容，需要其他公司配合，也能从中得到周转协调。业主确认后，进行内部评审，评审完成后，算是进入排期开发阶段。

总结

原型输出评审后，还会有开发跟进，也许跟进过程中会面临不同的需求调整，需要及时的做好版本记录并及时更新原型，G端项目制的产品，如果只做项目的话，很多公司可能会开发直接绕过，直接自己修改字段，做好原型记录，做好验收，做到细节心中有，可以提升自己的产品专业度，遇到不懂的别人也会第一时间询问自己，不容易被当背景板，但是具体的产品定位和自己想做的产品目标，也是每个项目制产品值得去思考的。