身邊的朋友都知道，因為一些眾所周知的原因，這周我的加班能力被提升到了新的境界：不光每天都能和技術帝們的下班時間完美匹配（技術帝們辛苦了），而且在公司的每一秒都在高速運轉，生命彷彿變得更鮮活而有意義了喲（……禁止賣萌！）
總之，經過整整一週的折騰，如果再不梳理下工作，就變成白忙活了。這次，讓我們不分國籍~不分種族~不分膚色~敞開心扉~促膝長談~~~聊一聊需求優先順序的問題。
1 網際網路屌絲or麥肯錫女神？看著辦吧
在這忙碌的一週裡，有一個問題被放置到了非常關鍵的位置，那就是如何評估需求的優先順序。
被壓在各種各樣的需求下是產品經理的常態，如何處理需求優先順序往往也反映了一個產品經理的水準和能力。就像題目裡說的，如果一週需要處理1000個需求，你該怎麼辦？老大們拍下來的要做吧？影響企業利潤的要做吧？能提高工作效率的要做吧？還有自己那點小心思、想要優化的ABCDE，也要做吧？……如果順著這個思路走下去，那麼就很容易陷入到被需求牽著鼻子走的境地，打亂自己原有對產品的規劃，更是會影響到整個團隊的工作節奏。
（親，你膝蓋中箭了嗎？）
然而，同樣面對著繁重、複雜、多執行緒工作的某個物種，不僅憑藉解決問題的能力賺得滿盆滿缽、馳名全球，更是總結出了一套科學且可複製的工作方法和管理經驗，供更多行業的人類複用。這個物種生存的星球叫麥肯錫，這個物種分為兩類，一類叫男神，一類叫女神。（……）
2 萬能的四象限法則
說到底，需求的優先順序是個時間管理的問題。如果我們有充裕的資源，無限的時間，那麼只要確認可以接的需求，我們都可以做。然而往往現狀是：沒有資源，沒有時間，N個需求壓過來，每個都說自己最重要，每個都希望今天提需求明天就上線，這時候，就必須評估需求的優先順序。
《麥肯錫方法》和《麥肯錫思維》中都不斷地提到，對專案管理和時間管理，非常有效的工作方式是四象限法則。根據事件的重要性和緊迫性為座標軸，可以將所有事情區分放在四個象限：重要且緊急、重要不緊急、不重要但緊急、不重要不緊急。對所有事件分類後，才可做更好地分析處理。
四象限法則的兩個座標軸是重要性和緊迫性。緊迫性和時間關聯，比較好量化，而重要性則需要認真定義，樹立標準。
2.1 有錢有勢，不如有標準
什麼叫重要？從網際網路行業的普遍角度看，一個產品的需求重要性可以細化為以下幾4個標準：
1）基礎服務。越靠近基礎服務的需求越重要。一方面，越基礎的服務越靠近產品所滿足的本質需求；另一方面，如果沒有完善的基礎服務，功能性的需求往往也無法實現。把產品比作一座塔，塔尖少蓋基層，最多是矮一點，可如果不搭好基座，整個塔都有可能倒塌。
2）利潤來源。比較共識的優先順序取捨是，客戶大於使用者。如果某一個需求直接影響到公司的收益，當然會被放在高優先順序。
3）戰略支援。如果是公司層面的戰略落地，需要業務線支援，能夠支援公司決策、引起市場和輿論效益的，也會被判定為重要。
4）關聯性強。最後一點，有可能一些需求在你看來一般重要，但該需求會牽扯到其他部門的重大功能，或是許多部門需要該需求支撐，成為了“牽一髮而動全身”的那“一發”，那就需要調高這個需求的優先順序。
2.2 四象限的處理方式
確認好現有需求的重要性和緊迫性，可以讓他們排排坐到四象限的格子裡去啦！
然後，看看該如何去解決這幾類問題吧：
1）第一象限：重要且緊急。首要解決這類事情是毋庸質疑的了，但需要控制好的是該象限的需求數量。以你的重要性標杆為主，需求提出方的標杆為輔，如果本末倒置，就永遠跳不出這個坑了。
2）第二象限：重要不緊急。對待這一類的需求，不建議立即開工。比“立即執行”更重要的，是反覆評估，儘量確保產品方案的嚴謹性。等時機成熟，能拿出一個儘量完善的方案支援開發，高效完成，避免反覆。
3）第三象限：不重要但緊急。這個型別簡直太經常遇到了。“反正是小事順手做了吧”、“我們很著急用這個功能，幫個忙嘛”……這個時候千萬要把持住！不要隨口答應！千萬記得，再緊急，它也是不重要，既然不重要，就需要好好評估。最可怕的是因為需求提出方著急，自己也跟著急，結果沒有想清楚就提了開發需求，最後產品方案也不完善、功能又不重要、還浪費了開發資源，最後出力不討好。
那麼如何處理這個象限的需求呢？第一，和需求提出方對重要性和緊迫性認知的分歧，需要我們做出進一步的溝通，以判斷是否仍然需要你的配合，是否可以轉移到其他象限。第二，如果對方確認仍需要向你提出需求，那就要考慮該需求和自己的其他專案是否有重疊，如果是可以一起開發支援，那就一併放到其他專案中；第三，如果該需求確認需要你配合，又和其他專案無重疊，又很緊急，那麼這時候需要和需求提出方確認下能夠接受的時間期限，儘量爭取自由度，即便需要臨時支援，也要給現行的專案足夠的緩衝。
4）第四象限：不重要不緊急。遇到這類的需求，就不要裝好人了，該推掉就推掉吧。如果對需求的認知有歧義，那麼就幫助需求提出方瞭解為什麼是不重要又不緊急。總之，把你的精力放在其他需求上吧。
到這裡，相信你那一大麻袋的需求已經有一個清晰的規劃了。
完整內容點此檢視
總之，經過整整一週的折騰，如果再不梳理下工作，就變成白忙活了。這次，讓我們不分國籍~不分種族~不分膚色~敞開心扉~促膝長談~~~聊一聊需求優先順序的問題。
1 網際網路屌絲or麥肯錫女神？看著辦吧
在這忙碌的一週裡，有一個問題被放置到了非常關鍵的位置，那就是如何評估需求的優先順序。
被壓在各種各樣的需求下是產品經理的常態，如何處理需求優先順序往往也反映了一個產品經理的水準和能力。就像題目裡說的，如果一週需要處理1000個需求，你該怎麼辦？老大們拍下來的要做吧？影響企業利潤的要做吧？能提高工作效率的要做吧？還有自己那點小心思、想要優化的ABCDE，也要做吧？……如果順著這個思路走下去，那麼就很容易陷入到被需求牽著鼻子走的境地，打亂自己原有對產品的規劃，更是會影響到整個團隊的工作節奏。
（親，你膝蓋中箭了嗎？）
然而，同樣面對著繁重、複雜、多執行緒工作的某個物種，不僅憑藉解決問題的能力賺得滿盆滿缽、馳名全球，更是總結出了一套科學且可複製的工作方法和管理經驗，供更多行業的人類複用。這個物種生存的星球叫麥肯錫，這個物種分為兩類，一類叫男神，一類叫女神。（……）
[img=需求,四象限法則,時間管理]https://jf-bucket-public.oss-cn-qingdao.aliyuncs.com/jfperiodical/attached/image/20150713/1375015426.jpg[/img]
說到女神我就想到她！
2 萬能的四象限法則
說到底，需求的優先順序是個時間管理的問題。如果我們有充裕的資源，無限的時間，那麼只要確認可以接的需求，我們都可以做。然而往往現狀是：沒有資源，沒有時間，N個需求壓過來，每個都說自己最重要，每個都希望今天提需求明天就上線，這時候，就必須評估需求的優先順序。
《麥肯錫方法》和《麥肯錫思維》中都不斷地提到，對專案管理和時間管理，非常有效的工作方式是四象限法則。根據事件的重要性和緊迫性為座標軸，可以將所有事情區分放在四個象限：重要且緊急、重要不緊急、不重要但緊急、不重要不緊急。對所有事件分類後，才可做更好地分析處理。
[img=需求,四象限法則,時間管理]https://jf-bucket-public.oss-cn-qingdao.aliyuncs.com/jfperiodical/attached/image/20150713/-1079643082.png[/img]
四象限法則
四象限法則的兩個座標軸是重要性和緊迫性。緊迫性和時間關聯，比較好量化，而重要性則需要認真定義，樹立標準。
2.1 有錢有勢，不如有標準
什麼叫重要？從網際網路行業的普遍角度看，一個產品的需求重要性可以細化為以下幾4個標準：
1）基礎服務。越靠近基礎服務的需求越重要。一方面，越基礎的服務越靠近產品所滿足的本質需求；另一方面，如果沒有完善的基礎服務，功能性的需求往往也無法實現。把產品比作一座塔，塔尖少蓋基層，最多是矮一點，可如果不搭好基座，整個塔都有可能倒塌。
2）利潤來源。比較共識的優先順序取捨是，客戶大於使用者。如果某一個需求直接影響到公司的收益，當然會被放在高優先順序。
3）戰略支援。如果是公司層面的戰略落地，需要業務線支援，能夠支援公司決策、引起市場和輿論效益的，也會被判定為重要。
4）關聯性強。最後一點，有可能一些需求在你看來一般重要，但該需求會牽扯到其他部門的重大功能，或是許多部門需要該需求支撐，成為了“牽一髮而動全身”的那“一發”，那就需要調高這個需求的優先順序。
2.2 四象限的處理方式
確認好現有需求的重要性和緊迫性，可以讓他們排排坐到四象限的格子裡去啦！
然後，看看該如何去解決這幾類問題吧：
1）第一象限：重要且緊急。首要解決這類事情是毋庸質疑的了，但需要控制好的是該象限的需求數量。以你的重要性標杆為主，需求提出方的標杆為輔，如果本末倒置，就永遠跳不出這個坑了。
2）第二象限：重要不緊急。對待這一類的需求，不建議立即開工。比“立即執行”更重要的，是反覆評估，儘量確保產品方案的嚴謹性。等時機成熟，能拿出一個儘量完善的方案支援開發，高效完成，避免反覆。
3）第三象限：不重要但緊急。這個型別簡直太經常遇到了。“反正是小事順手做了吧”、“我們很著急用這個功能，幫個忙嘛”……這個時候千萬要把持住！不要隨口答應！千萬記得，再緊急，它也是不重要，既然不重要，就需要好好評估。最可怕的是因為需求提出方著急，自己也跟著急，結果沒有想清楚就提了開發需求，最後產品方案也不完善、功能又不重要、還浪費了開發資源，最後出力不討好。
那麼如何處理這個象限的需求呢？第一，和需求提出方對重要性和緊迫性認知的分歧，需要我們做出進一步的溝通，以判斷是否仍然需要你的配合，是否可以轉移到其他象限。第二，如果對方確認仍需要向你提出需求，那就要考慮該需求和自己的其他專案是否有重疊，如果是可以一起開發支援，那就一併放到其他專案中；第三，如果該需求確認需要你配合，又和其他專案無重疊，又很緊急，那麼這時候需要和需求提出方確認下能夠接受的時間期限，儘量爭取自由度，即便需要臨時支援，也要給現行的專案足夠的緩衝。
4）第四象限：不重要不緊急。遇到這類的需求，就不要裝好人了，該推掉就推掉吧。如果對需求的認知有歧義，那麼就幫助需求提出方瞭解為什麼是不重要又不緊急。總之，把你的精力放在其他需求上吧。
到這裡，相信你那一大麻袋的需求已經有一個清晰的規劃了。
完整內容點此檢視