“1人100個月完成的項目，不是100個人1個月就可以完成。”
項目管理是讓項目活動中相互競爭的各類制約因素：質量、進度、資源、風險等取得平衡的藝術，同時也是平衡項目干系人的各種需要、關注和期望，帶領不同的人朝著相同目標邁進的領導藝術。
成功的項目管理可以簡單理解為：按時、在預算內+滿足產品需求+滿足質量需求 地完成項目。
以下是我對項目管理的一點體會記錄。
需求等級
視覺 A：圖片沒有分享功能嗎？
技術 K：圖片有鏈接轉發分享、微博或郵件形式分享等多種分享，全部開發的話需要推延時間表。
策劃 D：圖片只做預覽、下載已經足夠了，暫時不做分享。
交互 E：如果我們的用戶是基于郵箱用戶，圖片的郵件分享還是建議做。
… …
如果在前期產品需求文檔中沒有明確定義每個需求的優先等級，或者說項目成員對需求的優先等級沒有明確的意識，可能類似的爭論會時常發生在項目成員之間，每個人會基于自己對產品目標的理解來考慮這個需求是否要做，什么時候做，做到什么程度而產生分歧，因而增加項目推進的阻力。
所以在前期產品需求文檔中，必須明確定義出每個需求的優先等級，需求的粒度可細化到每個大功能下的子功能需求，如：圖片分享功能的轉發鏈接分享、郵件形式分享這樣的子功能需求。等級的劃分依賴于前期的用戶需求調研、產品的預定目標、開發成本、運營計劃等；
一般的需求等級劃分：
P0 -Must have： 如果缺失，產品不能發布
P1 -Should have： 如果缺失，產品能發布，但不能達到預定目標（功能/性能）
P2 -Nice to have： 做了則更好
P3 -Neutral： 對產品沒有明顯的好處，用戶不在意
… …
每個需求的優先等級確定之后，產品經理根據產品預定目標、開發成本、運營計劃等來定義一個等級分界線，高于或等于這個等級分界線的需求在本期開發，部分根據成本、運營計劃等因素調整到下期開發，而低于這個等級分界線的需求則只會在下期開發，這樣讓全體項目成員對本期要做的需求達成共識。
“1人100個月完成的項目，不是100個人1個月就可以完成。”
項目管理是讓項目活動中相互競爭的各類制約因素：質量、進度、資源、風險等取得平衡的藝術，同時也是平衡項目干系人的各種需要、關注和期望，帶領不同的人朝著相同目標邁進的領導藝術。
成功的項目管理可以簡單理解為：按時、在預算內+滿足產品需求+滿足質量需求 地完成項目。
以下是我對項目管理的一點體會記錄。
需求等級
視覺 A：圖片沒有分享功能嗎？
技術 K：圖片有鏈接轉發分享、微博或郵件形式分享等多種分享，全部開發的話需要推延時間表。
策劃 D：圖片只做預覽、下載已經足夠了，暫時不做分享。
交互 E：如果我們的用戶是基于郵箱用戶，圖片的郵件分享還是建議做。
… …
如果在前期產品需求文檔中沒有明確定義每個需求的優先等級，或者說項目成員對需求的優先等級沒有明確的意識，可能類似的爭論會時常發生在項目成員之間，每個人會基于自己對產品目標的理解來考慮這個需求是否要做，什么時候做，做到什么程度而產生分歧，因而增加項目推進的阻力。
所以在前期產品需求文檔中，必須明確定義出每個需求的優先等級，需求的粒度可細化到每個大功能下的子功能需求，如：圖片分享功能的轉發鏈接分享、郵件形式分享這樣的子功能需求。等級的劃分依賴于前期的用戶需求調研、產品的預定目標、開發成本、運營計劃等；
一般的需求等級劃分：
P0 -Must have： 如果缺失，產品不能發布
P1 -Should have： 如果缺失，產品能發布，但不能達到預定目標（功能/性能）
P2 -Nice to have： 做了則更好
P3 -Neutral： 對產品沒有明顯的好處，用戶不在意
… …
每個需求的優先等級確定之后，產品經理根據產品預定目標、開發成本、運營計劃等來定義一個等級分界線，高于或等于這個等級分界線的需求在本期開發，部分根據成本、運營計劃等因素調整到下期開發，而低于這個等級分界線的需求則只會在下期開發，這樣讓全體項目成員對本期要做的需求達成共識。
“1人100個月完成的項目，不是100個人1個月就可以完成。”
項目管理是讓項目活動中相互競爭的各類制約因素：質量、進度、資源、風險等取得平衡的藝術，同時也是平衡項目干系人的各種需要、關注和期望，帶領不同的人朝著相同目標邁進的領導藝術。
成功的項目管理可以簡單理解為：按時、在預算內+滿足產品需求+滿足質量需求 地完成項目。
以下是我對項目管理的一點體會記錄。
需求等級
視覺 A：圖片沒有分享功能嗎？
技術 K：圖片有鏈接轉發分享、微博或郵件形式分享等多種分享，全部開發的話需要推延時間表。
策劃 D：圖片只做預覽、下載已經足夠了，暫時不做分享。
交互 E：如果我們的用戶是基于郵箱用戶，圖片的郵件分享還是建議做。
… …
如果在前期產品需求文檔中沒有明確定義每個需求的優先等級，或者說項目成員對需求的優先等級沒有明確的意識，可能類似的爭論會時常發生在項目成員之間，每個人會基于自己對產品目標的理解來考慮這個需求是否要做，什么時候做，做到什么程度而產生分歧，因而增加項目推進的阻力。
所以在前期產品需求文檔中，必須明確定義出每個需求的優先等級，需求的粒度可細化到每個大功能下的子功能需求，如：圖片分享功能的轉發鏈接分享、郵件形式分享這樣的子功能需求。等級的劃分依賴于前期的用戶需求調研、產品的預定目標、開發成本、運營計劃等；
一般的需求等級劃分：
P0 -Must have： 如果缺失，產品不能發布
P1 -Should have： 如果缺失，產品能發布，但不能達到預定目標（功能/性能）
P2 -Nice to have： 做了則更好
P3 -Neutral： 對產品沒有明顯的好處，用戶不在意
… …
每個需求的優先等級確定之后，產品經理根據產品預定目標、開發成本、運營計劃等來定義一個等級分界線，高于或等于這個等級分界線的需求在本期開發，部分根據成本、運營計劃等因素調整到下期開發，而低于這個等級分界線的需求則只會在下期開發，這樣讓全體項目成員對本期要做的需求達成共識。