UED 團隊組織架構應該是怎麼樣的？

01-09

你們覺得應該按照業務支持來劃分好，還是按照專業維度來劃分好？
還是其他？

這個，可能要考慮到團隊規模。在大公司裡面，我覺得從公司整體的運作來說，還是按照業務支持來劃分好。理由如下：

1、公司一旦大起來，跨部門的溝通與協作成本將會非常非常的高，如果UED作為一個公共部門存在，而不是在具體業務中，又將極大的提升這種成本。

2、在人員相對穩定的基礎上，UED團隊中的任何職位，都必須非常熟悉產品和業務，才能夠提供靠譜的設計。很多時候，對產品的了解，要比實際的技能和通用的設計經驗更重要。

3、跟UED團隊中的成員合作最頻繁最緊密的，並不是團隊內部的同事，而是處於UE上游的PM，以及處於UE下游的前端等技術團隊。那麼，按產品線劃分，有利於合作的各個環節的相互交流、溝通和了解，有利於彼此的適應，進而有利於提升整體效率。

但是，就像上面的朋友提到的，「如果按照業務維度，只是一時增加了和業務團隊的緊密合作程度，時間一長，ued一定會被業務壓下去而無法發揮作用。」所以，以上理由，還需要基於下面的前提：

1、UED跟其他團隊，需要擁有同等的話語權。至少不能很弱。

2、在相互合作和溝通的前提下各負其責，對於UE所涉及的細節，UE有否決權，任何PM和技術人員，只能提建議，然後大家討論，但最終如何設計，必須由UE決定。（同樣，PM等團隊，也對於自己所負責的那部分擁有否決權。比如，一個功能，要不要上，大家都可以提出自己的見解，但是最終由PM決定。）

3、從管理上，KPI分配上進行調節，保證個團隊人員都做事相對客觀。

以業務劃分為主，專業為輔。

通過實際項目鍛煉個人的專業能力，內容加強總結分享提升團隊技能。

專業維度更利於長遠發展。如果按照業務維度，只是一時增加了和業務團隊的緊密合作程度，時間一長，ued一定會被業務壓下去而無法發揮作用。到時候用戶體驗就是扯淡了，不停的上新產品，不停的下老產品，所有人都是流水一般。退一萬步說，ued和業務、技術團隊的合作好壞，不應該是由部門架構決定的，而是靠人和制度。