G端产品设计-需求篇

番茄机长 2024-10-26 15:45:17

一、G端业务分类

目前G端数据化项目根据其服务内容和目标的不同，主要分为公共服务类、内部服务类、行业监管类这三种类型，主要在提高政府服务效率、优化内部管理流程以及加强行业监管等方面发挥着重要作用，以下是这三种分类的一些介绍和特点：

我目前接触的只有内部服务类和治理监管类的政府项目，都是从0-1开始，主要包括建筑行业、审计业务这两个行业。接下来我也是以这些项目经验为例子，讲解G端项目在需求调研、需求沟通、以及需求设计方面需要考虑和注意的一些事项。

二、需求来源与收集

一般对于B端项目的需求，一般可以通过市场分析和行业需求、客户反馈、竞品分析、销售和客服团队反馈、内部团队协作与反馈以及数据分析潜在的需求和改进点。

但是G端的项目比较特殊，就我目前接触的内部服务类和治理监管类这两种类型来说，基本都属于定制类开发，基本都是内部系统和固定群体使用，市面上没有竞品作为参考，他们的需求主要来自于客户需求调研以及政策文献，也有部分来自于内部老板的需求。

1. 来自客户的需求

针对G端项目，需求调研的对象主要分为三类：

A：核心领导类：比如，局里大领导。一般只关注驾驶舱内容和设计，他们对具体业务的操作过程不关注。一般只有节点性的对内对外汇报时会重点关注下。

关注的内容主要是，上一段时间的成果汇总统计，本阶段的一些成果展示，部分领导也会关注未来存在的一些隐患问题或者可提升方向。

B：业务领导类：比如，处/科室领导或者局里的分管领导。他们不仅会通过驾驶舱去实际关注自己分管处室/自己处室各种事项大概情况以及进度，也会在后台中处理（比如任务分配、审批）和自己相关的一些业务信息。

C：一般业务人员：比如，具体处/科室业务人员。他们才是真正关注这个系统是否符合实际业务操作，怎么用，哪些功能点不对，哪些功能应该用着不舒服。

这类客户他们其实是后台管理系统主要的需求调研对象，以及也是后续系统试用过程中，以及系统迭代更新的主要需求来源。

在针对G端项目用户需求调研的时候，这三类用户我们都要去做调研，可以结合每种对象的关注点去收集需求，我们和客户沟通获取需求的方式，可能是面对面或者线上沟通，可能是通过历史文件获取信息，也可能是通过具体的政策文献等方式，具体需要看每个业主的需求情况。

建议第一次正式需求沟通，以及后期整理后的需求汇报或者节点性的需求汇报，都能采取面对面交流。

比如：审计整改管理系统是市县两用的，系统核心业务流程主要是新建项目信息（科室/股室负责人或主审）→编制整改问题清单（主审）→利用模板起草告知函（主审）→告知函审核（主审、科长/股长、分管领导）→发送告知函、问题清单及审计报告等给被审单位（主审）→被审单位接收告知函、问题清单、审计报告等（被审单位整改联系人）→被审单位上传其落实审计整改责任主体的佐证资料（即研究如何落实审计查出问题整改措施的有关会议记录）→被审单位通过平台反馈整改情况及佐证资料（整改联系人）→审计机关（主审、科长/股长、分管领导）审核其反馈的整改信息资料，符合整改标准的进行销号操作。项目整改清单下所有问题销号，则该项目整改结束。

针对整体业务流程的需求调研，我们主要是根据审计服务中心领导对接，通过客户在讲解局里目前实际业务过程中，其实就已经把大致的需求逻辑理顺了，包括有哪些事项节点，每个节点是哪些角色人员去操作。

至于里面的一些细节信息，比如新建项目所需信息、整改问题所需信息、以及大概在什么业务阶段会进行到下一流程情况，都需要根据具体业务处室提供的一些脱敏文件（如历史项目计划表、项目台账、问题台账、历年汇报统计的问题数据需求等）基础上进行设计。

针对业务细节的设计，遇到业务不通畅，以及需求准确性的确认都是需要跟具体业务处室的业务人员代表沟通确定。

基于以上的需求调研，已经满足后台管理的需求设计了。至于驾驶舱的需求，主要是面向局领导的设计。

但是在系统没有出现，无法感受到真实信息，因此领导一般都会提出一些大概的要点展示，但是这些已经可以填充驾驶舱的版面模块信息了，至于里面放哪些数据哪些信息，还是要看整个系统中能够产生哪些数据，以及通过数据能够哪些可决策的，客户是一时半会是看不出来的；所以在这个项目中，驾驶舱的设计我们是根据领导提出的这几个要点，设计了审计项目情况、整改概况、审计文书、整改成效、审计移送情况、整改预警等。

至于每个模块的信息，我们根据系统数据情况，我们是先设计出一版，给到客户看了之后，客户就可以在这个版本基础上，提出自己的看法和建议，我们也可以针对性的修改设计。

2. 针对具体政策文件

一般在做政府项目中，具体的政策文件参考是少不了的，比如我刚接触审计业务的时候，需要做审计整改管理系统，当时我们是研读了《审计署8号令》《浙江省审计条例》，以及地方的一些审计办法，基于这些文件，我们基本上可以整理出整体的审计业务的流程，以及每个节点产出文件，至于具体细节要根据各地市各客户的需求定制。

不过在客户需求清晰、沟通积极性很高的情况下，政策文件不作为主要需求采集来源，更多的是提供行业的背景支持，能够帮助产品经理快速准确的理解客户表达含义。

但是针对一些非正式立项的或者其他情况下的政府项目，部分业主的需求沟通积极性不高，可能会存在问一句，答一句，不问，也不会答的情况下，我们就需要多去查找一些政策文件，作为参考，以辅助需求沟通和需求确认。

这种情况存在的原因可能是，业主不重视这个项目，也可能是具体对接人员，不了解全貌业务流程或者部分业务细节。一般遇到这种情况时，我们在需求调研的时候就需要积极主动去主导，尽量去推动客户去提供信息。

至少要在客户那边把系统的核心业务逻辑理清楚，弄清楚每个流程节点情况，如果无法通过客户理清楚，就需要参考当地政府发布的一些政策文件作为参考，然后自己梳理出具体的逻辑信息，然后反推客户，让客户确认已梳理逻辑是否正确，如果不正确，客户自己就会提出不合理的点。

就比如我之前负责的工地自助服务管理平台就属于这种情况，这个系统主要是建筑行业政府监管类型的项目，系统的核心业务为企业、项目、项目关键考勤人员三大审批业务，其中企业端主要提供自助申报服务，政府端主要提供审批以及管理服务。

当时这个项目，客户积极性很不高，领导层面基本上不主动推进项目，但是我们老板很主动，而且我们负责对接的住建部门基层的业务人员，无法对整体的业务逻辑准确表达，很多点都比较模糊，我们考虑到客户他们可能清楚业务，但是一时想不起来或者不知道怎样表达和描述。

因此我们当时更多是参考建筑行业政策文件，以及熟悉行业流程的土建B端客户的沟通情况，来主动引导客户去说更多关于业务流程的细节信息，通过我们的梳理，让客户去确定业务的整体逻辑准确性。

至于细节信息，当时考虑到这种情况，我们只能先按照最简单的信息情况设计，然后给客户看的时候，他们能知道缺了哪些，哪些不对，我们才有根据的修改信息，但这个过程也是不断反复的过程，因此当时的这个项目做的其实还是蛮累的，不过也幸好是正式使用起来了。

3. 来自老板的需求

在产品设计环节，不同的老板在项目中参与的程度是不同的，这个也和他们对业务的理解程度有关。

有的老板只是在参与项目进度-原型设计汇报时，对整体上或者部分细节提出大致的疑问或者修改建议，一般会比较关注大屏的内容和展示效果，有的会直接参与到需求讨论阶段，会融入自己对业务的理解和需要，以及会提出一些市场战略方面的一些需求，这种一般对业务很熟悉，能够针对业务细节提出针对性的建议。

但是很多时候，客户的有些需求我们是可以做些取舍，但是老板的需求如果不合理很难去反驳，只能看具体需求具体分析。

当然内外部需求可能也有冲突的时候，这个时候，就来到了产品经理最难受的点，客户和老板需求不统一该怎么办？我目前是要看具体需求，如果牵涉到一些逻辑性的、客户坚持的需求，得说服老板听客户的。

如果是一些非客户坚持的，我就比较狗腿子，这个时候听老板的。

以上其实就是G端目前主要的需求来源，一般在项目过程中，这三种情况都会同时存在，具体需要看实际情况参考使用。

三、需求管理

需求采集过之后，就要开始进行需求分析，经过筛选后确定后再开始设计，毕竟不是所有的需求，都需要全部实现，有些需求可能也是伪需求，因此对于需求的分析和筛选，需要多方面考虑，包括项目的总体目标、项目的限制条件，如预算、时间、资源、以及开发能力等。

在整个需求分析和筛选过程中，我是这样操作的：

1. 需求整理

个人觉得需求池还是蛮重要的，这个主要是由产品经理管理维护。

在项目初期，我会把所有需求都记录在需求池中。

在每次客户需求对接后，可以将客户所有的需求整理在这里，按照时间、模块、需求描述、需求来源、需求类型、需求状态、产品设计状态、需求处理版本、是否实现等情况，方便产品经理管理哪些需求是否需要做？要在哪个版本做？对于一些暂时无法确定的或者需要暂时搁置的需求，后期也可以在这个文件中找到。

也便于后期整理系统二期的需求和预算。

2. 初步拟定项目框架

需求沟通后，基本上每个大致的模块已经清晰了，可以先把收集好的需求整理到对应模块下，然后再确定这个需求是否要在这么模块使用和保留，这个步骤我般都是和需求池文件一起整理。

3. 需求分析和确认

在分析需求的时候，我会先判断确定系统的核心逻辑，需要这些是必须要实现的。

至于在整体逻辑实现时，需要看客户提出的具体节点需求，是否合理或者是否时客户真实想要的需求，如果合理及真实，就可以确定要设计，如果不合理，但是要保证核心逻辑实现，就要学会需求转化实现。过程中我会搭配业务流程图一起进行分析，如果节点有疑问的，会顺便备注在旁边，方便后期咨询。

就比如审计整改管理系统中，整改挂号阶段，当时客户需求的是通知书必须要采用在线编辑套用模板的形式，然后通过在线编辑生成通知书，开始走内部通知书审核流程。

但是考虑到国产系统在线编辑插件适配、额外费用情况（局目前使用的国产系统有好多种，每一个如果使用都会产生插件费用），我们当时是改成通知书主体上通过手动上传文件，支持下一个审批人员下载编辑和再上传，然后购买了一个使用范围多国产系统插件，支持部分人员可在线编辑使用。

其他各模块需求也是要按照，是否客户确定要实现，客户需求是否是真实需求、功能开发是否能够实现、功能实现起来需要耗费的时间精力、整体预算方面多方考虑。

比如客户需求是否真实：比如在做整改管理时，我们设计思路时，是通过整改项目-问题管理-整改挂号-新增问题/整改反馈-销号审批。当时我们设计路径太深了，每次找的时候会很麻烦，客户想让我们直接用问题维度，只直接展示出来，这样更加方便操作一些。

但是客户的这个需求就不是很合理，如果直接按照客户说的意思去设计，这个模块就直接变成了问题维度下新增通知书、新增问题、以及问题跟进。后期使用时，会更加麻烦，也无法统计查看，因此当时就觉得不太合适，还是要最大程度的保留以项目维度去新增设计。因此我们将需求转化成了，按照项目-问题挂号-新增；项目-通知书-新增；项目-问题销号-问题跟进和审核销号。这样客户进入这个模块就清楚，在这个模块下可以做这些事情，也方面项目维度统计查询，同时也简化了操作步骤