文档|防范协作孤岛化(6):数据流( 二 )



文档|防范协作孤岛化(6):数据流
文章插图
一旦成为了隐性数据,那么这些数据的风险将会大增,一方面数据本身很难完完整整地再次恢复到显性状态,另一方面一旦团队中某个成员离职,或者离开了当前项目时,就会丢失。数据丢失给协作带来的后果会有多么严重,相信我们每个人都是能有所预见的。在信息化手段的加持,并配合良好的协作氛围下,这些数据流可以得到很好的“保驾护航”。我设想的信息化场景对于产品管理,我设想了以下信息化场景:

文档|防范协作孤岛化(6):数据流
文章插图
首先,将PRD文档进行结构化分拆,形成各个类别的基本数据,比如需求数据、功能模块数据、界面设计数据、菜单数据、界面提示语等,这些数据统一放在一个可共享的信息化系统之上。在实际管理中,针对每一类数据都设立一个组或空间,将相关人员拉入,比如界面设计数据空间的人员就包含产品经理和UI设计师。这些产品的数据空间都将由产品经理进行统一的维护和版本管理。这样做的好处是,传统的PRD文档只能作为一个整体进行版本管理,因为各类数据是作为非结构化内容堆积在文档中的,其中任何类别的数据更新都无法第一时间触达相关环节的人员。【 文档|防范协作孤岛化(6):数据流】

文档|防范协作孤岛化(6):数据流
文章插图
而将文档分拆成独立数据之后,即可实现独立的版本管理工作。在PRD正式冻结之前,任何经过评审后需要修改的数据,都能第一时间实现进行更新,做好可回溯记录,同时相关环节的人员也能第一时间收到更新通知,无需进入文档进行查找。然后,各团队根据这些最新的PRD数据进行后续工作,在这过程中,各团队同样会有其对应的输出数据。比如,基于PRD中的功能数据所设计出的测试方案和测试用例就是测试团队输出的数据,这些数据同样可以跳过文档这一媒介,直接采用结构化方式进行处理,并上传到原来由产品经理设定的空间中,进行版本迭代和后续的维护。其中测试用例本身就是结构化的形态。

文档|防范协作孤岛化(6):数据流
文章插图
这样,产品经理也可以在第一时间看到这些输出物,并组织相应的评审工作,评审过程也通过文字记录下来,作为每一个版本迭代的更新记录素材。在最后产品开发结束后,所有的数据都实现了有效的存储,同时在整个过程中都能够保持健康的流动,没有任何非人为的信息损失情况。如果未来产品做得足够标准化,那么甚至可以引入一些智能化手段,比如直接将数据导入到各环节的空间之后,对一些标准化的内容进行全面复用和自动化转换,然后再由负责人进行检查,重点放在差异化的内容之上,这样可以大大提高效率,并降低出错率。在明天的文章中,我将与大家聊一聊信息化是如何赋能业务状态跟踪的。

推荐阅读