作為項目經理來談談需求評審

原諒連結：http://blog.chinapm.com.cn/u/ucwxy/1748.html

1、不同類型的需求是否由不同的職能角色同學來負責編寫更合理？    * 一般情況下更建議技術優化需求由研發同學負責編寫。展現的形式可以是需求文檔，也可以是技術方案，技術方案一般會涵蓋了需求、技術架構、接口協定等描述（有些時候，沒必要把需求和設計分那麼開）    * 雖然有些技術優化需求不是産品同學來寫，但是每個版本要做哪些需求，都應該由産品經理來統籌和拍闆 2、如何有效的召開需求評審會？    * 首先你要了解如何組織高效的會議    * 其次才是軟體産品的需求評審    * 是産品同學去講解需求，還是研發同學來講解需求，産品同學來糾正和補充（反正這些在我們過去都有嘗試過） 3、下版本的需求評審工作應該放到什麼時候最合适？    * 2、3個研發人員規模的小項目，是否串行疊代更合适，就是說上個疊代釋出後再開始下個疊代的需求評審，但是需求文檔可以提前盡早發出，以友善研發同學在提測版本後的空隙時間去預審，測試同學在某輪次測試完成等待研發修改bug再次提測的空隙時間去預審    * 越複雜的項目團隊，是否要比目前版本釋出時間提前1-2周完成是最好的安排？    * 外部關聯需求越早評審越好 4、需求評審是否要分成需求架構和需求細節等不同層次的評審？    * 以前在樂園，分需求初評和需求細評，你對應的團隊是否也需要這麼弄呢    * 架構評審和細節評審的會議參與人員如何考慮和安排 5、需求文檔寫到什麼程度才是合适的？    * 對于進度要求更嚴格、版本品質要求更高的産品，需求文檔偏向于更詳細具體一些    * 對于關聯需求，關聯業務流程和協定偏向于描述更細節一些    * 需求文檔是為後面設計、編碼、測試工作服務的，同樣也是今後新同學了解業務的途徑之一。那麼文檔如果能滿足這2個條件，就合适了   6、項目經理是否需要參與一個版本中所有需求的需求評審？    * 核心需求、關聯需求、複雜需求一定要參與評審     * 根據團隊的成熟度靈活判斷，越不成熟的團隊，項目經理需要投入的時間和精力需要越多   7、是否所有需求在評審前，都需要有預審？預審中發現問題後要怎麼處理？    * 什麼情況下的項目，不用預審，直接組織團隊召開需求評審會會更合理（一些簡單的背景業務，我覺得可以不需要提前預審，但是複雜需求一定要提前預審）    * 如果大家都沒來得及需求預審，需求評審會議是否要考慮推遲    * 如果安排需求預審，那麼一般要在需求評審會議前提前多久發起需求預審    * 預審階段發現的問題和疑問，是等到評審會議上再去溝通還是評審會議前溝通清楚更合适（一般要會前溝通清楚更合适，以便需求作者評審會議效率更高） 上面的每一個問題都可以展開去耗費大量時間來讨論，而工作中你會遇到不同 業務類型的項目、不同 複雜度的項目、不同的 團隊氛圍、不同 性格的人、不同 能力的人、不同 重要性的項目、不同 成熟度階段的團隊等等，還有好多其他很多項目相關的因素，比方有些業務是創新業務，而有些是收尾業務等 你常常會聽到做項目管理需要有靈活性。可能你當時不能了解什麼是靈活性。單純從需求評審這個事情來看，能靈活的、高效的開展是需要對應的知識結構的，否則你是很難做好移動網際網路業務下的項目管理工作。是以，靈活性是在不同情況下你都能用最合适的方式去推動項目工作的進展。『 靈活性确實是一種綜合能力的展現』