無法理解也要去做 - 通達人驛站
2011/11/17

無法理解也要去做

最近,看了杜書伍寫的《要理解才去做,但無法理解也要去做》後心有戚戚。

這篇文章提到「要理解才去做」的人,他們的行為模式:非常堅持「要理解才去做」的原則,甚至當他「無法理解」時,還會非常理直氣壯的要求對方必須說服她會解釋給她聽,否則他就沒辦法做。

杜書伍說


實務經驗告訴我們,理解能力與個人閱歷的多寡,及悟性的高低有關。年輕、資淺者閱歷有限,對於未曾經歷的新事物,本來就未必能很快了解、認知;而即便是資深人員,其閱歷亦有其偏向。更何況世界之大,無奇不有,無人能百分之百了然萬事萬物的道理。所以「不聽老人言,吃虧在眼前」這句俗語,並不是陳腔濫調;它其實指出了任一人視界必有侷限的自然律,以及前輩智慧的價值。

所以,看待無法理解事物的正確觀念,應是先接受進來,透過「做中學」,一邊做一邊理解。

當旁人提點要去做某件事、或該去注意某件事時,應盡力去理解其說明;假使未能通透理解,也應該先「照著去做」,一面做一面去體悟其道理,一面體悟再一面比對、提問。只要用心,必能在實做的過程中,悟透大部分的道理。
...
真正掌握「要理解才去做」真諦者,對於無法理解的事物,她仍會嘗試去「理解」、「認知」、「深度理解」。確實思考後,她必能發現有些地方是不對的,是不可行的,是有瑕疵的;而能提出為何不對、不可行、或有瑕疵的理由,並請求主管或旁人解惑。絕對不會單以「不理解」這個說法,簡單回應。

因此,大家應該認知到,廣義的「要理解才去做」,應是「要理解才去做,但無法理解也要去做」...
我不知道杜書伍是在什麼樣的情境下有感而發地寫下這篇文章,因為我曾經也遇過這類「要理解才去做」的人,不過,我不像他是總經理,所以對人事有絕對的掌控的權力,能決定是否繼續僱用這類人仕。

我的經驗


我曾經在之前的公司,因為負責的專案忙不過來,就把腦筋動到新來的同事M小姐身上,在得到身旁負責FAE的同事F先生同意下,我向主管P先生爭取M小姐(她是F先生部門的同仁)加入我負責的專案。我會把該專案相關的資訊與經驗,逐步藉由實際的Test Case傳授給M小姐,讓她能儘快進入狀況。

P先生在徵尋M小姐的意願後同意了這個方案,但在實際執行時,卻遇到了很大的困難。

第一天


早上,我先花了兩個小時和M小姐溝通未來一個月的目標是要她完成部份已在上個版本執行過的Test Case,我則負責其他新版新增功能的Test Case。

同時,我也一併告知M小姐,往後在每天操作Test Case的過程完,我都會要求她寫一個Status Report,簡單描述每日執行的測試過案,與所花的時間。測試後,我會和她一起檢討執行有問題的Test Case。

我同時也解釋說之所以要這樣做,是希望從她的質(對產品的了解)與量(她執行Test Case的速度),能事先預估她能在時限內完成測試的機率。

到了下午,我就帶M小姐去機房介紹機架、和測試環境。然後幫她安裝/設定SecureCRT,也把目前的測試主機讓給她操作,同時演練了一次如何登入測試主機,切換測試環境,順便把我自己寫的Survial Guide給她參考,並告訴她,這些操作是最基本的操作,她必須自己熟悉這些步驟,在明天操作一次給我看。

然後,又在M小姐的筆記上寫下我們這個領域內的幾個重要字彙,希望她上wiki或Google去查,簡單告訴我這些關鍵字的意義。

最後,我又再次問她有沒有問題。她沒有說話,我就當沒有了。

至此,就完成了第一天的進度。我原本以為這應該可以了,有功課給她,有操作練習,這樣應該很充實了。

沒想到,我真的太天真了。

我的安排


是因為我認為,一個合格的Tester,應需要俱備以下三個「要件」:
  1. 軟體測試的概念
    這個觀念是要Tester能清楚區分不同的軟體開發階段、測試結果有效的條件。不過,通常學校教的不大有用,得要由實務的工作中去體會。
  2. 領域知識
    每個領域所需俱備的知識有天壤之別,只有進入後,才能逐步了解。此外,每個特定產品開發過程的歷史,也是很重要的資訊,尤其是對缺陷的判斷與Debug。
  3. 測試相關的工具
    測試不同領域的軟體,需要不同的測試工具。甚至不同的作業系統,測試工具往往也有很大的不同。如果Tester不能熟稔測試工具,往往無法執行測試。
我之所以稱之為「要件」,是因為這三項東西,必須同時具備、而且充份滿足。只要這三項東西少了任何一個,或是任何一個不能達到一定的水準,這個測試就是浪費大家的資源,測試結果也會讓人質疑。

另外,我的方式就像對待研究生一樣,我給了她很大的空間發揮,不需要我像個小學老師一樣,手把手的每個步驟都要說清楚、講明白。研究生就應該要自己針對特定的領域,花時間去了解。

我的歷鍊


其實也是建立在前述的三個要件上。

以我進入該公司的過程來看,雖然我已經在其他公司有了多年Tester經驗,也了解測試相關的工具,但對該公司的產品還是很陌生。所以我當時的主管因為在忙別的專案,就丟給我一本User Guide,讓我了解產品,又指派坐我隔壁的E先生做我的Guider,叫我有問題問就E先生。

E先生給我他自己的操作筆記,並簡單解釋了切換測試環境的架構與操作,然後讓我藉由實際的測試個案,自己理解、體會這個複雜的產品。

接近半年的時間內,我就按照User Guide上的操作與說明,以及TestLink上的Test Case,不斷從一連串錯誤中摸索與不斷練習,試著去了解我所欠缺對產品的了解。不懂的部份,就先擱著或是找時間問E先生。

而且,我始終認為對Tester或是FAE而言,錯誤的經驗往往比正確的經驗重要。因為有時客戶回報的問題,往往並無法提供完整的資訊,這個時候,錯誤經驗就能發揮填補資訊空隙的功效。

大約半年後,我終於比較了解產品特性,然後我就開始幫忙測試既有的專案,接著就被指派了一個小的新專案,因為某些原因,等小專案玩到一半,就又被指派了一個比較大的專案。

其實不只是我,其他同事也是以類似的方式,逐步嫻熟公司產品,不論他們在其他領域是某已有經驗。

第二天


一開始我就要驗收第一天的功課,而且我期待能聽到M小姐的問題。

不過,結果竟然完全超出我的意外,M小姐完全不認為她應該要這麼做!更簡單地說,她不但沒有完成這些功課,根本就不認為自己要用我所提供的方式學習。

因為,她要求我得先「簡介」這些Test Case,然後再「逐步」了解這些Test Case,至於來不及了解的部份,就要我自己測試。

此外,她也覺得單純執行這些Test Case,很像打字員,很沒有價值。希望能在「完成測試」與「了解產品」之間,能更「平衡」。言下之意就是「我只想要多了解產品,至於測試,那不干我的事。」

她的要求


我毫不思索地就回絕了,因為這完全與組織利益與我個人的利益衝突,也完全不切實際。

首先,以M小姐目前的狀況,既不了解「軟體測試的概念」、「領域知識」是0,「測試相關的工具」也是0。所以,她對我而言唯一的價值,就是當個能認真地執行Test Case的Tester。為了回報她的努力,我用我所知道的知識交換。如果,連最基本的要求都做不到,那她對我一點價值也沒有。

其次,我就是因為有專案的時間壓力,這個專案對部門未來的營收也有重大影響,所以才找M小姐協助。如果她不但不能解決我的問題,還可能把我的時間耗在和這個專案進行沒有關係的地方,這對我而言,就是浪費時間。

第三,M小姐看起來好像很喜歡看技術文件,但這不表示看文件就能了解這些知識,進而能動手作。如果連最基本的動手做都不願意,那就是眼高手低,這樣的人對我也完全沒有用處。

最後,如果不用Test Case的執行,做為確認她是否能了解這些功能的依據,我實在想不出來還有更客觀、更具體的好方法了。

為了避免花太多時間僵持在那,我就直接找P先生來處理這件事。雖然P先生是我的主管,但我仍然明確的告訴他「按照我的方式做,如果最後的結果差,我甘願負責;但如果按照M小姐的方式做,不但不能幫忙完成專案,我還得為她的方法負責,這我不能接受。」

當然,這其中還發生了其他的事情,直接影響了我對於M小姐的觀感,所以我當下就告訴P先生「要有備案」,並決定直接放棄這個不稱職的「幫手」。

更誇張一點的說,如果我是P先生,我會直接叫她回家吃自己。

其他考量


當然,我的決定,並非只考量了前述這三個因素。

我聽說M小姐有兩個碩士學位,但我同事說的好,「進入公司後,是什麼學校畢業都不重要了!」因為學歷只是進入企業的鑰匙,進入後這個鑰匙就會有很長的一段時間沒有用處。

聖經馬太福音中有個「兩個僕人」的故事。主人拿錢給兩個僕人投資的故事,一個僕人把錢拿去投資了,另一個僕人則把錢埋在地下,主人知道了就對後面的僕人說:你這又惡又懶的僕人,你既知道我沒有種的地方要收割,沒有散的地方要聚斂,就當把我的銀子放給兌換銀錢的人,到我來的時候,可以連本帶利收回。(太25:26-27)
「連本帶利收回」原本就是企業運作的精神,甚至最好連本都不用花就能回收,這樣更好。

因為企業可不比學校:學校是傳授知識的地方,容許你慢慢看、慢慢學,但企業卻是應用知識的地方,希望你儘快透過你的才智,學會必要的知識後幫他賺錢。

請記住,只需要能賺到錢的「必要知識」即可,而非多多益善。

如果進入企業後,還繼續沉愐於學校的習慣,希望學得即深又廣,除了增加自已陣亡的機會外,我看不出有任何的幫助。

下次,當我再遇到這樣的人,我會直接學周星馳告訴他「你快點回火星吧,地球是很危險的。」
 Related Posts with Thumbnails 

0 意見 :

張貼留言