起点学院课程

ToG产品建设思路

1 评论 4281 浏览 34 收藏 14 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

不同的产品类型,在建设的时候会有不同的思路。ToG是面向于政府机构的产品,本文作者用三个方面介绍了ToG产品的建设思路,希望对你有帮助。

大家好!我是你们的好朋友,nickChen!这是我首次在该平台发布文章,文章内容均来自个人多年产品工作经验、理解与心得,希望能与各位多多交流,欢迎拍砖!

个人经手的产品或项目中,包括ToC,ToB和ToG等类型,此篇分享个人在ToG类产品的建设思路。

一、落地形式

ToG,即面向ZF机构,ToG产品的使用人群是这些机构的公职人员。ToG严格意义上来说,属于特殊的ToB,其产品的需求来源,主要包括这几种:

  • 政策导向性业务需求;
  • 机构领导指派的任务-定制型需求;
  • 为解决机构内部某类问题而产生的需求;
  • 脱胎自机构内部传统场景,旨在提高业务流转,工作效率等的需求。

围绕以上需求场景,就产生了ToG比较特殊的产品落地形式,一种是项目建设型,一种是产品建设性。

结合我的实际经历,上面提到的第1、2种需求往往以项目形式进行建设;第3、4种需求一般按照可移植性的产品形式进行建设。

那么接下来,我结合自身经验,分享些关于ToG项目和产品的建设思路。

二、项目型

1. 特征

按照项目建设,一般都是基于特色需求或是本地私有化部署等情况,具有以下特征:

  • 体量普遍较大;
  • 研发周期较长;
  • 基本定制化需求;
  • 多需本地化部署;
  • 验收流程较长,一般分为初验,中验和终验;
  • 采购流程较长,采购款项少则几十万,多则上亿(个人仅经手过大几千万型);
  • 采购款,除了软件系统费用,通常还包含硬件设备资源和服务资源的采购费用;
  • 甲方有后续需求,可在一期建设基础上,探讨二期建设的可能性(一般会有二期)。

2. 承建来源

企业获得某机构项目建设的需求,一般来源自:

  • 客户关系到位,之前有过与该机构的合作基础;
  • 老客户推荐,机构与机构之间彼此交流中谈及企业有承建实力或业务方向契合;
  • 企业宣传触达,比如通过展会,省部级或地市级会议交流,市场推广等。

3. 建设方案

即项目立项前的准备内容,体现了很多要素,如行业对标,行业调研,预算,思路、目标等等。那么一个项目建设方案应该包含的基本元素2个W:when、why 及2个H:how、how much。

  • 项目背景,说明现状及痛点;
  • 建设目标,描述定位、场景、基本思路和总体功能架构等;
  • 方案详述,建设内容是哪些?建设周期?建设费用(报价)?

4. 项目立项

甲方与企业达成合作协议后(甲方认可建设方案),即走项目立项及采购流程。多数情况,项目立项前还需进行项目招标,决定权在甲方,与采购金额大小无必然关联。

我经手过的从几十万,几百万到几千万的项目,有需要走招投标流程的,也有直接立项走采购流程的,视具体情况而定(甲方大大决定)。

5. 招标与投标

项目建设一般都需要经历招标与投标过程,所谓招标,就是甲方给出项目建设需求,落地内容,验收要求等,这些招标文件通常都会提前给到有意向投标的企业(企业怎么得知招标信息的,就是“承建来源”提到的渠道)。

企业拿到招标的需求和内容,就需要在投标前,准备好相应的投标文件(标书,一般由企业售前部门负责),文件包含:

  • 企业相关资质(也就是各种证书);
  • 技术资质(能够达到甲方建设需求的各项指标);
  • 各项指标分值设置(通常指标有相应分值,分技术指标和报价指标)。

以上内容都准备好了,就等待招标评委会审核,审核过后,审核通过的企业在竞标那天到甲方现场参与竞标。竞标成功的企业,即获得该项目承建资格,接下来就进入项目需求分析阶段。

6. 需求沟通与分析

项目立项后,就进入详细的可落地的项目需求沟通阶段。

需求沟通通常需要到甲方处反复沟通多次,确保需求的准确性和可落地性。沟通过程,一般是与项目的甲方主导者,或需求相关的业务人员之间进行。通过此种沟通过程,需求能够细化的程度,往往是需要产品人员如实记录,并结合自身经验进行业务层面的需求交流,分解和转化,注意事项:

  • 对于甲方提出的需求,一定要透过现象看本质,千万别来者不拒,因为不是所有的甲方都对自身项目需求有非常明确的认知,尤其是具体实现,更多时候需要产品人员梳理出各个需求的业务目标和业务逻辑;
  • 有一定可能会遇到比较强势的甲方,那么这时候产品人员的专业性就是让对方愿意平和的和你交流,何谓专业性,简单来说,就是让对方知道你对业务的了解和理解程度,并能够将其业务层面的描述进行产品层面的拆解,让对方感受到双方的信息是平等的,相信你有能力从技术层面实现;
  • 每次沟通,都一定要做好记录,除了文本记录,有时候甚至需要录音记录(可以复查交流中内容);
  • 每次沟通前,都需要将上次沟通的内容,及时梳理成文档,开始可以是以功能实现逻辑为主,随着沟通的进程,逐步整理出产品架构,功能结构,直到输出完整的PRD文档;
  • 完整的PRD文档,在开发前,一定要先经过内部评审,需要领导决策,技术评估,再同客户确认,最后结合文档产出原型文件,同样需要先经过内部评审再与客户沟通;
  • 文档和原型都得到客户的认可后,再进入项目研发阶段。

7. 项目管理

真正进入项目研发阶段前,需要产出进度管理文档,文档管理方式有很多,可根据企业实际在用方式,比如可以通过微软提供的Excel,Project等,也可以通过禅道,worktile,JIRA等第三方平台实现。严格遵循SMART原则:

  • 整个项目研发周期必须有截止时间;
  • 每个细分任务,足够清晰,责任到人,技术指标可达成;
  • 人员工作足够饱和。

项目研发团队,一般都是由项目经理(也有产品兼任的)带队到甲方现场驻场开发。

过程中需要定期跟进、验证开发进度和实现情况,开发过程中难免会遇到在技术评估时,没有完全考虑清楚的地方,这时候就需要针对性解决,商量新的解决方案,或替代方案等。阶段性的成果,需要逐步交付到甲方真实环境运行、测试。

项目型开发,每一期的交付前,必须完成所有项目规划内容,因为每一项内容在验收阶段性验收时均需要逐项检测,全部检测完成,达标才算通过验收。

另外,项目研发内容除了自身软件系统的需求之外,往往还包括对接第三方系统,硬件设备资源和服务器资源的采购。

8. 项目验收与交付

研发、测试完成之后,首先是经过内部评估,从需求实现、技术指标的完成度,系统稳定性,用户体验流畅性,与第三方系统的协作效率,有些时候还需要考虑到申请资源的利用率等。

内部评估完成后,就等待甲方验收,一般会由第三方公司负责阶段性项目验收,验收前有很大几率系统已经在甲方真实环境运行起来(主要方便用户较早介入体验和协助测试)。

项目验收一般分为初验,中验,终验,其中初验和中验由第三方公司验收通过后,即完成阶段性验收指标。终验,即项目最终验收,除了需要准备一堆验收资料,还需要企业配合走甲方的财务审计流程(即项目款项申报-批款流程)。项目验收完成、交付之后,甲方的财务审计流程才会流转下去,款项最终落下。

三、产品型

产品型的建设流程,基本和项目型差不多,不过两者最大的差别就在于,产品型。从一开始在做战略分析和市场分析的时候,就已经有意按照产品的形式来建设。为何这么说呢?项目型往往是单价大,但是可移植性差,所以基本是做一单成一单,结束。即使能够找到其他甲方有类似的建设需求,往往也需要结合当地甲方的需求做很多定制化的建设。而ToG产品型,则是可移植性较强,需要定制化研发的较少,主动权在企业方。

1. 特征

始于项目建设,在产品迭代过程中发展。一般是基于特色需求或是本地私有化部署等情况,具有以下特征:

  • 工具型或数据服务型或检索型或分析型等居多;
  • 项目研发周期适中;
  • 前期基本定制化需求;
  • 第一家甲方需本地化部署;
  • 验收流程较长,一般分为初验,终验;
  • 采购流程较长,采购款项少则几十万,多则数百万;
  • 采购款,主要是软件系统建设费用;
  • 可产品化建设,后期需求来自新的甲方,或产品宣传中与业务方交流所得,或产品使用者,或产品人员的产品建设型需求。

2. 产品迭代

第一家甲方项目建设、验收完成后,往往在完成前,企业就已经在做市场调研,多客户方交流,企业内部战略规划等。所以验收后,即可无缝接入产品建设和运营思路。

ToG型的产品迭代较为特殊的地方有:

  • 迭代的节奏一般不会太快,1-2个月迭代一次居多(有些需要依赖客户方环境);
  • 迭代的需求,有来自新的甲方,或产品宣传中与业务方交流所得,或产品使用者,或产品人员的产品建设型需求;
  • 产品需求的优先级,可能不会完全按照既定规划,难免碰到有客户买单,提出了一些新的需求(较少定制化),那么此类的需求优先级就需要提高,优先考虑实现。

3. 产品运营

ToG产品的运营思路,同纯互联网的运营思路差别挺大!

主要体现在:

  • 宣传途径很少通过公域渠道(很多业务不允许公开),多数是通过官网一定程度上曝光(重在业务层简介);
  • 主要通过私域,比如自建论坛,微信建群等,互动交流、案例分享和定期宣传;
  • 线下主要依赖与业务方的交流,大型展会,参与各种甲方组织的交流大会,培训会等。

四、总结

以上是本次分享的内容,多数是结合自身经验撰写,部分地方颗粒度粗细不均,难免有所疏漏,后续会推出其它内容,或许会补充此篇未谈及、细化的内容。

 

作者:nickChen,微信公众号:薪火杂记

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

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 比较详细,目前我也正在做ToG的产品。
    其中,很重要的一点可能没有讲,关于培训系统使用。
    我目前开发的系统,主要是审批,从村级到区级,公务员这个团队是真的庞大,并且学历教育水平参差不齐,培训起来真的是头大,一个功能反复问,重复问。

    回复