意料內的意外 = or != 行銷

電視上新聞 "一直" 看到 Michael Jackson 的新單曲在正式 release 前, 很巧的 TMZ 又在網站上搶先 post 了 47 秒的 MV. 這類搶鮮試聽, 或是滿足人偷窺慾望的 release 方式, 實在覺得是很老的梗了, 不過我想應該還是很有效吧 :) 這類真真假假的娛樂新聞, 本來就很容易引起一般人的注意. 不過, 我是很佩服美國娛樂產業可以這麼快的用 "電影" 的方式, 來 release 最後未完成的 "演唱會". 除了行銷的 idea 外, 當初這些在排練 take 的畫面, 以及相關的合約 arrange, 若沒有充足的經驗, 是很難在短時間內組織出相關產品的.

很多 geek :P 可能會覺得這類娛樂新聞很無聊, 可是如果換一個方式呈現, 可能感覺就不一樣, 例如: 某個水果 3C 產品 release 一周被 hack 了, 或是某 online store 下載的軟體用很笨的 folder 方式保護. 到底是 user 破解了保護, 還是 marketing people 破解了 user 的心防.

世界真是有趣阿 :)

產品形象 (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 上的細節都有點到, 很值得參考, 推一下 :)

硬體產品專案管理經驗分享 - 規格 (specification)

前一陣子有朋友問到硬體產品專案設計/生產/測試該注意到的問題. 本來我想翻一下 google 找一些比較完整的說明 forward, 除本身這個話題範圍很廣外, 不知是我關鍵字用錯還是怎樣, 找不到比較適合的, 就順便就把我覺得 PM 該知道, 該注意的寫出來.

在有規模的系統廠, 組織的分工比較細, 硬體專案進行都有自己公司的標準 ISO 流程或 PDM/PLM 系統. 從前段規格確認, IP 專利分析規避, 合約檢查, 中段的設計檢查, 量產規劃, 到後段生產 flow, 生產 ramp up 該做的流程都蠻固定的, 但項目說起來頗多 (其實是非常多, 理論上所有 ISO 流程文件都會產出, 並且最後入到 DCC (document control center) 做統一管理). 像手持裝置 ("非" feature phone 類的) 變化又更多, 所以, 這邊介紹時會簡化很多.

在這邊除了寫規格該注意的事項外, 我覺得有幾個非技術的事情 PM 要隨時注意, 例如:

* 要保持對狀況的靈敏度 (例如: 要交付的目標是什麼, 目前共識有哪些, pending issue 有哪些, 問題的優先順序跟其他人是否一樣). 重點是, 不要讓自己或團隊狀況外. 你的產品會忠實呈現團隊狀況外的程度.

* 認識 team member 的行為模式, 不見得每個人都是華盛頓 (either 沒事會去砍櫻桃樹或面對問題認錯), 自我感覺良好不是高官們的專利. 從辦公室打掃的, 到公司管理階層, 沒出大事之前大家的感覺都會很好.

* 對自己不了解的問題, 不要輕易放水. 放水不代表不用負責, 只代表還不夠專業.

* 要記得追蹤有風險的決定, 不要以為一開始沒事就沒事. 莫非定律出現的機會通常比你的運氣好. 如果要用趕工 (crashing) 或是同步作業 (fast tracking), 請記得讓大家知道這叫 fast tracking 跟 crashing, 是有額外 cost 的. 要記得警告大家風險成本是多少.

* 問題能早解決就早解決, 拖到最後還是要解. 常見有人剛開始跟你說 ok, 但最後大家都得健忘症, 代價沒人願意承擔. 遇到這種情形, 請把深海魚油跟雞精準備好, 魚油給別人補腦力, 雞精留給自己熬夜吧 =_=

雖然大家都知道這些, 但是常因為現實環境 (成本, 時間, 部門利害關係) 而犧牲. 但是, 不管如何, 還是要隨時注意. 下面每個主題, 都只簡單介紹該領域我覺得最簡要的部份 (也就是包括, 但不限於的意思啦):

* 不要覺得規格確認是 one time work
規格確認不是一件做完就不用管的事, 而是一件到產品 phase out 之前都可能會跟著你的問題. 因為可能發生的狀況太多, 有可能零件停產, 某批零件 quality 有問題, 客戶發現新的設計問題, 有新的法規等... 不過以項目來說, 主要下面幾點:

** 硬體功能需求: 要有哪些硬體功能, 以及這些硬體功能的規格要求. 舉例來說: wi-fi 不是 chipset solution 決定就好, 輸出的 power 跟天線敏感度, 耗電量這些細節都要放到文件裡. 現在 wi-fi chipset 都會有 firmware 或是執行時要載入 firmware. Firmware 經常會有細小的差異跟 bugfix, 這些都會影響中段產品測試, 認證及產測規格. 如果客戶有指定或覺得重要的 test case (穩定在某個環境, 傳輸多少資料的效率或不中斷之類的測試), 請一定要做.
如果 wi-fi 傳輸時要亮燈, 或是可以用 packet 喚醒 suspend (IP phone 標準) 狀態的 wi-fi, 這些都跟電路的設計相關. 通常設計階段還會跟硬體及機構件的 placement (晶片放在電路板哪些位置) 相關, 這些都會影響 schedule 跟最終客戶驗收的 quality, 請注意.

** 與硬體相關使用者行為確認
使用者介面分為兩個, 一個是純軟體的 UI, 另一個是跟硬體的互動 (通常是 LED/按鍵/Dial/track ball 等等). 拿 iPod 當例子來說, 當 iPod 在播放音樂時, 把耳機線拔掉, 音樂就會停. 這就是硬體設計 interrupt 支援軟體行為可能性的範例. 盡可能把所有 user case 釐清楚. 請千萬記住, 硬體是沒辦法跟軟體一樣說改就改. 軟體按 make 重新 compile 的成本很低 (至少一般人感覺很低啦 =_= ), 以為改硬體也是重新焊個元件, 改個電路, 加個電阻或換個 filter. 但是改硬體馬上就有原有料變廢料,重新驗証新料/電路的時間, 新洗板子, 打件驗証的時間, DFM (design for manufacturing) 變更, 這時間跟成本其實是難以想像的高.
或許有人會提 rework 可節省一些驗證的時間, 但是問題是: rework 的 quality 通常不穩定, 很多驗證時會發生: 這是原有的問題, 還是 rework 的問題? 功能可能可以 rework 驗證, 但 DFM 可能還是要重新來一次才能確保 quality.

** 使用環境: 裝置是手持式, 車用, 家用, 工業用, 玩具都有不同的測試規範. 主銷非洲市場跟用在俄羅斯的產品要做的測試重點也不太一樣. 請針對環境可能的需求, 讓客戶盡量描述清楚, 並跟相關人員討論增加一些對應的 test case, 以及對應的入料檢驗規範. 在環測測試中, 你會發覺大部分東西遠比你想像的容易壞, 而零件的價格跟品質大部分都是有道理的. 請記得, 零件供應商的產品規格不檢驗的問題在 "你", 客戶通常是不會找零件供應商的. 東西該摔就要摔, 該震就要震, ESD 該打多少就多少. 產品的 quality 控制就靠這些細節執行. 我也相信 PMI 說的 quality 是 design in, 不是 inspect in, 但事實是: 通常大家都覺得已經 design in 了, 直到 fuse 爆掉那一天.

** 使用壽命: 使用壽命跟產品的成本 Life cycle 管理, 供應商管理, 售後服務都有關係. 跟產品的設計, 用料都有直接的關係. 機構料本身的 cycle 數使用限制, 到 SD 卡插槽的跟 SD 卡接點 pin 耐磨程度, connector 的鍍金厚度. 都是 base on 使用環境跟使用者行為來評估. 另外售後服務的時間, 跟備 customer support 的料的量, 都應該找相關部門以評估成本.

** 認證: 認證大致有幾種 1. 安規 Safty 類 2. 不同國家進口的額外需求 3. 客戶營運商需求 (PTRCB/FTA/etc) 4. 綠色環保類 (Green, RoHS, WEEE) 5. 還有要掛 Logo 類 (Bluetooth/Wi-Fi/etc). 不同國家的安規規定, 也會造成產品包裝/標示/說明書問題, 甚至送認證的名稱都可能會影響後續進口流程及系列產品認證, 這些都在認證時要考慮.

標準的安規例如 FCC/CE, 需要注意的地方是要跟安規實驗室 (lab) 討論 user test case. 產品的硬體版本, 及相關 accessory (尤其是變壓器/充電器), 連接 cable 等, 在進 lab 前請先確認. 同時, 進 lab 前記得要先做 pre-test, 如果 pre-test 沒過, 通常都是有 RD 沒說的隱藏問題, 一般來說送 lab 前還有這些問題, 這些問題都會影響最後 quality.

安規看起來大家都在做很平常, 但其實可以幫你從外部 lab 角度看產品 EMC/EMI 跟穩定問題. 不同國家, 可能有不同的認證需求, 像手機進台灣還要做 NCC. 如果是包含 GSM/3G 功能, 但是使用的是 chipset 而不是現成的 module (如 原為 Siemens 的 Cinterion), CE 還會需要 GSM protocol 相關測試, 這類 protocol 測試一個 run 要上百小時. 如果包含多個 RF 射頻的智慧型裝置, 不同國家還有不同的功率規定及通報規費 and 額外的時間, 請把它算到你出貨的 schedule.

Green 相關常見有 RoHS 跟 WEEE, RoHS 可依廠商宣告書管裡做自我宣告, 這部份每個公司對於廠商宣告書的 policy 跟管理工具都不太一樣. 當然 Lab 也有 X ray 掃描或化學方式可做分析, 但是大部分還是以供應商管理比較多. WEEE 除了要拆解說明書外,還要跟歐盟認可的廢棄物處理商簽約才算有效.

要把 Wi-Fi 跟 Bluetooth 的認證 Logo 合法掛在盒子上, 通常都有額外的認證/測試流程. 想掛 Logo 你必須先加入對應組織的會員 ( Alliance 或是 SIG (special interest group)). 加入價錢從免費 (Bluetooth), 到數千 USD 不等, 你必須選擇適合你的 package. 然後才是根據掛 Logo 需要的條件做認證. 請記得, 有 Wi-Fi 跟 Wi-Fi certified 是兩件事. RD 說功能 ok 不代表你可以掛 Logo. 掛 Logo 不是紙盒上印就有的, 要 1. 加入會員, 2. 做過認證 3. 符合相關掛 logo 規定才算. 最後記得把成本算進去. 有些 Logo 還有 IPR 的費用 (DVD/CD/MP3/etc), 付費方式也不一, 請先注意.

如果是你自己開公司作產品, 或公司本身先前沒有為 device 申請 MAC 專屬位置: 還需要先到 IEEE 申請一個 OUI (就是 MAC 位址前3 byte 啦), USB forum 申請一個 USB ID. 含通訊功能的手機或移動裝置的話, 還需要去申請一段空的 IMEI number 供使用.

IEEE OUI: http://standards.ieee.org/regauth/index.html
USB: https://www.usb.org/members_landing
IMEI: http://www.babt.com/gsm-imei-number-allocation.asp

被忽略的M2M (Machine to Machine / 物聯網)

近來好像大家的注意焦點都擺在小筆電, 或是智慧型手機平台這類產品上. 不論各家廠商如何行銷自己的功能 (多點觸控, 待機時間長, 便宜, UI 炫, 開機使用服務快不快) 但檢驗法則很簡單, 就是使用者 (人) 對於產品的接受度.

小筆電 (x86 based netbook) 目前基本上廠商都只能在 Intel 跟 MS 定下的規則下面玩 (螢幕尺寸, 使用的周邊 chipset, 甚至 Windows 版本). 接下來半年應該是看看 ARM based 的 smartbook 面世後, 看的是一般使用者對於效能及功能上的滿意度. 還有 netbook 跟 smartbook 的 BOM/Retail 價格是不是能重新區隔出一個市場.

Smartphone 智慧型手機看起來雖然家數很多, 目前能提供整合軟硬體的使用者體驗的其實只有 Apple (iTunes/App store) 跟 Blackberry (push mail). 不把 Google/Nokia/HTC/Samsung 算進去是因為 Google 不是自己作硬體, 而 Nokia 的 Ovi store 使用者太少, HTC/Samsung 並沒有使用者忠誠度高的軟體服務.

最近一則新聞沒佔到什麼版面, 不小心閒閒沒事翻 news 翻到, 引起了我的注意. 就是 Verizon Wireless 跟 Qualcomm 要合資組一間專做 M2M 的公司. M2M 是 Machine to Machine 的縮寫, 字面上來說, 就是機器對機器. 寫到這邊, 覺得本篇的標題下錯了. 因為, 今年暑假最 hito 的就是 M2M 啦, 連小孩都愛的 M2M...變形金剛啦!!!

基本上 M2M 涵蓋的範圍很廣, 簡單的例子, 從搭捷運用 RFID 卡到高速公路 ETC 易通機, 或者計程車隊服務都算 M2M 的基本應用. M2M 通常需要整合軟體服務架構及硬體設備, 以提供一個穩定的服務, 所以大部分都是以專案的方式進行. 這裡有一篇介紹 m2m scope 的內容可參考.

http://cdnet.stpi.org.tw/techroom/analysis/2008/pat_08_A021.htm

因為 M2M 中間並不會有 "人", 所以系統穩定性要求很高, 軟體服務設計架構與測試也比一般的 utility 難度高很多. 因為不管是工業應用上的 SCADA 或是移動式車隊服務, 考慮通訊時的狀態/通訊 handshaking 時間窗口/連線穩定都是很大的挑戰. 但是由於資訊服務是內嵌在 M 的 (machine), 所以 M (machine) 只要工作, 就會 "固定" 使用到這些資訊服務跟頻寬, 提供這些服務跟頻寬的公司就可以收到 $$. 這個 ecosystem 裡, 一般通常包含以下的角色:

* 硬體提供者: 製作硬體的公司
* 通訊服務提供者: 通常是電信公司或是網路營運商
* 軟體服務提供者: 提供特定的軟體後台, 以及通訊 middleware
* System Integrator: 整合軟硬體服務

目前專案 M2M 大概包含這些角色. 但是 M2M 是不是只有這樣呢? 前幾年因為專案的關係, 做過一些 M2M applications, 後來因緣際會 Project 剛好有機會接觸到 Dash Navigation 的公司 (前一陣子被 Blackberry 的 RIM 併購), 除了 GPS 導航軟體/通訊服務 (T-mobile/Google wi-fi network)/軟體後台 (JMS/Oracle) 外, 他們基本上扮演了第 5 種角色:

* 整合資訊流提供者: 包含即時路況播送, 網路搜尋, 以及其他 LBS (location based service) 相關資訊提供給 device, 同時 device 也將最新的資料透過內建的統計資料庫及 trigger 將資料即時 feedback 回資訊提供者.

傳統的 M2M 的資料都在原先建好的系統架構中流動, 跟外界基本上是隔絕的. 但是資訊流提供者的角色, 是將整合不同的資訊流 (政府即時路況/搜尋/車隊特定服務/ Telcom 網路) 不斷的將新的外界資訊 Push/Sync 到 Machine 中, Machine 也把資料回饋給外部系統, 讓 Machine 跟 Machine, 以及 Machine 跟人有新的互動可能性. 這也是目前許多 GPS/LBS 廠商, 想要整合的 "功能". 但是, 其實這是一個整合資訊流的新角色.

現在除了 LBS (location based service) 外開始有另一個新名詞 real-time GPS. 也許以後支援這類動態 + 即時 + 雙向交換資訊的 GPS (PND) 會貼一個 real-time GPS, 然後 powered by T-Mobile (or other Telcom) 也說不定.

Dash Navigation 提供不同的資訊流整合 (即時路況/搜尋引擎/來自各地的訊息) 技術, 透過客戶端 request 或將客製化的資訊 push 到每一台 device. 這個軟體 framework 是獨立在硬體之上的, 所以可以預見 RIM 以後, 有計畫提供這類的 LBS based push 服務 (push LBS?).

舉例來說, 這類服務除了可以幫你找附近哪間加油站便宜, 超商在特價外. 對商用人士的服務甚至可能幫你安排兩個人見面的最適當地點, 提供最有效率的評估, 提供建議, 並完成安排行程所有程序 (booking tickets/make reservations/etc).
Verizon Wireless 跟 Qualcomm 的合資 M2M 是只是朝 MVPN 邁進, 還是會像新的整合資訊流提供者呢?

PMP 唸書感想 - 2009

這一陣子離開 Openmoko 之後, 多了很多時間可以做這幾年計畫要做, 但是一直沒時間做的事. 生活也恢復到比較有趣的狀態. PMP 考試是我其中一個前幾年預計要做, 但一直沒做的事. PMP (Project Management Professional) 是一個專案管理的認證, 不是拍馬屁的縮寫 XD . 從 2000 年之後, 專案管理也一直是一個蠻 hot 的 topic, 我想大概是因為這十年來, 許多的公司原本的 operation 模式都遇到成長的瓶頸, 需要新型態的管理與加強原有組織資源的運用能力, 所以專案管理雖然不是什麼新的學問, 但是這幾年在一般公司才開始比較普及.

對很多人來說, PM (project manager, 有些公司把專案經理叫 jm, 產品經理叫 pm) 就只是幫忙管 schedule, 協調人員/資源的一個角色. 但是實際上, 專案管理的範疇並不是只有這樣. 當然, 有去上過 PMP 課程的都知道 PMBOK 9 大流程: integration, scope, time, cost, quality, HR, communication, risk, procurement 跟 42 個子流程 (PMBOK v4). 看起來 9 個流程好像很多, 也不見得組織內會在 Job description 中遇到, 但是我自己的經驗是一定都碰得到, 只不過不見得是 PM 的執掌, 有些可能是其他 function manager 的勢力範圍. PMI 只是把整個 PM scope outline 出來, 這一點我覺得還不錯, 讓所有準備 PMP 的人有心理準備, PM 不是只把落落長的 schedule gantt chart 填出來就好. 就算要填, 可能也要把 critical path 跟 float/slack 一起確認出來, 不然考試就不會過 XD

不過, 只要是流程, 就有 overhead 跟最小經濟規模. 這一點 PMI 隻字未提, 用一句 organization assets 就帶過去了, 也不管你的 assets 是 ISO 還是 CMMI. 還有如何整合 PMI 的 knowledge 到組織系統中, PM 知道這些東西 (像是 project charter) 的重要是一回事, 能讓想要引進專案系統的公司或組織, 提供一個友善的升級或是銜接方法也是很重要的. 我想一般 PM 管 project 內部的事情就管不完了, 應該沒辦法花太多時間對相關專案執行人員解釋每個流程的重要.

在上課期間, 聽到 effective PM 跟 successful PM 這兩個名詞, 感觸還蠻多的. 因為很多人覺得 effective (有效率) = execution (執行力) = successful (成功) 這幾件事畫上等號, 誤以為把 resource 跟時間投下去, manager 們開始緊迫釘人, 不需要特別的 planning 跟 risk management, 不斷的變更 scope, 只要投入的 resource 夠, project 還是可以得到預期的成果. Effective 可以是一種 PM/Manage style, 但是不見得是專案 successful 的保證 (經常只是把錢燒光). 這幾個名辭中都有潛藏的意思跟條件, 不然他們就該是同一個字. 專案經理的職責, 應該還是要確認專案能如 project charter 設定跟 sponsor 的最終期望 (公司或專案成功) 來設定行為標準.

PMP 考題跟模擬題很多問題很有趣, 剛開始讀會腦筋打結. 因為實務跟 PMI 的理想還有一段差距. 問的問題都很實務, 雖然不見得標準答案很實際. 哈哈... 不過, 撇開考試不談, 一個有經驗的 PM 應該是把盡量把答案準備好來等問題. 如果遇到問題再找答案通常都是災難. 當然無法預測的是風險的特色之一, 但是 PM 對大部分問題 (技術問題 or business 的問題) 應該心裏要有底.

網路上很多 PMP 考試的準備方法, 我基本上也是 base on 這些方法. 因為以前微軟 :P 的試考太多了, 對 CAT 類型的考試還有 Prometric 都很熟啦 :P 加上以前 SD 的 70-300 或更早的 Windows Architecture 也是這類模擬兩可 = 看起來沒標準答案的考試. 就上完課當天就向 PMI 提出考試申請, 一個星期通過申請後, book 時間, 強迫自己念書. 雖然還蠻多人警告 PMBOK v4 剛改版上線, 等幾個月在考, 考試資訊會比較多. 但我實在等不及了, 想說做 PM 那麼久, 被 PMI 當掉也不過只是個被 PMI 當掉的 PM >_< 只是考試費 4xx USD...很貴的失敗代價 >_< 第一次 booking 時間約 2 星期後, 發覺唸不完. 趕快延幾天. 考試 200 題, 寫到 3/4 就覺得超累, 因為大部分都要想一下. 還好最後撐完而且有過...PMP 入手. 以前每次想說考完這一次, 就不要再考試了. 不過好像每次都有意外... =_=