- 1月 03 週六 200913:54
易用性演講摘要與心得 part I -- 衡量易用性的指標
- 12月 31 週三 200814:29
Usability Study該怎麼選擇受測者
關於usability study來說，選擇參與者一向都是非常重要的課題，而從Measuring the User Experience這本書內容來看，筆者摘要如下：
為usability study選擇參與者要考慮的條件是什麼？
你選擇的參與者能多成功地反應你商業目標上的目標族群？
是否要將資料切割成不同種類的參與者？
為usability study選擇參與者要考慮的條件是什麼？
你選擇的參與者能多成功地反應你商業目標上的目標族群？
是否要將資料切割成不同種類的參與者？
- 在某些領域自我回報的專業〈初學者、中級者、專家〉
- 使用頻率〈如網站造訪次數、每月使用頻率等〉
- 與相關物品的接觸經驗多寡〈天數、月數、年數〉
- 人口統計資料〈如性別、年紀、地域等）
- 其他跟產品有關的功能或特性的熟悉度
- 12月 29 週一 200801:36
給PM的寓言漫畫
凡事一定有更好的方法，絕對沒有二選一，而是有更棒的更創新的第三條路，與大家共勉之。
(原始漫畫在http://zeusflamingstone.com/2008/07/25/chewrihanmailnet/)
(中文版翻譯者不可考，若是有知道的人可以跟我說)
- 12月 16 週二 200803:03
專案外包的衝突與兩難--delay篇 I
這次我們來談談delay。
delay對專案來說，是件非常容易發生的事情，就算是經驗豐富的專案經理與專案團隊，還是很難避免delay的命運。可是當我們參閱許多專案管理的書籍，確實有許多關於專案時程控管的知識，諸如：甘特圖、WBS、PERT、Critical path...等，但卻很少提及應該如何面對delay，又該如何處理delay，這方面的課題確實為一般專案管理書籍所忽略。
要學會面對delay，要先知道delay是怎麼發生的。
承包商執行面的問題，諸如：承包廠商內部分工的問題，關鍵人物離職、業務為了搶單亂開支票。
客戶端執行面的問題，譬如：客戶端該給的文件、圖片、流程...等，時間都到了，但是都沒給齊，承包商當然沒辦法繼續做下去，專案當然就會delay。
承包商對Scope所需執行時間評估錯誤，專案團隊不太可能對專案Scope所有內容，都具備相關執行經驗，那些沒有執行經驗的部分，所需時間就很容易評估錯誤。
客戶的需求總是會一直改變，當Scope change發生後，但若PM沒相對應的去要求Schedule的改變，那後果當然就是delay了。
在專案整個進行的過程當中，承包商和客戶之間對Scope的理解，其實是一個動態變化的過程，也就是說在專案初始，客戶其實對自己要的東西也只有八成把握，承包商對於客戶嘴巴裡的八成把握，頂多也只有七成理解正確，兩造心目中的Scope，是隨著專案的進行，產品慢慢訴諸具體化後，才慢慢收斂在一起的。而隨著Scope的收斂，專案Schedule的估計也會越來越準確（如下圖所示）。但通常我們所定義的delay，就是以估計誤差最大的「專案起始期」所訂立的時間表來做為標準，想當然爾，這樣的時間表當然會很容易發生delay的情況。
- 12月 11 週四 200801:55
電視廣告memo-La new篇
La new之前的電視廣告很有意思，它雖然都是廣告護士鞋或教師鞋，筆者雖然不是護士也不是老師，但是就是對La new留下「這品牌鞋子很像舒適」的感覺。
廣告對PM來說是個很有意思的效法對像，因為PM在設計產品的時候，都會落落長的寫一個power point，來敘述產品的賣點和特色。殊不知當PM開始與通路和業務甚至是消費者溝通的時候，PM準備的溝通素材越多，就會越沒有效果，除了沒有耐心記住這麼多賣點之外，對於產品訊息的傳播，也會有很大的阻礙。
La New的廣告有意思在於，它就找了群不一樣的使用者，這些人不是大明星，而是你我身邊的一般人（人類的認知系統很有趣，對於自己身邊接觸的到的人，對廣告訊息產生的感受，和大明星代言所產生的感受，會有非常大的差異），這些一般人，他們的職業對鞋子舒適度，應該是非常要求的使用者，但是長年來都沒有人特地拿他們當作廣告的主角。也許真正的護士和老師，不覺得La new是最佳選擇，但是La new這些廣告，以後見之明來說，或許它真正的廣告對像是一般大眾，只是藉由這些特殊職業的人士，像大家傳遞鞋子好像很舒適的感覺。
廣告對PM來說是個很有意思的效法對像，因為PM在設計產品的時候，都會落落長的寫一個power point，來敘述產品的賣點和特色。殊不知當PM開始與通路和業務甚至是消費者溝通的時候，PM準備的溝通素材越多，就會越沒有效果，除了沒有耐心記住這麼多賣點之外，對於產品訊息的傳播，也會有很大的阻礙。
La New的廣告有意思在於，它就找了群不一樣的使用者，這些人不是大明星，而是你我身邊的一般人（人類的認知系統很有趣，對於自己身邊接觸的到的人，對廣告訊息產生的感受，和大明星代言所產生的感受，會有非常大的差異），這些一般人，他們的職業對鞋子舒適度，應該是非常要求的使用者，但是長年來都沒有人特地拿他們當作廣告的主角。也許真正的護士和老師，不覺得La new是最佳選擇，但是La new這些廣告，以後見之明來說，或許它真正的廣告對像是一般大眾，只是藉由這些特殊職業的人士，像大家傳遞鞋子好像很舒適的感覺。
- 11月 24 週一 200803:01
能產生共鳴的廣告範例
一直以來，產品經理在產品上市之際，有一個很重要的任務就是，用行銷訊息使得消費者產生共鳴。注意喔，是要有共鳴，而不單單只把產品的訴求點傳遞出去而已。
最近筆者看了一些廣告有些感觸，同樣都是訴求話費便宜相關的訴求，不同的廠商之間的表達方式差異。以往筆者在擔任PM的時候，跟廣告公司brief過產品的特色和賣點之後，廣告公司回去腦力激盪後的腳本，大概就是下面這個廣告的模樣，有著清楚的訊息傳遞，但是好像少了點什麼。
最近筆者看了一些廣告有些感觸，同樣都是訴求話費便宜相關的訴求，不同的廠商之間的表達方式差異。以往筆者在擔任PM的時候，跟廣告公司brief過產品的特色和賣點之後，廣告公司回去腦力激盪後的腳本，大概就是下面這個廣告的模樣，有著清楚的訊息傳遞，但是好像少了點什麼。
- 10月 27 週一 200802:06
專案外包的衝突與兩難-引言
過去，Mr PM都是處在發包專案的角色，現在因為自行創業，必須將30%的力氣拿來接案來養公司，所以開始有了些接案的經驗。而同時扮演過發專案和接專案的筆者，或許有些經驗可以來分享給大家。
我們這邊來看看，最理想的軟體接案流程是什麼？
客戶很清楚Spec或User Scenario，詳細的告訴接案公司，雙方就依此簽約
接案公司設定了Schedule與Milestone，每個Milestone要交付的事項也被清楚且具體的定義
完美且準時達成了Milestone交付的事項，沒有拖延或爭執
客戶完成專案，而接案的公司也撐到專案保固結束，尾款也順利領到，皆大歡喜
我們這邊來看看，最理想的軟體接案流程是什麼？
客戶很清楚Spec或User Scenario，詳細的告訴接案公司，雙方就依此簽約
接案公司設定了Schedule與Milestone，每個Milestone要交付的事項也被清楚且具體的定義
完美且準時達成了Milestone交付的事項，沒有拖延或爭執
客戶完成專案，而接案的公司也撐到專案保固結束，尾款也順利領到，皆大歡喜
- 10月 23 週四 200813:03
[番外篇] 前英國搖滾團Pulp主唱要來台灣啦
我知道這跟產品經理沒什麼關係，但是因為太令人驚訝了，所以發文一篇以茲紀念。因為這團已經解散，我本來以為我的有生之年再也看不到他們表演了，沒想到，竟然來了台灣。
邀請他的是2008簡單生活節 (http://simplelife.tw.streetvoice.com/news/1017a.html)
而我最喜歡的歌曲「common people」，希望他當天會唱。
邀請他的是2008簡單生活節 (http://simplelife.tw.streetvoice.com/news/1017a.html)
而我最喜歡的歌曲「common people」，希望他當天會唱。
- 10月 09 週四 200817:08
Domain name想破頭嗎? 不妨試試下面網站
(本篇轉自筆者發表在另一個blog的文章)
想Domain name真是個超級困難的任務，一群人鎖在辦公室裡面一籌莫展，有時候好不容易想到個名字，但是卻早已經被人家註冊了。
英文畢竟不是我們的母語，要想個好名字，自己在那邊空想是沒用的，得需要有一些Input，除了翻字典外，或許可以借助一些英文名字產生器來幫忙。
- 9月 15 週一 200812:24
產品經理該怎麼發bug report
bug report，這是產品經理在做完User Accepet Test（簡稱UAT）後的產物，就是根據產品經理手上的Test Case，一樣一樣測試，然後把測到的問題整理成一份報告（格式或許是Excel檔），然後給研發部門參考，也可以當作產品經理與研發單位之間的Tracking List。
看起來很簡單的事情，不就是按照Test Case上的操作步驟，一個一個做，然後把結果不正確的找出來，就這樣而已。雖然僅僅只是如此，但是加上一些辦公室政治與人性在其中的話，那事情就會變得「不簡單」了。
在產品經理發的bug report上，bug項目太多的話，這對研發這項產品的小組，是為讓他們在部門中很「黑」的。因為常常bug list項目的多寡，都會變成部門間的交戰工具，行銷單位的經理內心可能想著：「研發單位之前都藐視我們，或是一直說XX規格做不到，甚至批評起我們的business model，態度非常差。現在bug report上bug項目這麼多，該是好好轟殺這些這些人的時候了」。
但俗話說，冤冤相報何時了，這樣雙方處在緊張的環境當中，合作起來當然也是效果打折扣。若是能夠「以德服人」，讓研發單位好像欠了產品經理一個「人情」，這樣的做法才是高招，未來PM做起事情來也才更方便。
要讓PM能寫出「以德服人」的bug report，最根本的關鍵就是，就是在上頭的老闆通常不會細細的看每一個bug是什麼，老闆只會看到一大篇的bug list，就會覺得系統好像根本不能用，進而推論研發人員沒有認真研發。以下是會造成老闆誤會的bug list格式：
筆者將這個表格修正一下，增加兩個欄位。
大家很明顯可以看到，這兩個表格最大的差異點在於增加了「bug歸類」和「root cause」兩個欄位。「bug歸類」是產品經理寫，而「root cause」是歸研發人員撰寫。
而「bug歸類」的分類法，可以依照產品經理自己的定義，可以分成如：
看起來很簡單的事情，不就是按照Test Case上的操作步驟，一個一個做，然後把結果不正確的找出來，就這樣而已。雖然僅僅只是如此，但是加上一些辦公室政治與人性在其中的話，那事情就會變得「不簡單」了。
在產品經理發的bug report上，bug項目太多的話，這對研發這項產品的小組，是為讓他們在部門中很「黑」的。因為常常bug list項目的多寡，都會變成部門間的交戰工具，行銷單位的經理內心可能想著：「研發單位之前都藐視我們，或是一直說XX規格做不到，甚至批評起我們的business model，態度非常差。現在bug report上bug項目這麼多，該是好好轟殺這些這些人的時候了」。
但俗話說，冤冤相報何時了，這樣雙方處在緊張的環境當中，合作起來當然也是效果打折扣。若是能夠「以德服人」，讓研發單位好像欠了產品經理一個「人情」，這樣的做法才是高招，未來PM做起事情來也才更方便。
要讓PM能寫出「以德服人」的bug report，最根本的關鍵就是，就是在上頭的老闆通常不會細細的看每一個bug是什麼，老闆只會看到一大篇的bug list，就會覺得系統好像根本不能用，進而推論研發人員沒有認真研發。以下是會造成老闆誤會的bug list格式：
| 項目 | 敘述 | 測試人 | 發現日期 | bug修正負責人 | 修正日期 | 備註 |
| -- | -- | -- | -- | -- | -- | -- |
筆者將這個表格修正一下，增加兩個欄位。
| 項目 | bug歸類 | 敘述 | 測試人 | 發現日期 | bug修正負責人 | 修正日期 | root cause | 備註 |
| -- | -- | -- | -- | -- | -- | -- | -- | -- |
大家很明顯可以看到，這兩個表格最大的差異點在於增加了「bug歸類」和「root cause」兩個欄位。「bug歸類」是產品經理寫，而「root cause」是歸研發人員撰寫。
而「bug歸類」的分類法，可以依照產品經理自己的定義，可以分成如：
