2012年4月10日

從需求到設計

(到博客來購買本書)

這本書買了很久很久,一直都沒時間整本看完,每次都從頭看起....orz

看完這本書之後,可以找來看的書有:與人接觸、顧問成功的秘密、領導的技術。

----------

需求要件作業程序(requirements process)--也就是開發過程中,人們試圖發掘什麼是人們想要的(people attempt to discover what is desired)的過程。[27]

許多客戶在與我們合作之前,都希望產品開發程序是一門精確的技術。這些客戶大都是電腦軟體業者--他們一直抱有不切實際的幻想,以為產品開發是一門精確的技術。所以我們引用馮紐曼的名言,以提醒業者注意:「如果你不了解自己所說的事物,即便你遣詞用字精確,也毫無意義。」[28]

如果人們不知道自己的想望,沒有一種開發方法--不論這方法如何精確,如何聰明,如何有效率--可以滿足他們。這就是為什麼我們必須進行需求要件作業--這樣,我們才不至於設計出人們不想要的系統。[28]

有效性永遠優先於效率。即便你相當重視效率,希望達成高效率的開發,你業要先剔除那些沒有人想要的產品開發案。我們也可以換個方式表達:不值得做的事,就不值得把它做好。[28~29]

艾森豪(Dwight Eisenhower)曾說:「計畫書不重要;訂定計畫的過程才重要。」[29]

產品不重要,重要的是過程。[29]

發現什麼不重要,重要的是發現(探索)的過程。[29]

文件不重要,重要的是建立文件這件事。[29]

除非你知道自己想要什麼,否則你不知道你將獲得什麼。[31]

如果你不知道自己想要什麼,或無法陳述出來,你的願望獲得滿足的機會就會降低許多。[31]

如果你說出你想要的,你就很可能得到它。如果你沒說出你想要的,你就不太可能得到它。[32]

產出程式碼和清除蟑螂屍體一樣,是一件瑣碎的工作。[37]

方法改變了問題。[37]

毫無疑問地,正規方法--尤其是自動化的正規方法--已改變系統設計工作的本質。[37]

不僅如此,在一個系統內,正規方法最容易處理的問題,可以迅速被解決,但剩下來的瑣碎(messy)問題,則無法運用正規方式來解決。基於上述兩種效應,問題的本質已然有所改變。[37]

方法改變了問題:首先,正規方法可以處理的問題,使問題的數量減少,導致瑣碎問題的比率增高。然後,由於正規方法原先的承諾,以及更大的企圖心,衍生更多更複雜的問題。[38]

用於處理技術性工作的時間愈來愈少,用於處理人與人之間關係的時間愈來愈多;用於細微末節工作的時間愈來愈少,大問題則似乎永遠處理不完。[38]

任何一種系統設計方法,其中最重要的是表示法(notation),也就是系統概念他自己的符號化方式。[39]

一個好的表示法的重要特質是容易修改,而且不影響需求要件作業的順暢度。[39~40]

一張圖最重要的特質,即是讓每個人都可以看得懂。[40]

地圖和實況不符合時,以實況為準。[42]

最重要的是使用圖表的目的--使用哪一種圖表,必須根據我們手頭上的工作屬於哪一類型,以及我們希望避免哪一類錯誤。[43]

務必記住,客戶只是不懂設計程序,他們在自己的領域裡可是專家(而專業設計者通常不是)。[45]

專家對於圖表都有「初戀症候群」。[45]

在開發產品的過程中,任何一個階段都可能增益其價值,需求要件只是指示方向罷了。需求要件應該被逐句遵守,但也不要矯枉過正。條條大路通天堂。[47]

研究他人,不如檢討自己。[58]

語意曖昧將浪費成本。我們必須去除語意曖昧![58]

對於同一件事物,不會有任何兩個人認知的內容完全相同(觀察錯誤)或完整無誤地保存所觀察到的內容(記憶錯誤)。[66]

我們使用的問句務必精確,更動任何一個字,都將導致問題的意義更動,進而引起解決方式的更動。[71]

幾乎沒有人邊看需求要件資料邊作業,而是根據對於資料的記憶進行作業。因此,容易正確記憶的資料,發生設計錯誤的機率較小。[71]

提出問題的次序,與問題本身同等重要。合理的次序安排,能導致近乎「完美」的解決方案,並能減少不正確假設的數量。[75]

我們了解某件事,並不表示我們能將手上的需要要件,與那件事相連結。[83]

我們只是普通人,不容易看見我們忽略的問題,因此我們需要其他的工具和技巧,以減少語意曖昧。[85]

運用任何新工具之前,我們必須接受一個觀念:完美之人也有能力不足之處。[85]

設計者會犯的一個重大錯誤,即是試圖給予客戶需要的東西,而不是客戶想要的東西。如果你覺得自己比客戶更了解客戶的需要,別以為自己就比客戶聰明。相反地,你應該說服客戶,他們需要你認為他們需要的東西。如果你無法說服客戶,你有兩條路走:一是製作客戶想要的東西;一是拒絕這個客戶,另外找其他客戶。如果你為某人工作又與他的想法不同,不會有完美結局。[86]

「問題」的最佳定義為,你的期望和你的感受之前的落差。[92]

有時候,我們腦袋裡並沒有任何問題,卻有一個解決方案在手--也就是說,已經存在解決方案,現在要找這個解決方案可以解決的問題。[94]

新科技的發明,常常就是先有解決方案,再找問題。[94]

由誰記錄並不重要,重要的是一定要有人把談話內容寫成白紙黑字,交給對方複查,以確認溝通清楚。[110]

後設問題的答案,則能確保雙方循正確軌跡釐清需求要件。後設問題可凸顯許多原本以為無須說明的事項,而這正些事項正是問題的曖昧之處。[112]

經濟學家韋伯倫(Veblen)指出,任何一項變動--不管事最好的或最糟的--必有某些人因而受惠,某些人因而受害。[121]

人際成本最高的部分就是開會。[133]

鍋爐般的會議,足以閉塞每個人的思緒。[139]

究竟為什麼,某人要參加與自己毫不相干的會議呢?答案是,多數人寧可忍受枯燥無聊,已獲得安全感。人們不願意缺席某個會議,因為這個會議可能討論與自己工作有關的事務。因此,他們去參加與自己無關的會議,以免錯失會議中討論與他們密切相關的事務。換句話說,不相干的人參加開會,表示會議的需求要件作業程序不確定。[142]

如果一個開發案必須開許多會,可能表示團隊冗員過多,或是專案的權責劃分不清,以致幾乎每個人的作業都會影響到其他人。[146]

變更會議時間具有漣漪效應,導致更多會議必須變更時間,然後再導致更多會議必須變更時間,擴散不已。時常取消會議或變更會議時間,表示規畫不當,或工作超量,或開發案已處於失控狀態。[146]

眾多心理學實驗證明,有意義的訊息,比沒有意義的訊息容易記憶。...沒有意義的部分最難記憶,而且最容易發生錯誤。需求要件文句也呈現同樣情形。[149]

進行腦力激盪時,應該鼓勵參與者,對於他人提出的概念加以變異,或結合他人的概念,以萌發更多概念。這種「概念改良」並不是對原概念的批評,而是變化原概念。經過變化的概念也是新概念,必須記錄下來。[175~176]

學習繪製草圖,使每一張圖包含足夠資訊,但不可資訊超載;而且,不應精確描述不確定的部分。[189]

重點並不是名稱本身,而是命名作業。[196]

我們可以藉由命名過程,更深入了解問題。[197]

即使人們思考多以圖像方式進行,但人與人之間卻先以名稱進行溝通。聽到一個名稱,聽者就會重建這麼名稱的圖像,因此每一個聽者心中的圖像,不可能與原始命名者心中的圖像相同,所以我們說:一個詞彙抵得上一千個圖像。[197]

名字是被反覆使用的,而且可以激發我們的思維。如果名稱容易被誤解或語意曖昧,麻煩就來了。[199]

開始進行任何一個新專案或附屬專案,或為任何新事物命名,都必須審慎取名,以免被誤解或發生語意曖昧。[199]

如果某專案全仰賴某個人,這人又總是控制不住情緒,則這個案子必然失敗。認為某個案子非某人不足以成事,將使你持續被情緒失控的人勒索。[205]

處理人員對立的秘訣在於勇氣。愈早面對問題,成功的機率愈高。根據我們的經驗,於專案的早期階段,沒有人是無可取代的。拖延將使可解決的問題變成無法解決。[205]

齊聚不同層級的人在一起討論,是解決層級衝突最有效的方法。[206]

調和人際關係的工具也類似,雖然不會傷到你的大拇指,卻可能造成心理創傷,使專案無法成功。[206~207]

一個優秀的會議主席,必須具有專心一意的能力--得以自由觀察、自由詢問、自由發表評論--但必須比大猩猩溫柔。[207]

協調者的第一項工作為釐清並測試雙方的假設。[211]

需求要件作業階段的主要工作,在於決定品質水準以及訂定開發所需時間。[212]

設計團隊必須依序獲取下列資訊:功能(functions)、特性(attributes)、限制(constraints)、偏好(preferences)、期望(expectations)。[217]

每一個有經驗的設計者都知道,失望與滿意的差別不在於產品本身,而在於產品是否符合客戶的期望(expectations)。[283]

開發案進行至某一點時,最佳選擇為,將產品分割為兩個相關產品--一個是便宜又沒有負擔的產品,以吸引新顧客;另一個則是針對喜新厭舊型顧客的精緻產品。何時將需求要件一分為二,是一種藝術,也是一個你永遠必須銘記在心的可能性--尤其是功能表開始顯露出失控狀況的時候。[363]

未經簽名的文件只是沒有價值的紙頭。簽名能增加價值。[373]

需求要件作業階段結束於意見合致,但產品完成之前,需求要件作業永不完工。但某個時點,你認為已有足夠的一致意見,就可以冒險進入設計階段。[376]

沒有人可以告訴你,什麼時候可以躍下萬丈深淵。這是勇氣的問題,面對任何一項需要勇氣的行為,人們都會發明減少勇氣的方法。[376]

我們知道這些同意書將來可能改變;因為在真實世界中,假設會改變。有些人企圖免於假設改變的恐懼,因此凍結需求要件。他們在進入設計階段的時候宣布:不得更動任何需求要件。[379]

凍結需求要件的觀念其實是一種妄想,用來抵制對於需求要件作業結束的恐懼。除非確知有再溝通的可能,我們無法晃心地結束需求要件作業。所以,需求要件作業的最後一個步驟為:雙方同意繼續溝通。[379]

有些決定確實不適宜記錄下來。我們相信,這樣的藉口是一種專業力量的濫用。如果我們還記得需求要件作業的正當功能,這種濫用顯然是可以避免的。[381]

設計者的工作不是決定產品需要什麼,而是協助顧客發現顧客的真正需求。[381]

專業人士應該遵守的原則--切勿答應你明知無法達成的事。[382]

需求要件作業的目的,在於避免錯誤,使開發案克竟全功。當然,你不是全知全能者,不可能永不犯錯。如果你不願意承擔犯錯的風險,如果你不願意承擔表現不佳的風險,那麼需求要件作業永遠無法成功。就像中國那句老話:「富貴險中求。」你必須承擔風險。[382]

如果你希望成為專業的設計者,你必須重新塑造自己,尤其是培養以專業做事的勇氣。不可將全部時間耗費於技術層面的事務,會為他人進行協調。只少要將一半的時間花在自己身上。[382]

特別注意需求要件作業的結束點,因為擔心不完美可能使你陷入永不超生的輪迴。[382]

握有所有必要的同意書,表示需求要件作業已結束。憂心需求要件作業結束,與宣布它已結束,是兩碼子事。如果你不面對自己的恐懼,需求要件作業將永遠無法結束。[383]

所有的參與成員必須同意需求要件作業已結束,否則他們會繼續做變更。當眾人同意繼續溝通時,即表示他們同意結束。[383]

結束需求要件作業就像一本書完稿--尤其書的主題就像需求要件的定義一樣,是開放式的。完稿之後,有時你覺得意猶未盡,但這些情況大多是:早上拿掉一個逗號,下午又加回去。遇到這種狀況,你只須承擔若干概念不完美的風險,以及若干啟示隱而不顯的風險。你只須檢手稿是否完整,然後鼓足勇氣套上筆蓋即可。[383]

商業周刊::一個比喻,勝過六十分鐘銷售

(摘自商業周刊第1272期2012.4.9-4.15)


美國作家奈德.赫曼(Ned Herrmann)這麼說:「比喻是從一種心理語言到另一種語言的翻譯,從字面描述到類比。其力量就如同翻譯所帶來的即刻理解。」


溝通的目的,是讓人領會和感受某件事。而大多數業務員所使用的簡報方式,都無法達到這些目標,唯有藉由比喻,我們才能擴大客戶的理解。


不要期待客戶能自行學會整套全新的原理和概念,你必須利用舊有和已知的觀念,來傳授新的知識。

2012年4月9日

商業周刊::星巴克與超商平價咖啡

(摘自商業周刊第1272期2012.4.9-4.15)



這是社會的常態,每個人都被別人秤斤論兩,每個人也都對別人秤斤論兩。當自己分量不夠時,就要發憤圖強,把自己做大做強,而不是對別人的「大小眼」生氣;對這種事,最好無視而淡然。


在專業上學習、提升,是每一個上班族必然會做的事,多數人也都靠著專業成就自我,只不過大多數人很少重視內在心性的修煉,也才會有類似「專業成功,待人失敗」的現象,這恐怕是當今社會上,每一個專業成功人士最值得探索的課題。

商業周刊::加油、添醋,為哪樁?[王文靜]

(摘自商業周刊第1272期2012.4.9-4.15)


我們是否活在行禮如儀的框架中太久,被形式綁架,忽略探究事情本質。


不論是消費者或職場的工作者,一個思考的人不該被行禮如儀的形式、或日新月異的科技給制約。


加油、添醋,為哪樁?


加油,非不該;添醋,也非不可。重點是,為何要如此。找到事情的「為何如此」,也就找到本質。不論做菜,不論創作,不論工作,重新盤點每一件事的本質,去除無謂的「加油添醋」,會有意想不到的收穫。至少,瞎忙的事,會少許多。