敏捷大資料流程

broadviewbj發表於2014-09-05

敏捷大資料流程

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

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

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

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

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

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

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

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

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

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

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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/13164110/viewspace-1264510/,如需轉載,請註明出處,否則將追究法律責任。

相關文章