浅谈G端项目产品设计的相关问题(上)

0 评论 2365 浏览 9 收藏 11 分钟

在做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端经常会出现这种问题,业务方领导提需求,验收是他部门下的小员验收。

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

公众号:书海智慧之窗

本文由 @霏凡 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!