企業巫醫：創業初沒準備好 就先別找工程師（讀書心得）

Don't hire a software developer until you read this book是一本有趣的書，它的副標題是：學習如何管理應用程式的開發流程，確保你的手機程式，網站，網路應用的產品會成功做出來。

這本書和一般的企業巫醫做法略有不同，它只專注在一個單純面向，就是「非軟體人員如何建構軟體開發團隊，並且做出自己要的產品」。實務上，它是一本工具書。裡面的Pro Tips直接而且不廢話的指出應該要的做法。

這本書花了好幾個章節，大致闡述了近年來軟體開發的相關技術與運用，並把重點放在非技術背景的創業者，如何組織建立軟體開發團隊，並且讓團隊往期待的方向前進。

做得到書上的內容的人，大概就是程式設計師心中的好老闆，或者是好ＰＭ。

然而，這本書其實也非常適合給「程式設計師」閱讀

它展示非技術人員領導軟體產品開發「真正關心」的地方：也就是實際產出。至於開發人員使用的程式語言，使用的軟體工具，甚至想要把產品做的完美...這些都是不是考慮的要務。

例如，在書中說明新創產品開發常犯錯誤的幾條

(1) 為求完美把錢燒光了：

MVP需要的是最小規模的產品以及最好的品質。但太追求完美因而增加太多附屬功能，在作者來說是一種無法控制的浪費

(2) 輕忽看似很小的需求規格改變

例如某些開發人員會說「這不會花太長時間，只是把按鈕從這邊移到那邊」。開發人員當然會負責搞定，但是要求預估時間是創業家一定要做的事情

(3) 忽略測試

測試的重要性應該不用多提。然而非技術人員很容易忽略測試的重要。

(4) 即將上線前做需求改變

對作者來說，這等同於自殺任務。其實資深的軟體工程師在內心深處都很清楚這點，但是創業者或PM想要自我毀滅的時候，又有多少人可以阻止？

(5) 開發中後期增加人力以加速開發

在人月神話這本書中有很長的篇幅描述，很多時候增加程式設計師只會讓專案速度更慢。



此外，一般開發人員也可以透過這本書獲得Lean-Startup的精神概念與實務上Agile開發的整合。
舉例來說：它說明了Agile原則，以創業者的角度，來看agile的各種方法論對軟體開發的好處。並且也拿實際工具(Trello)，展示一個創業者實際對開發團隊該做的動作，連同移動Task Card都說明很清楚。MVP，如何做出最小可行規模的產品。從創業者的角度，來看這些工具，其實更可以讓軟體工程師知道專注於最小變動需求的好處。

How to build a self-motivated software developer team

A team which all team members are self-motivated is a dream team where everybody want to join in. But, it is really rare. Well, maybe the 1992 dream team was one of the cases but we didn't see many examples in software developer's world.

Nevertheless, to build a self-motivated team is a major task of a manager. If you are the manager, this should be your priority-zero task, and should be only one zero, if you are going to build a new team.

Self-motivated might be the best way to drive software engineer's performance. Since high productive engineer works high involved in creativities and mental work.  These are hardly be gain or impacted by salary or physical award (reference: 1, 2, 3). Sometimes it could be driven by a noble target: save all poor children in the world, increase average human life to 200 years. But unfortunately, that kind of things normally happens in non-profit organization with a born charismatic leader. 

So how to build a self-motivated software developer team in a common working place?

Three key points: (1) selection (2) intersection (3) automation.

(1) Selection

If a member who is already a self-motivated person, then it will be easy to keep his good attitude. Since it is pretty hard to change a person's mindset, therefore to get a right person is the most easy way.

Do select a person who already has record on self-motivation. DON'T select a person who has good skill-set but has bad records on self-motivation and you believe you can change his/her mindset, I won't say it is possible but you need to understand that you really have much less changes. Since you can't be with the person 7x24 and his mindset is only inside his brain.

The key point of selection is try to understand his past. Do not judge his "self-motivation" by ask future question like: will you be self-motivated in our team? Understand his past working experience by asking the difficult moment. Especially, sometime he might not be in spotlight and what he did on that moment.

Again, identify a person's past is the best way to select right attitude candidates. And a best fitting person can really have positive impact for the team. 

(2) Intersection

There is no way to read team member's mind. People have left-hand-column, even if you already selected best people to join your team and you were very sure they all are honest. But they surly have things which can't tell or won't tell.

Some leaders or managers will try to dig it out, it is fine to do but not that easy. The best way is to admit the existence. And then leaders should focus on the intersection which is the area that covers the target of a single team member, the team and the organization. And that is also the area where creates win-win-win.

A self-motived member could find that area by himself. But if you are leader/manager, you should keep in mind that figure out the area and knowing the area is very different in each individual. To fine tune a bit earlier can largely reduce the risk of un-motivated situation.

For example, "Ken" is always in good performance and deliver pretty good result. And you believe that you knew that his career interesting is pure technical area. Which means he might want to be an architect in the future. However, if you see he is pretty happy to lead junior members to work out teamwork activities, for example : organize a study group, handle company travel, or year end party. That might be a sign of that he is actually want to be a manager in the future. If his actions is toward his goal then it is fine. However, if his actions didn't reflect your assumption, then it is your time to reset yourself or/and make a little changes.

The bottom line is to avoid lose-lose-lose situation. This sounds funny and should not even considered to happen. But there are too many true sad stories existed in the world. An usual/typical sample in software developer's world was: a team (which members are well-pay) worked over-time on an ambiguous project for months, delivered a product which didn't fit PM's expectation, company lose money, members lose life, customer didn't get result: no body wins.

To avoid 3-lose situation, make sure there is an intersection of all. If you were the manager, make sure you can guide your members into his own intersection. But if you really see that there is NO intersection at all, make sure to create one.

(3) Autopilot

Autopilot means a member knows exactly what to do, how to do. And most important thing is if there are tasks out of his current skill set, he will know how to learn. He can even do self-consideration of intersection and selection. Totally worry-free.

Again, if the selection was done good, to let team member become autopilot will be easy. All you need to do is coaching. Coaching is another topic of a few books plus lots of trainings/experience. If you are an experienced leader/manager then you already know how to do, just reminder to keep open your mind. And also please keep in your mind that open-your-mind is never easy.

The bottom line is to avoid micro-management.  Software development is highly brain consuming job. Micro-management never works in software development, it does work in other kind of job but it definitely doesn't work in software development. If you need to talk to your member about when to arrive in office, when to leave, what to update in Slack, how to write email. That means you are NOT trying to build self-motivated team or this specific person won't fit in a self-motivated team.

Sorry, No short-cut

There is no short-cut in for organization theory. However, practically do the right things normally will get the positive result in a few months. Of course, sometimes in a rapid startup environment, it seems no time to wait. But most of us in software developer world are running marathon not a sprint.

Skill sets and performance concerns:

There is one more thing. I didn't discuss skill sets and performance here. But this is actually extremely critical for a software developer's team. Without an excellent skill sets and performance delivery the self-motivated will be useless. However, this "should" be not difficult to identify during interview and resume check.

企業巫醫 - 贅字 廢話 泥巴仗

在組織中，溝通合作是大部分的人一定會做的事情。

溝通合作說起來簡單，畢竟人類是靠群體合作而存活在地球上。不過，在企業內部的有效溝通並不如想像中的容易(註1)。

某些人在對話或文字表達上，有意無意的更增加溝通的難度。如果是無心的，僅只是造成困擾而已。但如果是刻意為之，會讓溝通困難，讓事情滯礙難行。

無論有意無意，溝通上常見三個問題：「贅字」「廢話」「泥巴仗」

在這三個之中，贅字和廢話很煩人，但真正要解決的是可怕的泥巴仗。

贅字

典型的例子，像是最近淡江大學解聘兼任教師的新聞：高教工會主任：「學校也一再地向（兼任教師）表示說，也是因為今年的8月1日，勞基法要開始適用於，未具本職的兼任教師身上，學校不想負擔這樣的人事成本，所以他們才會做了一個解聘跟不續聘的動作。」

有人稱這類型的贅字為「語言癌」。(註2)

凡舉「關於XXXX這個部分」，「做一個XXX的動作」，無意義的拉長語句都是。

當然也有些人認為拉長語句是「敬語」的表達方式(註3)。

此外，狀聲詞：「嗯」「唉」「阿」因為在對話中，有實質表達情緒的功能，所以不算是贅字。

不過，贅字真正的影響其實很小，只是太多贅字會讓聽的人很不舒服而已。

廢話

在說明事情，或者文件上，用過多虛浮的形容詞，掩飾無意義的內容。或者，重複不證自明的真理，用以掩蓋無法找到重點的對話。

在政府機關的公務人員出國報告網，可以輕易地查詢到充滿廢話的報告。

例如：一個公司是多面向的結合。(簡單的說，整句都是廢話)

例如：透過本次會議實際瞭解大陸生醫相關市場現況，就本所研發之核醫藥物推廣應用極具參考價值，可納入本所未來研發方向之參酌。 (簡單的說，出國去參加這個會議，最後只是參觀看看而已，沒什麼東西是真的影響組織的研發方向！)

另一個例子：不論是什麼樣類型的數位化工具，除了便利性外，都應兼顧到安全性，日後推動電子化政府的過程中，應與各級資訊安全主管機關做密切的合作，確保資訊科技的演進不會成為資安漏洞。（資訊科技本來就不應該是資安漏洞，各級安全主管機關本來也就應該合作，哪會需要出國參加會議之後才知道這兩件重要的事？)

當然，某些企業網站資訊，也是廢話很多。不過，大部分是似是而非的術語，構築專業能力的感受。

例如：透過嚴格的專案控管與扎實的系統建置專業能力，我們有信心提供客戶最安心、最可靠的大數據優質服務。(如果把形容詞拿掉，這句話其實很短：我們提供專案控制和系統建置的大數據服務。但更具體一點，就是：其實有案子我們就可以接來做，大數據只是個行銷名詞)

有時候廢話很煩人，因為要花些力氣才能抵達事實真相。廢話浪費的很多時間，不過如果採用Scrum方法論，在會議上只專注於現況和事實，應該不太可能會有廢話太多的問題。至於網頁資訊和技術文件，就應該盡可能去除廢話。

泥巴仗

最高級，並且更難應對的是泥巴仗。

特別是在中大型組織，中階主管通常都位於關鍵職位。而好的中階主管，仍具備本職學能(註3)，會根據事實來溝通。也因此，優秀的中階主管通常會強調技術事實，產業事實，專案事實，資源分配事實...等等諸多事實根據，作為溝通以及決策的基礎。因此，反倒不會強調本身的溝通協調能力。因為這樣的能力，如同影子一般隨附在工作之中。

然而糟糕的中階主管，由於已喪失本職學能(註4)，就會強調其「協調溝通」成為其最重要的工作。然而，不基於事實和邏輯的溝通，會變得混亂不堪。某些糟糕的中階主管，在遇到爭議性問題時，會用打模糊的方式，試圖讓大家在泥巴仗中度過。而最高階的泥巴仗，會用看似合理的邏輯，但展示對技術完完全全無法掌握的事實。

例如：這個影片，非常經典，看似誇張，但在資訊科技產業其實常常發生。在該影片中，真正做事情只有一個人，而中階主管遇到技術難度的問題會省略甚至推諉，不能體會真正的重點而死咬不重要的細節，而技術人員要探索細節又會說這是專家的工作範圍。當然該影片是太誇張了一點，但其實在中大型組織時常發生類似的事情。

另一個例子：在老大靠邊閃中的有名片段，first thing or second thing。主角完全是用打泥巴仗的方式，在黑幫大老會議裡，刻意激怒某老大。而其他大老反倒會覺得生氣的老大很沒風度，一開始沒發現主角在打泥巴仗。

在此徵求案例：徵求在資訊科技中，重要會議裡打泥巴仗的案例。 


混亂泥巴仗是很可怕，要對應泥巴仗有先決條件，就是這不能是在「只有兩個人」的情況下。換言之，會議或者文件，至少要有三個人在場才有機會擺脫泥巴仗。

只有兩個人的情況下，只要有一人刻意打泥巴仗互相把對方弄的髒兮兮的，而且這個人還是中高階經理，另一個人根本不可能解決。唯一的方式是，儘速逃離現場，在下次確保有第三人以上在場。

在有起碼三人的情況下，以下方式可以解決泥巴仗問題。

1. 不隨之起舞

泥巴仗成立的條件是互抹泥巴。例如，在軟體專案中，當大家在解決A模組為何落後時，如果有人反覆提及一些沒有直接關連的事情：也許是另一個專案也落後了，也許是某RD的溝通態度不好。這些都是泥巴仗的徵兆。

2. 以白板展現事實

人的思考和言語是線性，因此在看穿複雜問題時，光是在腦中想是很容易被泥巴仗牽著走。

最好的方式是，一旦發現「同時」討論兩件以上的事情，就應該在白板畫圖或者條列。

畫圖是最好的選擇，最簡單的可以考慮心智圖或者魚骨圖。一旦有人試圖混淆事情，只要指一指說明我們現在在討論這個點，等討論完有決定之後，再往下一個點前進。而如果兩件事情有關連，就用線條與另一個點來說明此關連。

這也是為什麼，幾乎所有優秀的資訊從業人員(無論是低階還是高階)在會議中都喜歡坐在白板附近。

3. 耐心

簡單的說，就是有耐心的條理事情。透過工具(白板或紙)讓事情呈現。當知道對方採用泥巴仗手法-無論他是不是故意，就表示事情不會很快結束，因此要秉持著耐心條理問題。更重要的是，把這件事情當做類似刷牙洗臉的小事，在處理過程中沒有心情起伏 - 當然就不憤怒生氣)。

---

註1:特別是為求避免衝突，每人的說的話和實際心裡想的都有差距(參考left hand column)，這讓組織 - 特別是資訊科技組織 - 運作上增加不必要的難度。

註2:  並不是去除重複字眼，極端簡潔就是好事。在文學作品中，言詞的優美有時候會透過層層疊疊的語句產生，請參考這裡。不過單就企業組織的溝通 - 例如開會 - 應該和寫小說是不一樣的。

註3: 參考這裡。

註4: 以資訊科技來說，最基本的本職學能是寫程式，其他可以參考這裡或這裡。

建立軟體開發團隊 (1) 計畫 組成

... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作，不可能有完美的狀況。但是，妥善的計劃，能大幅降低軟體團隊的運作風險，並且讓團隊成員專注於發揮專長和創意，減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面，例如：

(1) 目標極端困難。例如：要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如：團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成，目標也還沒確認，就已經有時間壓力。例如：一個2-3個人合作的新創公司，剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如：在大企業中，因為高層要求，一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員，在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標，併購等等)，讓某個團隊大幅流失人才，而需要重整補齊人力。

(7) 因為文化與跨國合作困難，導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人，最最基本的認知就是：

軟體團隊組成這件事情：本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊，其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考：

(1) 了解探索事實，盡可能將事實攤在陽光下

許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」，或者「假設在3個月後可以找到2個優秀的iOS開發人員」，或者「假設大部分的使用者都有fb的帳號」，或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下，很多事情的確有假設，才能進行下去。

但是，在建立團隊的時候，除了瞭解背景假設之外，先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景：

可參考下節「確切定義短期中期目標」。如果是非營利組織，團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業，營利組織，除了獲利之外，也可能會伴隨其他更遠大的目的。例如：「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體，也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的，如果只是單單純純想賺大錢的公司，例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的，就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知，才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊，自然不會將社會責任活動當作是團隊成員想要做的事(例如：到沙灘撿垃圾，協助獨居老人)，當然「培育企業人才」也不太需要，甚至Scrum裡面的「自己選取task來做」也根本不用，採用由上而下的軍隊式管理，讓工作以最有效率的方式完成，才是這種團隊的最好方式。


(b) 資源現況：

目前的現況是不可否認的事實，但許多人一開始的時候，會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人。...這就是資源現況。

但也有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣，其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人，年預算只剩下600萬台幣，所以可以找10個人，但是平均年薪只能為60萬，或者找6個人，平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人，資源現況的瞭解和掌握，必須要越清楚越細節越好。實際上，絕大部分的情況下，只要稍微多花個幾個小時，就可以掌握到很多現況細節。


(c) 組成專長：

即使已經是軟體開發的專家，這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定，組合的專長可能大致確認。然而，某些專長不見得是「團隊成員需要有的」，這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段，需要清晰可見的專長分佈圖。

以上圖為例：簡單地列出做一個購物網站可能需要的專長，並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是，這樣的圖並不是要完全技術上正確，而是要做為未來計畫的參考。因此有可能一再修改，也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素：

哪件事情做好了，會讓這個團隊成功。成功關鍵因素應該只有1-3個，不應該太多。 這個關鍵成功因素必須要很「實際」，能夠被「衡量」，當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例，他的關鍵成功因素不只是火箭能發射，還要能「掉回地球後，能自己站立，以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而，建立組成的本身也有關鍵成功因素。例如，在2個月內吸引3個具有5年工作經驗，並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然，不可能花幾百天的時間，只是為了收集事實，只要在合理的時間內，盡量收集了解重要的事實。

(2) 確切定義短期中期目標

前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言，八九個短期目標完成後，差不多就等於一個中期目標完成。

任何軟體開發計畫，必定會有目標，而讓團隊朝向「同一個方向」前進。所謂團隊，當然是一群人往同一個方向前進，才能叫做團隊。一群在同一個組織架構的人，或者在同一個老闆底下工作的人，不見得是一個團隊，很有可能每個人在軟體開發

(3) 根據目標擬定計劃和備用計畫- Plan B

兵法有云「夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！吾以此觀之，勝負見矣。」

計劃本身並不重要，但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情！

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容：

(a) 團隊目的，短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是，哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示，根據分佈圖，來劃分團隊組成。

切勿用想像的方式。

以上圖為例：這是一個打算建立電商網站的技術分布圖，和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示，團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節，而且也把技術不相干的東西納入（例如裡面有個API doc，其實是還沒有去做的事情）。但整件事情的精神在於「視覺化」。透過視覺化，對團隊的變化才有整體性的考量和規劃，而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡。


(d) 初始化工作項目

當團隊的成員是逐漸到職，最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節，但是是隱含的關鍵成功因素。

初始化工作項目，在新成員到職的前幾天，最好是鉅細彌遺。規劃了新成員第一天到第五天，「每天」要做的事情和達成的結果。並規劃前4週，要達到的大項目，以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短，對團隊的組成越有利。

規劃前五天的細目，絕對不會讓這個新成員變得沒有創意，也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內，先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項，如果在前一段時間沒有擺脫，之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目，同時也是檢閱清單：

Day-1  
    - Mentor介紹工作環境，取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限，確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件，Mentor協助了解文件內容
    - 參加Scrum會議，理解Scrum雞與豬的原則 
    - 在Mentor協助下，建立自己開發環境

Day-3
    - 在Mentor的協助下，在自己的開發環境確定能修改程式/簽入(commit)/建立branch，最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例，這些看似細節，但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡和這裡。

簡而言之，建立團隊的過程也需要被檢討。

例如：

新加入的成員，在當初面試的時候所呈現的能力，和實際上工作的產出，是否吻合。

新的成員對於非技術類型的雜事，是不是很快能找到資訊。例如git的位置，目前各個branch的狀況，自動化建構的方式，建立開發環境的方式等等。

---

註1：如果這個挑戰對負責組織團隊的人來說太過困難，最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天，或者品質降低一些；但是一個失職的領導者，會讓整件專案崩壞。


註2：例如xspace

註3：建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術，需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等