這篇文章提到「要理解才去做」的人，他們的行為模式：非常堅持「要理解才去做」的原則，甚至當他「無法理解」時，還會非常理直氣壯的要求對方必須說服她會解釋給她聽，否則他就沒辦法做。
杜書伍說
實務經驗告訴我們，理解能力與個人閱歷的多寡，及悟性的高低有關。年輕、資淺者閱歷有限，對於未曾經歷的新事物，本來就未必能很快了解、認知；而即便是資深人員，其閱歷亦有其偏向。更何況世界之大，無奇不有，無人能百分之百了然萬事萬物的道理。所以「不聽老人言，吃虧在眼前」這句俗語，並不是陳腔濫調；它其實指出了任一人視界必有侷限的自然律，以及前輩智慧的價值。我不知道杜書伍是在什麼樣的情境下有感而發地寫下這篇文章，因為我曾經也遇過這類「要理解才去做」的人，不過，我不像他是總經理，所以對人事有絕對的掌控的權力，能決定是否繼續僱用這類人仕。
所以，看待無法理解事物的正確觀念，應是先接受進來，透過「做中學」，一邊做一邊理解。
當旁人提點要去做某件事、或該去注意某件事時，應盡力去理解其說明；假使未能通透理解，也應該先「照著去做」，一面做一面去體悟其道理，一面體悟再一面比對、提問。只要用心，必能在實做的過程中，悟透大部分的道理。
...
真正掌握「要理解才去做」真諦者，對於無法理解的事物，她仍會嘗試去「理解」、「認知」、「深度理解」。確實思考後，她必能發現有些地方是不對的，是不可行的，是有瑕疵的；而能提出為何不對、不可行、或有瑕疵的理由，並請求主管或旁人解惑。絕對不會單以「不理解」這個說法，簡單回應。
因此，大家應該認知到，廣義的「要理解才去做」，應是「要理解才去做，但無法理解也要去做」...
我的經驗
我曾經在之前的公司，因為負責的專案忙不過來，就把腦筋動到新來的同事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，應需要俱備以下三個「要件」：
- 軟體測試的概念
這個觀念是要Tester能清楚區分不同的軟體開發階段、測試結果有效的條件。不過，通常學校教的不大有用，得要由實務的工作中去體會。 - 領域知識
每個領域所需俱備的知識有天壤之別，只有進入後，才能逐步了解。此外，每個特定產品開發過程的歷史，也是很重要的資訊，尤其是對缺陷的判斷與Debug。 - 測試相關的工具
測試不同領域的軟體，需要不同的測試工具。甚至不同的作業系統，測試工具往往也有很大的不同。如果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）「連本帶利收回」原本就是企業運作的精神，甚至最好連本都不用花就能回收，這樣更好。
因為企業可不比學校：學校是傳授知識的地方，容許你慢慢看、慢慢學，但企業卻是應用知識的地方，希望你儘快透過你的才智，學會必要的知識後幫他賺錢。
請記住，只需要能賺到錢的「必要知識」即可，而非多多益善。
如果進入企業後，還繼續沉愐於學校的習慣，希望學得即深又廣，除了增加自已陣亡的機會外，我看不出有任何的幫助。
下次，當我再遇到這樣的人，我會直接學周星馳告訴他「你快點回火星吧，地球是很危險的。」
沒有留言:
張貼留言