17年十一過后突然接到大boss的任務，要在年前對現(xiàn)在的前后臺產品進行整體重構。大boss只是在戰(zhàn)略層面上給了2個大方向和1個deadline，就讓我們產品著手開始干了。因為這次重構涉及到前后臺所有的產品線，而且時間緊任務重，所以幾乎整個部門所有人都參與進來了。之前沒有經歷過這么大的產品項目，過程中遇到了很多問題同時也學到了很多東西。在這里跟大家分享下，希望能給到大家一些幫助。

一、宣講產品目標

提到產品目標，大家可能都覺得太虛，大部分產品都更加喜歡上來之后就說產品功能，例如我們這次要做一個問答的功能需要有問答頻道、問答列表、提問彈窗等等，感覺這樣可能更接地氣。然而我認為整個產品規(guī)劃的第一步應該是向項目組成員宣講產品目標。

首先跟大家同步下 我理解的產品目標是能為公司帶來的價值及為項目組成員帶來的價值。例如我們這次的產品重構，從公司角度上來說其實是公司業(yè)務轉型的一次重要嘗試，將決定公司接下來5年的發(fā)展甚至有可能改變整個行業(yè)。這樣讓大家覺得我們是在做一件有意義的事情，精神層面會有成就感。從個人角度來說，這是一次難得的機會，可以從頭開始參與一個全新產品的設計，而且業(yè)務還是如此復雜，過程當中能學到很多東西。不論是在公司內部的發(fā)展還是未來換新工作，這都是一張非常漂亮的成績單。大家可能還是會覺得前面提到的有點雞湯，所以最后要來點接地氣的，比如項目經費是多少，成功上線之后大家的能分到多少獎金。畢竟大家出來工作大部分都是為了賺錢，先把獎金拋出來會更有動力。

二、明確團隊角色及分工

1、決策者

決策者是產品團隊的核心人物，然而產品的決策者并不是一個人。

很多人認為老板才是產品的決策者，老板具有最高話語權。然而產品設計過程中有很多的東西需要確定。如果所有的問題都需要老板決定，項目進度肯定會有影響。同時老板并不是專業(yè)做產品的，很多細節(jié)的問題讓他來決定并不靠譜。而且如果產品設計過程中，成員沒有一點決定權，勢必會打擊大家的積極性。所以需要基于重要程度來分別設定不同的決策者。

例如產品對應的商業(yè)方案肯定是需要老板決策的，然后核心頁面需要產品總監(jiān)決策，之外的其他二級頁面、三級頁面，產品總監(jiān)如果有時間可以給點調整意見，但是盡可能放開手讓大家去做。

2、項目經理

大部分互聯(lián)網公司內部都沒有設立專門的項目經理崗位，很多時候都是產品經理擔任了。但是一旦涉及到多產品同時協(xié)作的大項目時，就一定要設立這樣的一個崗位。

項目經理需要負責控制整個產品范圍、制定及監(jiān)控項目進度、組織溝通會議、協(xié)調安排項目成員等工作。如果說決策者是對產品負責，那項目經理就應該是對項目負責，需要從范圍、進度、人員、成本等多方位考慮，以保障項目的成功。

3、會議記錄及整理員

產品規(guī)劃階段，會頻繁的開會溝通，很多想法都是在會上碰撞產生的。但是碰撞的過程大部分都是非常凌亂的，所以為了保證好的想法能最終被記錄下來，每一場會議都必須安排一個會議記錄及整理員。

注意我說的不是單純的會議記錄員，而是記錄整理員。如果只是把所有會議上的溝通點記錄下來沒有任何意義，因為大家沒有時間把所有記錄的內容看一遍 再找有用的點。所以記錄完需要整理，最終出來的文檔里必須要明確的記錄下：會議決議及對應的執(zhí)行分工、待決議事項及對應的處理方法。

建議每場會議分別由項目組不同的成員來擔任會議記錄及整理員，畢竟這是一份相對瑣碎的工作長期安排一個人做，不利于他的成長也不利于團隊和諧。

4、資料整理員

這是一個項目前期我們忽略的角色，但是到了后期UE設計的時候才發(fā)現(xiàn)少了這個角色，嚴重影響了項目進度。因為需要設計的頁面特別多，時間很緊，所以基本上是每個人負責幾個頁面的設計，對應的UE也都是在自己手里。當其中一個成員請假后，就會發(fā)現(xiàn)他的東西沒人能接手。再就是 因為調整版本太多，大家每個人的文檔整理習慣都不一樣，想要把方案整合到一起特別困難。所以項目執(zhí)行到一半，增加了資料整理員的角色。

資料整理員的工作就是——

1. 每天晚上負責把大家當前手頭最新的產品方案UE、流程圖等 收集上來；
2. 按照項目文檔的命名規(guī)范 整合在一起；
3. 將整合完畢的資料上傳到項目組的共享空間。

5、產品設計人員

最后就是我們產品經理的本質角色——產品設計人員。這里沒什么需要多說的，只不過作為團隊負責人，在分配產品設計任務時 除了考慮項目的進度和質量問題，如果可以盡可能多考慮下人員的成長。例如后臺的產品經理，如果想嘗試前臺的產品設計，請盡可能給予機會。

三、建立規(guī)范的溝通機制

對于這一點之前跟很多朋友聊到的時候，他們都特別不屑。認為在前期產品規(guī)劃階段，就是天馬行空的碰撞才會有好的想法，不需要搞什么規(guī)范的溝通機制，隨時想到了就隨時組會討論就行了。我認可在產品規(guī)劃階段，確實不需要設置太多限制。但是這并不意味著不需要規(guī)范的溝通機制。

我曾經就經歷過這種所謂自由開放的項目，領導隨時想到一個點就拉著大家一起去開會溝通，然后大家七嘴八舌 開始發(fā)表自己的想法，整個會議氛圍特別火熱有激情。然后會議開了2個多月，產品卻沒有一個基本的雛形，各種各樣的想法，今兒想到了 明兒就忘了或者是明兒就被推翻了。結果可想而知搞了3個多月，最后一個月不得不上線了，只能找各種相似的產品 東抄一點西拼一塊 湊成了新產品推到了線上。

我所謂的規(guī)范的溝通機制，并非限制大家的思維發(fā)散，而是有目的 有方法的去溝通，盡可能減少無效的溝通。接下來跟大家分享下，我梳理的溝通機制。

1、建立會議機制

日會：每天召開一次，建議早上開。會議目的是 回顧昨天的工作情況，明確當天的工作計劃。

周會：每周一次。會議目的是 穿透項目整體進度，梳理下周重點工作。

臨時會議：不定期召開。會議目的不固定，但是會議前必須明確目的。

2、明確會議目標

無論什么會議，會議前必須明確會議的目標，拒絕無意義的瞎聊。也許在前期這個目標比較大，但是也必須要有，否則大家聊得過程中沒有一個中心點，會無邊發(fā)散，最后沒有結果。

3、提前做好準備工作

與會人員應該提前做好相關的準備工作，盡可能不要在會上臨時去找資料。例如當前整個問答模塊進行重構，需要開會討論下重構的方向。參會前需要提前了解到 當前的問答功能的邏輯、本次重構的目的、當前問答模塊的PVUV等數(shù)據(jù)、競品的研究等等。

4、做好過程中的會議記錄

好的想法極難出現(xiàn)，然而在高強度的腦暴過程中又極容易被忘記。所以過程中會議的記錄員需要記錄下過程中的所有相關點，以備后續(xù)深入擴展。

5、必須有明確的會議產出及后續(xù)的工作安排

爭取每一次的會議 至少產出一個明確的決議以及對應的后續(xù)工作安排，以此來保證每一次的會議都是有意義有結果同時可落地執(zhí)行的。

四、建立文檔格式、命名規(guī)范、修訂規(guī)則及存檔方式

提到這一點就異常難受，因為前期沒有梳理，項目過程中導致了大量的時間浪費。例如在設計UE過程中，有的人習慣用Axure，有的人習慣omnigraffle ,然后有些公共的模塊，就無法復用，需要重復做幾遍。后期在跟UI對接的過程中，我們這邊UE的頁面是叫【圈子詳情頁】，然后到了UI那邊就是 叫 【圈子01 】。整套產品大小頁面差不多 200多個，命名一亂，不僅是要用的時候找不到，平時大家交流過程中也很痛苦，經常驢頭不對馬嘴。

所以前期一定要建立文檔命名規(guī)范、修訂規(guī)則及存檔方式。每個項目都不一樣，所以我這套方式僅供大家參考。

1、文檔格式

會議紀要：所有會議紀要統(tǒng)一用 思維腦圖 記錄。我們都是統(tǒng)一用的百度腦圖，因為可在線共享。

AI信息架構：思維腦圖

產品需求清單：Excel表格，表格中注明 對應的頁面、需求描述、優(yōu)先級、提出人、當前進度等等

產品UE：Axure

產品UI：PS

產品PRD：統(tǒng)一維護到confluence里，然后PRD統(tǒng)一編寫的格式，我們這邊是之前梳理過PRD模板，所以相對來說比較清晰。當然有很多時候項目比較近，可能來不及寫非常細節(jié)的PRD，但是建議復雜的邏輯還是最好寫在PRD里，方便后續(xù)測試也為了后來人能更好的了解產品。

2、文檔命名

會議紀要：項目編號-會議議題(會議時間)，例如 KPFS-PC前臺操作權限溝通會(17.10.24)

AI信息架構：項目編號-信息架構（編制時間），例如? KPFS-PC前臺信息架構(17.10.24)

產品需求清單：項目編號-需求清單（編制時間），例如? KPFS-需求清單(17.10.24)

產品UE：

注：一個產品線統(tǒng)一一個UE文件（包含產品所有的頁面），盡可能不要拆分出多個文件。如果是多人協(xié)作，可以分別單純出UE，但是每天都需要匯總到一起。如果是頁面實在太多，整合在一起之后文件太大，可以考慮按功能模塊劃分是幾個大類，每個分類下的頁面放在一起文件里。

• 整個UE文件：項目編號-產品名稱（最新修訂時間），例如 KPFS-PC前臺UE(17.10.24)
• UE內頁面：序號-頁面名稱（最新修訂時間），例如 01 注冊登錄頁（10.23），下圖我習慣的UE頁面劃分方式。

產品UI：與UE頁面的名稱保持一致即可

產品PRD：統(tǒng)一維護到confluence里，然后PRD統(tǒng)一編寫的格式，我們這邊是之前梳理過PRD模板，所以相對來說比較清晰。當然有很多時候項目比較近，可能來不及寫非常細節(jié)的PRD，但是建議復雜的邏輯還是最好寫在PRD里，方便后續(xù)測試也為了后來人能更好的了解產品。

3、修訂規(guī)范

A 如果是小范圍的修訂，則將原內容用刪除線注釋掉，然后將后面寫上新內容。同時在文檔頂部修訂記錄內寫明本次修訂的內容、時間、修訂人以及修訂原因。例如PRD里的需求調整，可以參考下圖：

B 如果是大范圍的調整，將原內容保留但是要注明已失效，重新編寫一份文檔。

所有修訂的內容，一定要第一時間告知項目組所有人，避免因為信息不對等導致大量無效的工作。

4、存檔方式

存檔方式可以因項目不同隨時調整，我一般習慣的是 按文檔類型先做一級分類，例如UE、UI、會議紀要這是大類，然后每個一級分類下 再按時間做二級分類。因為前面每個文件的命名規(guī)則已經訂好，所以直接按對應分類進行存檔就可以了。下圖我個人比較喜歡的存檔方式：

項目過程中產生的所有文檔，一定要記住存檔。千萬不要以為這版內容已經被推翻了就直接刪掉，因為大boss很有可能看完了5版產品UI，后來覺得還是第一版最好。而且每一版內容都是大家花心思琢磨出來的，即使在這個項目沒有用了，未來也有可能會用到。

五、制作標準元件庫

很多產品需求梳理明白后就開始著手畫具體頁面的UE。經常畫著畫著 想起來這個模塊 之前畫過，然后就回去找之前的UE打開然后復制過來。而如果是多人協(xié)作的情況下，其他人不知道之前有過這個頁面，又會重新畫一遍。這樣不僅浪費時間，還會導致同一模塊出現(xiàn)不同的效果。

為了避免這種情況發(fā)生，建議大家在UE設計、UI設計、前端開發(fā)、接口開發(fā)等協(xié)作過程中，提前梳理出通用的標準元件庫供大家使用。

六、搭建信息共享體系

這里其實就是想跟大家分享我常用的一些共享軟件，便于大家信息共享。

1. 百度腦圖：我們所有腦暴過程中的會議紀要都是記錄在百度腦圖上，然后共享給項目組所有人。
2. Processon：一個在線協(xié)作繪圖平臺,支持在線創(chuàng)作流程圖、思維導圖、BPMN、UML圖、UI界面原型設計、iOS界面原型設計等。我一般習慣用來畫流程圖，因為Mac沒法裝VISIO，使用還挺方便，同樣也可以直接共享出去。
3. 一起寫：云端基礎辦公軟件,支持多人協(xié)作編輯文檔、表格。這個特別好用，例如每周匯總大家每個人的工作進度時，直接把周報模板丟上去，大家在線維護下各自的內容就OK了。我把這個介紹給部門小助理后，她使用后說至少減少了她原來10%的工作量。例如年底為了給大家父母寄新年禮物，需要統(tǒng)計大家的家庭住址。之前都是每個人單獨給她一份，然后她再匯總為EXCEl。用了一起寫，只需要把人員名單導進去，大家每個人在自己的那一行寫下地址就可以了。
4. 奇妙清單：一款todolist軟件，比較適合小范圍的項目管理，例如產品團隊的任務分配及定時提醒。使用特別方便，隨時想到隨時就可以記錄下來，再也不用擔心遺漏需求點了。
5. confluence：這個不多說了，非常好用的一款產品PRD在線編輯軟件。強烈推薦大家使用
6. JIRA：和confluence是同一家公司的產品，用于開發(fā)測試過程中的任務管理。同樣強烈推薦使用

無論用什么共享軟件，也不能代替人與人之間的直接溝通。所以多團隊協(xié)作過程中，大家一定要記得多問多交流。

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

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