一、本期話題
IT行業中，如何在項目管理規劃階段對需求文件進行質量控制？
二、嘉賓分享
1
首先聲明一下，我不認為關於需求文件的質量只是要在規劃階段控制，需求質量的控制是貫穿在項目所有階段進行的，單一個規劃階段是解決不了問題的，而且這跟用的什麼開發模型不相關。
我們先看看需求質量到底是個什麼東西。
引用PMBOK中對基準的需求質量的要求是這樣描述的「只有明確的（可測量和可測試的）、可跟蹤的、完整的、相互協調的，且主要相關方願意認可的需求，才能作為基準。」這是對需求文件的要求，也是對需求基準的要求。
「明確的」意思是任何需求都是必要的能夠使用一定的標準去判斷需求是不是能夠得到滿足，並且能夠通過一些手段進行驗證。
很多同學不知道需求要跟蹤什麼，其實對於需求來說，跟蹤的內容其實會包含兩個大部分。第一個大部分是指，需求的成果，即可交付成果是不是能夠滿足最初的需要，其實，並不是說，我們對成果進行驗證這麼簡單，而是要在項目研發的每一個環節對項目原始需求對應。
所謂的完整，通俗來說，就是不能說半截子話，或者是，在表達需求的時候，要對使用場景和解決的問題說清楚。在表達需求的時候，一定把前因後果、場景用途表達清楚。
相互協調的，就是說，需求質量不只是單看某一部分，要整體來看。往往的，我們的一個需求整體是要解決一系列的問題的或者說，我們解決的問題都是有普遍聯繫的。那就預示著，需求整體來看，不能突兀關聯，也不能相互矛盾。
相關方願意認可的，這一點我覺得最重要，歸根結底來說，你生產出的產品和成果事要交付給用戶使用的，或者你的相關方希望能夠從這個項目的成果中獲取到什麼利益。那就不能霸氣的說，我不要你覺得，我要我覺得了。從根本上來說，你覺得更重要，即使不合理，即使反人類，但是當相關方願意承認這就是真實需求的時候，那這就是真實需求了。
第一、想辦法讓來源可靠
找準關鍵需求方，只是讓來源可靠的一個方面，另外一個更重要的方面要看咱們收集需求的時候，怎麼去深入挖掘真實意圖。所謂去偽存真，往往偽需求面具下藏著的就是用戶的真實需求。說到這就得用一點手段了。
第二， 採用多樣、多方位的需求收集手段。
標杆對照，引導，原型都是很好用的需求收集和分析工具，
需求採集和分析的手段很多，關鍵的問題在於，對不同的項目，不同的相關方，方法也不是一成不變的，這對項目經理和需求收集人員的要求是比較高的。見人說人話，見鬼說鬼話，不在於你用的這個方法的學術名詞是什麼，在於你真的可以把用戶需求收集上來。不但要需求換收集上來，關鍵的哪句話，要完整，協調，且有人願意承認。
第三、讓需求說人話
用戶故事可以讓所有的相關方理解趨近於一直，原型的表示方法更是能讓大家直觀的看到產品的樣子
這裡的說人話，不是語言的問題，問題在於，讓整個團隊和相關方，都能明白你的需求想表達的意思，而且要認可這個意思，很多地方講需求需要無二義性就是這個道理。我們如果在互相之間找不到一種共同的交流方式，那也沒有關係，就去創造一種。
第四、讓需求受控
很多的時候，我對面對需求變更，特別是IT行業中的需求變更是比較排斥的。但是在這裡我想說的是，受控的意思並不是絕對的不能變更，或者說必須將需求鎖定在某一個範圍。隨著我們對VUCA這個詞越來越熟悉，我們也知道，這已經越來越趨近於一個不可能發生的事情了。也就是我們說的所謂「擁抱需求」
除此之外，受控的另一個方面是，我們要保證所有的需求都有過正式的發布，這與傳統做法是相一致的。並不是說我們擁抱需求就可以在需求層面隨意的發揮，需求通過獲取、記錄、評審、驗證的過程也是必不可少的。換句話說，一口唾沫一個釘的事情還是要做。定義好的需求，要通過正式的發布，才能作為開發的依據。這是對團隊負責，也是對用戶負責。
第五、讓專業的人做專業的事
從PMBOK第六版開始，PMI在每個過程中加入了「發展趨勢和新興實踐」這個小結。另外，在每一年的《職業脈搏調查》中，也會對未來的一些趨勢做數據層面的分析和預測。
PMI有個專門的認證叫PMI-PBA，即商業分析專業人士。這個認證對項目分析師的要求其實我們可以近似理解為現在大家都能夠普遍接受的項目經理崗位。通過一系列的手段和方法，從實現商業價值的角度實現組織的戰略目標。
所以有一個合作良好的商業分析師或者產品經理與項目團隊進行合作，是最快也是最直接的解決需求質量問題的選擇。
2
大家好，我是追星騎士，十年來服務於金融行業的IT系統。從運維做到項目管理，從乙方跳到甲方。
我覺得這類IT系統特點是嚴謹，需求範圍邊界明確，個性需求眾多，開發周期相對寬鬆。相比其它快速迭代的系統來說，它對項目有更高的質量要求。
在分享之前先引入一個會計術語：勾稽。簡單來說，是指數據、內容在各個輸入、輸出結果中有內在邏輯對應關係，如果不相等或不對應，這說明輸出結果出現問題。
在這個話題裡，可以理解為需求文件與質量管理工具、輸出文件之間的對應關係。項目裡經常用到的流程圖和時序圖，是很好的質量管理工具，可以通過它們來制定勾稽規則和校驗需求。
通過流程節點與需求範圍說明和基準進行勾稽，檢查每個節點和文件內容找到對應關係，節點流向的邏輯和需求中的前後邏輯相通，可以校驗需求文件內容是否完整，邏輯是否正確，是否還有邏輯漏洞和分支。
還有一種情況是由於需求方安排了多人向開發商講解需求的不同部分，導致需求細節零散，各個小需求在對接上存在問題，甚至因用語導致雙方理解存在似是而非的情況。可以通過會議、建立系統原型等方式，將需求落地，讓需求的內部勾稽關係建立起來。
上面說的都是基本工作，相信項目經理都有嘗試去做，但因時間和精力的影響，效果不理想，項目周期緊，變更頻繁是制約需求文件質量的關鍵。
個人覺得首先是先明確需求範圍，避免範圍蔓延，如果有需求變更了，一樣先明確需求範圍；其次是按業務功能、流程分解好WBS，每個WBS分配人員負責，除輸出項目需求文件和質量指標之外，還制定勾稽規則；最後抓好關鍵WBS，在關鍵功能上多下精力，勾稽結果儘量完備、統一。
3
/ 我有話說 /
啊潮-廣州-網際網路：
「從0到1開始梳理需求，從文件識別相關方，業務流程、人員結構、形成文件後，在進一步確認需求，確認後進行相關方確認記錄，變更管理流程。」
EQ無-新疆-IT+教育：
「這個話題我的想法是：先收集客戶需求，之後讓PM先篩選一部分不合理需求直接反饋給客戶，之後把剩餘合理需求交給研發組一起討論一下，最後把討論出來的能實現的需求加上目前不好實現的，但是可以用其他方式實現功能的需求做一張表交給客戶，進行下一步溝通，如果客戶同意這些需求就直接上項目。如果還不行的話就和客戶繼續溝通。」
綠林豪傑：
「這個我有經驗，之前有個項目，有大牛在規劃階段就定義好質量控制的指標，項目跟著指標走，用戶也承認這個指標。這樣來控制項目的質量。」
安可-重慶-軟體：
「對於公招的項目 根據招標文件的需求方案 細化出來同甲方爸爸確認
非公招的項目 直接和甲方爸爸勾兌 但是一般甲方爸爸都會變 所以要設置邊界。」
當鋪當家：
需求質量有幾個點需注意一下 ：1. 需求的輸入 ；對客戶或高層反饋的需求得進行市場調研、競品分析等方式量化，選取妥當的實現路線。2.需求的梳理 ；梳理需求邏輯路線，建立閉環，進行優化。3.需求的輸出 一方面是獲得客戶或高層的認可，另一方面對內召開評審 與項目組的開發、UI、測試等明確目標、達成一致。
小嘉Carrie-上海-網際網路:
這個我有發言權了,如果這個是公司自有產品研發項目，一般先是商業論證吧，然後這個時候定下了產品的大方向，大目標。之後就看開發方式了。
像我們這種創業機構基本上就是敏捷方法（雖然我對敏捷開發管理這套不太熟）。我們基本上線產品規劃大迭代方向，基本上三個月左右算一個大迭代周期吧，大概會規劃3個以上，差不多覆蓋1年。然後就是把每個大迭代拆成迭代計劃+優化計劃。迭代計劃是可以確定的，基本上通過對需求的重要性分級，開發的時間等來拆，嗯，還有評審。主要是產品規劃出來之後，各業務部門和技術部門一起來評估這次產品迭代計劃，提出自己的問題，然後產品在會議再來反饋集合大家意見之後的調整，然後就直接進入開發階段了。
我覺得對於質量的控制，除了規劃之外，專家建議也是比較重要的。特別是目前很多產品不一定有運營經驗或技術開發經驗，所以需求有時候是非常天馬行空的（我們喜歡用「反人類」這個詞），因此評審是非常重要的，而且在開發過程中也會有各種變更的問題，所以項目管理的難度在於，對交付成果和最初需求的關聯，因為在IT行業中，交付成果大變動完全跟當初需求不一致也是常常發生的呀。