挖趣 wowTree 這個「私生子」出生 10 天了，跟之前我在Yahoo!奇摩所生的兩個小孩--交友、知識+ 相比，在各方面都差了十萬八千里。
雖然如此，我還是非常慶幸我走過這一遭，體驗不一樣的服務製作方式，而不是老用同一招在公司騙吃騙喝。
開發過程的檢討：
* idea 雖然重要，但快速的把它做出來，更重要
** 粗略算算，開發~上線，耽擱了有半年之久。
** 規劃思考，拖到 (後述)。
** 繪製 wireframe, mockup，拖到 (後述)。
* idea 雖然很珍貴，但不必把它鑲嵌在皇冠上，它不會變得更光亮
** 我還是用我在Yahoo!奇摩的模式在規劃思考，儘可能的把挖趣規劃得很週全，ex: 基本運作、激勵模式、社交機制、客服處理...etc。
** 說浪費時間太傷自己，但最後除了基本運作之外，其餘都被工程師刪掉了，哈哈哈~嗚嗚嗚...。
** 即使基本運作，太複雜的部分也被工程師暫時擱置...窘~。
* 別浪費太多時間寫文件
** 產品需求文件 (PRD) 列出大點及扼要說明，規格 (SPEC) 直接放到 wireframe 裡面，其餘細節用筆記下 & 放在腦海。因為工程師不一定會仔細看，即使看了也不一定看懂，省下這些時間，好好面對面溝通/討論。
** 叫我不寫文件，還有點不習慣，雖然工程師叫我儘量少寫一點，但我還是忍不住。最後，我發現連我自己都沒在看（或懶得翻來看）之前寫的文件，而是拿 mockup 及憑腦海印象跟工程師邊討論邊作業。
** 就這一回的經驗，我覺得要好好努力寫的文件是「使用說明」 ，因為會寫在裡面的，就是實際做出來的功能，而且內容要讓服務的使用者知道：這是什麼、如何使用。
* 不要再用 waterfall (一棒接一棒) 的工作模式
** 一開始的規劃，完全是我自己發想、自爽，工程師因有其他事情而無暇參與，以致於我花了不少時間在規劃一個太廣、太複雜的服務。
** 接下來的 wireframe, mockup 也因為規劃的失當，而導致時間的浪費。
** 實際跟工程師討論 db schema 及進行 coding 後，才真正進入二人開發的合作模式，迅速、機動，有彈性。
** 這讓我想到之前公司就是因為 waterfall 所衍生的弊端不少，於是想要導入 scrum (敏捷式開發)。但文件的束縛、人力的不足、部門的角力，使得原本要讓開發變簡單的 scrum 也變得困難又複雜。
* 沒有Yahoo!奇摩的日子
** 褪去了公司光環，我還是可以把產品做出來，但我發覺似乎少了些什麼。沒錯！是那個「聚光燈」~
** 之前在公司面試新人時，他說他來應徵工作，目的是想要進來找出Yahoo!奇摩成功的祕密在哪裡？我當時對他這個想法覺得很有趣，但現在有了感受和體認。
** Yahoo!奇摩的高流量，就像電視的黃金八點檔，具有讓產品瞬間人氣爆發的恐怖熱力。撐得住的話，發光發熱；撐不住的話，人間蒸發。
** 沒有了聚光燈，確實黯淡不少，但我也可以先點根小蠟蠋，然後再找個小檯燈，慢慢發亮。
上線後的反思：
挖趣 wowTree 目前處於充實內容的階段，雖然來瀏覽的人不少，但來建樹的人不多，還好有認識的網友在相挺。而我也重新思考它的定位，畢竟這個產品的出發點並不是要挑戰知識+ (它是大怪獸)，也不是要取代書籤網站 (中重度使用者在用)。
並非所有的事情，都有所謂的「最佳解答」，解答可能有兩個、三個，甚至是一串列表。對於同一件事情，你的解答(列表)，和我的未必一樣，每個人心目中都有他自己的 TOP LIST。
這是上線之後，我才慢慢體認出來的，沒有對錯，只有成敗。只是，我有些遺憾，沒能早一點上線、早一點實驗、早一點體認。
Google Labs (實驗室) 可以很快推出一個試驗品，然後進行 beta 測試、收集 feedback (意見/建議)、數據統計分析。如果實驗成果好，那就繼續研發推正式版，如果不好，那就放著再想想，或許只是時機未到，反正投入的資源不多，不痛不癢。
反觀 Yahoo!，它也有 Labs (實驗室)，是存在公司體制內的實驗室。文件的實驗、流程的實驗、設計的實驗、開發模式的實驗，總是要先通過內部的種種實驗，才能上線接受市場考驗，時間拖慢了、產品複雜了。如果成績不佳，還是得繼續撐著，因為之前已投入太多的資源，不推不行。
下一步：
* 專案 1 號：SiteTag 塞標籤，配合工程師改版。
* 專案 2 號：挖趣 wowTree：持續充實內容，增加/修改小功能，或許去參加 Web 2.0 創新服務大募集，找個公司來認養。
* 專案 3 號：工程師的新 idea，我來規劃機制。
* 專案 4 號：我的新 idea，還在發想 ing。
* 找工作：專案再做個 3~6 個月，沒搞頭就去找工作囉！
寫雜了，只是感觸良多~