知乎上看到一個問題“你覺自己在什麼時候真正地從產品助理成長為產品經理？”，我想起了第一次跟leader提需求，跟進至上線的那種喜悅和成就。對於我這種野生產品而言，在成長的路上遇到過很多雞湯，也有很多幹貨，而我希望大家能看到的，是如何避免給別人埋坑。讓你的設計，開發，前端都能順利的與你合作。對產品小白來說，這必定是你成為大神的第一步！
很多產品小白，成功入職後的除開寫文件外，第一個相關任務應該就是跟進已有的一些需求。此篇將闡述作為一個產品小白，如何更好的跟進需求。適合產品新人及未來準備入行的產品童鞋。同時也歡迎大神交流指點。最後，在文章最後將歸納出值得大家深究下的乾貨！
一.跟需求前的戰前準備
在此，假設你已經入門產品，學會並掌握了Axure或其他原型設計軟體，也看過了許多產品類書籍。對產品工作的整體流程有一定了解。那麼請做好以下準備，至少做到心裡有數。
1.需求的背景
說到底，就是需求分析。需求分析考究的是對業務的理解和對行業的把控度，做需求分析時，不管是你提的需求或者客戶/老闆提的需求。一定要清楚，功能是為誰做的，受眾使用者是誰。是否有深刻的使用者畫像的概念，他們能否從需求功能中得到他們想要的效果。
此處分享一個乾貨，分析需求時刻記得哲學唯心三問題。
瞭解需求的背景，可以讓你在驗收的時候更落地，避免貨不對板，降低迴爐再造的可能性。
2.需求的人員/時間安排
現在的網際網路公司都有許多奇妙，似是而非卻又有一定道理的名詞。比如“小步快跑”“快速試錯”。深究起來，無非是為了更快的搶佔市場。所以一般老闆或者leader對專案時間的把控都非常嚴格，身為PM也應該對每個節點的時間敏感。在PM定時間的時候，需要PM對技術有一定的瞭解。
舉個栗子：我們的需求是做一個端午的活動頁面，那麼我們知道流程的走向應該是產品原型等確認後，設計先出高保真，再由前端切圖並完成頁面效果（比如抽獎，砸蛋等動作），交給後端綁資料，最後再按需求看是否需要在網站後臺做統計資料。
那麼我們就需要把握這幾個時間節點，並且儘量細分。設計有幾個頁面，分別需要多久？高保真出來後，頁面有多少效果需要前端做的，有沒有公共樣式可以呼叫？到了前端側，有多少效果需要寫程式碼。對於簡單的效果或者一些不復雜的頁面通常只要幾個小時就可以完成的。
最後就是後端的開發，這裡強烈建議PM們去學習下資料結構，推薦書籍《大話資料結構》，有些新功能在後端開發時，需要重新建表。那麼建表的欄位有哪些，是否要做表的關聯。這些即涉及到了新功能系統分析這一步。建議PM和開發組長一起建表或者對錶有一定了解，這樣做的好處，一是，自己對開發的瞭解可以更深入，也能增加自己的邏輯，知道哪裡的資料從哪裡來，經過怎樣的運算展示給使用者。其次是可以避免給開發兄弟埋坑，也避免給開發兄弟忽悠。
3.需求完成後的統計/反饋
這一步容易被一些小公司，或者年輕PM忽視。但是PM一定要記住一點，”資料是PM職業生涯的保障！”為何我如此強調資料，因為不管是在你跟領導曬成績談需求，又或者是在需求會議上跟人PK時，如何能夠讓你的計劃得到實施，如何讓你的團隊信服。很多時候，人格魅力都是虛的，資料才是真的！當你拿出支援你言論的資料時，你會發現你的邏輯，你的佈局都是有條有理的，不會被人挑出毛病，也不會被老油條們噴的太慘。所以請一定要重視資料！
言歸正傳，當需求完成後，你需要一套完善的資料便於分析以及瞭解功能的不足，下一步的戰略。資料分析是門很深奧的功課，在此不做展開，之後會更新一篇專門講解資料分析的文章。但是簡單的資料分析還是要有，比如新功能使用的人數，反饋如何。 上線後，DAU，PV，UV等，是否有所提高。
在此，給大家分享的乾貨是在騰訊PM的PPT或者文件中，最喜歡用到的資料分析方法之一。定性分析與定量分析！這兩個名詞百度可以搜出一大堆解釋，本文的解析只出於作者本人的片面理解。
兩者是相輔相成的，但是一起拿出來，放入到你的PPT或者各種分析報告中，給人感覺就是專業又裝逼的。例如：QQ相簿裡面的親子相簿功能，這個需求是由qq空間的產品經理看到身邊的同齡人都在各種平臺曬娃想到的。他認為對於使用者是有這樣的需求，所以就先進行定性分析，發現20-30歲有孩子的女性是這個需求的核心使用者，接下來又使用定量分析，嚴格分割年齡層和性別比例。又發現寶寶的各種第一次，第一次洗澡，第一次哭等….是父母們最喜歡曬的圖片之一。
二.跟需求中需要避免的東西
在跟需求的時候，難免會遇到各種各樣的問題。排期延後，設計貨不對板等等，說實話，這些問題只有具體問題具體分析了。更多的主要靠交流，經驗的積累，還有對細節的重視程度。
接下來就常見問題和一些常常埋下的坑做下分析。
關於設計：
為什麼這個設計風格老是不達標，領導也覺得不好看？
其實我覺得最簡單的方法就是去學UI吧，PS+AI，神裝兩件套。親自做一下，對設計的理解就會不一樣了。推薦書籍《給大家看的設計書》,《設計心理學》，前者能對色彩，排版等有基礎的瞭解。後者能夠在與設計撕逼的時候，引經據典，搬出心理學等高大上的理論。曾經有個UI跟我說“好設計一定是會講故事的”，經我反思，會講心理學的產品一定能成為好UI！
為什麼老是拖我的需求的排期？
這個原因很多，我來解密下藏得最深的一個原因吧。 那就是，你的需求或者你所在的專案根本不是KPI上的重點專案。 此情況常見於大公司，由於UI一天可能接很多case，有時遇到節日活動，預約UI都要提前一個星期的。但是對於UI來說，每個人審美是不一樣的。所以，做的好不好都是虛的，KPI高才是硬道理！ 當然也不是所有情況都是這樣的，還是那句話，具體問題，具體分析！
關於前端：
為什麼做出來的網頁，總有使用者說在他們電腦上顯示有問題？
其實前端的坑算比較少的。樣式問題，是我們最常見遇到的問題。其實準確來說，這是一個技術問題，牽扯到核心，相容性等問題。但是我們要儘量避免的，就是使用者提出來之後，我們還沒發現。通常我會在電腦上裝三個瀏覽器，谷歌，火狐，360。谷歌的F12太好用，火狐的FIREBUGS也是神器，360則是許多普通使用者的首選。當然還有自帶的IE。 建議是使用這四個瀏覽器都測一遍，然後使用IE自帶的除錯工具，按F12找到瀏覽器模式，切換IE版本。部分IE版本沒有IE6，這時需要下載IEtester來測試了。
關於開發：
在和開發碰需求，或者跟進需求時，是遇到坑最多的地方。再次的強烈的建議大家學習下資料結構，然後和開發哥哥一起建表。或者至少建表完後自己也要去看下。其次關於流程，關於邏輯，一定要理清！這也是非常重要的。
為什麼這個功能做不了？
這是很多不懂技術的PM最心酸的問題，特別遇到不耐煩的開發哥哥。許多剛入門的PM就在這一步被打擊到了。首先作者覺得PM雖然不一定要懂技術，但是一定要知道技術做的是些什麼東西，按怎樣的流程怎樣的邏輯去設計。懂技術當然最好，作為一個PM知識面越廣越NB！
至於這個問題，最好的方法當然是懂技術，知道開發哥哥是不是忽悠你。不然的話，就趕快找其他開發，你的朋友，你的親戚詢問具體流程。嘗試找出問題是在哪一步。再去深究。
我都不知道這功能要做多久？程式設計師說要3天有沒有騙我？
這個相對上面的問題比較好認知一點。憑經驗判斷都可以大致猜到需要多久。同時，你可以注意幾點，是否需要建表？有沒有表之間的關聯？有多少種關聯？當然具體開發難度還是要跟技術組長等去碰。
在這裡再介紹一個好玩的需求時間遊戲。同樣適用於此種情況，玩法是：提出一個需求，讓至少兩個程式設計師在紙上寫上他們來做分別需要的時間，同時不可交流，不可相互檢視。在最後同時攤牌。若一個人填2小時，另外一個人填10小時。那就可以去問下他為什麼需要這麼久了。
關於開發的坑實在太多，在後續的章節裡會持續更新可能會遇到的坑點。在此篇先不做詳述。下圖來此知乎，僅供大家一笑。
三.總結自己，反思團隊
每次需求做完都是對自己能力的一次檢驗，在培養團隊默契之外如何更好的使需求落地。一個牛逼的產品經理，在專案組內應該是那種坐在誰位置上就能做他的事的人。不管是業務邏輯還是設計細節，不管是開發排期，還是資料統計，都應該瞭如指掌。一定要記得每次掉下的坑，掉的越猛，飛的越高！
最後是文中推薦的乾貨：
知乎上看到一個問題“你覺自己在什麼時候真正地從產品助理成長為產品經理？”，我想起了第一次跟leader提需求，跟進至上線的那種喜悅和成就。對於我這種野生產品而言，在成長的路上遇到過很多雞湯，也有很多幹貨，而我希望大家能看到的，是如何避免給別人埋坑。讓你的設計，開發，前端都能順利的與你合作。對產品小白來說，這必定是你成為大神的第一步！
很多產品小白，成功入職後的除開寫文件外，第一個相關任務應該就是跟進已有的一些需求。此篇將闡述作為一個產品小白，如何更好的跟進需求。適合產品新人及未來準備入行的產品童鞋。同時也歡迎大神交流指點。最後，在文章最後將歸納出值得大家深究下的乾貨！
一.跟需求前的戰前準備
在此，假設你已經入門產品，學會並掌握了Axure或其他原型設計軟體，也看過了許多產品類書籍。對產品工作的整體流程有一定了解。那麼請做好以下準備，至少做到心裡有數。
1.需求的背景
說到底，就是需求分析。需求分析考究的是對業務的理解和對行業的把控度，做需求分析時，不管是你提的需求或者客戶/老闆提的需求。一定要清楚，功能是為誰做的，受眾使用者是誰。是否有深刻的使用者畫像的概念，他們能否從需求功能中得到他們想要的效果。
此處分享一個乾貨，分析需求時刻記得哲學唯心三問題。
我是誰？——受眾群體是怎樣的一群人我從哪裡來？——需求的背景是怎樣，為什麼會產生這樣的需求我要到哪裡去？——客戶想要怎樣的功能，他們想要實現的目的是什麼瞭解需求的背景，可以讓你在驗收的時候更落地，避免貨不對板，降低迴爐再造的可能性。
2.需求的人員/時間安排
現在的網際網路公司都有許多奇妙，似是而非卻又有一定道理的名詞。比如“小步快跑”“快速試錯”。深究起來，無非是為了更快的搶佔市場。所以一般老闆或者leader對專案時間的把控都非常嚴格，身為PM也應該對每個節點的時間敏感。在PM定時間的時候，需要PM對技術有一定的瞭解。
舉個栗子：我們的需求是做一個端午的活動頁面，那麼我們知道流程的走向應該是產品原型等確認後，設計先出高保真，再由前端切圖並完成頁面效果（比如抽獎，砸蛋等動作），交給後端綁資料，最後再按需求看是否需要在網站後臺做統計資料。
那麼我們就需要把握這幾個時間節點，並且儘量細分。設計有幾個頁面，分別需要多久？高保真出來後，頁面有多少效果需要前端做的，有沒有公共樣式可以呼叫？到了前端側，有多少效果需要寫程式碼。對於簡單的效果或者一些不復雜的頁面通常只要幾個小時就可以完成的。
最後就是後端的開發，這裡強烈建議PM們去學習下資料結構，推薦書籍《大話資料結構》，有些新功能在後端開發時，需要重新建表。那麼建表的欄位有哪些，是否要做表的關聯。這些即涉及到了新功能系統分析這一步。建議PM和開發組長一起建表或者對錶有一定了解，這樣做的好處，一是，自己對開發的瞭解可以更深入，也能增加自己的邏輯，知道哪裡的資料從哪裡來，經過怎樣的運算展示給使用者。其次是可以避免給開發兄弟埋坑，也避免給開發兄弟忽悠。
3.需求完成後的統計/反饋
這一步容易被一些小公司，或者年輕PM忽視。但是PM一定要記住一點，”資料是PM職業生涯的保障！”為何我如此強調資料，因為不管是在你跟領導曬成績談需求，又或者是在需求會議上跟人PK時，如何能夠讓你的計劃得到實施，如何讓你的團隊信服。很多時候，人格魅力都是虛的，資料才是真的！當你拿出支援你言論的資料時，你會發現你的邏輯，你的佈局都是有條有理的，不會被人挑出毛病，也不會被老油條們噴的太慘。所以請一定要重視資料！
言歸正傳，當需求完成後，你需要一套完善的資料便於分析以及瞭解功能的不足，下一步的戰略。資料分析是門很深奧的功課，在此不做展開，之後會更新一篇專門講解資料分析的文章。但是簡單的資料分析還是要有，比如新功能使用的人數，反饋如何。 上線後，DAU，PV，UV等，是否有所提高。
在此，給大家分享的乾貨是在騰訊PM的PPT或者文件中，最喜歡用到的資料分析方法之一。定性分析與定量分析！這兩個名詞百度可以搜出一大堆解釋，本文的解析只出於作者本人的片面理解。
定性分析：如名字一般，用語言文字做出趨勢，屬性的分析。在資料上非常抽象，但是對人而言更易理解。定量分析：也如名字所言，需要有資料支撐的分析。對於分析的範圍，平均分佈更加敏感。在資料上非常具體，經常一大堆數字讓人看到一頭霧水，所以對人而言不友好。兩者是相輔相成的，但是一起拿出來，放入到你的PPT或者各種分析報告中，給人感覺就是專業又裝逼的。例如：QQ相簿裡面的親子相簿功能，這個需求是由qq空間的產品經理看到身邊的同齡人都在各種平臺曬娃想到的。他認為對於使用者是有這樣的需求，所以就先進行定性分析，發現20-30歲有孩子的女性是這個需求的核心使用者，接下來又使用定量分析，嚴格分割年齡層和性別比例。又發現寶寶的各種第一次，第一次洗澡，第一次哭等….是父母們最喜歡曬的圖片之一。
二.跟需求中需要避免的東西
在跟需求的時候，難免會遇到各種各樣的問題。排期延後，設計貨不對板等等，說實話，這些問題只有具體問題具體分析了。更多的主要靠交流，經驗的積累，還有對細節的重視程度。
接下來就常見問題和一些常常埋下的坑做下分析。
關於設計：
為什麼這個設計風格老是不達標，領導也覺得不好看？
其實我覺得最簡單的方法就是去學UI吧，PS+AI，神裝兩件套。親自做一下，對設計的理解就會不一樣了。推薦書籍《給大家看的設計書》,《設計心理學》，前者能對色彩，排版等有基礎的瞭解。後者能夠在與設計撕逼的時候，引經據典，搬出心理學等高大上的理論。曾經有個UI跟我說“好設計一定是會講故事的”，經我反思，會講心理學的產品一定能成為好UI！
為什麼老是拖我的需求的排期？
這個原因很多，我來解密下藏得最深的一個原因吧。 那就是，你的需求或者你所在的專案根本不是KPI上的重點專案。 此情況常見於大公司，由於UI一天可能接很多case，有時遇到節日活動，預約UI都要提前一個星期的。但是對於UI來說，每個人審美是不一樣的。所以，做的好不好都是虛的，KPI高才是硬道理！ 當然也不是所有情況都是這樣的，還是那句話，具體問題，具體分析！
關於前端：
為什麼做出來的網頁，總有使用者說在他們電腦上顯示有問題？
其實前端的坑算比較少的。樣式問題，是我們最常見遇到的問題。其實準確來說，這是一個技術問題，牽扯到核心，相容性等問題。但是我們要儘量避免的，就是使用者提出來之後，我們還沒發現。通常我會在電腦上裝三個瀏覽器，谷歌，火狐，360。谷歌的F12太好用，火狐的FIREBUGS也是神器，360則是許多普通使用者的首選。當然還有自帶的IE。 建議是使用這四個瀏覽器都測一遍，然後使用IE自帶的除錯工具，按F12找到瀏覽器模式，切換IE版本。部分IE版本沒有IE6，這時需要下載IEtester來測試了。
關於開發：
在和開發碰需求，或者跟進需求時，是遇到坑最多的地方。再次的強烈的建議大家學習下資料結構，然後和開發哥哥一起建表。或者至少建表完後自己也要去看下。其次關於流程，關於邏輯，一定要理清！這也是非常重要的。
為什麼這個功能做不了？
這是很多不懂技術的PM最心酸的問題，特別遇到不耐煩的開發哥哥。許多剛入門的PM就在這一步被打擊到了。首先作者覺得PM雖然不一定要懂技術，但是一定要知道技術做的是些什麼東西，按怎樣的流程怎樣的邏輯去設計。懂技術當然最好，作為一個PM知識面越廣越NB！
至於這個問題，最好的方法當然是懂技術，知道開發哥哥是不是忽悠你。不然的話，就趕快找其他開發，你的朋友，你的親戚詢問具體流程。嘗試找出問題是在哪一步。再去深究。
我都不知道這功能要做多久？程式設計師說要3天有沒有騙我？
這個相對上面的問題比較好認知一點。憑經驗判斷都可以大致猜到需要多久。同時，你可以注意幾點，是否需要建表？有沒有表之間的關聯？有多少種關聯？當然具體開發難度還是要跟技術組長等去碰。
在這裡再介紹一個好玩的需求時間遊戲。同樣適用於此種情況，玩法是：提出一個需求，讓至少兩個程式設計師在紙上寫上他們來做分別需要的時間，同時不可交流，不可相互檢視。在最後同時攤牌。若一個人填2小時，另外一個人填10小時。那就可以去問下他為什麼需要這麼久了。
關於開發的坑實在太多，在後續的章節裡會持續更新可能會遇到的坑點。在此篇先不做詳述。下圖來此知乎，僅供大家一笑。
三.總結自己，反思團隊
每次需求做完都是對自己能力的一次檢驗，在培養團隊默契之外如何更好的使需求落地。一個牛逼的產品經理，在專案組內應該是那種坐在誰位置上就能做他的事的人。不管是業務邏輯還是設計細節，不管是開發排期，還是資料統計，都應該瞭如指掌。一定要記得每次掉下的坑，掉的越猛，飛的越高！
最後是文中推薦的乾貨：
產品唯心三問題推薦書籍《大話資料結構》 定性分析與定量分析推薦書籍《給大家看的設計書》,《設計心理學》IE自帶切換IE版本工具 IEtester需求時間遊戲