技術團隊有 Pair Programming，那產品經理有 Pair Documenting 嗎？

這篇文章想來分享我最近跟主管遠端工作時嘗試的共同協作寫文件方法 — — Pair Documenting！

【文章目錄】
- 什麼是 Pair Programming？
- 什麼是 Pair Documenting？
- 為什麼我們會開始嘗試？
- 如何實作？
- 優點＆採用時機
- 結語

▍什麼是 Pair Programming？

先來簡單介紹 Pair Programming（結對程式設計）。

相對於一個人自己寫程式，Pair Programming 的作法則是兩兩一組，由二個工程師同時去實作相同的程式功能。

兩個人的角色分別為：

• 駕駛者（Driver） — 微觀執行者。實際敲鍵盤、寫程式的人，通常會一邊動作一邊說明自己的想法與做法。
• 觀察者（Observer） — 綜觀思考者。在旁邊觀察駕駛者輸入內容的的人，思考邏輯是否正確、有沒有沒處理到的情況、適時討論、即時 Code Reivew。

實作流程如下：

【事前】選定這次的實作目標、定義好範圍與任務

1. 兩人分別擔任駕駛者、觀察者這兩個不同的角色
2. 兩人共用一台電腦，看著相同的內容與畫面，駕駛者負責寫程式、觀察者在旁敲鑼打鼓
3. 定時交換角色

優缺點分別為：

• 優點：即時討論與發想解法、充分學習交流、現場抓錯、互為職務代理人、讓新手容易上工 … 等。
• 缺點：一次出動兩個人力做同件事，有些人覺得較沒效率；有人盯著自己寫 Code 壓力很大，反而無法發揮平常應有的實力。

延伸閱讀：《Code Review 與 Pair Programming》

▍什麼是 Pair Documenting？

我不是工程師，當然沒嘗試過 Pair Programming，但近期跟主管嘗試了一陣子一起寫文件的工作方法。上網查了一下，還真的有 Pair Documenting 這個說法，硬要說的話，其實程式也算是文件的一種對吧？

Try writing documentation with a partner, just like there is significant value pair programming, there is similar value in “pair documenting”. — — 《Core Practices for Agile/Lean Documentation》

工程師的工作時間可能有一半以上都在寫程式，然而產品經理並不會分配那麼多時間在寫文件。

產品經理的文件，根據不同的目的，會有很多種不同形式、溝通方式，所以每一種文件形式、溝通形式可能都會有各自適合產出的方式。而 Pair Documenting 這種兩人同時協作的寫作方式，在某些情境下不但效率高、甚至能夠產出更高品質的內容。

若你還不熟悉產品經理相關的文件，歡迎參考：
1.《產品經理與牠們的文件》by Peter Su
2.《如何撰寫產品需求與規格文件？給產品經理的問題、心法與實作小撇步！》by Anne Hsiao
3.《告別落落長的產品需求文件，用產品啟動文件一決勝負吧！》by Nana Chiang

▍為什麼我們會開始嘗試 Pair Documenting？

先來說說我們目前的狀況：

• 上工以來都是全遠端工作
• 公司只有我一個產品經理 + 專案經理，跟設計、工程團隊合作密切
• 我主管是 COO，也算半個產品經理，跟 Data、Operation、Business 團隊合作密切
• 公司不只一個產品，產品們背後也有多個 Backend Services 需要管理，我們兩個分工來管理這些產品

原本的工作模式：

• 需要文件的時候，各自會以最有效率的方式完成
• 寫完後互相 Review、找相關團隊成員討論
• 討論後，自己再回去看著會議紀錄修改文件

我在之前的公司算是用統一制式的格式寫 PRD 文件，但因為在現在公司只有我一個人、又有很多其他更重要的事情要做，因此就會努力找出當下最低成本能夠達到目的的文件產出形式。

例如：跟會議記錄結合、用 Test Cases / Acceptance Criteria 的角度寫、我生骨架跟目標，讓設計師先寫內容，然後我再補充產品與技術角度的限制 … 等。

💡 會議記綠小撇步：Synced Block

Notion 其中一個功能是可以同步不同文件中的同個區塊，改動一邊的內容時可以同步連動另一邊，因此能夠做到無痛把會議記錄跟文件連動。在會議中如果討論了什麼東西需要修改，可以即時在會議紀錄中的區塊更新，Notion 就會幫你即時同步到文件本身。

至於為什麼不直接改在文件內呢？為什麼還要有會議紀錄呢？

我的習慣是，文件內放的是目前「確認版」的東西，會議紀錄則是我們所有人確認這個共識的過程。所以會議紀錄本身會有時間、與會者、主題等基本資訊，內容則是我們提過的不同版本、誰提了什麼建議、考慮過的因素、討論過程與最終決策等等。

雖然每份文件的核心大綱與寫作邏輯大致相同，但格式還是會因為目的與當時忙不忙而略有差異，未來如果有空才會再回去重新檢視要如何架構與整理，哇，文件債的概念！

這個流程與作法其實目前還沒有造成什麼大問題。但我們想知道的是，有沒有更有效率、品質也更好的作法。

怎麼延伸出 Pair Documenting 工作方式的？

• 我們第一次嘗試共同寫作的時候並沒有什麼特別的感覺，就是單純在討論的時候，兩個人同時編輯同一份文件，把剛才討論的東西寫下來。
• 我們發現這個工作方法滿順暢的，加上一些小限制後，可以持續用這種形式來共同撰寫文件。

💡團隊架構、產品經理分工

發文後有朋友提到，通常一個產品會有多個工程師，但只有一個產品經理，因此比起工程師，產品經理比較難找到適合的人 Pair，也不是每個人都可以請產品主管一起 Pair。

能夠有效實行 Pair Documenting 的情境，非常看團隊架構、產品經理的分工方式。依照文件目的，PM + UX 的組合也值得嘗試！

▍如何實作 Pair Documenting？

相對於一個人自己寫文件，Pair Documenting 的作法則是兩兩一組，由二個人同時去寫同一份文件。

不過我們並沒有分駕駛者、觀察者這兩個角色，而是平行互補的狀態，且兩個人同時都要有產出。

我們是遠端工作，使用的文件工具是 Notion。開啟視訊後，兩個人會移駕到 Notion，可以即時看到彼此的游標人頭在文件的哪個部分。

實作流程如下：

【事前】 選定這次的討論與文件目標，在參與協作前要先各自想過這個主題

【事前】其中一個人要先負責準備文件，包含架構與大綱

1. 兩人用各自的電腦、看著同一份文件，一起檢查大綱、排定討論與寫作的順序
2. 實際討論並一起寫文件
3. 事前定好的共同協作時間結束，打完收工

事前準備的文件的部分，有時候是空白文件（只有大綱）、有時是已經編輯到一半的文件。準備架構與大綱的概念就很像每次開會前都要有 Meeting Agenda，確保大家都很清楚知道今天要做什麼。Notion 裡面本身就有很多模板可以使用，非常方便！

第２點一起寫文件，有幾種做法可以參考：

• [執行＆思考] 可以選擇像 Pair Programming 一樣，一個人寫、一個人觀察與分享想法；
• [善用即時協作工具] 也可以選擇兩個人共同討論完一部分後，各自分頭寫一小部分，寫完後再互相 Review 一次確認共識，接著討論下一部分；
• [分頭使用不同工具] 或是選擇一個人處理文件內文字的部分，另一個人去畫流程圖、拉數據、搜集/整理相關參考資料等等需要用到不同螢幕畫面跟工具的工作，完成後再貼回文件本身並互相檢查內容。

以 PRD 舉例，實際分工方式可以是先一起寫 Objective、Assumptions 來暖身，然後你寫 Problem Statement、我寫 Use Cases 之類的。

第３點共同協作的時間，我們規定這個活動不能超過１小時。

若時間到，我們還沒完成，就會分工要分頭回去寫的部分，並列下 Aciton Items，定好各自的完成時間，以及下次再 Pair 的時間。如同平常在寫文件一樣，不會一次到位，需要多次討論與迭代。

▍Pair Documenting 的優點＆採用時機

▧ 優點一：高度專注、集中火力、速戰速決

Pair Documenting 伴隨而來的同儕壓力，會讓雙方都更集中注意力完成眼前的事情。

這不像是開會的時候，報告的人很認真、聽的人微偷懶；文件協作是兩個人同時都要有產出，自然而然會希望彼此的速度跟上。

而因為要即時產出，也不會發生要發出文件給大家 Review 之前先琢磨很久用字遣詞才送出的狀況。（還是只有我這樣 😅）

雖然剛開始會覺得，把第一直覺的東西就這樣直接呈現出來給對方看有點赤裸 —— 覺得自己的想法或寫法不是很好，思考速度也跟不上對方。

但優點就是能夠快速生出第一個版本，彼此現場討論與交換意見後，事後再花零碎的時間去各自優化和補足文件內容。

💡小前提：兩人都願意承諾一小段時間的極度專注，來共同完成這件事情。

▧ 優點二：結合開會與寫文件，即時討論與交換意見

這點跟 Pair Programming 一邊 Coding 一邊 Code Review 的概念非常像。

一般來說，自己埋頭寫完文件後才會找團隊討論；比較大的專案，中間可能會有幾個接觸點、驗收點來持續確認共識與方向。Pair Documenting 就是把這件事即時處理，若有疑惑、沒共識、覺得可以更好的地方，就可以馬上討論。

開會跟寫文件這兩件事情一般會分開，是因為兩者目的不同：開會是向大家搜集意見、再收斂並取得共識，；寫文件則是自己思考、整理並輸出的過程。

如果兩個人對於大方向已經有共識，只需要討論與發想部分內容；且兩個人都是能夠熟練的輸出自己的思考內容、能夠獨立作業的寫作者，Pair Documenting 即時討論、同步寫作的做法實行起來並不會太困難。

若繼續延伸開會的概念，大綱架構是 Meeting Agenda，那 Pair Documenting 就是兩個人一邊開會一邊寫會議記錄的概念。

只是這份會議紀錄的成果會是可以拿去當成產品需求文件（PRD）、產品啟動文件（Kickoff Doc）、上線規劃文件（Release/Launch Checklist）之類的內容，一舉兩得。

值得注意的是，發散、探索階段因為還很模糊、沒有共識，又需要來來回回的思考，搭配多種不同搜集資訊的方式，因此並不適合使用 Pair Documenting。而沒有共識的主題，或是利害關係人很多的議題，也都不適合 —— 那種情況還是回歸一般多人會議來討論會比較有效率。

💡適用時機：與其等到會議上才來讓大家針對文件提出疑問，不如面對面突破盲點。

- 適合的人：本來就已經擅長寫文件、且有部分共識的兩人。
- 適合的文件類型：已聚焦後的規劃階段，包含進開發前、開發完成後所需的文件。
- 不適合的文件類型：發散、探索階段，包含產品研究、策略相關文件。

▧ 優點三：從彼此身上學習、互相檢視想法與文件內容

除了團隊效率外，個人能力提升也是一個優點。

一同寫作時可以從第一線直接看到對方架構問題的方式、撰寫文字的邏輯，建立更深層的知識傳遞與學習互動。

我平常工作比較常跟設計師、工程師互動，我主管則比較接近商業團隊，因此剛好是個知識光譜與資訊來源很互補的組合。默默覺得除了理解另一頭的知識與在意的事情外，也是一個對焦利害關係人想法的好機會。

最後一點，我主管剛好是英文 Native Speaker，所以也可以順便幫我加強英文寫作能力 😈

💡小前提：覺得對方有值得學習的地方，想要頻繁交流想法及寫文件的方式。

▧ 優點四：強調團隊成果、而非個人英雄主義

做產品忌諱的一點是太愛自己的產品、太愛自己的產出，感到「這是我的產品、我的文件、我的想法，我的想法真的超棒！」以至於想推銷自己的產出、低估其他人給的回饋。

我不需要總是房間內提出最棒的想法、知道標準答案的那個人，但我希望能夠引導團隊提出他們的想法、達成共識並一起前進。

共同寫文件時，會很清楚知道這次的產出是團隊成果。在早期就充分展現團隊合作、共創多人的心血智慧結晶是很好的體驗。

💡小前提：如果你的公司很競爭，很追求個人成果與績效，那可以多想想。

▧ 優點五：平常就培養好職務代理人，同步思考方式與決策邏輯

舉例來說，如果需要開 Kickoff Meeting，我就算請假了，主管也可以幫我開，不會有思想黑洞、邏輯下線、或需要等我回去上班才能決定的事。如果我要離職了，也不用花很多時間交接。

前面也提過我們有多個產品、Backend Services，雖然我已經上工快一年了，但還是有些東西是很少碰到的，因此 Pair Documenting 也可以幫助我快速 Onboard 我沒碰過的東西。

話說回來，一般的文件也應該要有這樣的功能。不過若是能從寫文件的過程就開始同步，對彼此規劃與決策背後的原因會更理解。

💡適用時機：不只適用於 Onboarding，也適用於 Offboarding 唷！

▧ 優點六：肩並肩一起實體工作的感覺

可能因為我從上工到現在都是全遠端工作，公司又只有我一個 PM，雖然參與了非常多的討論與會議，但還是常常覺得自己是孤僻邊緣人 😭

跟同事連線，利用一個小時的時間，一邊做事、一邊討論，真的很像回到辦公室跟同事肩並肩坐著上班的感覺。總之我很推薦疫情期間遠端工作的大家試試看！

💡適用時機：遠端工作久了想要增加團隊感！

之前在《跨國團隊遠端工作好困難？十個技巧增進工作效率！》中也有提到：處理緊急事件時，我們遇到台灣 PM 跟香港工程師需要合力解決的嚴重問題，曾經將視訊一直開著來模擬大家坐在隔壁的情景 — — 主要負責的台灣 PM 可以即時更新台灣端的最新狀況、香港工程師也能夠隨時說明他的假設與處理進度，其他各地的 PM 則分階段幫忙總結狀況在 Slack Channel 裡讓其他相關單位了解狀況。等到危機處理完成，才將視訊關閉。

❌❗該避免的情況

1. 避免共同協作時間過長，精神疲勞！
2. 避免 Micro-management，對方的用字遣詞、標點符號使用方式不是重點，目標、架構、內容與易讀性才是重點！
3. 若沒共識就想要一起協作，就像是沒有想法就去開會，浪費時間！

▍結語

我很喜歡這種借用不同的方法論、從其他團隊的工作方法，來學習如何提升產出品質與加速工作流程的概念。

其實這個概念不是什麼新東西，團隊協作也行之有年，例如： 利用工作坊進行問題研究、發想、點子挑選、優先級排序、寫 User Stories 等等常常都是共同協作的成果。

隨著新的線上協作工具不斷出現，這件事也變得愈來愈簡單方便。推薦一些好用的線上即時協作工具：

• Notion — https://www.notion.so/
• Slab — https://slab.com/
• Airtable — https://airtable.com/
• Figma — https://www.figma.com/
• Miro — https://miro.com/
• Butter — https://butter.us/

最後的最後，老話一句：產品經理真正的目標成果是持續推出好產品、造福用戶，而不是產出文件。文件只是達成目標的一個過程與方法，共勉之 💛

謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒

如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多產品經理職涯相關文章，請盡情長按拍手（max 50）讓我們知道 👏🏻

想要持續追蹤我們的最新文章和 Podcast，記得追蹤「產品三眼怪實驗室」的粉專(◉◉◉)！
想看我們所有的文章與分類，歡迎參考「文章列表」並善用標籤來搜尋與篩選！

我們每週都會認真更新唷！千萬別錯過了～