不管是做壹個項目，還是做個產品，明確知悉「目標」，並且以「目標」為最終導向來分解各個階段目標，朝著方向努力，正如黑夜中向著光明的那壹盞燈，即使道路曲折但只要有方向，就不會迷失。
產品的目標，分為［長遠目標］和［短期目標］：
產品的長遠目標，是與產品定位和戰略掛鉤的，產品最終給用戶呈現的是壹個什麽東西，能給用戶解決什麽問題。
短期目標，則可以理解為長遠目標的拆分，可按時間拆分季度目標、月目標，或者再細顆粒度拆分為版本目標，在考慮短期目標時需要確保方向是在長期目標範圍之內的。
這點相信很多的pm在工作過程中也是知道的，所以不展開細講，寫在這裏，只是強調“目標”的重要作用，不管在分析壹個需求還是在做規劃的時候，都需要有桿“目標”秤，時不時去思考，訊問自己：這符合目前的目標嗎？對完成目標有意義作用嗎？
pm的工作不但是對產品需求進行挖掘分析、產品設計，而且更多的時間需要花在版本/需求管理上，所以，想重點來講講關於版本管理和需求管理的壹些工作經驗分享。
什麽時候需要開始版本的管理？如何進行管理？版本前和版本後具體需要做些什麽？想必是具體的疑惑點，結合自己的工作經驗和總結，個人總結了產品版本規劃的流程規範，具體可以看下圖：
為確保版本開發資源的銜接性，版本開發需要進入並行狀態才不會產生資源的閑置。當壹個版本開發完畢後，就要立馬開展下壹個版本的開發，因此，在上壹個版本的開發完畢前就要完成新版本的需求設計任務。
壹般來說，在完成壹個版本的需求分析（包括原型制作、需求評審、需求文檔編寫）並成功遞交給開發後，就要開始新版本的規劃任務了。
1、版本目標的確定：在這個版本需要處理哪些模塊的功能或者重點支撐哪個用戶
2、版本規劃書：具體要做什麽功能，涉及到哪些端，壹般壹個版本是大功能＋小功能＋眾多bug
3、版本規劃會議（部門內部會議，確定版本，確定資源分配）：眾人拾柴火焰高，個人的力量與想法畢竟有限，而且技術、運營在版本上也會有自身的計劃和想法，因此需要壹起來評審規劃的版本計劃，讓各方了解計劃要做些什麽，也提前準備和進行時間評估。
版本中管理，在我理解，其實就是壹個需求管理的過程。
許多同學會問：那麽每個版本到底要做些什麽需求呢？來源在哪？我個人覺得，管理好需求，就是規劃版本的來源了。
需求可以分為未挖掘的需求、待規劃的需求、規劃開發中的需求，來源包括外部用戶反饋、同事反饋、內部領導、運營團隊、項目團隊以及競品中分析的需求，自己的產品研究得出的想法等等。
那麽根據需求類型也可將需求管理總結為三點：1、用戶反饋的記錄管理 ；2、需求池的管理? 3、當前開發任務的跟蹤
針對以上3個方面的，我總結了3個層面的列表管理清單（需求池的建立及管理工具，有很多，excel、X-mind、trello 、oBridge、禪道，最適合也最直觀的個人還是會使用excel）：
用戶反饋列表，收集各種吐槽、優化建議、新創意idea（用戶的任何壹個反饋，都不能放過。從中挖掘，或許會有新的想法和創意）
使用說明：
只要是有產品的反饋，不管大小，都需要記錄下來，最原始最直接的反饋，往往是很多pm會不重視。
及時針對反饋進行等級標註，致命問題需要及時排入版本或者緊急修復，也可鍛煉pm的敏銳性。
需求特性列表，需求記錄及日常管理的清單列表，我會統稱為需求池子（這三個清單中最為重要的）
使用說明：
這個清單有兩個用途：
(1)對目前開發中的需求進行進度跟蹤，包括需求分析的進度和開發的進度，哪些需求還在UI設計階段，哪個端已開發完畢等等，在壹個列表中能看得很清楚。具體要看公司對pm的定位，有些公司會將pm的職責定位為項目管理者。
(2)是作為需求池子，對待規劃的需求進行管理、分派解決版本，即為確定哪個需求在哪個版本中處理
這個清單，是需要團隊中的每個人進行及時更新、維護的，因此規範非常重要。
壹般來說，錄入需求池是由pm來負責，包括優先級、來源、類型等內容的確定（黃色區域）。在做每個版本的規劃前，需要把即將要在下壹個版本作的功能需求更新到該清單中（壹般是在開完版本規劃部門會議，並且得到大家認可無誤後更新）。
開發團隊、設計團隊則對目前該需求的狀態進行更新維護（紅色區域）。更新時間壹般是在每周五部門例會前進行更新，例會時會根據狀態進行工作核對。並且在周壹分配工作任務時，也可結合清單來進行分配。
自己在每天的體驗產品方面遇到的bug及優化點（這個列表，是鍛煉自己要保持對產品使用頻率）
使用說明：
這個清單其實是給自己記錄來用的。作為合格的pm是需要每天來用自己設計的產品，從用戶的角度去體驗產品，從中發現需要改善的地方。因此就給自己制定了這個清單。
另外也想聊聊，關於pm的日常工作。傳言產品經理需要掌握的技能很多，能畫得了原型，分析得了市場，談得了需求，也能協調得了產品生命周期各環節的工作。我也想分享下，自己作為產品經理的日常：
1、每日產品體驗 （Bug List)
每天需要處理關於產品的很多雜亂事項，但每天我也會至少留半小時的時候，對自己的產品以及競品反復體驗，並且記下體驗過程中得出來的需求點。這壹點能保持作為pm的產品觸覺，也能讓自己回歸為用戶去體驗、思考產品。
2、用戶反饋收集與反復查看（Feadback List）
每天定期查看產品的用戶反饋後臺，自建渠道包括用戶群，社交媒體是否有用戶投訴反饋，清楚問題之後記下需求點，若是屬於bug或者急需解決的需求，立刻反映給開發解決，若是屬於不緊急的需求，則列入版本叠代規劃中。
3、數據分析（可行性低，b端產品）
4、每日站會，了解目前階段情況，統籌與識別風險
每天會組織團隊開10分鐘左右的站立式會議，主題很明確，每人發言將昨天自己工作的內容和今天計劃要做的事情，具體涉及到需要協調、溝通的，會議後再具體進行，在不耽誤大家的工作時間情況下，是了解目前進度的很好的方式。