(原始漫畫在http://zeusflamingstone.com/2008/07/25/chewrihanmailnet/)
(中文版翻譯者不可考，若是有知道的人可以跟我說)
]]>
歡迎舊雨新知繼續支持，基本上用RSS訂閱的朋友不用更改，RSS還是 http://feeds.feedburner.com/pmmustknow
人對了最好，但是人不對，才是職場的常態。
| 上個世紀，一場精彩的音樂表演是一流的古典樂手加一流的指揮家(都是競爭門檻)，把聽眾找進來音樂廳，產品制式化，消費者也很聽話，對於只有這樣的選擇也還滿足。新的世紀，商業競爭像是爵士音樂會。爵士演出的好壞，不只是樂手與編曲，跟場地的燈光氣氛、聽眾的回應、動線安排、現場供應的啤酒都有關係。門票可能很便宜，但琴酒(Gin)也許是廠商贊助的，爵士樂團也不在乎門票收入，只是為了在那邊錄音以後賣CD到唱片行。這個爵士俱樂部，只是為了站穩它是「best jazz in town」的名號，白天時可以出租場地給時尚名流辦派對來賺錢。 |
其實這種多邊化策略越來越多見了，諸如：流行音樂產業中，歌手的主要收入漸漸來自於廣告、代言與演唱會，詞曲創作者的收入主要來源是KTV的點播而非來自CD銷售抽成...等。這本書大家或許不會發現什麼太令人驚訝的理論或發現，但是確實可灌輸自己一些觀念，讓自己能從多邊化的方式來做產品策略的思考。
推薦給大家。
其實這樣的例子屢見不鮮，這也不是說是上司的錯，新產品的發展本來就充滿著風險與不確定性，上司挑剔的理由其實都非常正確，所以在PM理性分析的簡報當中，就算是準備再多充分的證據和數據，要是簡報內容不能引起共鳴，不能打動老闆和同事的「感性層面」，公司內僵化的心智模式，就會讓上司偏向以批判的角度來看待新產品，新產品的構想自然在公司內就沒辦法獲得資源與支持。
那該怎麼對抗公司內部僵化的心智模式呢？筆者很喜歡一個關於IDEO的例子，跟大家分享。(摘自創意黏力學)
幾年前，一群醫院管理人員請了 IDEO 設計公司來幫他們改善醫院的工作流程。IDEO 團隊非常明白自己的建議將會遭到醫院內部的極大阻力。要讓醫院員工有作改變的慾望，第一步就是讓他們明白醫院有問題，然後讓他們關心這問題。
於是
IDEO
團隊製作了一部錄影片，是從一位骨折而住進急診室的病人的角度拍攝的。在這錄影片中，我們看到的就是病人看到的。我們就等於是病人。我們穿過門進到急診
室，到處找掛號說明，跟住院工作人員打交道，而他們講的是一套外國的醫學用語。最後，我們好不容易躺到擔架上，在醫院裡被推著走。我們看到大串的醫院天花
板。我們聽見殘破的聲音，因為看不見說話的人。偶爾他們會探頭進入我們視界之內。更常發生的是，有大段停頓時間，我們停著不動，瞪著天花板，不知下面會發
生何事。
珍﹒富頓﹒蘇麗是 IDEO
公司的心理學家，她說這段影片播給醫院員工看時，當下就產生震撼。「第一個反應總是比如『哇，我從來沒意識到……』」蘇麗說她很喜歡「意識到」這個詞。在
沒看影片之前，對於員工來說，這個問題並不真正存在。她說，而在之後，「他們就感到有解決這問題的立即動力。那不再是待解決的問題清單上的一個問題而已
了。」
IDEO
公司也製作了一些角色扮演的練習，讓職工們從病人的角度看事情。這些練習包括了，比如，「假想你是法國人，你想找你在醫院裡的父親，但你又完全不通英
語。」IDEO 公司已經以這種迫使員工同情客戶的模擬訓練聞名。在某些情況下時間似乎會侵蝕人的同情心，而 IDEO
的模擬訓練就能重建我們對他人的自然同情心。蘇麗說：「商業世界往往強調模式而忽視個體。模式的理性層面讓人們無法再關愛。」
這項覺悟──同情心生自個體，而非模式──把我們在繞了一大圈之後又帶回到本章開頭那句特瑞莎修女的名言：「如果我看到的是群眾，我絕不會有行動。如果我看到的是個人，我就會。」
這個IDEO的例子告訴我們，PM在提案的時候，讓公司內的同仁和上司有 "fu" ，是非常重要的，怎麼樣才讓PM的提案有fu呢？筆者有幾個建議：
有些朋友可能不知道使用者訪談研究是什麼，在這邊補充一下，基本上也是一種針對「易用性」的一種觀察研究法，事後受測者錄影的錄影帶，可能也會拿給工業設計部門或是PM觀看，從觀看錄影帶的過程中，會得到一些質性的資訊，藉以改善「易用性」方面的設計。
而易用性的焦點團體訪談法，與一般在實施焦點團體訪談法時，會有許多不一樣的地方，因為易用性的焦點團體訪談法，主要目的不在於收集意見，而是要理解消費者內心的認知歷程，進而改善意用性。
了解使用者在接觸目標網站的時候，會喚起哪些過去的經驗，而這些經驗又產生了什麼樣的影響，就是易用性焦點訪談的重點。所以在訪談過程當中，主持人會根據受訪者的回答，來作為推敲使用者認知歷程的證據，而且也會隨著焦點團體訪談的進行，隨時更進一步詢問，來收集更多的證據，來推演出目標消費者的認知歷程。
了解目標消費者的認知歷程後，就更能站在使用者的角度，確實了解網站為什麼不好用的「理由」，有了這些「理由」，產品設計者就有改版的依據，讓產品的易用性提升。
以下大略敘述一下易用性的焦點團體訪談的流程，老師這次講了兩種，一個是可理解性，另外一個是可學習性。
目標對象篩選：網路中度使用者，會收發Email與瀏覽網站，但是又不像重度使用者那樣，極度熟悉web 2.0服務。
可理解性的焦點團體訪談：
可學習性的焦點團體訪談：
在經過兩種焦點團體訪談後，老師舉了幾個他執行過的網站作為範例，筆者在這邊就不一一舉例，但是在這邊整理一些網路服務常犯的issue給大家參考。
簡單的說就是看到一個東西後，使用者對其功能的認知。老師舉了個令人印象最深的例子，就是高鐵的收票閘門系統，大眾在使用高鐵的收票閘門系統，通常都會被激發起使用ATM提款機的經驗，將沒有磁條的一面朝上插入，但是偏偏高鐵的收票閘門必須要將有磁條的一面朝上，所以造成非常大的使用不便。
可學習性，使用者接觸系統之後，很快的知道如何完成作業。
一個系統的可學習性高低，其實和使用者的背景有很大的關係，譬如：一個宅男，對於3C產品的可學習性當然非常高，但是對像筆者的父親而言，就算想要註冊個yahoo拍賣的帳號，其過程之煩瑣，使得他望之卻步。
效率，使用者熟悉系統之後，能夠很有效率的完成作業。
可記憶性，一段時間過後，還能記得如何操作。
錯誤，系統可以避免使用者犯錯，萬一犯錯也有機會回復。在犯錯後具有可回復性的系統，也會讓使用者比較願意去嘗試使用。
滿意度，系統應該主觀上讓使用者覺得喜歡。
筆者認為滿意度是個很主觀且整體的指標，使用者對產品滿意，可能是因為外型漂亮，可能是因為觸感很好，當然也有可能是因很有效率的將事情完成。
筆者覺得有幾個指標或許也可以納入考量
可察覺性，產品常有很多很棒的功能，但是都沒人在使用，這就是可察覺性的issue。
舉個例子來說，手機現在的功能其實幾乎事無所不包了，擁有上百種功能，但是一般人常用的功能只有5種。但是iPhone問市之後，它在可察覺性的部分做的很好，使用者在使用iPhone時，常使用的功能數目，遠較其他廠牌手機高出許多。
彈性，使用者若不遵照最佳使用方式(best practice)下，仍然可以完成作業。
諸如：允許使用者中斷操作流程後，之後還可以接續之前的流程繼續。或是使用者不一定要遵照Step1->2->3的順序，也可以採用Step2->3->1的執行方式，來完成作業。舉個例子來說，我們在Smart phone上撰寫note時，可能會剛好碰到臨時有電話打進來，好的設計應該要能夠在結束電話之後，還能讓使用者繼續編輯剛剛尚未完成的note。
不過呢！在實際應用上，該怎麼知道自己的產品或系統所提供的「彈性」夠不夠，筆者現在還想不出什麼較佳的衡量方式。
例外狀態適應性，使用者若不在最佳情境下使用，也可以輕鬆完成作業。
譬如說：手機使用的場合可能是在安靜的室內，也可能在吵雜的室外；某些品牌的手機話筒的收音功能，會把背景的吵雜音，收的比使用者講話的聲音還大，造成對方聽不清楚的狀況。
產品概念本身的複雜度，其實產品概念本身的複雜度，往往都是影響易用性最大的關鍵。
筆者認為，一個產品概念若是含括太多範疇，其實應該就要考慮開始刪減或是隱藏起來。這些相關ISSUE其實在前田約翰的簡單的法則，有敘述到不少。
產品概念的複雜度，最容易的就是採用電梯測試法，若是產品設計者都沒辦法在30秒內將內容說清楚，那肯定是太複雜了。
但是有另外一個面向也是必須要被考慮的，有時為了易用性而更動了產品概念本身，就必須要注意是否因為易用性而影響到了市場性。
以上這些易用性指標，其實很難讓每個指標都達到一百分，常常發生的狀況是，要提升對外型的滿意度，通常都會導致對其他易用性指標的降低；譬如說：iPhone將外型做的很簡潔漂亮，但是要利用iPhone進行撥電話時，其所需的操作步驟硬就是比HTC的手機還要多，在效率這個指標上，當然iPhone就遠不如HTC的手機了。
這些指標上的衝突中，有時候是可以靠設計的創意，來突破非得在二個相衝突指標中2選1的困境，但是很多時候都得是要在其中求取一個平衡，至於怎麼求取平衡，筆者也在學習中，有心得以後再來和大家分享。
usability study要尋找多少參與者？
早期研究時，需要較少的參與者來辨認usability的議題。但是，當研究越接近末期，就需要越多的參與者來辨認剩下的議題。初期可能只要3~5個，到了後期為了做出可量化的統計報告，就必須尋找更多的受測者加入。
between subject和within subject在usability study上，各有何優缺點？
(關於between subject和within subject是什麼，請看這裡)
基本上這二種study是可以混用的，根據你的目的和成本，可以做調整。
有沒有可以消除學習效應或遺留效果的方法？
但是當任務之間完全沒有任何關連性，或是任務次序對調，會導致測試不合理，就沒辦法使用以上方法。
我們來看一下另外一則讓筆者驚喜的廣告，類似的行銷訊息，不同的表現手法。
我個人還挺喜歡吳念真的最後一句「若是你感覺賺到笑出來沒關係！」，這句話非常有畫龍點睛的效果，而主要的目的，是在一堆優惠的訊息轟炸之後，用這句話來勾起「賺到了」的「共鳴」。
另外利用生活中的惱人情境，也是很好的共鳴方式。筆者最近看到最令我共鳴的一個廣告，就是下面這個廣告，這個廣告的鋪陳相當引人注目與共鳴，廣告裡面的對白，都不知道在生活裡面發生了多少次，很容易就勾起共同回憶產生共鳴。
不過很可惜的是，筆者還以為這個鋪陳是要帶出SE新的手機的出現，沒想到只是個抽獎活動而已，這前面的鋪陳雖然引起共鳴，但是和後面的促銷活動之間的連結可能弱了些，這是很可惜的地方。
替消費者點出他們所不知道的問題，也是一個引發共鳴的好方法。另外一個吳念真導演的廣告--威寶日租型的方案，就是採用這種方式，也非常有Fu。這個廣告透過Problem - solving的手法，來替消費者有「原來如此」的感覺，自然引起了不小的共鳴。而根據調查顯示，這個廣告的效果也非常之好。
當然，以上是筆者的主觀觀賞經驗，是不是在調查數據上就特別突出，還有待查證。但是這些廣告還是可以帶來給我們一些學習，也就是在設計行銷溝通訊息時，不只要要求自己或廣告公司設計出「清楚」的訊息、「吸引目光」的訊息、「有創意」的訊息，甚至是「有質感」的訊息。但是千萬千萬別忘記了，產品經理要站在消費者的立場，去思考這個行銷訊息：
這種時時檢驗是否有「共鳴」的思維，就是產品經理的必要修練與不可逃避的任務。
事實上，大家都知道，這種類型的專案是存在的，但是這種專案一定都是非常簡單的專案，利潤不高，而且競爭者多。而大部分的接案情況並不是這樣進行的。比較接近真實的狀況如下所示（有些也是筆者在當客戶端時發生的狀況喔）。
身為一個接案單位的人，面對真實世界的狀況，若是以為透過教科書中教的流程管理手法，包括詳細的資料表、查核清單...等，就可以保證專案成功，那這樣接案單位的PM，大概找個機器人就可以勝任了。事實上，資料表、查核清單...等，確實是很好用的專案管理工具，但是過於在乎這些工具，反而會忘記其實接案的時候，其專案管理的重點應該在於「人」與「管理預期」。而就「人」與「管理預期」這兩個課題來說，最重視的反而是是「領導能力」與「溝通手法」。
未完待續...
http://www.fakenamegenerator.com/
這個網站可以讓你產生適合各國國情的名字，裡面可以選擇德國、西班牙、俄羅斯...等。而且最重要的是，請看紅線部分，他會告訴你，這個名字可以直接拿去註冊Domain Name使用。這真是太方便了。
其他還有一些網站也不錯，但是就是沒上面這個網站方便。諸如---
http://www.dotomator.com/web20.html
這個網站雖然沒有Fake name generator方便，不過他取的名字倒是挺Web 2.0的，值得推薦，不過就是還要去check這些名字的domain name是否有被註冊就是。
再來這個網站也不錯，http://www.netsubstance.com/
這個網站可以讓你輸入你想要的關鍵字，然後這網站會弄出一堆合成字產生在畫面右邊給你做參考。
再不然就從街頭找靈感，看看大家都說些什麼黑話。這個俚語辭典相當的推薦。對於激發創意也相當有幫助。
http://www.urbandictionary.com/ 
同場加映，幫助你想名字的好書，「行銷的語言--一句話讓產品賣翻天」，這本書大概是我看過命名的書中，最棒的了。
同場加映，有名字後，常常都還要需要想Slogan，筆者相當喜歡這個網站，因為這網站是街頭俚語的收集網站，裡面常會有意想不到的驚喜喔。
http://www.clichesite.com/
| 項目 | 敘述 | 測試人 | 發現日期 | bug修正負責人 | 修正日期 | 備註 |
| -- | -- | -- | -- | -- | -- | -- |
| 項目 | bug歸類 | 敘述 | 測試人 | 發現日期 | bug修正負責人 | 修正日期 | root cause | 備註 |
| -- | -- | -- | -- | -- | -- | -- | -- | -- |
然後「root cause」的意思是說，從研發人員角度看，有時候很多個根據UAT測出來的bug，其實原因都是同一個，而「root cause」就是用來填寫這個原因的欄位。
產品經理多寫「bug歸類」這個欄位有什麼好處呢？就是讓老闆看到這bug report後知道，在這麼多的bug上，不是每件事情都一樣嚴重，而是有輕重的分別，例如：UI需要調整的bug嚴重度，就比當機輕微多了。而且可以根據這些分類，上頭老闆可以很快的了解現在系統的可用度，而不會因為看到一大篇bug list，就覺得系統一無是處。但那為什麼不用「嚴重、普通、輕微」的分類呢？這是一種在報告上預防辦公室角力的方法，不要到時候老闆因為bug被歸在「輕微」的分類，就用經費不足或時間不足的理由，把它搓湯圓搓掉了。產品經理把bug分輕重，是為了解決辦公室政治，但對消費者而言，是每一個bug其實都一樣重要，一個bug沒解，產品的完整性就低，其user experience就差，造就失敗的產品。
那研發小組為何要寫「root cause」呢？一方面是逼迫研發單位不要因為趕進度，對於bug就見招拆招，頭痛醫頭，而能去真正的尋找根本原因。二方面也是讓研發小組對自己小老闆也有個交代，讓他們可以根據「root cause」解釋說：「雖然有上百個bug，可是真正的root cause只有5個，所以雖然PM列了幾百個bug，可是實際上只有5個」。這樣一來，研發小組成員績效也不會因為這份bug list而變差，甚至有可能還會被嘉許呢！
簡單的說，產品經理發的bug report，要能同時考量到對方的績效指標，也要同時考慮產品目標的完成，這樣才會是一個兼顧辦公室政治與人性的bug report嚕。
缺點