會議上沒共識、私下又意見一堆！身為專案負責人你該怎麼辦？

你的團隊從組成到高產出，花了多少時間呢？一個月、一季還是一年？

其實就像情侶相處一樣，從相識、熟悉、到熱戀一直到分手（也不一定會分手啦），在關係建立過程中有許多不同的階段，產品開發團隊也是一個有機體，從團隊建立開始，通常需要一段相當可觀的時間才會度過磨合期、開始有穩定的產出。

我自己覺得比起小型團隊，在大型組織內「協作磨合」的問題困擾我更多，因為合作的人數非常多、分工也很細、和每個人的關係也不是那麼的親近。

因此這篇文章想就我個人的經驗，整理出一些磨合期的特徵和可以做的事情，希望以後自己卡關的時候可以再回頭看這篇去除一些當局者迷的盲點，如果你也跟我一樣為了磨合期而煩惱不已，也不妨參考看看！

團隊建立過程的五個階段

1965 年時，一位美國心理學家 Bruce Tackman 定義了團隊建立的五個階段，在此引用一下他的定義，並且幫大家做個簡單的摘要：

建立期（Forming）
團隊初見面，開始瞭解團隊的定位和目標（但是或許還一知半解），信任與共識尚未建立，屬於互相接收知識的上工適應期。

磨合期（Storming）
對於共同的目標團隊開始有了不同的解讀和意見、也有了意見分歧、對於彼此的期待也或許會有落差，這時期會有很多的摩擦和衝突，是整個過程中最不好受的一個時期。

規範期（Norming）
這時期開始團隊有了比較穩定的流程、也開始理解彼此的職責、強項，整體來說會覺得「有上軌道了」，有的時候規範期和磨合期也是會重疊的。

高效期（Performing）
一但規範期也穩定之後，團隊再也不需要擔心各種「人」的事情，可以專注在把「事情」做對、做好、做更好，就算出了問題也能夠迅速的接球傳球並射門得分，這個時候才算是真正的
高產出團隊。

休整期（Adjourning）
這個階段是這位心理學家在 1977 年才加進去的，這個階段是當團隊階段任務結束、或者團隊解散時有的時期，就像分手一樣，在這階段人們會感到失落與不捨。

面臨「建立」和「磨合」這兩期的時候需要處理大量人與人的關係，非常消耗心力，這段磨合期可長可短，成熟的團隊、專業的夥伴和好的組織設計可以降低陣痛期的痛，但這個過程通常會讓團隊充滿不滿和壓力，若是關係沒有建立好，也有可能會造成後面的問題。

如果公司很常進行組織重整（re-org）或者組員的來來去去很頻繁，團隊可能在昇華到產出期之前就又要砍掉重練。

其實現在大環境的變動很快、產業變化也會很快，不管是新創公司、或者大型組織，重整的頻率會相對於我們父母的那個年代還來得高，也因此我認為若團隊領導者們建立一套好的機制和心態來協助成員度過「磨合期」，會大大增加產品開發與迭代的效率。

所以，我該如何協助團隊順利度過磨合期？

在建立團隊之前：清楚的定位（Ownership）和目標很重要

在建立團隊的時候，每個團隊都要有清楚的主權定位和目標，所有討論都該從「我們團隊為何要存在」開始出發，若連這點共識都沒有，後面的路只會更難走。我自己踩過雷之後，我認為在開始一個團隊前，領導者們需要一起去釐清以下這些問題：

▲我們團隊的目標和願景是什麼？為什麼需要有這個團隊？
▲我們如何定義與衡量這個團隊是否是成功的？
▲為了達成目標和願景，我們一開始會先做哪些事情？我們團隊負責的範疇（Scope）和主權（Ownership）？有哪些事情決定權是 100% 握在我們手上的？
▲公司中有哪些團隊會跟我們密切合作？我們是否和其他團隊有重疊或相似的產品領域與範疇？如果決策打架，我們該如何做決策？

關於這些問題的答案，通常設計組織架構的人（通常是老闆或大主管）會有個大概想法，但領導團隊的人（通常是產品經理或工程主管）也必須要一清二楚，兩邊必須要有完全的共識，如果有覺得不合理的地方也必須提出。

我曾經在以上的答案並沒有完完全全釐清時就加入新團隊，因為大主管說我們先跑跑看再看看怎麼調整，結果這一跑就是三個月的超痛苦磨合期，不管怎麼做決策都是跟別的團隊打架，天天都在打架團隊效率自然很差。

1. 花時間瞭解團隊之間合作的問題

假設上面問題都釐清了，我加入新團隊的第一步會是觀察和瞭解目前團員們遇到的問題。在這階段身為一個產品經理你可以做這些事情：

▲和成員 1–1 瞭解他們在哪些地方卡關或感到挫折
▲參加所有相關會議，筆記下你看見的問題和狀況
▲和主管 1–1，分享你觀察到的問題，試著瞭解更多歷史脈絡（context）

這部分有點像是補足步驟零的不足，畢竟有些問題可能真的沒有跑不知道，開始跑了之後會有各種狀況，需要不斷的反饋和調整。在 1–1 的情境下，我們可以專注在單一夥伴身上，有足夠的時間去傾聽與理解他們的疑問，像這樣子的一對一互動也是一個很好建立關係的方式。

2. 將問題視覺化、確保大家要解決的是同一個問題

當問題很複雜的時候，這招很管用。

瞭解問題後，你會發現可能工程師有工程師的困擾、設計師有設計師的疑惑、分析師有分析師的瓶頸，這個時候問題不只一個面向、可能是環環相扣，那麼我會建議先把問題寫下來，再來解決。
視覺化的方法有很多種，例如：用 Post-it 蒐集問題之後，分門別類；或者是將問題整理好後，畫成樹狀圖或者 mindmap（心智圖）；或者把所有問題與細項用 Spreadsheet 整理成表格等等，端看你遇到什麼問題。

如果問題真的太複雜，另一種做法是寫出「現狀」和「理想狀態」，再來比較兩者之間的差異，以找出目前的問題點、也有利大家一起思考「如何朝理想狀態前進」。

3. 選擇對的人、在對的場合解決問題

什麼是對的人？
產品經理是個 generalist（通才）的職位，我們可能樣樣都瞭解皮毛，但絕對不會是每個領域的專家，所以「事必躬親」不一定是最有效率的。

如果問題是「系統設計的內部討論流程太混亂」，那麼我們可以協助把問題和它對團隊和產品的影響寫清楚，交給工程主管或資深工程師們去處理。如果問題是和其他團隊的領域打架、不知如何決策，可以上報大主管們請他們來主持與說明各團隊該如何互動。

什麼是對的場合？
有的問題不是線上拉群組文字討論就可以解決的，這種時候就必須下定決心找大家面對面聊，可以是會議形式或工作坊形式，總之需要一個痛定思痛把寶貴的時間拿來處理「人」的問題的決心。

和「蒐集問題」時需要一對一情境正好相反，「解決問題」的時候通常需要群組共識，因此關鍵就是要創造一個公開透明誠實的討論環境。

就我自己的經驗，團隊磨合期的問題常常都是「一群人對於某件事情或方法沒有共識」或是「決策流程太混亂，不知道誰可以做什麼決定」所造成，如果你私下去找 A 談找 B 談又找 CD 談，還不如一次把 ABCDEF 拉到同一個會議，點出問題讓大家公開透明的討論。

【磨合期常見做法】期望分享會議 Expectation alignment meeting

有的時候團隊的每個人來自不同背景、公司、產業，可能因為過去經驗的元素導致有特定習慣的工作流程和方式，對於角色責任的定位也會不同。例如同樣是設計師的職位，有的公司會希望偏重UI、有的注重流程，對於同樣是產品經理的職位，有的公司會希望產品經理做時程控管，但有的公司希望產品經理專注在產品策略。

為了加速大家熟悉彼此的過程，我們會開 Expectation alignment meeting，大家可以討論每個人的職位應該要負責什麼、不負責什麼，藉由這個過程去釐清一些灰色地帶，訂出工作協議（Work agreement）。這是在歐美國家的團隊中很常見的做法，非常推薦！

4. 將解決方案系統化、持續觀察團隊狀況

● 使用文件協助決策流程
使用場景：當問題規模很大、有多個解決方案或者需要多方利益關係人（ stakeholder）的同意的時候，當然遠端工作的時候也很好用！

使用方法：其實很簡單，就是與其大家來來回回討論，不如就拿份文件，把問題的前因後果、目標、決策原則、可能的選項和每個選項的優劣寫下來，讓大家都有機會提出自己的選項，一目瞭然可以瞭解所有方案的決策邏輯。

● 每週團隊的 Show & Tell
使用場景：當團隊成員對於彼此的進度掌握不足、或者對於彼此工作內容不熟悉、又或者需要促進合作關係的時候（例如工程師和設計師）

使用方法：Show & Tell 會議其實就是讓大家展現自己這週的成果的時間，平常產品經理很多話，這時間就讓工程師和設計師秀一下自己的成果，讓大家互相問問題、給一些簡單的回饋，如果發現跟自己想像的不一樣也可以提出來。

● 使用 Trello 或其他 Kanban board 取代列點式會議記錄
使用場景：一個需要長期耕耘的主題（例如團隊的 Retro、或者和行銷業務團隊的每週例會等等），包含多個項目的複雜任務，或者包含多個團隊人數眾多的協作團體。

使用方法：會議紀錄通常都會包含會議的內容、做出的決策以及下一步該做的行動（action items），如果是。這種時候就可以用 Trello，把每一個行動（action item）開成一張主題卡片，也可以用不同欄位（column）表達不同階段，這樣對於需要數次追蹤的事情或者比較複雜的任務來說，會比單純的會議紀錄更好管理。

我會建議大家在嘗試新方法的時候，不需要一開始就定死，可以先嘗試跑個一兩次，試個一兩週，就當作做實驗，如果有用的話就繼續用，沒有用的話也不需要強加流程。

這些方法都是我使用了之後覺得對團隊來說很有幫助，所以後來就沿用下去的一些小撇步，希望對大家有幫助囉！

【延伸閱讀】
產品願景真的重要嗎？五步驟教你打造團隊溝通的秘密武器！
產品團隊組織劃分- Product Organization Structure

※本文獲產品三眼怪實驗室授權轉載，原文出處：【產品團隊甘苦談】該如何協助團隊順利度過磨合期？

責任編輯：梁喆棣