敏捷大数据流程

敏捷大数据流程

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

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

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

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

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

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

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

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

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

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

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