分析端产品和非端产品的区别

　　G端产品，G指的是＂Government＂，是为政府、包括事业单位开发的产品。本篇文章中，笔者从两个方面分析了G端产品和非G端产品的异同点，一起来看看吧。
　　来到公司已经三个年头了，做了很多产品，虽然从事着用户体验的工作但对产品的观察以及学习也从没断过。特别是在垂直领域做产品，让我对做产品有了更深的兴趣，也尝试性的做了研究和思考。
　　今天的这篇文章就个人理解的角度来分析一下，面向政府的产品和非政府类产品的共性和区别。由于公司主要面向特定人群以及C端产品和G端产品差异较明显，本次讨论的非政府类的产品也主要讨论B端。
　　首先我们先来解释下什么是G端产品，G指的是＂Government＂，是为政府、包括事业单位开发的产品。严格来讲，G端产品是B端产品（面向企业）的一个分支，他们有很多共性。
　　虽然有很多共通之处，但也有一些特殊性和区别，为了更好的设计出这两类产品，本篇文章会和大家一起＂粗浅＂的分析一下。
　　G端产品与非G端产品的共通点
　　1. 真正的使用者不一定是决策者，大部分是具体的执行人员在应用
　　B端产品一般在决定是否购买前都是高层在关注或者指派专人来对接，但对接的人大多数情况下不是真正的使用者，因为一般采购软件的一个部门的职责，实际应用的是另一部分人员。
　　这也是我们在做类似产品的前期调研时需要注意的问题，我们是否了解到了解使用者的需求，我们如何转化决策者和使用者之间需求上的差异，做到千人千面，这也是我们做产品经理的同学每天在苦苦思考的问题。
　　2. 产品主要服务于可以提升效率减少成本的环节中
　　服务于政府或企业的软件，大部分要帮助其解决实际问题，对效率、利润产生贡献，通过智能化信息化帮助工作人员在具体的流程环节中提升效率从而达到节约成本和高效产出的目的。
　　3. 注重业务流程和业务场景，做合理且专业的产品
　　政府企业类的产品，如果产品经理或者设计师如果不了解实际业务，没能把业务流程梳理清楚，对实际工作场景掌握不足，就不可能产出让客户满意的产品。
　　所以产品的设计者要思考产品需要解决哪些具体场景下的问题、理解整个工作流程、分析客户的需求，才可以做出专业并令客户满意的产品。
　　4. 要兼顾用户体验和业务需求之间的平衡
　　2B产品重业务，很多功能需求直接来源于实际业务，就有很多人会感觉用户体验并没有那么重要，实际上并不是这样，试想如此重视业务逻辑的产品如果没有一个可以让用户流畅操作的界面，那将是多么灾难的事情。
　　所以我们要平衡好两者的关系，将细节打磨贯穿到整体产品的设计中，做到逻辑正确、清晰简明、操作顺畅。
　　以上的总结主要来源于我的工作经验和实际输出，针对代表性的共通点加以阐述，当然还有一些产品共性以及相同的方法论，比如＂都是给人用的＂这种大家都知道的内容就不详细赘述了。
　　说完相同点，我们在看看他们之间的差异，首先我们从政府端产品说起。
　　政府端产品的特殊性
　　1. 产品受国家政策影响较大，产品功能需要紧贴政策需求
　　我们在设计政府产品时，要时刻关注国家相关条文政策，设计提高政府办公效率的软件，必须围绕主轴核心业务来设计；
　　核心业务的依据参考就是相关政策法规，所以产品人员要根据政策来调整自己产品的流程功能。再好的业务功能也不能偏离国家政策。
　　2. 做好主轴流程，严控最终输出结果
　　政府项目要把握好产品的主流程，所有功能围绕主流程来实现和延展。
　　虽然说B端产品的功能可以串联整个工作流程，各个应用之间串联并行，但作为政府项目来说，或许并不需要大而全，我们可能最终只会负责整体流程的一部分；
　　这部分相对对立和专注，我们要保证好完成这部分的最终输出，保证输出结果的专业性、规范性、正确性。同时也为数据的下一级流转提供强有力的支持。
　　3. 想好如何将数据转化为知识服务产品提升效率
　　我们在设计通用类产品的时候，大多数情况下我们更愿意把数据转化成内容来满足c端用户的衣食住行。
　　但在设计g端产品时我们必须更注重的是数据在系统中的流转、沉淀、在回传。要将数据形成知识，将知识转化成辅助工具，提升效率而不是占用时间。
　　所以在设计之初就要不断的在头脑中完善，如何将数据对应到业务需求，将业务如何转化成具体的功能，不断完善产品体系，在脑中形成基于业务的产品架构。
　　把握好自己产品所在场景的业务需求以及该场景下知识辅助可以解决哪些问题，数据沉淀客户帮助客户提升多少效率，这是产品经理要做的重点工作。
　　4. 数据安全很重要，对做好数据的安全性要求更高
　　我们做政府系统因为其特殊性，对于数据安全的要求就非常高了。
　　产品设计阶段的数据涉密问题，再到产品之间的数据流转、存储、交换等都需要严格的安全保障。
　　在C端看似非常简单的数据更新云存储，在设计功能的时候就要考虑＂线下＂流转数据的情况，在没有公共云的情况下如何更新备份数据，是通过内网云来做更新，数据存储在哪里？如果通过线下拷贝数据，那么系统中的相应更新流程如何设计？这些都是摆在产品设计师面前需要仔细思考的。
　　5. 产品的采购依据政府年度预算，具有极强的时效性和周期性
　　政府的产品采购都是通过年度预算的方式，所以在做产品时一定要考虑到周期性和实效性，当年的政策影响以及当下的重点事件都会是产品跟进的方向。
　　这时候就要迅速转化成功能到产品设计中来，落实政府需求，尽可能拿到更多的预算。
　　6. 对于驻地和现场的反馈要高度重视
　　政府项目非常依赖于驻地的培训和服务，服务做的越好接下来的项目机会就越大，这个很好理解，大家都希望项目流程简单，对于经常在一起合作的厂商，政府一般不太愿意在更换其他厂商了，因为已经＂知根知底＂合作模式清晰了，这也是一种效率。
　　基于这点作为产品人员对于驻地同事的相关需求和反馈一定要高度重视，他们反馈的大概率是客户真正的需求和反馈，这些建议如果可以及时得到响应，我相信会提高我们的产品在政府内的认可度。
　　同时搜集这些一线反馈对于产品人员分析需求，构建人物模型，搜寻市场机会都有极大帮助。
　　三年来我们在设计输出了很多产品，也有很多积累，以上的文字都是一些点滴的总结和思考，并不是完整的方法论体系，肯定有很多不足支持，但这些不足就是我们今后不断努力的方向，毕竟好的爆款产品也是在无数点滴积累和无数失错中产生的，那么我们就继续加油吧。