一開始就錯了，拿什麼來拯救結局
一、 明確問題
“一千個觀衆眼中有一千個哈姆雷特”
本身需求理解會存在一定的偏差性，那麼我們如何在遠程辦公的前提下，開一場高質量的需求會？
二、 方法簡述
l 難 在 where？
需求本身不明確；需求文檔不詳細；人員不全； 接受氛圍差；溝通不順暢（網絡等）；
l how？
最好讓用戶參與需求評審，產品需要結合目前的產品形態梳理邏輯，避免產品走不通；
需求是產品的理想的最高形態，產品一定要想的多，想的全，最終研發不一定能落地，但是要落地的功能一定要有清晰的規則描述；
建立釘釘/微信羣，提前發公告，保證項目成員都能參加；
遠程開會，你不知道對方的投入度，也不知道對方在幹什麼，產品出調用問卷/參與者出需求紀要，以及問題彙總
三、分步操作
動作1：確定項目的負責人，有條件的話跟盯所有環節，包含需求調研階段
1） 具體動作：
l 需求確認後，根據項目的大小，確定是採用立項的形式，確定項目負責人，注意一定要先與需求評審前確定；
2）好壞差異點
l 先確定項目的負責人，有利於職責明確，培養團隊成員的組織協調能力，積極推動項目的發展。
l 不確定項目負責人或者後確定項目負責人，不利於統籌安排，並且無法對資源達到最大化的利用，項目推進慢。
3）正誤案例
l 正確案例： 確定項目負責人，要形成相應的文檔記錄，並由項目負責人完善後續進度跟進和把控
l 錯誤案例： 只是口頭描述，沒有可視化的記錄，造成職責不明確或者項目記錄不詳細。
動作2： 召開大而全的會議，所有涉及到的人員儘量參加會議（至少2次會議的評審）
1）具體動作：
l 產品確定需求後，需要確定項目開發的負責人，由負責人協調資源，召開涉及到所有人的會議，參與需求評審
l 至少召開2次大而全的會議，第一次爲需求的初步評審，讓所有人知道做什麼事，會議結束後，需要開發人員消化功能，並列出疑問點。
2）好壞差異點
l 會議人員不全，會造成很多無效的溝通，需要找跟多的人開更多的會，能一次性開會解決問題，儘量不要開多次小會。
l 所有與會人員，一定要積極思考，涉及到的問題，一定要溝通清楚，儘量避免大會後再次溝通顯而易見的需求問題。
3) 正誤案例
l 正確案例：
l 錯誤案例：
動作3： 形成清晰可理解的文檔，注意不要出現規則同xx功能的描述
1）具體動作：
l 產品形成需求文檔，並根據需求評審，做相應的修改，進一步完善文檔，文檔一定要描述清晰，不可由歧義，儘量把細節都體現。
l 需求文檔共享，方便項目人員隨時查看，可以放到語雀或者騰訊文檔。
2）好壞差異點
l 開發人員最終根據UI或者需求文檔進行開發，描述不清晰或者規則不全，容易造成返工，影響項目進度
l 清晰的文檔，不需要與產品反覆確認，只需要閱讀文檔，就瞭解產品邏輯，開發效率高
3）正誤案例
l 正確案例： 教師端當日課表顯示規則，“有三部分組成：已完成，待開始，進行中，已完成排到下面，進行中放到最上面，待開始放到中間，按照開始時間進行正序排列”
l 錯誤案例： 學生端當日課表顯示規則，同老師端。
後續動作： 明確開發目標，細化功能
1）具體動作：
l 任務拆分的越細，目前達成期望值越高，越符合預期
l 大任務拆分小任務，細化到每個小功能的具體負責人。
2）好壞差異點
l 清晰的任務拆分，幫助開發人員做好模塊的劃分和技術文檔設計，避免遺漏
3）正誤案例
l 錯誤案例： 功能點： 文件庫相關功能 工期： 4天 執行人：張三
l 正確案例： 功能點： 文件重命名的需求，不需要重複 工期：1天 執行人：張三
文件和文件夾的排序規則 工期：1天 執行人：張三
支持ppt和word的上傳，並且大小不超過20M 工期：2天 執行人：張三
開發期動作： 一日兩會
早計劃，晚覆盤（總結於反思）
三、 可用工具
產品UI工具：l 藍湖(lanhuapp.com)
在線文檔：l 語雀/騰訊文檔-項目立項表
任務記錄：l TodoList/ Trello/ Teambition
項目排期甘特：l Ominiplan(mac) /工作雲(workyun.com)/ UPGantt(gantt.mindsup.com.cn)
即時通信：l 釘釘/微信-即使溝通
五、知識清單
l 召開最少2次會議，進行需求評審，第一次爲初步評審，第二次爲詳細評審
l 形成清晰可理解的文檔
l 有條件的話，儘量用ui設計圖進行講解，並根據評審的結果，進行標註
l 最好讓用戶參與需求評審
六、列覈對表
|
覈對項 |
是否完成 |
|
項目負責人是否確定 |
是口 否口 |
|
是否利用語雀/騰訊文檔完成立項的填寫（研發負責人） |
是口 否口 |
|
是否進行了項目初審 |
是口 否口 |
|
用戶是否參與了需求評審 |
是口 否口 |
|
需求初審是否對修改意見做了記錄 |
是口 否口 |
|
初審後，研發人員是否消化了功能，並記錄疑問點（todolist ，便籤等） |
是口 否口 |
|
是否召開了最少2次大而全的會議 |
是口 否口 |
|
需求文檔是否清晰，功能描述是否全面 |
是口 否口 |
|
項目排期和里程碑是否確定 |
是口 否口 |
|
任務拆分是否細緻 |
是口 否口 |
|
一日兩會是否按時執行 |
是口 否口 |
七、練習任務
根據產品需求，結合目前項目的實際情況，完成一次產品需求的演練。