大家好，我是產品經理大會主持人“驪山老郭”，今天是第14篇文章。我們來聊聊作為產品經理，在會議上，面對四面八方的發散需求，如何高效的記錄會議紀要？
小冰是入職兩年的產品經理，也是我的同事。
管理項目、輸出需求文檔和原型、溝通都沒問題；但讓小兵苦惱的是自己總是會理解錯業務的需求。
有一次甚至都開發完了，才發現需求理解有偏差。溝通之後，小冰才說了出來。
那天因為是一個推廣活動，所以運營、合規、銷售、產品、領導都一起開會討論方案，小冰作為產品經理來撰寫記錄會議紀要。
因為人多嘴雜，運營拋出一個方案，大家七嘴八舌的討論一番；
有的被否定，卻又說了可以做；有的方案被大家通過，但覺得這個可以作為一個補充保留下來。
小冰聽一句記錄一句，最後會議就散了，小冰的本子上記錄了滿滿的需求討論方案。
經過分析，小冰連夜加班出了方案，和運營的某個同事確認方案的可行性後，召集技術進行開發。
等到快開發完成，領導發現開發出來的只是他們會議上討論的備用推廣方案，不是主打的方案。
而相應的海報和文案都是按照主打方案來做的，所以基本上可以宣告本次的推廣方案已經失敗了，之後領導狠狠的批評了小冰，並扣除了他全年的績效。
無獨有偶，類似於這種的事情，幹過產品經理的人都遇到過。
然而通過上述的例子，作為產品經理，我們才能體會到，能正確記錄和理解業務的需求才能避免我們的功夫白費，才能使我們輸出的產品符合業務的需求，才能滿足符合公司商業戰略，更重要的是避免被扣績效。
所以，在前期蒐集需求階段，尤其是這種直接會議的場合中，能準確和高效的撰寫需求，才是檢驗一個產品經理是否合格的側面反饋；也是上層領導考察你領導力的關鍵場合。
但有人可能說了，直接會議的方式，涉及到的部門眾多，涉及到的關鍵人員也多，那麼在會議上大家討論的需求都不確認，這一句那一句的，怎麼記錄和確認呢？怎麼才能高效理解，並輸出高質量的會議紀要呢？
今天我們一起討論下有幾個辦法能滿足上述的疑問。
首先，明確會議的目的是什麼？
一個需求或者一個項目的設立，都是應該有明確目的的。
比如說運營提出的推廣方案，在這個階段主要以拉新為準，在下個階段以促活為準。
那麼作為產品經理，在開會前應該明確方案的目的是什麼，進而在會議上，專注於需求方對於這個目的提出的方案來做記錄。
方案可以分1、2、3、4的記錄，記錄完成後，及時與提出方案的需求人員在會議上當面確認是否有遺漏。
還有另外一種情況。在會議中往往會出現不可控的現象，說著推廣的方案，結果發散到了促活的點子上，而且往往中間還穿插著拉新的小點子，雲裡來霧裡去的發散。
如果遇到類似這種情形，類似於不屬於實現該目的的方案，建議聽聽就行，只要沒形成完整方案，不用過多記錄。
其次，會後再次與需求方確認本次會議記錄的內容
會議有時候會持續很長，所以前期討論的方案，會被後面大家討論的更完整方案所覆蓋；
此時作為產品經理在會後要及時將這種差異點和風險點暴露出來，如能當面確認則及時更改，如不能當面確認，會議紀要中需要寫明或者標明差異點並與之確認。
一個方案的成型是需要多次打磨的。大家在會議上討論的方案和本身可實行的方案往往是有差異的，有技術方面，有政策方面，也有資源方面的原因。
所以作為產品經理，在發出會議紀要之前，需要在會議紀要中標明，提醒業務部門。
然後，會議紀要的格式和方法
每個公司有每個公司的會議紀要的格式，但基本上就是參與人員、缺會人員、參會時間、會議內容，已決定的方案、待定的方案、異議方案等等。
參與人員：包括部門名稱和部門人員；
缺會人員：涉及到該人員，但未參與會議；
參會時間：寫明年月日時；
會議內容：將會議中提出的所有基於本次目的方案、提出人記錄；
已決定方案：即會議上大家認可的方案；
待定的方案：即一些基於該目的的備用方案；
異議方案：即有意見的方案。
整理完會議紀要後，記得抄送相關業務部門領導和同事，確保各位信息同步；與關鍵需求人員溝通，確保回覆郵件確認本次記錄的會議紀要。
綜上，本次會議紀要才算高效的撰寫和記錄
會議紀要的發出並不代表本次需求的確認，只代表高效的完成了本次會議的結果輸出。
所以與業務打磨、與技術打磨、與自己打磨後，最終可能會產生與會議紀要中不一樣的推廣方案。此時我們才能根據該方案輸出需求，進入開發，達成最終目的。
補充：作為普通人，我們沒有喬布斯、張小龍般的才華，也不是擁有超級記憶力的天才。支持我們能在職場上走的更遠的一定是謹小慎微的仔細，所以各位可參考上述幾個方法，從高效的撰寫會議紀要開始。
