李博士終於結束病假回來工作了，佳麗與Gavin 鬆一口氣，如大老闆Servo交待，李博士回來後主要需求窗口回復原狀，新技術需要研發的，先由李博士部門統籌，如須外援再移轉到現在『AI探索專案』。佳麗早先安排與幾個BU主管以及業務主管們談過，似乎有點做白工，不過也算有收穫。例如：因約不到ARM部門頭Colin，所以Fields 幫忙先從以前的同事探聽一些消息。得知ARM 主要客戶軍方前瞻研究所正在找合作對象，要發展無人駕駛飛彈快艇，這主要用到所謂機器學習的 Reinforcement Learning，以及自動辨識等等技術。而ARM部門也要延攬相關人才，並考慮投入不小的資源在上面。

思考一輪迴後，她訝異有個共同的願望，雖然不見得與『AI探索專案』有直接關係：所有專案從承攬評估，一直到進入開發階段，多少都會遇到該主導BU不熟悉的領域，如果不考慮成本或收入如何分配，大家都很期待如果其他BU有相應的技術能支援。但是現實往往背道而馳。

這件事最經典的是Fields原來歸屬的 ARM BU 需要電子工作流程自動化，一開始也知道當時 GOV BU 已有一套公文審批自動化平台，而且比對現有功能與需求，居然高達九成以上吻合，用戶看過展示基本接受此現有的平台，但是專案最後卻是 ARM 又平地起高樓，再打造一個除了使用介面有差異，其他功能幾乎一致的平台給客戶。這被戲稱『重複發明輪子』。

現在之所以關注這個議題，如果沒有解決這個問題，很可能T軟在 AI 領域，各個部門又要『重複發明輪子』，這到底對公司是好是壞？

她進一步分析

1. 需要被支援的團隊如何知道其他部門或是團隊有這個技術。T軟這家公司基本上跨 BU 如同另外一家公司，互動交流很少。能得到情報，人脈是關鍵。
2. 即使知道某BU有該技術，通常不是把源代碼交給需求方即可。通常還是要有熟悉該技術的人員支援一段時間。這是最困難的部份，T軟的 UP 跟 Scrum 一樣重視專案團隊必須專注在專案上，沒有 PM 願意讓成員去支援其他專案幾天。
3. 最難的是如何與客戶計價，因為 T軟是代工性質，基本上沒有自我品牌的軟體產品，客戶如果沒有實際的人力投入，很難說服客戶花大錢買單。因此寧可重複開發給客戶，反而容易穩穩的收到錢。
4. 內部誘因，如何讓BU的老闆或是PM更支持採用其他部門先有的成果或技術。

佳麗找Gavin 合作針對這個跨出專案或是部門取得資源議題提出了分析與對策，Gavin 十多年來其實一直知道問題所在，自認無解。但他衡量一下，佳麗很久沒有參與外部專案，也許能跳脫專案實施的舊框柩，提供公司一點建議吧？

兩人討論了半天，因為公司都是採 UP，很重視團隊必須面對面的溝通。無形當中，整家公司每個專案團隊都像一根高高的煙囪，只有專案搞得烏煙瘴氣排出濃濃的廢氣來，其他專案聞到了才會知道鄰軍發生什麼事，通常要救也是大費周章。能解決這問題嗎? Gavin 之前協助客戶導過 Business Process Management 相關系統，其中 Workflow Automation 似乎有機會，但兩位都清楚這不是重點。

他們也把這個議題當作『AI探索專案』後天要舉辦的第一個 Sprint Review Meeting 素材。

這裡先把結論透漏：
對這個議題，Servo 聽了，思考了好一會ㄦ，直接回覆:暫不打算處理這個議題。雖然不確定像騰訊內部競爭文化，各部門兄弟爬山各自努力的管理模式是否可以套用到T軟這公司，但是這樣的模式因為充分的競爭取得高度效率，看來是可以彌補『重複發明輪子』的浪費。T 軟既然堅持要走 UP，未來還可能往Scrum做一點調整，每個開發團隊要能高度自主管理，成員要能充分互相支援合力完成專案所有待辦事項，那就意味著外部資源並不容易打入這個團隊，並且還能有效的協助。

RJ 也表達，這是必要的惡，或是必要成本，短期內他也不認為有好的解決方案可以兩全其美，就不用糾結在此。

備註：

專案的工作執行記錄在【深度學習所需入門知識--一位初學者的認知】