Apr 21st, 2014 by mmdays
傳統的瀑布流開發模式
[圖片來源: wikipedia]
在上一篇文章中，我們提到了網路因為其產品特性的關係，因此帶來了許多根本性的改變。而首當其衝的，當然就是開發產品的方式必須要改變了。傳統的開發方式是一般人所熟悉的瀑布流（waterfall）開發方式，這也是一般在教科書上面會看到的開發模式，這個模式最大的特點就在於是在針對 “需求明確” 的產品所做的開發流程。所以，特別會注重前期的市場調查，也就是大部分產品經理或是行銷經理會花很多時間在處理的 MRD (Market Requirement Document)；然後根據這個這個 MRD 會開始設計產品，好一點的話，中間或許有幾個迭代（iteration），當功能確定之後，就會開始撰寫產品規格書（Product Spec）；根據這個產品規格書，RD 會開始實作；接下來產品會進入到 QA (Quality Assurance)，然後在這產品會在 RD 跟 QA 間來來回回好幾次，直到 bug 收斂到某一個程度後，終於這個產品進入 GM (Golden Master)，也就是說這產品終於要做一個上市的動作了；於是行銷終於可以開始進場大展身手了！這時，時間大概已經過了一年或是過了二年，反正這單位不會是用月來算的就是了。
傳統的方陣作戰隊形，缺少彈性
（圖片來源：www.emersonkent.com）
也許有人會問：「這樣子有什麼不對？為什麼不好？」其實這個開發模式本身沒有錯，但是如果放在網路產業的話，這個模式就會顯得很沒有競爭力。以作戰來譬喻的話，這就好像在戰鬥時選擇了一個錯誤的作戰隊形，而選擇了這個作戰隊形時，其實沒有考慮到武器的進步（科技的進步），以及大環境的改變，只是一味地因循沿用。
Gartner Hype Cycle
2013
(圖片來源：Gartner)
我一直很喜歡看 Gartner 每年發佈出來的 Hype Cycle 圖。看著這個圖上密密麻麻的點，每一個點都代表著一個全新的科技，而曲線上的每一個科技都大到足以改變人類的許多互動行為；而每一個新的科技的實現，則是代表著一個新的 “基礎建設” （infrastructure）被實現了；而這些被實現的科技又將回頭過來影響整個創新的程序，於是最終我們會看到這個點冒出來的速度越來越快，以及這個點往前移動的速度也越來越快。是的，這邊想要表達的事情是，這個世界改變的速度越來越快了，也就是我們所認知的 “戰場的環境” 已經因為網路的崛起而根本上地改變了。所以我們必須要認知到：這是一個不可逆的程序，創新的速度只會加快。
IOT (Internet of Things)
[圖片來源：advisoranalyst.com]
2000 年的時候 Dot Com 泡沫化了，許多人當時把網路看成一個笑話，但是實際上網路才正要崛起；2004 年 web 2.0 這個由使用者產生內容（UGC, User Generate Content）的概念被 Dale Dougherty 提了出來，然後在 2006 年 YouTube 被 Google 以 16.5 億美金收購時來到高峰，許多人以為 Google 頭殼壞了，但是經過了這麼多年後，YouTube 最終成了 web 上面的 “基礎建設”；在 2007 年 Apple 的 Steve Jobs 帶領著公司一腳跨入智慧型手機市場時，許多人覺得他頭殼壞了，竟然想要改變電信公司的遊戲規則；同樣的，當 2010 年當時全部的公司都看好小筆電時 (Eee PC like product)，唯獨 Steve Jobs 堅持推出 iPad 進入智慧型平板電腦市場時一樣，大家等著看他的笑話。不過最終的事實是，現在智慧型手機（smartphone）跟智慧型平板（smart tablet）成了新一代的 “基礎建設”，並且引領了現在 “Mobile Frist” 的設計浪潮。2012 年隨著 Google 推出 Google Glass 之後，穿戴式運算（wearable computing）正式崛起，今年初的 CES 大展上使用者最感興趣的莫過於可以跟網路連線，並能夠記錄自己生理數據的智慧型手環。而隨著可上網的穿戴式裝置的推波助瀾下，現在 2014 年大家開始思考任何一個實體存在的物體是否可以用網路連上網，這個概念也就是許多人所熟知的物聯網（IOT, Internet of Things），現在總算開始站上檯面，並且正以很快地速度移向舞台中央移動。
世界變動太快，你只能掌握方法，而不能控制結果
[圖片來源：theatlantic.com]
所以我們可以看到，我們現在是處於一個快速變動跟高速創新的大環境。而這些高速的創新，很大一部份都脫離不了網路；或者我們可以說，正是因為網路，所以這些創新的程序都加速了。而當越多的裝置連上網後，越多的內容/數據傳到雲端後，整個大環境改變的速度將會越快。如同前面所說的，這是一個不可逆的過程，而且這是一個不斷連續質變的過程（這個部分我們會在之後的篇幅談到），因此任何的預測或是控制，在這個過程中大多都會顯得有點徒勞。而在面對這個快速創新以及快速改變的過程，既然結局無法掌控，那我們就只能將因應的重點放在「面對的方法（approach）」上。以衝浪來譬喻的話，這就好像你不知道下一個浪頭在哪裡，但是只要你掌握了方法，就能在這瞬息萬變的浪潮中抓住讓自己前進的機會。
SCRUM 軟體開發模式
[圖片來源：www.codeproject.com]
既然市場的需求是快速變動的，並且帶有非常高的不明確性，那麼顯然傳統的瀑布式開發方式在這個時代、在這樣子的產業就會面臨到非常嚴峻的挑戰。因此，面對著這樣子的環境，一種新形態並且強調彈性的敏捷式開發（Agile Development） 就孕育而生了。敏捷式開發最重要的精髓就是讓產品儘快面市，也就是非常強調快速發佈（release first）。並且在面市之後，強調迅速地根據使用者以及市場的回饋，快速地改版。而在敏捷式開發裡面，最有名以及為最多人所用的開發模式就是 SCRUM. 而將這種開發模式描述地最傳神的，莫過於小米的用戶體驗總監唐沐所提出的「小步快跑」概念。 也正是因為這產品必須隨著使用者跟市場的回饋而時時改變，因此，我們才稱這樣子的產品為「有機產品」（Organic Product）。
精實執行的模式
[圖片來源：schiffblog.com]
既然必須要快速地跟著市場變動，因此在產品的開發上面就會特別強調精實（Lean）的精神。這個精實執行的模式，通常是透過 Build / Measure / Learn 這個快速的循環來調整產品的方向。因為是要快速地開發（Build）出產品，因此在產品的 launch 階段會特別強調 MVP （Minimum Viable Product）的概念；簡單的來說，就是在每一次更版的時候，開發團隊都要問一個很重要的問題：「哪一個功能開發出來後最能夠滿足目標使用族群？」當然，或許剛 launch 的產品在整體上面根本沒有達到 MVP、也或許團隊自己為的 MVP 根本不是使用者族群想要的 MVP，但是無論如何，及早讓產品接觸市場是非常重要的。
Palm Pilot 的 Pretotype
[圖片來源：Cody Blog]
在精實執行裡面，強調的是快速地接觸市場，不過即使再怎麼快速、MVP 再怎麼精簡，開發都一定會需要時間，有時候光是一個功能的開發就可能需要耗費數個月的時間。這對於重視速度的團隊是尤其不利的，也因此，在最前面的設計階段就開始發展出各種快速製作原型（Rapid Prototype）的方法，甚至是快速製作出能夠模擬出跟最後預想產品樣子的原型（prototype）來做測試而發展出的 Pretotype 概念。這在網站設計上面尤其是比較容易達到的，很多的測試可以透過簡單的到達頁面（landing page）設計，或是其他的類似手法來做市場上的探針（probe）。而這手法其實不是只有在產品剛開始發佈時才會使用，而是要在每一個短期的開發循環裡面都要習慣以及活用這樣子的操作手法。而這樣子的手法，也成了現代網路公司所需要具備的 Marketing 新技能。
數據分析工具之一：Google Analytics
[圖片來源：www.gnutomorrow.com]
我們剛剛提到，即使再怎麼猜測，都有可能有失誤的時候，那在產品投入市場之後，怎麼知道自己哪邊失誤了呢？以及怎麼知道哪些事情做對了呢？其實非常簡單，就是透過 log 使用者行為的數據我們就可以觀察到使用者的好惡了，這比你直接用嘴巴去問還更真實。也因此，在產品的開發階段就必須要同時要考慮怎麼去搜集使用者的資料設計進去，這件事情已經是網路公司在開發產品時不可跳過的階段。也因為可以得到這些真實的數據，因此團隊在檢討以及開發之後的功能時，就不會出現太多自以為是的想法，即使是老闆或是 Team Leader 也要客觀地看待呈現的數據。而這些搜集到的數據，將會帶給整個團隊理解市場的方向以及使用者的行為，讓下一次的產品決策更能符合市場需求。這就是所謂的 Build-Measure-Learn 三個階段的快速循環。
所以在開發上的方式我們可以用上面這張圖的概念來做總結。你的團隊有一個想法了，你很快地做了市場調查（還是要做，但是千萬不要做得太久…），於是你確定這是一個可以切入的市場，我們也假設你的發現是正確的。這時，千萬不要傻傻地想要一口氣去迎合（meet）市場上的所有期待，這是因為現在市場的變化速度太快了，今天可能使用者想要的或是需要的，過了幾個月，這些需求又有了巨大變動。因此，這時你要先退一步想，在這個階段最重要的產品功能是什麼？（MVP 是什麼？），然後快速地開發出來，並且透過 log 的使用者數據來瞭解市場的反應。就跟上面這張圖一樣，有時候你表現得好一點、有時候差一點，但是整體來說，你必須要是小步快跑地快速推進的。然後，重點就在於這整個過程很像「夸父追日」，你永遠無法設計出 “完全” 迎合市場期待的產品，但是透過這個開發方式，可以保證你不會陷入開發出一個 “過時” 且不符合使用者 “現在” 所需要的產品，並且至少你可以 “很接近” 真實的需求了。
我們這邊所分享的網路產業開發方式，是在目前階段的最佳典範（Best Practice），不過在不同的公司或是團隊在應用時，多少都會有些變形或是例外。希望讀者這邊能夠抓到這些開發思維上的精髓，至於執行的細節這就是每一個團隊的挑戰了。在下一個篇幅裡面，我們將會跟各位分享一下網路公司是如何來 “行銷”「有機產品」，也請各位期待了：）
作者簡介：
Sega Cheng (Mr. Saturday)，現為 LiveHouse 及 iKala 執行長，曾任 Google 軟體工程師。
Keynes Cheng (Mr. Monday)，現為 LiveHouse 及 iKala 產品設計總監，臺大資工博士。 本文
出處：http://mmdays.com/2014/04/21/develop-organic-product/
