有趣的互動設計概念 (interactive design concept)

感謝 youtube/vimeo and google, 最近看到幾個有趣的互動設計 concept.

* 這是真實物件位置跟背景光影互動

Bouncing Balls from Dofl Yun on Vimeo.

* 這是透過不同感知的方式來展現互動創作的可能性

ensemble project from Dofl Yun on Vimeo.

* 一個有趣的互動 Drum/sequencer (thanks, wilson :) )




* 可提供觸感的 3D 投影 (搭配 ultrasonic pad)




* Wii 的一個新 game, 非常令人深思的遊戲進行方式.

感動的 T-SQUARE 表演

原來以為日本 Fusion 已經沒辦法再打動我了, 果然現場表演才是王道阿, 現場的氣氛讓我回想到以前天天聽他們 CD 的日子. 好聽的音樂還是好聽的音樂, 不會因為時間跟人的改變而改變.

想當年 (驚覺過了 20 年@_@ ) 開始聽 Fusion 這個領域, 最早是因為海國的老師, 拿了高中正義的虹傳說譜給我練, 當時狂練 Yngwie 掃弦的我根本不知道什麼是 fusion, 更不要說知道什麼是 jazz. 只是覺得很好聽, 但是聽不懂. 但是還是很努力的存錢, 買了一張又一張每張 700 到 1,000 起跳的原裝日本 CD. 開始慢慢喜歡上 CASIOPEA 跟 T-Square 這種華麗, 聽不懂, 也不是很吵的音樂.

後來隨著各種音樂越聽越多, 也到了美國這個 Jazz/Fusion 的發源地洗腦了兩年. 看到了許多有名或不有名但超厲害的表演. 也獨自到 NY 窩在巷子�狹小的 smalls, 呼吸充滿 jazz 的空氣, 體驗來自各個不同背景的樂手, 整晚交替表演各式不一樣風格的音樂. 每一個表演都充滿用靈魂敲擊音符的原始音樂能量. 後來有很長一段時間, 很少聽日本系的 fusion, 因為總覺得太拘謹, 過分修飾 (電味太濃) 跟華麗, 缺乏了那種生命推動音符的震撼.

好不容易過了 20 年, T-Square 終於來台灣. 可能很多人不知道 T-Square 這個團, 但其實聽過 T-Square 的音樂, 像傳統日本 F1 的轉播主題曲 Truth 就是 T-Square 的安藤(Andoh) 作品. 還有以前的 Arc the Lad (http://en.wikipedia.org/wiki/Arc_the_Lad_(series )遊戲, 跟 PS 上最有名的賽車 GT (Gran Turismo) 系列, 安藤也是音樂總監跟主題曲作者.

T-Square 官方站: http://www.tsquare.jp/free/index.html

期間 T-Square 團員也更換過好幾次了, 雖然 keyboard/bass/drums 都不是我那個年代的, 不過 "最" 主要的吉他安藤 (Masahiro Andoh) 跟負責 Sax 跟 EWI 的伊東 (Takeshi Ito) 都有來. 表演一開始, 我雞皮疙瘩就起來了, 因為我那時心情很平靜, 以為是冷氣太冷. 不過後來想想, 應該是潛意識的激動. 表演維持個一慣日系的精準, 華麗, 控制, 但是跟 CD 不一樣的是, 現場表演多了一股共鳴的張力. 果然日本 Fusion 也是可以很熱血.



現場表演很讚, 年輕鼓手的能量很夠而且完全的控制內. 加上很多來的人應該對 T-Square 都很熟, 也有很多音樂圈的樂手有來. 整體氣氛其實很 high, 最後 encore 表演 truth 更是熱血百分百. 如果沒提早開燈, 我想應該會 Encore 更多首. 雖然沒辦法像負責導聽的小呂老師有機會參加 T-Square 的慶功宴 ...>_<... 但這的確是難忘的 J-Fusion 之夜.

T-Square 最高....

產品形象 (identity)

昨天到國家音樂廳, 看了我個人非常喜愛的一位吉他手 John Scofield (http://en.wikipedia.org/wiki/John_Scofield) 的 band 表演, 他很喜歡用一般 musician 不會用的 color note, 但是用非常流暢的藍調 a-like phase 跟 shuffle/funk rhythm 來表現他的音樂, 雖然曲目大部分是最近這一張專輯 gospel 類的音樂, 曲目本身結構不像他在純 jazz band 那麼複雜, 但是用音依舊是他自己的 taste, 而且非常 groovy 的一場好表演.

翻翻幾百張因為跟吉他手相關而買的 CD, 發現常聽的幾張, 音色跟旋律線的辨識度都非常高. 而且, 他們對現場即興 (improvising) 演奏的 taste 都有獨到品味難以被模仿.

美國娛樂產業發達, 有同樣技術的太多, 市場 (包含: "消費者" 以及挑選產品進市場的 "唱片公司") 非常注意原創性及獨創性, 所以能夠出現在一般人面前同時受歡迎的專輯, 其實都是打敗了數以萬計的競爭者才冒出頭的. 換句話說, 通常一般人看到的都是已經 build 好的 identity, 經紀/ marketing/promoter 對這些 identity 建立, 都下了許多一般人看不見的功夫 (選擇 artist/包裝/行銷) 在裡面.

人透過 identity (tag/icon) 來認識一樣東西是被從小訓練的. 例如: 受教育的過程本身就是一個 format 認知的過程, 如果大家都考一樣的試, 搶念一樣的學校, 看一樣的 MTV, 把一樣的人當偶像 (藝人 or 非藝人). 說實在的, 如果教育 build-in 這麼深, 要一般消費者有獨立思考跟自我品味這件事其實太強人所難 :)

正因為大家對於 identity 的認知多半來自於外部的描述, 而少有自己的感受, 所以廣告跟行銷手法才有發揮作用的地方. 很多人覺得 identity 是被包裝出來的, 我個人的看法有些不太一樣. 例如, 一般電子產品常見的 identity (簡化的):

* 最便宜
* 最炫, 最牛B
* 最物超所值
* 功能最多
* 服務最好
* 最方便
* 最有品味

其實建立好任何一樣 identity, 應該都可以在市場上存活, 持續重現這些 identity 的能力也都是每間公司的 know-how. 以製造業最擅長的 cost-down 為例, 都會知道一直做到 "最" 便宜其實也沒那麼容易, 因為從流程 - 設計 - 生產, 每個細節都會影響 "最" 這個字, 不小心就會讓 "最" 變得很 "一般".

從另一個角度來說, 當要作一個最有品味的產品, 出發點就是品味 :) 所有的包裝 (marketing/promote) 都會繞著品味打轉. 產品定義的人的 mindset 就跟 cost-down 的人 mindset 就完全不一樣. 人通常也不會是同一種人. 在現實生活, 經常 marketing 要把原先設計 " 功能最多" 的產品, 轉化成 "最有品味" 的產品 image, 其實不是那麼容易. 因為要改變產品的既有印象是很困難的, 除非 marketing 的人找到一個夠好的 story.

我常聽到: A 產品本身就沒有什麼特色可包裝, 所以廣告跟 marketing 效果不好. 但是, 經常問題來自於 A 產品當初建立時就沒有什麼明確的核心思想, 或本來的核心思想跟要進入的市場無關, 所以後來 marketing/promoter 在包裝時, 累得半死想破頭加減一些無關緊要的東西, 目的讓產品在要進入的市場看起來更 attractive, 經常是事倍而功半.

如果能在 identity 中, "建立" 一個市場沒有的字彙, "然後" 又獲得認同. 通常就是該新市場的 leading 角色了. But keep leading always another story :)

硬體產品專案管理經驗分享 - 時程 (schedule)

不論專案或是產品, 通常都有俗話所謂的 deadline 或是market window 限制. 基本上 PM 被賦予的任務就是得到目標後 (明確 or 不明確 :P 的目標都有可能), 在指定的時間內, 協調公司內外部 resource (錢, 人員, 組織), 達成指定目標. 所有的 resource 投入, 都是為了在某個時間點取得某個成果 (working sample/demo/trade show/shipping/etc). 錯過了時間點, 後果通常都很嚴重. 通常影響 schedule 最大的是 scope 變更, 但這裡不討論 scope 變更的問題.

這幾天又在 HBO 看到 "大敵當前 (Enemy at the Gates )" 這部片子, 這個戰爭電影有一句還蠻經典的對白:

Vodka is a luxury we have. Caviare is a luxury we have. Time is not.
-Enemy at the Gates, Nikita Khrushchev

意思是說, 我們可以享用 (一般老百姓沒有的) 伏特加跟魚子醬, 但是唯一沒有時間可以浪費 (Time is not luxury we have). PM 可以協調找到資源, 但是永遠缺時間. 假你錯過時間, 可能產品失敗的機會或隱藏的成本, 一般來說會呈現 "幾何" 倍數增加. 要有一個重要概念: 最後一個月追加 30% 的預算跟 delay schedule 東西 marketing/sales 預估少賣 30% 的量, 到底是哪一個損失比較大. cost 觀念不是只有 PM 要有, 同時專案裡的人對 cost 要有相同共識.

Schedule 這個東西 "看" 起來很簡單, 不過就是做一件事需要多少時間, 把所有需要的時間按照發生的先後順序調整一下就好 (跟 programming 很像, 不是嗎 XD ). 問題來了:

* 如何知道做這個軟/硬體或做這個 project 一共有哪些事情 (scope 有多大)
* 這些事情對應的 function 組織及負責人是誰
* 如何知道這些事情需要多少時間
* 如何分辨這些事情出錯造成的風險跟衝擊有多大
* 遇到問題的應變跟通知對象

這一部分其實就是大部分 Developer 踏入 PM 領域的第一項 "技術" 門檻, 因為瞭解組織跟認識 API/function block 一樣, 都需要時間跟精神. 同時, 跟 "人" 溝通不是 下 command 給電腦, 不是馬上有結果 or 每次結果如你預期一樣. 當然某個程度來說, 做產品/專案有一點像 coding, 只不過 coding 的對象是組織而不是 library. 當然, 你對組織/流程/工具越熟, 就越能有效率跟機會達成原先設定的目標. 根據不同的成長經驗, 每一個 PM 都有每一個 PM 不同的風格, 下面是我覺得一開始比較重要的:

* 了解並釐清公司內部組織跟流程規範

每一間稍具規模的硬體公司, 都會有標準的流程或是 follow 公司訂的 ISO 流程. 認識這些流程是了解硬體相關專案管理的第一步. 台灣從純代工的 OEM 到現在佔世界 3C ODM 跟 OBM 的重要地位也有幾十年了. 從微利的代工開始, 所以設計到製造其實分工很細, 流程本身相對於很多其他產業來說也嚴謹許多, 每一個細節為什麼這樣做都有其歷史原因. 一般來說, 因為其實細節太多, PM 可以了解或不了解, 不懂可以問, 但最好不要用猜的.

* 總共有哪些重要項目, 哪些時間是固定的, 例如 (但不限於):

a. 每一個階段 (EVT/DVT/PVT or 不同 flow 階段) 的 check point 時間, 跟 check point 對應的 check item 是什麼.
b. BOM 裏面的關鍵零組件備料時間 (採購通常會提出一個安全反應時間, 有一些例如: 發 PCB gerber 到交貨時間, 常都是固定的天數)
c. 硬體產品認證時間 (Lab 會評估如果 sample "軟" + "硬" 體都沒問題, 多少時間可測完)
d. 每一個關鍵硬體功能的需要驗證時間 (從發出需求給 vendor, 到 sample 驗完)
e. 採購的作業時間
f. 整合測試的 cycle time, 例如發行軟體測一個 round 需要多少時間
g. 量產從 RD 到 PE 到工廠的技轉時間
h. 工廠的前置作業時間

* 產出重要文件需要的時間請放入 schedule 中

文件通常不是交付或驗收標的物, 所以很多人就忽略文件的重要性. 一般 Follow "標準" (ISO/CMMI) 流程的專案 (如果公司跑 ISO/CMMI/PDM 的話), 會產出一堆的文件, 用這些必然產出的文件當控制點是蠻方便作法. 但是因為跑流程, 有額外的文件負擔, 許多小規模的專案, 常只產出少量文件或完全沒有文件. 因為口說無憑, 進行到後段經常會很難收尾. 如果該產出的重要文件, 我個人覺得還是要放入 schedule 計畫中比較好. 有時前面為了省一些寫文件時間, 後面會浪費更多協調溝通時間.

* 將預先設定好的 milestone, 跟必然產出的文件項目放入 project 管理軟體

用最簡單的例子: product spec 展開後可以有-> hardware design spec + software design spec, 接下來又有各有對應的 verification citeria 跟 factory test item. 這有一定會產出的 item, 可以像樹狀圖一樣依照分類 (軟體/硬體/測試/etc) 先放到 project schedule 軟體, 這樣對整個 project scope 跟各個事件的相依性會清楚很多. 當然, 如果最後畫的出 critical path 更好, 不過在現實世界的互動裡, critical path 會隨專案進行變動的 ;)

* 保持溝通透明與順暢

專案越大, 協調溝通的人越多, 溝通透明跟順暢就越重要. 透明是盡量讓溝通過程中造成的誤解減少, 原則是對事不對人, 記得傳遞訊息的目的是解決問題. 順暢是讓專案成員願意主動傳遞訊息 (不論是好消息還是壞消息). 專案進行中有意識 or 無意識自我過濾訊息, 通常是災難的開始. Schedule 很多東西是看不到的, 通常事情都是發生問題, 才能從 schedule 看到 delay. 溝通的透明跟順暢讓這些看不出的問題, 影響 schedule 的程度減少, 同時縮短下對策的反應時間.

硬體產品專案管理經驗分享 - 專利 (IPR)

記得很久以前, 小時候看天下雜誌還是商業週刊, 提到企業的資訊蒐集及 data mining 能力很重要. 那時只是很抽象的知道這件事很重要, 但是並沒有意識到到底有多重要 (or 多可怕). 工作一段時間之後, 透過許多不同的方式, 看到各家的產業報告, VC (venture capital) 的投資分析, 以及 real world 的專利分析報告. 才驚覺自己所學在整個產業中的渺小.

並不是每個人都喜歡 Intellectual Property Right (IPR) 的觀念, 跟所造成的壟斷跟限制, 但是現在除非是都是以專案 (非歐美地區) 或是封閉性小眾客戶為主, 我個人認為, 做產品很難不遇到 IPR 問題. 所以做某個跟 $$ 相關的決定, 要能先意識到 IPR 問題是很重要的, 因為這代表著隱藏的時間, 成本, 跟風險. 這類跟 IPR 相關的產品管理不是只出現在電子 or 製造業. 其它例如藥品業, 也是產品開發時就已經結合 IPR 跟生命週期管理. 透過有組織的分析各種公開資訊 (專利/法律/財報), 可以看見很多公司內部的訊息, 常見的包含:

* 公司未來可能產品方向跟佈局
* 公司有哪些專利訴訟正在進行 <- 有哪些 IPR 是經的起考驗, 或真的有 value 可以跟人家 trade
* 專利申請人有哪些 <- 通常是有 know-how 的 key man
* 用 IPR 被引用的次數, 做公司實際 value 的評估

另外, 很多人把 IPR 管理/分析, 跟商標/專利申請混為一談. 也很常常見到低品質, 或是其實無任何保護或攻擊效力的專利申請, 當成是 IPR 應用的全部. IPR 這個領域也已經有百多年歷史了, 其實有分工非常細的生態, 不是簡單可以說完的. 我個人是覺得科技業的企業整體戰力, 跟 IPR 法務戰力基本上是成正比的. 產品遇到的 IPR 問題, 也通常跟產品的熱門程度成正比 :)

很多人對 IPR 有很多迷思, 典型的例如: 這個產品是我們自己設計的, 沒有參考別人, 就沒有 IPR 問題. Or 我的 reference design 來自某某知名公司, 不會有相關 IPR 授權金問題. Or 用 Open source 沒有權利金的問題... 很多啦, 這幾個敘述都該打 X, 因為都是錯的 :) . 這邊有幾點常見注意的問題.

* 產品有哪些關鍵零組件 (key components), 這些關鍵零組件本身是否已經 cover 了 IPR (尤其是需要 essential IPR (基礎專利, 簡單來說就是你不可能做出功能一樣, 但是不侵犯專利的產品) 的元件, 如 GSM/3G/etc...)的費用? 一般來說, chipset solution 不 cover 終端產品的 IPR, 而 module solution 有些會, 有些不會. 在選料時要先確認.

* 很多專利 alliance/pool, 是找 manufacturer 簽約付授權金, 而不是根據 design house 或是 branding company 的實際生產/出貨數量. 這會造成 manufacturer 不見得願意付, 或是跟你一起跟 alliance/pool 談.

* 若使用的硬體 chipset 有內建 codec (MEPG2/MPEG3/others), 或 firmware (software) 包含 codec, 就有可能需要付授權費. 簡單的使用者 2 次加工 (例如: 出貨時功能不全, 但使用者把某一個東西放進 device, 或是按下某個鍵, 就可以讓 device 功能完整), 不見得能規避 IPR 的問題.

* (歐洲) 某些國家海關 (如: 德國), 海關可以直接扣押主觀認為有侵權疑慮的產品, 所以可能在沒收到任何 IP holder 的 letter 下, 毫無預警被扣押.

*產品交貨是 FOB, DDU 或是 DDP, IPR 授權金基本上跟出貨地點有間接關係 (who will pay), 在考慮整體 cost 跟 BOM 時, PM 應該把這一部份成本跟 schedule 考慮進去.

* 因為通常一個產品裡面會有多個 function block, 每個 function 都有可能有 patent 的問題. 所以被人發 letter claim IPR fee 時, 先確認人家 claim 什麼? 很多公司都是發警告信, 但是不會在第一時間跟你說要 claim 什麼. 此時不要 panic, 請先回信確認他代表哪些 IPR pool, 他要 claim 什麼?

* 如果產品中有包含 Open Source (GPL) 軟體/tools (如 busybox), 產品相關的 source code 也需要公佈, for example: http://thinkingopen.wordpress.com/2008/06/10/busybox-is-back-back-again/ 如果用到 codec, 還是要付 codec alliance 的 IPR.

當初 google android 不直接使用 Java ME VM 在產品中, 而自己重做 Dalvik VM, 其實也是有 patent 跟策略考慮在裡面, 因為能 open source code 跟能將 code 以硬體產品方式散佈是不同的授權 (不知道有沒有人冒冷汗 ^^!). 其中還點到 MS 跟 Sun 當初對 JVM 交換授權的問題. 有興趣可以搜尋一下 dalvik vm 相關的文章. 例如這一篇: http://www.betaversion.org/~stefano/linotype/news/110/ 裏面把 google 不使用 sun 的技術的原因, 從策略角度上做了不錯的說明. 除了規避之外, Microsoft 買了 Andy Rubin (Android leader) 的前一個 fund 的公司 Danger (同樣 base on JVM), 很多分析家都在看 Microsoft 何時會拿出這張牌.

即使是單純接收資料的 GPS, 可能在不同地區也會被 claim IPR (會發生很奇怪的現象, 收美國軍方衛星資料, 但要付歐洲公司錢??) 所以沒有什麼不會被 claim 的.

相關 IPR 的資訊現在開始越來越多, 下面幾個網站我覺得還蠻值得入門參考的:

* 國家實驗研究院科技政策研究與資訊中心 http://cdnet.stpi.org.tw/intro.htm
* 資策會科技法律中心 http://stlc.iii.org.tw/

參考書籍的話, 周延鵬 (周律師) 的書不錯, 很多 Business 上的細節都有點到, 很值得參考, 推一下 :)