我一直認為產品管理是一項團隊運動（）。但是，只要一個組織中有多個團隊並且需要它們彼此互動，就會引入摩擦。團隊之間的這種摩擦，就是我們現在會存在如此多專案管理書籍和方法、收件箱和發件箱、依賴項管理等等的原因。摩擦會殺死動因，摩擦會殺死速度。
如果你刪除團隊之間的依賴關係並引入自治產品團隊，就不會產生摩擦。首先，要確保每個團隊都有執行目標所需的全部技能和專門知識。除此以外，你的團隊是否還有諸如客戶成功、市場營銷、合規等職能的需要？請詳細考慮團隊真正需要什麼技能以取得成功，並考慮如何繪製出多樣性，確保團隊擁有不同的背景、經驗和見解。 下面的蜘蛛圖是一個供參考的模型示意，當你開始確定團隊成員時，你可以快速檢視他們有哪些重疊，在哪些方面具有不同的經驗和技能互補，以及哪些地方需要填補。
這種多樣性，不僅包括性別和背景，還要有技能、經驗和背景，這對於消除對其他團隊的依賴至關重要。並且，團隊中涉及的背景和觀點越多，就越有可能擁有同理心去理解客戶。我最喜歡的案例來自線上貨幣兌換平臺Transferwise。它的團隊負責新增貨幣兌換型別，例如將USD轉換為GBP。可以想象，這比僅在下拉選單中新增選項要複雜得多。這意味著要在目標國家/地區開設銀行帳戶並更新條款，以符合當地的反洗錢和證券法要求。在任何其他組織中，這恐怕都需要團隊去法律部門尋求有關條款和限制要求的幫助，然後去銀行部門尋求與帳戶有關的幫助。但是Transferwise的看法有所不同。在Transferwise，他們在團隊裡不僅擁有設計、工程和產品，也有銀行家和律師，並嵌入到團隊中。這意味著團隊成員無需去另一個團隊或是部門尋求幫助，而是可以專注於完成自己的目標。相比之下，我最近遇到了一位出色的資料科學家，他曾在《財富》 50強公司任職，他自豪地宣佈自己曾在研究與洞察部工作。想象一下，負責研究和見解的部門，是不是聽起來棒極了？整個部門！彙集這麼多聰明的人和驚人的資源來進行開創性的客戶研究、人種學研究、調查、資料收集等，這應該是多麼驚人的研究啊！
但是，仔細一想，這事實上是一個部門壁壘引發的官僚噩夢。思考一下，禁錮的資源，在與所有其他部門之間進行共享時所需的各種申請表、優先順序和批准流程。再想象一下，為了進行研究所需的業務案例而建立的商業案例…我們並不是在棉紡廠或工廠工作，為什麼我們要使用它們產生的管理風格？指揮和控制的模式，只有當所有的知識和技能僅掌握在少數的高層管理人員時才合理，而此時人力資源僅僅是字面意義上的資源，因此可以加以管理。
我們今天使用的大多數敏捷方法和精益方法都來自豐田生產系統。如果你設計了一輛汽車並希望它儘可能的便宜，可以高效且無錯誤地製造它，那麼採用豐田生產系統會很棒。但是我們別忘了，一開始設計汽車的團隊是不能那樣工作的，以生產系統的方式管理設計團隊是無法奏效的。歸根結底，你的團隊比你更聰明，擁有比你更多的資訊，比你更接近問題，比你更接近客戶。那麼，為什麼需要你告訴團隊該怎麼做呢？相反，我們需要增強團隊能力，我們需要擁護自治，我們需要讓團隊利用所有這些驚人的知識，經驗和技能來持續的解決客戶問題。2.1 動機
大多數人認為，激勵的最佳方法是像金錢這樣的獎勵，即胡蘿蔔加大棒的方法。Daniel H. Pink說，這是一個錯誤。在他的著作《驅動力》一書中（並且也在TED有精彩演講），他借鑑了過去四十年的科學研究，認為動機的關鍵是人類對自己生活的深刻需求。他的研究表明，一旦你被支付了足夠的薪水，額外的財務激勵措施就不會使個人或團隊更有動力，更具創新性或感到更加成功。取而代之的是，我們受到自治、精通和目標的激勵。自主是我們渴望自我指導的願望，它增加了對合規性的投入；精通是提高我們的技能和掌握我們的工藝的衝動；目的是對做有意義的事情的渴望。2.2 自治意味著保持敏捷
真正的自主權意味著消除任何依賴關係以及對共享資源或中央團隊的依賴。正如我們從Transferwise示例中看到的那樣，確保每個團隊都擁有所需的一切，意味著不必擔心依賴於其他團隊的優先順序。不僅於此，如果產品的目標得以實現，那麼所有團隊都應該能夠對其進行更改。例如，營銷不必等待產品來構建所需的產品，他們應該擁有建立頁面，更改使用者流或執行其目標所需的其他一切操作的完全訪問許可權。真正的成長型營銷團隊不能只停留在目標網頁上，他們需要能夠按照他們的佇列進行完整的轉化和留存過程，以瞭解渠道或廣告是否真正奏效。2.3 自治意味著每個人都可以參與其中
真正的自主權還意味著團隊中的每個人都可以參與進來，並利用他們的技能來應對團隊面臨的所有挑戰。只有共同創造，我們才能真正將所有這些技能和觀點帶給客戶。正如Marty Cagan所說：“如果僅使用工程師進行編碼，那麼你的價值將只有一半。” 我認為這對我們所有人都適用：如果僅使用設計人員堆畫素，則只能獲得其價值的一半；如果你僅使用產品經理來整理待辦列表，那麼你只能獲得其價值的一半；等等。因此，請你的工程師參與設計，讓你的設計師參與工程討論，讓每個人都參與客戶研究。因為洞察力、靈感和出色的產品創意來自未曾預期的角落。現在，許多人聽到自治權，就會想到混亂或無政府狀態。他們認為這意味著每個人都可以做他們想做的任何事情，建立他們想要的任何東西，然後隨心所欲地來去。
但是，成功的自主產品團隊的關鍵是要承擔責任。僅當團隊不僅感覺到自己是流程和他們所建立的東西的主人，而且他們也感覺到自己對客戶結果負責時，它才起作用。因為那樣，他們將為這些結果而生或者赴死。領導力在設定團隊執行的願景、任務和目標方面仍然扮演著重要的角色，以使這些自主團隊在其中運作過程中擁有邊界和護欄。領導力最大的職責是確保這些團隊之間保持一致，以便每個人都知道他們的目標是什麼，他們如何與公司目標聯絡在一起以及其他人正在做什麼。著名的Spotify小隊和部落模型（第4期DevOps案例深度研究物件之一，文末可獲得影片回顧）背後的敏捷和組織教練Henrik Kniberg用一張2×2的圖表來說明這一點。與任何良好的2×2矩陣一樣，你希望位於右上角，因為高度一致和高度自治是你建立創新組織的方式。
我記得，作為產品經理，這可能依然是我職業生涯中最驕傲的時刻之一。許多年前，我在倫敦的一家SaaS公司工作，構建協作軟體，而我們正在嘗試這種新的工作方式。我們建立了一個由產品經理、前端和後端工程師以及設計師組成的半自治團隊，儘管我們是一家小型創業公司，最初只有兩個團隊，但我們還是按照業務流程對他們的日常工作和重大新功能釋出進行職責輪換。
有一天，我們啟動了一項重大的新功能，完全重寫並重新設計了產品的核心部分，並且首次的，我們在sprint 0的前兩天召集了所有相關人員，明確說明了我們打算做和構建什麼。我說的召集了所有相關人員，是指真正的所有人。當然會包括產品經理、工程師和設計師，與此同時還有銷售代表、市場經理和客戶服務經理。當我們向所有人簡要介紹了專案目標、要解決的客戶問題以及針對如何驗證該客戶問題的研究後，事情就自然而然的發生了。我沒有寫什麼使用者故事，也沒有為該功能繪製任何線框圖。團隊提出瞭解決該客戶問題所需的所有想法，最重要的是，一位初級開發人員提出了基石功能——最終只花了幾個小時進行編碼，結果是它解決了80％的客戶問題。這是我永遠無法獨自想到的東西。永遠不要忘記，作為產品領導者，你和你的團隊一樣出色，建立成功的自治產品團隊併為他們提供達到最佳狀態的空間將是你和你的產品成功的方式。
關於作者：馬丁·埃裡克森
馬丁·埃裡克森（Martin Eriksson）（）擁有20多年在公司和初創企業工作經驗，為Monster，金融時報，哈德勒和科孚多等全球品牌製作了世界級的線上產品。他是Product Tank的創始人，Mind the Product的聯合創始人和策劃人，以及領先的私募股權和風險投資基金EQT的常駐執行官。他還是暢銷書《產品領導力，頂級產品領導者如何推出優質產品並建立成功團隊》（ ）的作者（O'Reilly，2017年）。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31558019/viewspace-2681101/，如需轉載，請註明出處，否則將追究法律責任。
