ToG产品建设思路

nickChen 2023-07-24 03:25:17

大家好！我是你们的好朋友，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产品型，则是可移植性较强，需要定制化研发的较少，主动权在企业方。