初次接办ToG项目，我真是太灵活了（中）

开心每二天

原标题：初次接办To G项目，我真是太灵活了（中）

编辑导读：to G是从to B衍生出来的一种特别分别，面向的企业为当局或相干奇迹单元，重要是根据每年当局投入的财务预算，然后去做的一系列信息化项目。本文从作者自身工作出发，联合详细项目实践中的所思所想，根据本身第一次所履历的to G项目，分享总结了本身的一些心得领会，供各人一起参考和学习。

编辑导读：to G是从to B衍生出来的一种特别分别，面向的企业为当局或相干奇迹单元，重要是根据每年当局投入的财务预算，然后去做的一系列信息化项目。本文从作者自身工作出发，联合详细项目实践中的所思所想，根据本身第一次所履历的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应该都多，那么向导层在意的体验是什么呢？

是反馈。谁的反馈？

体系利用者的反馈不多说，这相称于绕回了上面说的B/C端用户体验计划，而数据反馈是这些年随着大数据概念的鼓起而衍生的一种关注。

之前说过用户基数极大是To G项目标一大特点，怎样将这个“大基数”运用恰当，是每个To G项目都在思量的题目。

03 产物计划要点

接下来，我会对这半年中总结出来的一些产物计划想法归纳一下，将最重点的部门举行报告。

1. 发掘需求底层逻辑

这里指的底层逻辑并不是需求的深条理应用场景，反而是最底子的原始功能逻辑发掘。

这次对接的To G体系由于更换过多个开辟团队，对接人也是一年一换，体系开辟等相干文档都处于零存储。

经常在对接新需求时，业务方对于旧功能也是一问三不知。全部的功能流程，数据库建表等逻辑险些都必要通过研发小哥哥对着代码一字一句抠出来的，

末了，我们只能在每次对接到新需求后，将涉及到的旧功能重新梳理一次，相应的接口，数据库表格字段能找到的也都找出来。

研发小哥哥前两天和我说了这么两句话：

• 我第一次碰到开着数据库表和我讲需求的产物司理！
• 你居然也会写SQL，下一步来开辟吧，功能接口你都熟了！

这半年来对于做To G项目有一个感受是：每一台服务器都带着厚厚的工单条。

项目资源申请大到服务器，小到数据库容量，每一次扩容都必要举行申请，时间是非不一，内容复杂度乱七八糟，假如碰到告急变乱加急工单也是漫长的敦促流程。

以是在产物计划中必须有较全面的前瞻性，与研发同事确定好必要的资源，提前做好规划。

3. 思量最小并发值

由于To G项目标大用户基数，在举行需求计划时，必须时候服膺计划好每个功能的最小并发值，并让研发和测试举行压力测试，否则一旦上线后出现宕机，又暂时申请不到资源，那可就真的是贫苦大了。

04 总结

下一篇应该会来讲讲怎样与To G项目标业务方举行需求沟通，对于我这个之前做惯了B/C端产物的产物司理来讲，这半年的沟通本领可真的是突飞猛进……

互勉！

初次接办To G项目，我真是太灵活了（上）

本文由 @DHAllison 原创发布于大家都是产物司理。未经允许，克制转载。

题图来自 Unsplash，基于CC0协议返回搜狐，检察更多

责任编辑：