初次接手To G项目，我真是太天真了（中）
本来想两篇文章完结To G这个话题，但是在这半年多的工作中，却发现这里面的水深实在不是两篇文章可以说完的，那么就用三篇文章来说明To G这个大型话题吧。
在上一篇我们讲到，To G项目有几个特点：
- 用户基数极大
- 用户画像不明确
- 准确率，支撑能力等务必100%
- 需求有着大量不确定性
这次我要再补充两个特点
01 外部系统依赖性高
在这次合作的To G项目中，他们与很多其他的政务类，政府类系统都进行了业务上的连通，在一些主业务上甚至需要其他业务系统来进行信息完善和核对。
10月中就曾经发生过这样的一个事情：
由于对接的另一个系统出现问题，主业务上某个信息就无法进行校验和填充，这直接导致了该业务无法正常运行。
由于对方系统无法在短时间内完成修复，征得业务方的同意下，我们只能临时修改业务流程，跳过这一步校验，这样的操作也导致了系统中这部分业务出现了两天的脏数据……后续的数据清理工作也是一件十分繁琐而复杂的事情。
也许你认为这只是政府部门之间的对接问题，不属于我们的工作，这种想法是错误的。
不论是做To G还是To B/C这类的事情都有可能发生，如何在短时间内拿出方案，将影响降到最低，是非常考验产品经理的应急能力的。
02 用户体验的对上与对下
我相信每个产品经理都会说这样的一个词：用户体验。
在做To C项目时，他强调的是应用场景下的流畅体验，无论什么方法，让用户爽是目标。
在做To B项目时，用户体验指的是流程通畅，因为对于B端的使用用户来讲，保证流程便捷通畅，完成既定的业务是目标。
那么To G项目的用户体验是什么？
是用户的流畅使用吗？不完全是，他们会为了保证数据准确，从而多重校验。
是流程的快速便捷吗？不完全是，政府业务有着严格的业务流程标准，需要多个部门协作的流程一个也不能缩减，甚至有着严格的上下级层级流转制度，不允许跨级。
那么他们的用户体验在哪里呢？有两个方面：
对下：具体基层使用者
他们的体验诉求在宏观上与B端用户相似，需要保证流程的通畅；
但同时对于一天8个小时都需要使用系统的他们来讲，每个微观功能点的使用体验都需要像C端用户体验打磨那样，保证他们使用起来顺手流畅。
对上：领导层
对于To G项目来讲，获得领导考察的机会比起市场上的其他APP应该都多，那么领导层在意的体验是什么呢？
是反馈。谁的反馈？
- 系统使用者，包括内部业务操作人员以及C端用户。
- 数据反馈。
系统使用者的反馈不多说，这相当于绕回了上面说的B/C端用户体验设计，而数据反馈是这些年随着大数据概念的兴起而衍生的一种关注。
之前说过用户基数极大是To G项目的一大特点，如何将这个“大基数”运用得当，是每个To G项目都在考虑的问题。
03 产品设计要点
接下来，我会对这半年中总结出来的一些产品设计想法归纳一下，将最重点的部分进行陈述。
1. 挖掘需求底层逻辑
这里指的底层逻辑并不是需求的深层次应用场景，反而是最基础的原始功能逻辑挖掘。
这次对接的To G系统由于更换过多个开发团队，对接人也是一年一换，系统开发等相关文档都处于零存储。
常常在对接新需求时，业务方对于旧功能也是一问三不知。所有的功能流程，数据库建表等逻辑几乎都需要通过研发小哥哥对着代码一字一句抠出来的，
最后，我们只能在每次对接到新需求后，将涉及到的旧功能重新梳理一次，相应的接口，数据库表格字段能找到的也都找出来。
研发小哥哥前两天和我说了这么两句话：
- 我第一次遇到开着数据库表和我讲需求的产品经理！
- 你居然也会写SQL，下一步来开发吧，功能接口你都熟了！
2. 提前规划资源
这半年来对于做To G项目有一个感受是：每一台服务器都带着厚厚的工单条。
项目资源申请大到服务器，小到数据库容量，每一次扩容都需要进行申请，时间长短不一，内容复杂度参差不齐，如果遇到紧急事故加急工单也是漫长的催促流程。
所以在产品设计中必须有较全面的前瞻性，与研发同事确定好需要的资源，提前做好规划。
3. 考虑最小并发值
由于To G项目的大用户基数，在进行需求设计时，必须时刻谨记设计好每个功能的最小并发值，并让研发和测试进行压力测试，否则一旦上线后出现宕机，又临时申请不到资源，那可就真的是麻烦大了。
04 总结
下一篇应该会来讲讲如何与To G项目的业务方进行需求沟通，对于我这个之前做惯了B/C端产品的产品经理来讲，这半年的沟通能力可真的是突飞猛进……
互勉！
#相关阅读#
初次接手To G项目，我真是太天真了（上）
本文作者 @DHAllison 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
