敏捷大資料流程

標籤：產品經理   軟體開發   市場調查   資料庫   設計師   

敏捷大資料流程

敏捷大資料流程利用了資料科學的迭代性本質和高效的工具，從資料中構建和抽取高階的結構和價值。

資料產品團隊技能多樣，會產生多種可能性。由於團隊覆蓋了大量的領域，構建web 產品也自然是一個協作的過程。團隊需要方向才能協作：每個成員都應該熱情飽滿而又頑強地追求一個共同的目標。要明確這個方向，需要一個共識。

在協作中達成共識是開發軟體過程中最難的一個環節。軟體Team Dev最大的風險就是根據不同的藍圖進行開發。相互抵觸的願景會讓產品缺乏專註，最終失敗。

有時在實際開發應用之前會做一些樣品（mock）：產品經理進行市場調查，設計師根據目標使用者的反饋不斷改進這個樣品。這些樣品可以作為團隊共用的藍圖。

即使資料本身是不變的，隨著對使用者的瞭解以及外界條件的改變，真實世界中的需求也會變化。所以藍圖也需要隨著時間而變化。而敏捷方法就是為了更好的實現不斷變化的需求，並儘快將樣品轉化成真正能啟動並執行系統而發明的。

典型的web 產品是由表格驅動的，在後端由資料庫中可預料、有約束的交易資料支撐，這和資料採礦產品有根本上的差異。在CRUD 應用中，資料相對一致。資料模型是可以預知的SQL 表格或者文檔，對它們進行改動是產品層面的決策。資料的“見解”則是不相關的，產品團隊可根據意願構建模型以符合應用的商業邏輯。

而對於由資料採礦驅動的、可互動的資料產品，以上任何一條都不成立。現實資料都是髒的，要挖掘就要面對髒資料。假如資料不髒，那就不是資料採礦了。即使是精心抽取、提煉出的資訊，也可能是模糊的、不可預測的。將它們展示給消費者，還需要大量的工作和十分的細心。

對於資料產品，資料是冷酷無情的。無論希望資料能表達什麼，資料對我們本身的意願壓根毫不關心，它只陳述事實。這意味著瀑布模型沒有用武之地。也意味著，樣品也是一個為了在軟體團隊中建立共識但不全面的藍圖。

資料產品的樣品是應用程式的規格說明書，它沒有產品最重要的特色——具有真正價值的資訊。這些作為藍圖的樣品會對複雜的資料模型做出毫無依據的假設。面對一個建議清單，樣品經常會誤導我們。一旦加上成熟的互動，樣品甚至會抑制真相，放大假設。

然而我們知道好的設計和使用者體驗就是要最小化假設。那該如何是好？

敏捷產品開發的目標是辨識出產品最根本的特性，將這個特性先實現了，然後再添加其他特性。這將敏捷帶到了項目裡，讓項目更有可能滿足產品進化過程中最真實、最根本的需求。在資料產品中，最根本的特性會給人驚喜。假如不是這樣，要麼是你做錯了，要麼是你的資料沒有太大意義。資訊有它的背景，如果背景易變，就無法使用洞察進行預測。

敏捷大資料流程