專案經理(PMO)對於大組織、跨團隊高效協同有著不可替代的作用。跳出組織架構的束縛，橫向推動公司級別的大專案向前推進，跟進進展和拿到結果，PMO的小夥伴有著獨特的優勢。
我之前寫過小團隊如何高效共同作業的一篇文章《 高效能敏捷交付團隊反思：特性團隊(FeatureTeam)+Scrum》，還寫過一篇關於研發效能團隊組織架構的文章《網際網路公司研發效能/工程效率團隊建設和規劃》。這兩篇文章對於專案推動、研發效能團隊和PMO團隊如何共同作業有過一些介紹，本文將在這兩篇的基礎上做一些補充。
本文重點討論研發效能團隊和 PMO 團隊如何團結一致，合作共贏。
專案經理(PMO)的訴求和目標
首先我們需要了解專案經理(PMO)的具體訴求和目標，以便我們能夠更好地理解和支援他們的要求和期望，並同時從研發效能的角度出發，給出專業的意見和建議，表達我們的想法和方案，一起來探討如何更好地為業務提供支撐，確保各業務線在工程能力與效率上能確實有所提升。
研發效能團隊更關注提高產研共同作業效率、過程改進、產品質量提高和平臺使用者體驗；專案經理(PMO)更關注資源投入、專案進展和業務目標達成。理解這一差異可以避免矛盾,也能更好地找到合作的契合點。
如果一味地進行過程改進和產品質量，忽視了業務目標的達成，造成業務無法按期保質保量的交付。這就成了流程改進的反面例子。
研發效能給PMO提供工具支撐
既然專案經理(PMO)更關注資源投入、專案進展和業務目標，我們研發效能團隊可以在這些方面給予工具支援。比如專案資源的統計，專案進展的視覺化，業務目標的細分和跟進等等，這些都可以靠研發效能平臺來自動統計與展示，方便PMO的小夥伴得到這些資料。
PMO可以給研發效能團隊反饋
當產研的小夥伴和PMO同學都使用我們的研發效能平臺時，我們需要來自使用者的反饋，而作為與業務肩並肩戰鬥的小夥伴，PMO當然有發言權。而且PMO在工具選擇、流程改進和質量提升上有非常高的話語權。我們可以與PMO的小夥伴一起把這些工作做好。
如果研發效能團隊悶頭幹活，閉門造車，做出來的平臺很可能不是業務需要的，這樣的例子比比皆是。平臺團隊在那裡炫技，在那裡撓頭想出了一個好想法，結果業務方都不想看第二眼。
舉個例子，比如很流行的 Infra as Code(IaC)，很多人在鼓吹這個事情，不管公司死活，團隊大小都要上 IaC。我覺得把 IaC 暴露在他原本所在的邊界內可以，比如ops team，但是千萬不要影響上下游團隊，讓大家也都接受 IaC。小公司本來存活時間就短，老闆折騰無所謂；大公司分工合作，高效協同，如果強推某些看似「酷炫」實際對他人無用的東西，非常地遭抵制且危險。
研發效能和PMO互相共同作業
研發效能和PMO都是共同支援業務，所以很多時候要通力共同作業，比如一起參加業務會議，一同收集反饋，共同實施流程改進等等。
PMO因為需要跟進資源、進度和結果，所以和業務方的管理團隊有著廣泛的接觸，可以帶來一線產研小夥伴工作之外的訴求。而這些訴求對於研發效能團隊的成功有著重大的影響。但是這些訴求，也需要仔細甄別，有時候就是某個大佬拍腦袋想出的東西，如果你不辨真偽不分好壞按部就班去做，就會出問題。
比如一些+2+3的大佬，因為已經無法實時跟進N個專案的進展，很難評價一線員工的產出，這時候就想通過程式碼量來辨別一下。其實他自己也是知道如果僅靠程式碼量難以有效辨別，但是苦於沒有其它資料。此時研發效能平臺方就要好好地想一想是否要做這個需求，怎麼做這個需求。
分享專案成果和榮譽
業務成功才是真正的成功。在研發效能團隊的支撐和PMO 團隊的支援下，只有業務取得最終的結果才是真正的成功。沒有結果的過程屁都不是。我們要攜手和業務方一起拿到結果，同時要共同分享專案的成功與榮譽，這將有利於提高團隊凝聚力，這也是對研發效能工作最好的認可和回饋。
舉個例子，曾經有個產品剛上線，前後端一起去團建了，其餘的小夥伴還在公司咔咔的工作。幹活的時候稱兄道弟，剛上線就開始分角色分正式外包，這就有點太傷人了。
思考
專案經理(PMO)對於大組織、跨團隊高效協同有著不可替代的作用。但是這裡有一點點的瑕疵就是 PMO 團隊是否對最後的結果負責。按照雞和豬開飯店的例子來說，雞隻出了幾個雞蛋，豬卻要貢獻一條腿。
我的其它文章
高效能敏捷交付團隊反思：特性團隊(FeatureTeam)+Scrum
研發效能組織能力建設之特性團隊FeatureTeam（上）
網際網路公司研發效能/工程效率團隊建設和規劃
DevOps｜AGI : 智慧時代研發效能平臺新引擎（上）
AI DevOps | ChatGPT 與研發效能、效率提升(中)