當接手一個新專案的時候，產品經理應該做些什麼
大家好，兩週沒更新啦！！！趕緊來補一篇
話說產品經理做完了一個專案的時候，或是說當專案穩定了後，接下來會幹什麼，怎麼幹，這裡面有些頭頭道道，尤其是需要重新接一個自己不擅長領域的專案時，一般都會先處於一個懵逼的狀態當中。
那麼我們如何能快速的進入狀態，瞭解專案的背景以及專案的意義呢。這就是今天我們要來聊聊的話題。
前不久，公司對當前所有的專案進行了梳理，把每個產品經理所負責的專案拿出來挨個過，然後對每個功能的定位，以及當前的進度規劃，做了說明。目的也很簡單，要將當前所有不重要的工作放一放，把每個人手頭中最重要的事情單獨拎出來，用最快的速度進行開發，並重新分配開發資源。
這就導致了多個問題，其中最突出的是，忙的人很忙，個別人竟然落不到開發資源，說句不好聽的就是閒住了，對於個人來說，這就有點可怕，因為一旦沒工作了就意味著可能隨時下課。
當時我就處在一個尷尬的位置，怎麼辦？找領導談談唄。當然領導也清楚實際的情況，於是給我安排了一個內部系統的構建工作。
可是對於我來說，並不是很擅長做內部系統的搭建，業務需求、整體框架、功能設計等等這些幾乎是沒什麼概念，所以當時我就一直在思考這個問題。
先思考一下業務背景
這個系統是給誰用，做什麼的，要起到什麼作用。這些想清楚後，我簡單概括了一下，就是資料平臺和客戶關係管理，類似BI和CRM的簡化版合集。
在這裡，我首先考慮的業務的價值，這個事情做好了能起到什麼樣的效果，對產品有哪些促進的作用。然後將這些好處羅列出來。
進而，再來看哪些人會重點關注，關注點是什麼。比如老闆關注什麼，總監關注什麼，業務需求方關注什麼。當這些我們清楚後，就能走向下一步，構建框架。
再思考如何構建框架
框架的搭建說簡單也不簡單、說難也不難，關鍵在於分類。
每個業務，可能包含了幾個功能，這幾個功能或是頁面都有相似的屬性，那麼就分類到一起，成為一個子模組，然後子模組在累計疊加，成為一個大模組，也就是我們說的業務線。
業務線要和需求掛鉤，每個需求都是一個功能，能整合到一起的，儘量在一個頁面來顯示。
舉個例子：
資料：使用者資料、公司資料
使用者資料：總活躍資料、分層活躍資料、使用者使用頻率、使用者流失、使用者啟用等等
這就是所謂的搭框架，當然我只是簡單的舉了個例子，實際情況可能會更加複雜，有興趣可以參考《後臺系統進階》
最後設計功能和一般互動
說到功能設計，就是將需求中所定義的元素（欄位）給顯示出來，怎麼顯示我在這裡不做詳細的闡述，看得多了就自然能快速的將原型設計出來。
常用的互動，提及一句：增、刪、改、查、空、異常，需要的都考慮一遍，在進階的就是，按鈕的擺放位置。
最後就是引導和提示，不用多說，這是一套產品經理的標準流程
寫在最後，不管是新人還是老人，接手一個自己不擅長的功能時，是一件很平常的事情。
有些人做的手忙腳亂，有些人卻能從容不迫，我感覺更多的還是經驗導致，所以別怕錯，才能一直走，向上走。
做產品經理時間越長，越發現經驗（也就是過程）的重要性，雖然大部分時間都是處於蟄伏或是失敗的狀態，但時間長了會發現，其實你一直都沒有停下來。接下來的就交給時間和運氣了。
其次就是知識的轉化能力也是超級重要的，比如讓你做短視訊（你沒做過這方面），你不是能把市面上所有短視訊的功能抄一遍就好了，而是能將短視訊的精髓應用到自家的產品上，而且你能階段性、漸進性的對這部分知識進行轉化。
簡單點來說就是，多數人會直接把功能給抄一遍，而聰明的人會先去理解這個功能，然後把這部分經驗轉化為自己的理解，先提升了自己，然後產品也會逐漸形成節奏。
好啦，今天分享就到這裡了，有興趣可以來找我聊聊～