編輯導語：產品經理在做項目時需要跟多個部門進行交流，帶領好自己的團隊共同完成一個產品的研發(fā)上線；產品經理在團隊中要把控大局，起到帶領團隊協(xié)作的作用；本文作者分享了關于產品寫作流程的思考與積累，我們一起來看一下。

產品經理的日常少不了和設計、開發(fā)、測試、運營等團隊打交道；如何與各團隊的小伙伴協(xié)作，也是值得思考和總結，畢竟“協(xié)作能力”亦是產品的基本能力之一。

9月的月度總結來總結我的產品協(xié)作經驗，緣由是9月做了一次比較大的APP改版；做大需求能讓自己成長，其中很大一部分便是協(xié)作經驗的思考與積累了。

功能上線后，我主動把協(xié)作流程的思考和設計、研發(fā)小伙伴分享復盤，大家坐在一起，討論如何讓整個“產策——設計——開發(fā)——驗收——測試——上線”環(huán)節(jié)變得高效；因此總結了一些實用的方法，落到實處地記錄，在日后的工作中加以運用和改善。

一、整體流程與角色

或許看到【UI設計師】、【研發(fā)工程師】、【測試工程師】這些名詞，都會把他們與相關的角色職責掛鉤，卻沒想到他們還有其他的“角色本領”。

圖1：我的產品協(xié)作流程

無論任何需求，從我做產品以來便是這個協(xié)作流程。

從這次改版需求中，發(fā)掘到其實各團隊的角色絕不僅限于自己的職責范圍，人人都是用戶，人人都是產品體驗者。

例如：

【UI設計師】

• 需求評審環(huán)節(jié)，可以提出界面交互的意見，甚至對于每個按鈕、彈窗的使用，都可以給到產品可能未想到的意見。
• 產品/設計驗收環(huán)節(jié)，可以充當產品體驗者，除了驗收UI實現(xiàn)效果外，還可以指出自己對產品流程的意見，哪里不合理、可以怎么改。
• 功能上線后，配合產品輸出設計規(guī)范，同時和其他各團隊的UI設計師共同討論，打磨更好的產品。

【研發(fā)工程師、測試】

• 需求評審環(huán)節(jié)，不僅可以提出技術實現(xiàn)方案，供產品選擇了解何種更優(yōu)；更可以作為用戶，從自身體驗其他APP出發(fā)，給出產品設計的意見。
• 從用戶角度體驗產品邏輯，復雜了？用戶能使用明白不？這么多我都繞暈了？這類的感覺，可能也是給產品經理一個靈感：產品設計是否合理。
• 總的來說，研發(fā)和測試，不僅僅是工程師，更是用戶；他們在實現(xiàn)和測試功能的時候，產品應該積極地去接納和回應他們的意見；同時也要求研發(fā)和測試更熟悉公司業(yè)務，通過不斷體驗和反饋來熟悉。

給我的成長思考是：對于產品經理來說，

1）借力很重要：專業(yè)的事情交給專業(yè)的人來做，而不是把所有（界面、前后端實現(xiàn)）攬在自己身上。

2）主動很重要：主動包括行為上的主動和心理上的主動。

• 行為上的主動，是指每個環(huán)節(jié)都要主動去push，從上面的協(xié)作流程圖可見，產品是每個環(huán)節(jié)必不可少的角色參與者，主動去溝通和解決問題很重要；
• 心理上的主動，是包括對各方意見的包容和積極回應；不同角色對產品功能提的意見，有合理的有不合理的，積極回應、不要畫地為牢；既能提高“隊友”的參與感，也能汲取各方靈感，完善出更好的產品功能。

二、Case By Case 各流程的協(xié)作思考

下面便根據(jù)這次改版需求中，各個協(xié)作流程出現(xiàn)的問題反思及經驗沉淀進行拆分敘述。

具體問題具體分析，也不至于太籠統(tǒng)。

1. 環(huán)節(jié)一：PRD輸出

1）文檔細節(jié)：PRD文檔是闡述產品整體設計需求背景、設計思路、功能范圍、交互邏輯、頁面細節(jié)及其他信息，因此需要涵蓋該產品功能的方方面面。

高效寫出PRD文檔，可以借助功能結構圖和流程圖，先把邏輯理理清，不著急畫原型和寫文檔；這樣產品對各模塊細節(jié)在心中有了初步估計，寫文檔的時候也能考慮進去。

2）圖的魔力：PRD的主要閱讀者是開發(fā)和測試，他們在接收到一份文檔時，是很不愿意去看“長篇大論”的密密麻麻的文字的；為了提高研發(fā)兄弟的閱讀效率，產品盡量“能用圖就用圖”。

• 首先，做出交互原型，在原型旁寫需求說明也可以；
• 其次能用邏輯圖、結構圖、流程圖，甚至是效果錄屏視頻附在文檔中，都會比長篇大論的文字看得爽。
• 最后，UI、開發(fā)、測試看不懂時，產品記得隨叫隨到，當面討論可提高雙方溝通的效率和深度。一回生兩回熟，主動就完事兒！

3）子需求拆分：接到大需求，學會拆分子需求也是鍛煉對需求的邏輯理解。

知道自己的需求分為幾部分，每個部分的聯(lián)系是什么，若該版本排不完則優(yōu)先做哪個，都是產品需要考慮的事情；子需求拆分好，分文檔編寫，即一個文檔說明一個需求點即可——這樣也便于開發(fā)大佬針對不同模塊分配開發(fā)人員。

2. 環(huán)節(jié)二：需求評審

之前寫過一篇文章，專門思考如何讓開發(fā)懂得產品的需求《需求評審：如何讓開發(fā)明白產品的需求》，亦是關于需求評審的協(xié)作思考。

3. 環(huán)節(jié)三：UI設計

1）產品設計確認機制：從需求評審結束后，UI同學應結合多版本的適配問題給出預估工期；設計過程中，產品除了及時回復，也應該積極配合UI同學；例如共同腦暴細節(jié)、交互細節(jié)的交流互通，也是產品經理學習交互設計的一種途徑。

2）設計的AB test：有時候設計和產品對某交互功能的討論無結論時，可嘗試AB test，讓用戶來選擇，也是一種節(jié)約無謂的討論時間的好方法；可能test多了，產品和設計都能形成一定的交互感知了，也就能避免無謂的討論。

4. 環(huán)節(jié)四：開發(fā)過程

1）產品切忌成為傳聲筒：雖然產品要緊密團結在工程師的身邊，只要開發(fā)看到哪里不懂，產品主動溝通，這是沒錯的；但是切忌成為各種各樣問題的傳聲筒。

在這次需求開發(fā)過程中，開發(fā)有遇到設計的問題、技術的問題（問我要哪個參數(shù)），都是直接找我溝通；后來我直接拉群讓他們溝通，并在群里說明，對應問題找對應伙伴直接溝通。

我一開始會認為“這樣做是不是不太好呀，畢竟開發(fā)是“接單做任務”；但是后來leader和我說，產品是要為結果負責的，中間過程需要提高效率，對自己的磨練并不是在不斷替他人解答不相關的問題中產生的；因此不必覺得不好意思，這是提高效率的溝通手段。

2）PRD更新和同頻：對于大需求來說，中間細節(jié)更改在所難免；而很多時候都是當面溝通定下結論然后執(zhí)行，產品就會忘記同步到PRD，導致測試驗收、日后回溯時遺漏，產生后續(xù)一系列問題。

因此在私下溝通結果要及時同步補充到文檔中，并給相應的開發(fā)和測試做特別說明，目的是確保信息更新是所有人都知道的。

5. 環(huán)節(jié)五：驗收（產品、設計、測試）

注：因三方驗收內容不一致，產品/設計驗收環(huán)節(jié)可與測試驗收環(huán)節(jié)同步進行。

1）專業(yè)的事情交給專業(yè)的人做：一個有能力的產品經理，不是大包大攬給自己，而是知道什么事情交給什么樣的人做。

在前期，我總想著自己也能驗收UI，不僅導致效率降低，也導致了UI和我重復“造輪子”；所以專業(yè)的事情交給專業(yè)的人做，效果更好。

2）驗收文檔：在開發(fā)完成代碼合到test分支后，產品、UI就可以開始驗收了。

需要有一份驗收文檔，給到開發(fā)修改和自己進行二次驗收；文檔需要包括驗收問題、截圖、二次驗收這3列，簡單直接告訴開發(fā)需要修改哪里即可。

6. 環(huán)節(jié)六：功能上線后宣導

在功能上線前夕（大概1-2天），準備好宣導手冊，可以是文檔、PPT；也可以是郵件、在線直播等形式。

需要明確需求會影響那些業(yè)務方的使用，針對不同業(yè)務方所關注的內容，區(qū)分宣導文件的重點。

APP改版需求設計到的業(yè)務方有學管、銷售、客服、運營。

前三者關注的內容基本一致，主要是引導用戶去使用新版APP，為用戶解答初期使用上的問題；因此需要制作新版APP引導手冊下發(fā)即可。

對于運營團隊，他們需要了解新版APP的資源位變化情況，為后續(xù)活動宣發(fā)做好物料準備；因此需要還需要額外告知設計規(guī)范，資源位使用規(guī)范等操作說明手冊。

三、總結

在產品協(xié)作過程中，會隨著對業(yè)務熟悉、技術的淺層理解及團隊伙伴的相識合作，推動的效率會提高。

但是在這個過程中，還是需要多站在不同角色的角度，思考他們的利益，換位思考，盡量避免說出“這個不是很簡單嗎？”之類的話。

多了解設計、開發(fā)、測試的工作內容，主動跟進、主動反饋、積極回應，不斷鍛煉自己的跨部門溝通和協(xié)作能力。

本文由 @莫琳 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議