不同的产品类型，在建设的时候会有不同的思路。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协议