在乙方公司做 toG 产品的流程和感受

这篇文章记录我在一家乙方公司,做 toG(to government 面向政府或事业单位)产品的全过程。

其实我都表示怀疑,是否有「做 toG 产品」的概念,在经历了四五个项目之后,我更倾向于称之为「软件项目」。

项目是临时的,是有时间周期的,这是它跟「产品」最大的区别,因为产品是持续迭代的,是长期的,直到其生命走到终点。

而我所接触的大多数 toG 的项目都是临时的,软件交付就是其终点,目标不是,完整的产品功能或是良好的用户体验,从而为用户创造价值,而是,最后的验收。

一切以拿到经费为始,以成功验收为终。

写来似乎有些悲观,但我看到的确是如此,就当作是人生经历的一部分吧,尽力为之,关注个人成长是最主要的。

接下来,梳理一下 toG 的软件项目开展的大致流程,主观感受,仅供参考。

流程

需求来源

对于 toG 产品来说,就没有那么复杂了,多数都是靠老板的资源以及人脉,即便你不愿意承认,这也是事实。倘若能够傍上一两个大客户,基本上一两年内都不用愁了。

当然,也会有凭产品实力拿到合同的,但其背后的关系通常也不简单,现实环境就是如此,商业从来都不是理想主义。

业务需求

在整体经济情况还不错的情况下,从来就不缺要做的事情,国家要发展,要提高效率,在信息化方面的投入还是比较大的。

投入是投入,只是做出来的东西,很多时候,还不如一个创业小团队做得好,这里面的潜规则就不多说了。

其实,toG 的那些软件产品也都是一些小公司做的,大多数这类公司是没有产品,没有运营,甚至没有测试的,一个项目经理,带着一堆程序员,干着几百万的项目。

业务需求并没有那么重要,也没有什么技术难度,只要你有钱(经费),我就能干。

所谓的业务需求分析,不过是这个过程的附属品罢了。

最开始,我也是特别的不理解,在我的认知里,用户需求沟通是做一款产品前期,最重要的一个环节,快速准确的挖掘出用户需求点,不是件容易的事情。

后来我发现,对于 toG 产品来说,似乎没那么重要。因为很多时候,压根就没什么需求,甚至很多的需求都是我们帮他们「想」出来的,替甲方写需求,这是我之前闻所未闻的,但是,为了所谓了合作,这种事真的见怪不怪了。

总体来说,toG 的业务,根本就不需要产品经理,一个懂点技术的项目经理可能更加合适。

任务书

这是甲方给出的文字版需求,除了必要的沟通,甲方也会形成一份文档来描述自己的需求。

这份文档一方面会作为乙方的输入,另一方面,也是甲方内部评审的依据。毕竟想要花钱,一些审批流程是少不了的。

这里要分两类甲方来阐述了:

第一类,组织结构相对规范的甲方,内部会有对应的信息化部门,来应对内部业务部门的需求,他们的信息化部门通常不会承担软件开发工作,所以,他们会把这部分工作外包出去。

针对这类甲方,我们会有明确的技术要求或任务书,前期沟通起来相对顺畅,以技术要求或任务书作为后续软件交付的依据。

但是,对于这类甲方的软件产品,后期测试验收往往会出现问题,因为我们面对的不是最终用户,拿到的是二手需求,当最终用户不满意,我们除了改,别无选择。

这是作为乙方的悲哀,如果甲方内部负责对接需求的信息化部门,能力很强,且负责的话,那么乙方就幸运多了,但是,别想了,这种情况几乎没有,toG,你想想。

第二类,内部没有信息化部门,直接对接你的就是实际用户,这类甲方,前期沟通就要费劲一些了,它们通常也不会给你写什么技术要求或任务书,这部分工作自然就落在乙方身上了,前期就是不停的沟通需求,写需求文档,有的甚至原型设计都做了,需求还没有聊清楚呢。

因为人的想法是一直在变的,甲方看着你写的一版又一版的方案,从开始的毫无想法,变得想法越来越多,几乎就是无底洞。

当开发完成之后,交给他们使用的时候,这时才是噩梦的开始,久而久之,我们自然也都形成了「乙方思维」(瞎造的词),那就是,甲方说啥就是啥吧,没必要解释,也懒得解释。

项目方案

不管是哪种类型的甲方,写项目方案这步是少不了的,根据任务书,出具项目方案,这是固定流程。不一样的是,方案做多细?

对于第一类甲方,由于与实际用户之间隔着内部信息化部门,很多时候,通过文档并不能正确表达实际用户真正的需求,但你又无法接触到实际用户,所以,对于软件需求分析就粗糙得多了,项目经理只能依据对方的任务书,咬文嚼字,猜想使用场景,臆想用户需求。

所以,这类方案写出来同质化非常严重,几乎都是通用的内容,去年的项目方案,随便改一改就成了今年新项目的方案。

针对第二类甲方,实际用户就是他们自己,在没见到实物之前,他们希望你把工作都要描述清楚,甚至是原型系统都给做完了,确认过后,才会进入开发阶段。

这种情况,就比较折腾项目经理了,一遍一遍的根据甲方的口头描述,修改一版又一版的项目方案。而且这个工作还不一定有意义,为啥,见上条。

报价单/合同

做完了项目方案,大致要干啥就已经清楚了,接下来,就要谈钱了。

谈钱的第一步,就是我们会出一份报价单,把项目中的成本费用,都列举出来,尽量把条目写细,虽然没啥用,但是至少让别人觉得这是认真梳理出来的,而不是随意要的价。

但是,双方都心知肚明,这就是随意要的价,而且都是固定的套路,项目总额都是提前商议好的,并且是根据甲方的经费定制的,所以,我们的报价单就是按照规定好的金额,造出来的,而且还不能让别人知道这是造的。

做报价单,只是谈合同的一个步骤,合同谈什么呢,不就是商议一下,干这些事,需要多少经费支撑嘛。

遇到关系比较好的,基本就没啥可谈的了,谈也就是签个到,走个流程。遇到审查稍微严格的,要求多方评审的,也就是在报价单上再划划价,作为乙方的我们,断然是没啥议价权的,对方说多少就是多少了,不过话又说回来了,羊毛还不是出在羊身上。

方案评审

这通常也是固定流程,同样,百分之九十九都是形式。

在会议上,一些专家会针对你的项目方案,提出意见,毕竟是评审,没有审,评一评还是要的,毕竟拿了评审费,不说几句,显得自己多没有存在感。

当然,评审会嘛,最后一定是要有结论的,通常的结论都是「某年某月某日,针对某公司某项目的方案进行了方案评审,参会的专家有某部门以及某部门的专家,最终结论是,方案按照专家意见修改之后,可进入项目实施阶段。」

至于方案还要不要修改,就看你了,因为过了这道流程,就没有人再看方案了。

软件开发

不管是从哪里来的需求,终归还要做个东西出来的,毕竟是软件类项目,没有软件终归是没法交差的。

软件开发的流程大体就类似了:

首先是设计,设计就是原型以及 UI,项目经理把大概的界面样子画出来,然后交给设计师,做一下界面美化,面子工程还是要做足的,实现功能相对没那么重要。

其次是开发,这块可以说是关键一步,没有东西出来,方案说得天花乱坠,设计做得再好看,也没办法交差验收,但是,做出来的东西,通常情况都比较差强人意,因为目标是验收,而不是产品。

最后一步是测试,这个同样看甲方要求,有些保密性比较严格的甲方,通常要求第三方进行渗透测试,并且要产生专业测试报告,但大多数情况下,都是没有测试的,项目经理点吧点吧就算通过了。

这个过程能省时就省时了,毕竟人工都是成本呀。

验收交付

前面一切的工作都是为了这一步,然后拿尾款。

验收交付也是有正式的评审的,没错,还是那些专家,又可以拿一次评审费了。有些甲方,中间可能还有一次中期评审。

验收评审也不会有太大的问题,前面那么多流程都走过了,断不会在最后一道流程上出现问题,因为出现问题,双方都会有责任的,尽量避免出现问题,顺利通过,才是大家一直认同的。

当然了,能拿下来这类项目的公司,大都是有一些关系的,而且深谙其中的规则,做出来的东西断然不会差得太远而使大家难堪,再不济,至少在面子工程上要过得去。

随便说一句,这下知道那些 toG 产品为啥那么难用了吧,因为能用就不错了。

后期服务

验收交付之后,并非项目就结束了,除非真的是那种只需要演示一下的项目,大多数项目还是有人在用的,用的过程,一堆问题是避免不了的。

我们通常会有大致一年的后期维护服务,后期服务的意义,除了对前期软件的修复或优化之外,还有一层重要意义,那就是关系维持,以便寻求下一次的合作。

总结

可能写得过于片面,但还是能反映一些问题,我之前还比较疑惑,toG 其实也是 toB 的一类,为啥要把 toG 单独出来呢。

我曾经也考虑过,是否是由于客户企业性质的原因,而导致用户需求或是产品设计上的差异,后来发现,其根本的原因可能是,做好产品所投入的资金从哪儿来的区别。