「古之學者必有師，師者，所以傳道授業解惑也」。這句話是節錄於韓愈在唐德宗十八年(西元802年)完成的著名文章《 師說》，貫徹這邊文章的宗旨是「聞道有先後，術業有專攻」，鼓勵人要勤學、不恥下問，如孔子所說：「三人行必有我師」。
學生時代，大部分老師講課的內容都是來自於書本上面；所以有時候在課堂上稍微不專心聽課，回家努力點看書，還是可以應付考試；不過出了社會，太多事情是沒有標準答案的，這時候「勤學」更顯得重要。
「你現在的成就是你以往的習慣累積而成，如果要成功，首先要克服自己人性的弱點！」這是OT的老闆每次開罵時出現率最高的一句話之一，而這個觀點亦是正確的。人生其實是無數個選擇堆積而成，本來每件事情當作個別事件就是只有「Yes」跟「No」簡單的兩個選擇；但是經過無數次的「Yes」跟「No」的選擇後，每個人造就了不同的人生道路。所以如果一個人的人生高度想要持續成長，光是守著自己以往的觀念是沒有太多幫助的；更多的時候，是挑戰自己既有的認知，尋求突破。
這系列的文章中OT舉自己的幾個例子，是曾在學生時代學到的觀念，並且隨著這一、二十年來不斷與時俱進幫助OT前進；有些話當時OT並沒有理解，而有些則是現在回想起來還覺得挺有意思。相信其中有些例子大部分的人都是聽過的。
關於軟體
OT研究所念的是軟體工程。起先是念圖形識別，但是因為念得不怎麼樣，所以被當時的指導教授轉去做軟體工程相關研究。軟體工程本身講的是方法論，並沒有Domain knowledge，因此為我將來的職業生涯留下許多想像空間。很感謝當時的指導教授鄭有進老師，在畢業論文中將通訊概念與軟體工程結合，這十多年來通訊加上軟體一直都是門顯學；隨著物聯網(IoT)、車聯網(V2X)、人工智能(AI)的普及，我相信不僅是商業應用的蓬勃發展，對於基礎的科學及工程研究(無線通訊、密碼學)，都將會進入更深、更複雜的層次。
- 「這些軟體工程裡面提到的流程、方法，就看你傻得願不願意相信。」
- 意義：這句話是有次鄭老師在「物件導向分析與設計」中講的一段話，當時上課的背景是在講說軟體工程當中有很多種流程，如何去把你的軟體寫好，有些流程很複雜(像是Waterfall)，會產出很多文件；有些流程相對來說簡單(例如Scrum)，講究設計與實作的靈活度。但是哪種比較好、哪種比較不好，就要看你願不願意很踏實的去實踐那些方法，最後得到自己實踐後的結論。所謂「傻得願意相信」，就是指不要才準備開始實踐，發現這個文件要寫、那個流程要做，就決定放棄了。
- 啟示：以目前OT所在的車用產業來說，文件化是一件非常重要的事情；文件化的目的，是從一台車(及車上的元件)開始設計的時候，就要考量品質、安全性等重要議題。我們如果拿汽車與飛機作為比較，常常忽略了汽車講究的安全性是比飛機高出許多的。為什麼？因為汽車作為民生用品，是任何持有當地駕照的人都可以駕駛的；而飛機則是受過訓精良的專業人士才能駕駛。所以從機率上統計，各國交通事故死亡人數大約是每10萬人有5~10人，而空難死亡人數則約為每1400萬人有1人。如何落實車用安全，在車用產業的狀況是，不論是哪種車用標準：IATF-16949、ISO-26262、AutoSAR，無一不要求完善的文件化管理。
- 挑戰：身為一位以軟體工程為專長的學生，對於打造流程、遵守流程以及文件化管理這些事情，特別是在車用產業裡面，真的執行很不確實。甚至曾經也懷疑流程及文件化這兩件事情對於工作的影響有多大？隨著公司在車用產業越來越大的影響力，客戶對品質更加嚴格的要求，也看過越來越多精製的流程及文件，最後還是回歸到了身為軟體人最基本的流程及文件化管理。與其逃避，說這個工作緊急、那個工作忙，沒時間顧流程、寫文件，不如紮紮實實的面對。要做好流程及文件化，除了需要專業知識來完成，同時也考驗著執行力以及毅力。
圖片來源：https://www.linkedin.com/pulse/20140626152045-3625632-car-software-100m-lines-of-code-and-counting
- 「工程就是把要解決的問題結構化。」
- 意義：這句話同樣是在鄭有進老師的「物件導向分析與設計」提到的。當時課堂上是在講說要如何做軟體架構的設計，例如設計樣式(Design pattern)要怎麼用？甚麼情況可以用那些pattern等？如何做架構設計是來自於我們對於問題的理解有關。工程就是要解決問題；軟體工程就是要解決軟體開發的問題。當我們可以把要開發的軟體問題結構化之後，就可以用適當的設計來解決這個問題。補充一點，鄭老師也常說「設計」這種事情只有「比較好」，而不存在「最好」的設計。
- 啟示：其實在老師說這句話之前，我從來沒有明白「結構化」這件事情的意思；原來我們對於很多事情的看法，都是可以「結構化」的。例如建一個庭園，可以結構化成需要有植物、陽光、水、籬笆，至於植物要種植那些？陽光從哪裡來？水要怎麼表現？籬笆是甚麼樣式？這些則變成是實作問題。例如吃頓飯﹐也可以結構化成要有主食、主菜、配菜、湯、水果，至於它們是如何料理、用甚麼材料，都是實作的問題。
- 挑戰：隨著工作經驗的累積，我越相信「結構化」這件事情：寫軟體可以結構化，寫文件也可以結構化，而流程就是把做事情的方式結構化後的產物；現在甚至發現溝通也可以結構化！每當事情出了錯，也不斷練習從抱怨別人、檢討枝微末節的細節，慢慢從整個問題的結構來探討要怎麼調整。訓練自己對問題結構化的能力，其實就是來自於對於一個問題的瞭解；為了能更順利的解決問題，也會因此更加推動自己去攝取不同的知識，累積不同的能量。
- 「你怎麼知道你哪天不是靠寫需求來賺錢？」
- 意義：與前面兩句話相同，也是來自鄭有進老師的「物件導向分析與設計」。軟體工程最基本的流程是Waterfall model，這個經典的模型將軟體開發分為需求、設計、實作、驗證、維護等五個不同的流程。當還是學生的時候，總是比較好奇如何把東西做出來，而設計及驗證的工作比較沒這麼仔細，對於需求則更是不怎麼重視。當時鄭老師在上「Requirement Elicitation」這一段的時候就有感而發，要我們好好寫需求文件；怎麼知道哪天不是靠寫需求吃飯呢？
- 啟示：如何讓使用者的需求變成文件化，OT覺得應該是一門很深的溝通工作；我們平常在說話時，即便不去文件化，都很容易產生誤解，更何況是要將概念性的東西用文件的方式表達出來？所以越能夠將使用者需求文件化的越精準，表示對於客戶想解決的問題理解的越清楚。
- 挑戰：在車用產業，通常需求是來自於車廠，Tier 1提出設計，Tier 2及外包的第三方完成實作，驗證及維護則是車廠、Tier 1、Tier 2、3-Party各有各自的驗證及維護方式。現在許多數位巨擘如Google、Apple、Amazon、Baidu、Alibaba等都想方設法想進入這個產業，車廠對於這些新進的競爭者也抱持著許多想法，但是這些想法如何反應在產品上，很多時候是隱而不宣的，甚至車廠不知道該找怎樣的供應商來幫他們實現。若是這時候能夠有很好的需求誘發者，也許就有機會將一些概念實現為一個很棒的產品。
下一篇我們談談「關於學習」、「關於志氣」以及「關於愛情」。
OTORI
27.01.2018
沒有留言:
張貼留言