有些公司永遠在徵人（人員一直在流動），實際去應徵過後，會深刻理解到為什麼。

前幾天提到GitHub時，有順便說過「很多人（主管級、甚至是組織決策者）都有一種想法：凡有技術需求都找現成解決方案就好」。
所以我會花很多力氣強調：絕大多數公司根本不做研發。因為他們都在追求「現成解決方案就好」。
不管這種想法是否合理、是否真實可行，但他們會認為「工程師在到職前就要懂各種需求的施工技巧去完成專案任務」。

就好像貨運公司徵求貨車司機時會要求「會開貨車」一樣。

但在資訊工程來說，任何技巧跟實際需求之間總是有段很大的鴻溝與落差，就好像「會開貨車」跟「把貨車從各種起點開到各種終點（還可能要在各種時段與路況下）」之間的鴻溝與落差一樣。

所以如果貨車司機會開車卻不會認路？那自然一樣無法把貨送到。如果工程師懂的很多技巧，但卻不懂的把這些技巧變化組合成需求的樣子，那......
（這件事情複雜的程度遠超越上面這樣簡單的文字，前面幾天的文章也介紹過「光是專案的規模擴張就可以讓程式在特定平台上變成無法預期的樣子卻又始終找不到原因去控制跟排除」。
所以......這篇文章不是要講「工程師要懂的去解決技巧跟需求之間的落差」，因為那根本講不完。

事實上，真的有些現成解決方案著重在如何彌補技術與需求之間的落差。
但這些現成解決方案如果是「已經被整合進Library」「已經有官方認證套件」「已經有GitHub使用者數百顆星認證」，那也就表示「這些方案沒有特殊性」「以這些方案作為專案團隊技術基礎會造成專案團隊的技術力沒有競爭性（因為別人也會）」。

尤其，這類的元件通常都是用來完成UI/UX需求的。
這會回到之前講「多媒體時代遺毒」的問題，但在這裡用不同方式重新描述定義一下這個問題吧！

如果只是想要用美麗的UI/UX包裝一項平凡無奇的東西，那這是終將被市場跟時代的產品，去負責完成這項產品的專案根本沒有成功可言。（只是「完成、收錢」而已。）
如果客戶不懂技術但又想追求技術，常見的策略就是經由專案團隊提出的產品設計來評估「專案團隊的技術能力」。如果能做的東西其實別人也能做，業務就只能藉由「低成本」「超快速」「團隊隨意消耗使喚」來當競爭賣點了.......

（知道為什麼有些團隊永遠在徵人了嗎？）

但，如果團隊管理者、業務主導者、企業經營者在思維上不懂「追求現成方案」長遠來說註定的結果，那不是團隊成員要擔心的，團隊成員只管「工作、領薪水、練功」就好了！（要人家幫忙煩惱這個問題，好歹先升遷、先加薪、先承諾會給對方相對權限改造組織吧！可能嗎？）

既然說到練功...工程師應該要懂一個基本上跟技術幾乎完全無關的能力，那就是「理解設計師」。

很多設計師的設計圖只是按照客戶在會議桌上提出的需求規劃去按表把功能概念圖一張一張畫出來的結果。
為什麼？
比較正向的看法是：這樣的圖連客戶也看得懂。
所以用工程思維去思考「這個APP的每個功能標題有個類似的框架，我現在要把這個框架畫出來，」「這個APP的每個功能都有個類似的副選單，我現在要把這個副選單的輪廓與運作邏輯畫下來，」可能對設計師來說就不是那麼有用的一種工作策略。（沒人喜歡專案領導整天跑來找自己吵著要「可以拿去跟客戶展示的工作成果」。）
所以這種工作變成要工程師在看到概念圖後自行吸收完成了！

看到設計圖時，工程師要能快速判斷「這個設計師構思了某種會被重複大量運用的風格」，然後將它元件化模組化，好快速大量應用。

但，很多專案的常態是：根本需求還沒完全敲定就要開始施工，已經施工完的功能又經常會被推翻，後期完成需求並進行規劃出來的功能又經常跟前期的功能在風格與邏輯上完全不同。
這基本上無解，除非設計師願意接受工程師的抗議後並收回設計圖重做。（不要被我嚇到，因為願意這樣做的設計師其實並不在少數。所以工程師們先別絕望，只是要能掌握到專案團隊的運作模式，「發生這種事情工程師要盡快反應。」）

但這裡藏了一個陷阱......（準備回頭罵Google。明天吧。）