荀子《勸學篇》裡提到:「螣蛇無足而飛,鼯鼠五技而窮」,李小龍在紀錄片《李小龍的生與死》中,說過:「我不怕練過一萬種踢法的人,我只怕將一種踢法練過一萬次的人」,這無非都是在強調專注於一個領域的重要性。

然而,現今亦常見不少人呼籲別只是埋首自身領域,強調跨界的重要性,只不過若沒拿捏好,就怕螣蛇或鼯鼠都當不成,只能作個「魯蛇(loser)」。

那些紛擾的跨界呼籲
老闆要不要懂程式?專案經理要不要懂技術?做設計的要不要學程式?MIS要不要寫程式?UI要不要懂RD?……類似的問題或文章標題你一定看過,從開發者角度來看,大多會讚同老闆、專案經理、設計師等角色要懂程式,別人多瞭解我在開發上都做些什麼不是很好嗎?這可以省去我不少溝通上的麻煩不是嗎?

那麼反過來呢?RD要不要懂UI?寫程式要不要懂設計?工程師要不要懂管理?不少開發者可能會開始反對了……「你這是管理思維」、「畫面好看有什麼用」、「東西會動比較重要」諸如此類的理由都有可能出現。

這一類的程式人要不要懂XX的文章,並不是真的要程式人去學會其他領域技能,出發點在於不要只關心自身領域,應當多理解其他領域的思維,以減少溝通的誤區,增進合作的順暢,畢竟當共處一個專案或合作團隊之中時,大家都是在一個世界中,而不是你在你的UI世界、我在我的RD地獄、專案經理等管理角色在完全摸不著的絕對領域之中,然後程式人看到〈這幾句話,輕鬆惹火程式設計師〉時,火氣都上來了,然後,老闆看到〈Don't Call Yourself A Programmer〉就拼命轉寄給工程師們。

有些人確實能擁有兩個甚至多個領域的能力,並且發覺領域之間交錯的部份,能夠想辦法將不同領域的觀點綜合在一起,因而發揮出莫大的效果。Steve Jobs在2005年6月於史丹佛大學畢業典禮上發表的演講中,就提到這麼一個例子,他在設計第一臺麥金塔電腦時,心中浮現出十年前書寫課上習得的字體、空間之藝術,後來把它們應用在電腦之中;Samuel Arbesman在〈Let's Bring The Polymath〉中提到「最令人激賞的發明常出現在各個學科的邊緣,在那些能將不同領域概念綜合在一起的人」。

技術內的跨界
實際上在技術之內,程式人本身就要有跨界能力。就現今程式開發而言,程式人不只要熟悉一門程式語言或平臺,更要熟悉從語言或平臺延生出來的生態系,生態系本身就是由多個領域的概念或解決方案組合而成,單純就開發Web應用程式來說,開發者基本上就要瞭解(雖不一定負責)資料庫、後端甚至是前端技術,得瞭解重構、測試、模式等概念,必須會運用整合開發工具、建構工具或版本控制等工具,在同一個生態系下,越是能熟練、運用、整合這些生態系下的各個元素,往往就越被定位為優秀的開發者。

開發面對的問題,往往有著相似性或重疊性,因而能夠用不同語言或生態系來解決同個問題,只是彼此之間便利性、約束性或抽象程度等有所不同。不少優秀開發者除了本身專精的語言平臺之外,亦熟悉多種語言生態,並能發覺語言生態間的實作,其實有通用概念或模型,因而也常見他們能同時在不同語言生態間轉換,甚至在必要時,於A語言生態系中,實現B語言生態系的概念或模型。

生態之間的交融,也是技術內跨界的一種表現,在同一個專案中依需求使用多個語言技術,就現在來說並不算新奇之舉。例如Java生態中,有不少可運行於JVM的語言,像是Scala、Groovy等,亦有JRuby、Jython、Rhino等實作,讓應用程式開發可依需求而有各種語言選擇,善用各種語言優點,在《The Productive Programmer》中,Neal Ford稱這類開發為〈多語言程式設計(Polygot Programming)〉;實際上不僅是語言,Martin Fowler在〈PolyglotPersistence〉就討論過,現今應用程式在資料永續(Persistence)上,可依需求而採用甚至混用不同的資料儲存技術。

技術外的跨界
技術內的跨界較容易為程式人理解,畢竟就是定義在「解決問題」,只是依問題需求或複雜度不同,採用不同的技術,但終究還是技術領域。「科技始終來自於人性」這個廣告術語大家耳熟能詳,技術如何與人性關心的領域結合,就往往難上許多,然而就因為難上許多,技術外的跨界往往能發揮「1+1 > 2」的效果。

就身為自由工作者的我來說,在這點最能感同身受,不少客戶並不單只是因為我對技術上的熟悉而前來合作,寫作與教育訓練就是因為與技術結合的實際案例(也比較容易為人所理解);有趣的是,因為我對各語言生態系的瞭解一向有著濃厚的興趣與涉獵,萬萬沒想到,因為長期的涉獵與觀察各語言生態系,也帶來了一些合作的契機。

顯然地,我本身並沒有預知跨這些領域的重要性,而是覺得這些領域很有趣才涉入,近來察覺到因跨界而受益的例子,實際上可遠溯到我退伍前想找美術工作的決定,雖然後來意外走上程式之路,然而十幾年前培養的美術能力,結合現今對各技術生態文化之瞭解,讓合作對象在某次對話中談到,我畫的一些圖,比他找的美術人員,更能傳達文件想表達的概念。

領域知識(Domain knowledge)的重要性,每個開發者都知道,實際上這就是技術外的跨界,曾經看過銀行找Cobol人才的條件還不錯,然而實際上那樣的條件,並不是買你會不會Cobol這項技能,還包括了對銀行存放款等業務是否熟悉,也就是好的條件是買技術與銀行業務的Know-How,而不是單單只是Cobol本身。

以先前我的例子來說,如果我是空有繪圖技巧,看不懂技術文件,無法以圖片表達出文件內涵,畫出來的圖大概也只是好看,細緻度卻比不上專業美術的作品罷了。

撈過界還是跨界?
跨界很重要,對吧!老闆或專案經理因此開始學程式設計了,然後沒多久用著一知半解、自我想像的方式,開始對你的程式指指點點,然後說著「這個我學過,應該很簡單……」,或者有天要你去上課,說是要培養你的跨界能力,之後某個東西就由你負責了……這顯然是撈過界而不是跨界了……

跨界的機會可能是偶然發生,而且,通常這類意外結合兩個或多個領域能力的效果驚人;跨界能力確實也能特意經營,只不過原來領域如果沒有一定專業,特意跨界多半也只能學得皮毛,或者是原本領域與跨過去的領域毫無交集點,硬是以原有領域聲望,一知半解、自我腦補地解釋著另一領域的事情,那就很容易鬧出撈過界的笑話。

自然而然的跨界,往往是出自於對某個不相干領域的好奇心與嘗試,而後在偶然的機會,跟既有的穩固專業結合在一起;特意經營的跨界,大多會選擇與現有工作或專業相關的領域,然後認真地磨練該領域的技能。

無論如何,最終你橫跨的領域都要有不錯的水準,結果可以是回饋至原有專業或兩個領域共伴成長,或者從兩者之間建立起獨到之處,能夠達到這類結果的關鍵都在於專注。

對既有領域的專注,對跨過去的領域也要專注,到最後你會感覺,試著將不同領域進行結合時,就像是在認真地追求一種藝術,隨之而來的實際效益,反倒只是個附屬品了。

專欄作者

熱門新聞

Advertisement