防范协作孤岛化（6）：数据流

大家好！

这两天我将针对业务管理的信息化进行初步展开，主要以业务管理中的数据流和状态管理作为切入点。

今天先聊一聊业务管理中的数据流。

数据流是重要的“前线资产”

加强企业的信息化建设，不仅仅是以各种审批流程为切入点，更需要在业务管理上下功夫，特别是在业务执行过程中的“数据流”上。

“数据流”可以说是企业中最为重要的虚拟资产之一，同时也是真正和日常业务充分融合，在协作中起到重要作用的“前线资产”。

在现代商业环境中，不同领域的管理工作正日益走向系统化和精细化，专注于面向整个生命周期的全覆盖管理，将项目化的运营手段应用到各类事务中。

在此过程中，良好的数据流传递能够起到了举足轻重的作用。

产品管理中的数据

这里举一个产品管理的例子。

一个产品从最开始的构想，到中间的各种开发、测试工作，直至上市，再到从市面上退出，这是一个闭环管理的过程。

在这样的闭环管理过程中，会产生大量的数据，这些数据也会随着各个流程环节而不断“流动”，直接参与每一个阶段的业务活动。

在典型的产品管理工作中，文档总是作为信息传递的重要载体，扮演着重要的信息传递角色，没有这类载体的话，所有后续环节都没有了开展工作的依据和标准，产品管理工作将陷入可怕的僵局。

在产品初期的构想阶段，产品经理撰写的PRD文档就是后续所有工作的“数据源”，不同数据将会在其对应的环节上发挥重要作用。例如：

• 交互逻辑和原型将为UI设计师提供设计依据，也为前端开发工程师提供了开发依据；
• 从需求分析到最终落地的相关内容，又为后续的架构、开发和测试提供背景和依据；
• PRD文档中的更多数据，如界面提示语定义、界面文字、功能构想说明等又为后续的用户侧文档写作提供依据。

通常情况下，PRD文档总会以word或者在线文档的形式呈现出来，有时也可以直接用Axure这样的原型设计软件来进行撰写。

无论是什么形式，PRD文档都会在冻结之后，作为产品管理的标准往后续环节传递。PRD文档可以看作是一个完整的“产品数据库”，所有用于后续环节的数据都汇集在这样一篇或多篇小小的文档之中。

结构化数据是信息化的基础

如果从信息化的角度进一步优化的话，可以考虑将PRD文档进行进一步的拆解，形成结构化的数据，然后分发给对应的后续环节，这就是从一篇完整文档转化成结构化数据的过程。

更进一步，如果企业的技术传播团队引入的是“结构化写作工具+内容管理系统”组合的话，那么能够在一定程度上实现结构化数据的自然传递，特别是那些界面菜单、提示语信息等结构化数据，实现“一数多用”。

如果未来有更改的话，只需找到原始数据更改一次，便能完成多处的更新，省时省力。在这些“数据源”正式进入到产品的生命周期中时，也就参与了产品管理的整个过程，正如每个人身上的新陈代谢，总会伴随着我们的一生。

参与业务的数据永远不会停滞，而是会处于不断的变化发展过程中，会进行一定程度的敏捷迭代，也会不断转化成不同形式的数据，为各团队所用，最终会进入一个相对稳定的状态。

如果这些数据没有做好严格的管控的话，如版本管理、变更管理和评审管理的话，那么整个产品管理工作将无章可循，处于一个相对混沌的状态，从而给协作带来阴影。

在这样的情况下，任何行进过程中变更的数据，也会渐渐从呈现在传播媒介上的“显性数据”转变为进入大脑中的“隐性数据”。

一旦成为了隐性数据，那么这些数据的风险将会大增，一方面数据本身很难完完整整地再次恢复到显性状态，另一方面一旦团队中某个成员离职，或者离开了当前项目时，就会丢失。

数据丢失给协作带来的后果会有多么严重，相信我们每个人都是能有所预见的。

在信息化手段的加持，并配合良好的协作氛围下，这些数据流可以得到很好的“保驾护航”。

我设想的信息化场景

对于产品管理，我设想了以下信息化场景：

首先，将PRD文档进行结构化分拆，形成各个类别的基本数据，比如需求数据、功能模块数据、界面设计数据、菜单数据、界面提示语等，这些数据统一放在一个可共享的信息化系统之上。

在实际管理中，针对每一类数据都设立一个组或空间，将相关人员拉入，比如界面设计数据空间的人员就包含产品经理和UI设计师。这些产品的数据空间都将由产品经理进行统一的维护和版本管理。

这样做的好处是，传统的PRD文档只能作为一个整体进行版本管理，因为各类数据是作为非结构化内容堆积在文档中的，其中任何类别的数据更新都无法第一时间触达相关环节的人员。

而将文档分拆成独立数据之后，即可实现独立的版本管理工作。在PRD正式冻结之前，任何经过评审后需要修改的数据，都能第一时间实现进行更新，做好可回溯记录，同时相关环节的人员也能第一时间收到更新通知，无需进入文档进行查找。

然后，各团队根据这些最新的PRD数据进行后续工作，在这过程中，各团队同样会有其对应的输出数据。

比如，基于PRD中的功能数据所设计出的测试方案和测试用例就是测试团队输出的数据，这些数据同样可以跳过文档这一媒介，直接采用结构化方式进行处理，并上传到原来由产品经理设定的空间中，进行版本迭代和后续的维护。其中测试用例本身就是结构化的形态。

这样，产品经理也可以在第一时间看到这些输出物，并组织相应的评审工作，评审过程也通过文字记录下来，作为每一个版本迭代的更新记录素材。

在最后产品开发结束后，所有的数据都实现了有效的存储，同时在整个过程中都能够保持健康的流动，没有任何非人为的信息损失情况。

如果未来产品做得足够标准化，那么甚至可以引入一些智能化手段，比如直接将数据导入到各环节的空间之后，对一些标准化的内容进行全面复用和自动化转换，然后再由负责人进行检查，重点放在差异化的内容之上，这样可以大大提高效率，并降低出错率。

在明天的文章中，我将与大家聊一聊信息化是如何赋能业务状态跟踪的。