敏捷大数据流程

敏捷大数据流程利用了数据科学的迭代性本质和高效的工具,从数据中构建和抽取高阶的结构和价值。

数据产品团队技能多样,会产生多种可能性。由于团队覆盖了大量的领域,构建web 产品也自然是一个协作的过程。团队需要方向才能协作:每个成员都应该热情饱满而又顽强地追求一个共同的目标。要明确这个方向,需要一个共识。

在协作中达成共识是开发软件过程中最难的一个环节。软件开发团队最大的风险就是根据不同的蓝图进行开发。相互抵触的愿景会让产品缺乏专注,最终失败。

有时在实际开发应用之前会做一些样品(mock):产品经理进行市场调查,设计师根据目标用户的反馈不断改进这个样品。这些样品可以作为团队共享的蓝图。

即使数据本身是不变的,随着对用户的了解以及外界条件的改变,真实世界中的需求也会变化。所以蓝图也需要随着时间而变化。而敏捷方法就是为了更好的实现不断变化的需求,并尽快将样品转化成真正能运行的系统而发明的。

典型的web 产品是由表格驱动的,在后端由数据库中可预料、有约束的事务数据支撑,这和数据挖掘产品有根本上的差异。在CRUD 应用中,数据相对一致。数据模型是可以预知的SQL 表格或者文档,对它们进行改动是产品层面的决策。数据的“见解”则是不相关的,产品团队可根据意愿构建模型以符合应用的商业逻辑。

而对于由数据挖掘驱动的、可交互的数据产品,以上任何一条都不成立。现实数据都是脏的,要挖掘就要面对脏数据。假如数据不脏,那就不是数据挖掘了。即使是精心抽取、提炼出的信息,也可能是模糊的、不可预测的。将它们展示给消费者,还需要大量的工作和十分的细心。

对于数据产品,数据是冷酷无情的。无论希望数据能表达什么,数据对我们本身的意愿压根毫不关心,它只陈述事实。这意味着瀑布模型没有用武之地。也意味着,样品也是一个为了在软件团队中建立共识但不全面的蓝图。

数据产品的样品是应用程序的规格说明书,它没有产品最重要的特色——具有真正价值的信息。这些作为蓝图的样品会对复杂的数据模型做出毫无依据的假设。面对一个建议清单,样品经常会误导我们。一旦加上成熟的交互,样品甚至会抑制真相,放大假设。

然而我们知道好的设计和用户体验就是要最小化假设。那该如何是好?

敏捷产品开发的目标是辨识出产品最根本的特性,将这个特性先实现了,然后再添加其他特性。这将敏捷带到了项目里,让项目更有可能满足产品进化过程中最真实、最根本的需求。在数据产品中,最根本的特性会给人惊喜。假如不是这样,要么是你做错了,要么是你的数据没有太大意义。信息有它的背景,如果背景易变,就无法使用洞察进行预测。

09-12 08:21