當需求來臨時，不能來者不拒，一定要思考下面六大問題，可有效避免做無用功。
需求描述
為什麼要做
是否真的必要
期望的目標
怎麼做做什麼
透視最根本目的
自查，減少浪費
設定可量化的指標
系統設計和詳細設計
以建設公司內部知識社群為例：
1.需求描述
建立乙個內部知識分享社群。
2.為什麼要做？
可以形成業務知識沉澱、解決工作中的共同難題、激發員工創造力。
3. 是否真的必要做？
3.1 全域性導向
是否能直接推動業務？是否能以最小投入取得最大收益？
3.2 是否有現有類似或可替代的功能？
公司目前是否有類似系統，是否擱置沒充分利用？市場上是否已經有成熟產品可以直接使用？
比如釘釘知識庫、語雀，已經被驗證過好用，那就不需要再開發。
3.3 排優先順序
這個需求在公司的全域性戰略中比重多大？是否有其他對於客戶而言優先順序更高的需求？
5.期望的目標
在經過了上述思考後，要設定可量化評估的指標，目的是後期確定成果是否有效，根據指標結果再進行迴圈改進。
6.怎麼做
6.1 系統設計
現根據現有經驗列出功能清單，然後選出最重要的、能夠馬上實現的功能模組進行誰規劃，注意要考慮後續的擴充套件性，然後開始詳細設計。
6.2 詳細設計
針對模組細節、內容進行規劃設計，不要求一步到位，關鍵是日常使用過程中注意使用者的反饋，持續迭代。
借鑑敏捷方法的理論，社群運營需要持續的優化迭代，不斷重複下面的過程。羅馬不是一天建成的，卓越產品和普通產品的差別就在於前者把細節做到極致。
專案開發系列 需求評審
今天進行了傳說中的需求評審。開始以為是一群大boss坐在那裡挑我們的毛病，沒想到是乙個極度輕鬆和open的過程。總結下一哈 首先，需求評審的參與者是pd，pm，需求方和專案小組全體成員。目的是對需求方提出的需求進行確認和補充。大致的流程是 需求方給出乙個大概的輪廓，開發團隊提出自己的想法，然後諮詢需...
專案中的評審管理
專案中的評審分成了技術評審和管理評審。技術評審分成了正式審查 組內評審 書面輪查 個人複查。管理評審分成會議評審 會簽 審批。實際上，要想做好一場評審會議，真的不是一件容易的事情。我早期參加專案的時候，要麼成了乙個需求討論會，要麼就是設計討論會議，或者乙個有領導參加的評審會議完全成了領導個人的脫口秀...
專案過程管理（六）需求評審和工作量評估
流程 預審 產品提前2小時發出通知和初稿 不需要完善細節，可以只是原型 召集主管或負責人預審。未必需要開會，只要每個人能確認需求沒大問題就好。跟運營有關的需求，應該在全體評審前由運營先審核完畢。產品經理根據問題修改完畢後，逐個找負責人確認。都通過後，發出通知 專案經理收集工作量評估進行排期，並在各方...