2009年10月30日 星期五

Z03 振聾發聵的文章──別把專家當笨蛋(3)

小朋友有天說出他被學校的同學在部落格上攻擊,我們發現對方的文章裡盡是刻薄的字眼。把小朋友叫來詳細詢問事情經過,他起初描述是因為小事有誤會造成的,但是根據小朋友的習性抽絲剝繭後才發現他的行為也不恰當。與老師溝通時,我們傾向於說小朋友目前還是學習階段都難免有錯,請老師教導他們對錯觀念再修正即可;不過老師透露當初看到那些文章時,倒很擔心雙方的家長會在學校鬧出風波。

有些人完全不想學UML,但是在認定UML無用的同時卻無法做出大多數人看得懂的文件;很明顯地這是因為心裡沒將製作文件視為自己該做的事,因而不想要任何對應的處理工具。各類的文件在系統開發階段中一直要求得具備,倘使心裡認定撰寫文件是浪費自己的時間,自然不會在意文件對於其他人與日後自己的影響。要讓一個人願意學UML必須要先讓他認定撰寫文件是必須做的,要能接受撰寫文件是必要的得瞭解文件在各個開發階段的應用,要是心裡打一開始就認定開發方法論無效,就跟之前的我一樣什麼都不用再談了。

“主觀”是個殺傷力很強的念頭,可以將小朋友間的爭執鬧到上法院,可以讓自己變成別人眼中的老頑固,也可以將旁人的心血說得一文不值。同樣是一個人,為什麼從小到大的立場會如此轉變?為什麼會從天真瀾漫變為結黨營私?為什麼在互動頻繁的人類社會裡能夠變得自我中心?不是心理專長的我當然沒有答案,不過我至少發現了一把可以改變自己想法的鑰匙。

人們總是習慣從自己的角度看待事物,唯有學習從不同人的角度重新審視原先熟稔的事物,才有機會突破自己預先設下的侷限,重新顯現出不同的格局。將自己放低後,其他人的經驗與知識自然開始源源不絕地流入,收集眾多的資源後就比較容易分析比較各項優劣。我已經相信這個道理並且開始實行,至於你相不相信?都是你個人的選擇。

2009年10月29日 星期四

Z02 振聾發聵的文章──別把專家當笨蛋(2)

小時候遇到各種新的或不同的事物,總會很有興趣地去學、去瞭解,甚至還會提出一些新奇的想法來嘗試;沒想到這樣的熱忱於長大後卻大多演變為“我不需要”或“看起來沒用”的回應。小朋友前幾天對我說:“為什麼要學勾股定理?根本用不到嘛!”當時我心頭一震,彷彿看到在學校與工作時抵抗著其他知識的自己。我回答說:“學一些知識是讓自己擁有這個能力,未來要從事更高深的科學研究時就有機會用到;當然也有可能用不到,但是需要的時候沒有就是你自己的痛苦。”

同樣地,專家提供根據他們領域知識的精華,根據專家整理過的資訊能夠快速地提升自己的水平;要從一份整理資料裡去蕪存菁地擷取有用的經驗,還是要因為一些蕪而廢棄菁地整個丟棄都是自己的選擇。以往對一件事物習慣去看旁人對它的評論就吸收為自己的看法,藉此來決定是要接受還是抵抗,如今學會反問自己:“我完全瞭解它的意義嗎?能明確說出它的全部優缺點嗎?”,想要有明確而完整的答案,就非得親自去體會不可。

之前與年紀較大的同仁打交道時,總感覺他們的想法非常固執、極難溝通,現在的自己慢慢地朝高齡化發展,卻漸漸發現排斥其他想法與知識的行為與他們類似。似乎具有一種心態,認為某些事自己已經擁有很多的經驗值,如果別人隨隨便便提出幾句話就改變自己,會是很沒有面子的事,所以面對可能的改變時不是消極地掩耳盜鈴當作不知道,就是想出許多藉口來說服自己新的想法並沒有現在心裡面的好。

回憶自己的過去,故步自封的確是因為自己太有自信去控制一切,也就是過於輕視眼前的領域,不想接受其他不同的思維所造成。學歷可以無用,像在大學時我根本蹺課到等於沒去上課,現在的工作目標照樣可以用自己的方式達成;但是要能有良好的做事方法與產出內容,如今相信真的需要先參考專家們的經驗,再調校為適合自己實行的模式才會有機會更上一層樓。

2009年10月28日 星期三

Z01 振聾發聵的文章──別把專家當笨蛋(1)

原始網頁:http://www.ithome.com.tw/itadm/article.php?c=57685

是否曾經有過這樣的經驗?有一個東西在身邊已經存在很久卻一直沒有什麼感覺,等到某天的一個場合再看到它或是某件與它相關的東西,心裡頭各式各樣的想法就不自禁地流動起來,翻騰到最後定型下來卻是另外一個層次的感動。我提到的那個東西並不是女友或妻子(雖然很像是),而是E主管堆在我桌上的一疊書,這篇文章就是引發我不同觀念的催化劑。

Sun的OO-226課程是我接觸OOAD的最初,開始時隱隱覺得這是很不錯的設計作法,但是實際應用在開發時卻有很多無法串連起來的缺漏;累積幾年的經驗後試著以其為藍本,再自行定義一些捷徑作法將所有的點連成線再到面而形成現在的想法。雖然有自信可以合理地做出一些不同的東西來,但是那畢竟只是“用自己的經驗湊出符合既定目標”的產物。

RUP一直是有名的開發方法論,不過很多人的評價都說它過於笨重並不適合實用。在與E主管討論方法論(他傾向用RUP)時我常搬出這類的評價來抵抗,他總會說:“你瞭解RUP的全部作法與其精神嗎?你說得出哪裡有問題?哪些作法適用?哪些作法不適用嗎?”當時我認為這僅是強辯時的說詞而堅持己見,每次的討論也常不了了之。然而我現在已經在閱讀RUP的全部正式文件,因為現在終於明白應該從一個穩固的基礎為起點再用自己的經驗來調校它,並不是自己創建一個全新的作法。

完整的開發方法論是一大群人耗費心血所完成的,定義出所有階段、所有角色、所有行為與所有的產出,相信那都是每個人的多年經驗與思索研究的精華,是一個人在一、二十年的經驗所無法相比的。專家的產出是將其自身經驗輸出為系統化、組織化的作法,進而建構起環環相扣的關聯,在某些細節上或許的作法或許不盡理想,卻也不應因噎廢食而全盤否定。

2009年10月26日 星期一

X07 規畫書撰寫實務課程的收獲

公司打算開一門規畫書撰寫實務的課程,對象主要是業務與市場規劃的同仁。原本不在上課名單內,但是想起上回撰寫規畫書的慘痛教訓後著實希望自己具有這方面的基本能力,因此商請主管在上課的當天硬是向人事部門報名。

課程為十二小時,在授課的中途看著講師整理的投影片對應到之前的問題點時,才發現計畫書的編排除了把內容寫出來之外,是有目標、有架構、有不同角度與不同寫法的,同樣的內容必須根據不同的因素組合來調校。看得出講師在投影片的整理上花費了相當大的心血。休息時間與其他同事閒聊時,他們說雖然教材內容經過整理,但是提出的一些目標與原則感覺根本做不到,譬如說計畫書的內容要寫到能感動人心就太過理想。

認真觀察投影片的結構,慢慢領悟到:對一個難以直接達成的目標,可以拆解為數個可以分開完成的項目,每個項目有自己的作法、輸入與產出。概念就像是下面的圖所表示:


自行推想的思考原則如下:
●每個目標拆解出來的項目必須互斥。(項目拆解子項目時亦同)
●每個目標拆解出來的項目組合起來必須剛好等於目標。(項目拆解子項目時亦同)
●每個作法的輸出必須剛好符合項目的要求。
●每個作法內要有規定的執行步驟
●每個作法使用規定的輸入後,能夠產生規定的產出。

用簡單的一句話表示,會是“精確地拆解,完全地對應”,將目標分割為可以獨立完成的項目,每個項目全部完成後代表目標達成,輔以輸出項目的檢驗標準用以度量目標與項目的進度與品質。觀察自己身邊的許多事若能用這樣的原則處理,相信就會習慣用文件來記錄想法的拆解內容。

註:講師在投影片中根據經驗定義了評審審查的數個重點,根據每個重點建議一些適合的作法。如果定義的審查重點在邏輯上等同於那個目標,那麼針對各個重點的加強就能提升其效果,更有機會達到“打到人心”的目標。

2009年10月18日 星期日

Y08 不要只用技術的角度想事情(3)

業務人員是最貼近客戶的,在拜訪客戶的同時蒐集客戶目前欠缺與可改善的資訊,回報給公司的市場規劃人員作整體性的計畫;以技術人員的立場來說,一直以來都認為這是最有機會瞭解客戶需要的管道。不過,得到的資訊與真實的差距到底有多遠?我在最近才開始體認到其中可能的誤差。

不管是SOA或是服務體驗,初接觸客戶服務時我都直覺地認為不過是“從客戶的角度來想事情”,然而在很多的時候我們只是“把自己視為客戶”來討論;即使直接對客戶訪談或作問卷調查,取得的資訊通常只是片面的資訊,因為得到的答案是經過思考(可能帶有修正)才輸出的。

德國的服務工程與美國顧客體驗洞察技術提倡的是使用科學化、系統化的方法,將客戶的真實行為模組化為數種Model再進行服務設計。剛開始時實在不以為然,甚至萌生不知道為什麼要學習這種東西的負面想法;隨著漸漸瞭解服務的本意,才慢慢明白要用什麼樣的立場與方式去思考客戶的事。現在與技術人員開會(我當然還算是技術人員啦)時,時常會感覺他們看事情的立場有很大的差異,才猛然省悟原來自己以前也是這樣!

從完全不懂到能初窺其奧妙經過至少四個月,心態上也從抗拒轉變接受並嘗試;回首歷程,能不能聽懂是第一個關卡,想不想接受是第二個關卡,會不會去做是第三個關卡。倘使不去嘗試、不去吸收、不去思考、不去改變,是永遠不可能走出現有模式的。

事情常有一體兩面,以往自己獲知一件事時最先想到的都是找出其問題點並提出難以施行的障礙,現在則會先考慮可以順利執行的狀況然後想出困難點再思考克服的方式。從負面指出哪裡有問題的確是技術人員(與政治人物)會最先想到的,我覺得這才是想事情角度不對的最大癥結吧?

2009年10月16日 星期五

Y07 不要只用技術的角度想事情(2)



與不同的同事們聊天時,才發現每個人的設計想法差異很大,最常見的設計想法是將執行交易種類次數報表與記錄模組全部都綁在一個模組裡,然後套用“只作出客戶需要的東西”這個說法。如此一來,這個模組的存在最差的情況下只符合這一個報表,而且記錄的資料元素很可能因沒妥善思考而不足,根本沒法應付未來的各種可能。

不去想其他可能而只注重單一功能,進行速度當然可以很快。但是在未來有需要修改記錄的資料元素才能產生的報表時,就需要改動最底層的模組,連帶地影響其他原本可以正常運作的報表;為了隔絕對舊有系統的影響,唯有copy-paste出另外一套來修改。這樣就產生了號稱絕不疊床架屋的設計──只是同樣的東西有很多套而已。

交易記錄模組是需要良好的設計來提供最大範圍的支援,報表部份則從底層模組取得資料只作客戶所需要的就好。底層的模組用最大化的可能設計來應付未來需求的改變,實際的呈現則只實作客戶提出的部分即可;雖然客戶想要的可能會增加,但是多送他不需要的東西也絕對不會收的。

觀察主管的感覺,發現他們通常會先定出做事目標,然後會陳述做事的順序與原則,但是對於每個步驟所需要用到的資源與可能的困難點幾乎都不涉獵,通常變成很理想化的想法。實際做事的人需要顧及每個步驟的可行性、風險與替代方案,這些都不是只談原則就能夠順利推動,而是需要精確地衡量與思考才有可能做好的。

在主管的想法與實際施行有衝突時,實在有股衝動想跑去主管面前大聲疾呼:可不可以拜託你們從技術的角度來想事情!

2009年10月14日 星期三

Y06 不要只用技術的角度想事情(1)

從程式員的角色成長後,慢慢會接觸到業務與主管等非技術的角色,有時在討論對事物的看法時,他們總會冒出一句:“不要只從技術的角度想事情”。任何事物當然都有不同的切入角度與思考觀點,其他人說這句話時多少都否定說自己提供的僅是片面的想法。然而,只用技術的角度來想事情就表示有缺漏嗎?

在開會時思考系統可以加強的地方時,我想到之前很需要但是沒辦法產生的一份報表(註:不能描述太詳細,就暫時以執行交易種類的次數報表稱之),連帶地想到產生該報表時需要配合記錄Log的各個時間點,並想這個想法整合為一個Log記錄模組的概念。後來將這個概念私下陳述給E主管聽時,他回答說:不要只用技術的角度想事情,不要習慣從bottom-up思考而應該是top-down。意思是說概念要思考能符合客戶的需求且賣得出去才算是成熟的概念。

當時我的腦中忽然發出像是什麼斷掉的聲音,立即有了否定的回答。

現在我需要一份現有系統無法產生的報表,便開始思考要怎麼做才可以滿足自己的需求;發現報表所需要的資料可以從增加特定時間點的Log來取得後,就認為應該有一個專門負責記錄Log的模組來收集各種資料。這個模組概念的產生是由我自己(客戶)需要的報表(需求)所引導出來的,完全符合由上到下、根據使用者需求而出現的想法。

目前其他客戶想要什麼樣的報表我們都不可能知道,即使今天訪談了十個客戶所收集到的報表種類,在找到第十一個客戶時還是有可能要之前沒提過的報表;就算我們想從客戶的角度來思考,也不能肯定思考出來的範圍是不是百分之百。在無法肯定未來變化的現在,我只能以現有模組的角度來定義其中的資料元素(譬如人、事、時、地、物),期望在設計的同時可以有最大範圍的排列組合,而未來客戶想要的報表儘可能地落在設計的範圍裡。



用最小的額外花費涵蓋最大範圍的可能需求,不就是設計的目的嗎?我這麼反問E主管,他沒有反駁。

2009年10月10日 星期六

Y05 都只是為了完成功能……

對程式設計人員來說,被要求的結果就是要寫出能達成需求的程式碼,而最尋常的情況就是遵循最簡單的道理:產出一堆可以完成功能的程式碼交差。暫且不管程式碼對於功能是否有多餘的設計、也不管程式流程控管的處理是否完善(這些是程式碼與功能的內容對應),光是“程式碼為可見之物”這個事實就會衍生出一些管理的事。



就像作文一樣,看到題目之後心裡就要先有文章的架構鋪陳;功能明確之後同樣會有執行的順序。如同作文時的擬定大綱,設計程式也需要概略描述達成功能的過程。作文的大綱完成後要開始逐段、逐句、逐字寫出文章,程式碼的產出也是如此;其中的差別在於作文強調的是從頭到尾、一氣呵成的感覺,寫程式除了這個感覺之後還有逐步的例外處理。

寫出程式後需要經過測試來精確地保證功能可被達成,測出錯誤會使得程式碼有再次的修改,每次修改都會有版本的記錄;每個版本各修改了哪些地方,造成什麼影響都必須要能迅速查詢到。怎麼佈置、怎麼撰寫、如何保證與如何管理,是因為有程式碼的存在所連帶產生的四件事情,標準化的做事會有方法與準則,這意味著還要定義出至少四組的做事方法與做事準則。倘使做這些事的過程裡需要有其他的物(工具)協助時,還會再衍生更多的事……。

只是為了達成一個功能,在產生程式碼的過程需要考慮很多其他的事,可以想見如果沒有全面性地看待而只注重在如何完成功能,就會造成除了執行正確之外的全部都有潛在的問題。雖說完成功能是最終目標,然而考慮程式時常被修改的特性後應同時注重其他方面的要求。

2009年10月6日 星期二

X06 建立小朋友的能力架構

在小朋友的成長過程裡,父母總會希望他們具備各種能力以應付日後社會上的各種競爭。有些父母會以“多才多藝”作為小朋友的學習目標,但是學習項目過多會使得小朋友們失去童年的時間,因此我的想法在於建立他們的能力架構。能力架構倘使可以適當地建立起來,日後可以根據個人的興趣喜好選擇適合自己的項目,再經由這個能力架構達到更快速的學習與產出。



能力架構的想法類似於電腦的架構,在最底層的需求有輸入、記憶、搜尋、運算與輸出五種能力。每種能力根據自己的認知定義應該要學習的技能。

●輸入:單位時間內傳入的資料量越多就有機會攝取更多的知識,速讀可以提升傳入資訊的速率。速讀的訓練可以從國小低、中年級開始。
●記憶:傳入的資料需要被記憶下來才能在日後再度使用,速記可以提高傳入資訊被記憶下來的比率。坊間的速記課程也包含了速讀,同樣從國小低、中年級開始。
●搜尋:根據現在的情境到腦中的龐大記憶裡搜尋各式各樣符合的資訊運用,我不知道學習什麼技能才能提升這項能力。或許,這是倚賴天份的?
●運算:年輕時跟算術有關的運算都會佔據考試很多時間,學習珠心算將運算時間降到最低,自然有充分的時間驗算並思考其他更有意義的問題。從剛學會筆寫阿拉伯數字的中班年紀開始。
●輸出:思考的結果會經由肢體創造出一些產出,其中很大的部分會是文字,現在電腦的使用佔了很大的比例,因此打字可以提升輸出文字的速率。從認字與注音都稍具基礎的國小中年級開始。

在這五項基本能力之上,我認為還有三個概念性的能力需要加強:

●輸入準則:閱讀能力有助於拆解文字(或圖形)成為腦中可記憶的儲存想法,拆解得越多越可以看懂更多其他人所想要表達的想法。
●輸出準則:作文能力有助於將腦中儲存的想法用文字(或圖形)組織為別人可以看懂的內容,想法描寫得越詳實越有助於讓旁人的腦中建構出與自己相彷的想法。
●規劃能力:利用棋牌類必須規劃佈局同時推算對手各種對策的規則特性,養成每一步進行都先思考各種可能的習慣;同時等待對手回應也能夠培養等待的耐心。

建立起基本的架構能力後,其他需要輸入、記憶、運算與輸入的技能都能有事半功倍的效果,同時運用輸入準則、輸出準則與規劃等概念性的能力還能夠再加強這些架構能力處理資訊的品質。這樣的道理與架構的設計不是很接近嗎?