产品经理TO G项目全流程复盘.pdf

编辑导语：创业团队应该如何更好地规划、执行ToG项目，兼顾用户需求

与功能设计，进而推动业务的正常进行？本篇文章里，作者结合自己的ToG项

目建设经验，从项目的各个阶段进行了详细的复盘和梳理，不妨一起来看一

下。

此次项目本人从前期商务接洽、售前工作、招投标工作，初期需求采集工

作、方案设计工作，中期产品设计工作、产品研发测试工作、项目管理工作，

后期项目交付和持续运营工作，全流程参与。本次复盘也是一次全方位的项目

复盘。

此项目业主方为某市某区网信办，项目由某大型国企作为总集成方，某软

件服务央企作为软件部分分包商，我司作为的该央企软件外包服务商。

软件部分包括舆情大数据监测管理系统（PC）和网信指令交办系统

（PCApp），主要解决舆情监测预警和后续的网信指令交办问题。

目前项目合同涵盖功能和其他需求功能已完成开发工作，并已完成验收交

付工作。合同中目前“对接其他舆情系统”尚未完成，“舆情简报”功能改版功能

尚未完成。

项目自试运行以来共更新迭代9个版本，后续会根据网信办用户和镇街用

户反馈持续优化迭代项目，同时做好日常运行的运维工作。

由于此项目本质上是一个TOG建设交付类型的项目，不同于团队研发的

标准化产品，交付类型的项目需求相对不可控，而客户需求蔓延，可能会导

致：

在处理用户需求问题上，前期团队尽可能满足用户需求，所以我们也同样

面临2、3、4点的问题，导致项目迟迟无法交付，团队士气受挫。为了解决当

前问题，我做了以下改变：

对于交付类型项目不管是在前期需求调研、需求搜集，中期产品设计、开

发编码，后期项目验收过程中，作为项目负责人都应从商务、产品、研发层面

强化需求边界意识，让团队成员认识到需求边界的重要性，严格控制项目边

界，以便更加顺利推动项目。

产品设计的前提是对业务本质的理解，通过对业主方需求和业务模式抽象

出产品框架和业务流程，具象成具体的产品功能。

由于此次项目对我来说是一次全新的项目，所以在前期我也参考了许多成

熟产品的资料，但发现市面上大多数同类产品更多地聚焦在舆情信息监测舆

情，而对后续舆情处置、指令交办没有过多的涉及。这里就需要思整个系统的

核心到底是什么？

通过前期与业主方的多次沟通，发现其实系统的核心非常明确，通过信息

化手段和相关技术，实时监控掌握网络舆情信息，同时建立起多机协同、多部

门参与、信息共享、共商共治的网络突发事件处置体系。

在理解业务核心后，接下来需要将前期搜集、思考的信息抽象到产品框架

中。

首先应该为了完成从舆情监测到指令交办，是怎样一个流程？这些流程中

会涉及到哪些角色和关键节点？每一个流程这些角色的输入和输出是什么？到

下一流程的限制条件？流程是否可逆？出于对上面流程的思考，梳理除了以下

业务流程：

作为一个完整系统，除关键业务流程外，还需要一些基础配置和支撑管理

的模块，这里我们考虑了包括：用户管理、权限管理、消息推送、数据统计、

审计日志、基础配置管理等。

由于本项目还涉及到原有系统的整合及历史数据的迁移，我们也设计统一

应用管理模块。以下是我们对系统架构的抽象：

接下来我们要做的就是对产品功能的梳理和罗列，对前期所有信息和知识

的整合，我们对业务流程和产品框架进行了进一步拆解成产品功能，进而进行

产品原型设计。

产品原型设计本应是与业主方进行前期沟通、团队内部（研发、测试、

UI）评审的重要工具手段，但在这里我犯了2个非常严重错误：

鉴于第一版存在的问题，通过和业主方及研发团队的沟通，我们决定在保

留基础功能的前提下，对系统进行重新设计。

对于重新设计的系统，我更多地从用户视角出发，深入了解网信办用户和

镇街用户的日常工作状态以及工作量，在保证正常功能流程能跑通的前提下，

更多地考虑产品的易用性和灵活性问题，比如重复问题的一键生成模块，流程

自定义等。

同时为了避免之前设计的功能并非业主方需要，我在后续的设计过程中，

每完成一个版本的设计提前和业主方沟通，明确后再投入开发工作，也避免了

开发团队反复修改。

产品经理在设计产品的时候免不了会带有一些主观意识，但产品设计绝不

是依靠某个人的感觉和判断来完成的。对于建设交付类型的项目，我们需要同

时考虑业务可行性和技术可行性，与客户充分沟通确认设计原型和与研发团队

评审产品实现是同样重要，所以在产品设计的时候需要在产品维度、