文章來源 Jim Wang王軍
記得在2006年初，我加入一家Start-up，我們有MRD，PRD，業務需求文檔，功能規格說明書(Spec's)，設計文檔。這麼多文檔，一是花費好多時間寫文檔，二是要花時間去閱讀這些文檔。讀的過程中要理解技術的語言，文檔中有好多不同領域的術語，問題和解決方案混雜在一起。我記得整整用了一個下午閱讀，頭都大了，最後死活讀不下去，關鍵是也記不住，更談不上透徹理解。後來在項目實施過程中也偶爾「翻閱」一下這些文檔，發現這類文檔內容沒有及時更新，內容已過時，文檔成了「擺設」，因為它夾在文件夾里，還厚厚的頁碼。唯一的好處是滿足心理上的一個「安全感」，儘管這種安全感是假的。
PRD邀請需求範圍蔓延(PRD invites Scope Creep)，寫文檔的人會一股腦兒的把想到的需求和功能都寫在PRD里，PRD變成了wish–list，都希望能開發。如果干系人有這個那個需求，先寫上去再說。我接觸過一些產品經理，為了避免後期的需求變更(因為走需求變更的流程漫長而痛苦)，產品經理會把可能要做的需求，能想到的都「塞進」文檔里，哪怕只有1%的可能，這樣做的策略是，避免後期走合同或需求變更的流程(change request process)，文檔變成一個了「大雜燴」，Do more成為可能，根本沒有優先級的考慮。有的產品經理甚至擔心項目結束後人員「解散」了， 怕抓不到「資源」，就提前「預支」開發一些假象的未來可能的功能。
PRD的存在會自然成為業務和研發溝通需求的唯一通道，說白了，變成了「合同」遊戲。最可惜的是，寫需求分析文檔的時間佔用了大把開發的時間。毫不誇張的講，我經歷的有些項目，預估6個月的項目週期，但是前3個月在準備文檔報告，需求分析，開發人員只剩下3個月時間，「死亡行軍」不可避免。這麼做的背後有一個理論假設： 因為項目晚期的需求變更的成本會更高，所以在項目啓動時，最好把所有未來的工作都要徹底理解和規劃，瞭解需要什麼功能以及在項目開始時討論如何交付實現，佔用大量開發的時間做大而全的前期詳細規劃。通常以SOW或合同的形式固定下來，用「範圍時間成本」的約束，即我們熟悉的項目制來控制風險。這種理論和方法僅僅適用於清晰或繁雜的環境和項目。它在複雜的環境中不能很好地起作用，Scrum旨在複雜的環境。
所以：
當我們不太瞭解客戶需求時，提前計劃太多細節可能會浪費時間
當我們發現客戶真正需要什麼時，過早的決定會導致浪費
許多項目都經歷了在項目開始時不可能知道的「湧現」的需求
PRD隨瀑布式開發模式應運而生，敏捷開發需求在不斷變化，敏捷對規格說明書(Spec)和文檔的原則是：
我們不能只靠寫文檔假想需求
我們不能把文檔扔到牆上就萬事大吉(扔給開發團隊)
我們需要「剛剛好」的文檔
產品待辦列表(PBL)是Scrum框架下最重要的一個工件(Artifact)。我認為PBL和PRD不應該共同存在，企業運行所謂的「Hybrid」流程和模式，增加了團隊的負擔和困惑。如果產品待辦列表PBL取代傳統的需求規格說明書PRD，是否可行？有什麼樣好處和挑戰？產品待辦列表與PRD有什麼不同？
（1）產品待辦列表PBL 符合滿足「DEEP」（見下圖）的特徵。通常我們用DEEP來體檢PBL的健康狀態。
D: 需求的顆粒度有不同的層級，優先級高的需求更細化，未來不重要的需求放在底部，不需要我們當下去關注和細化它，PBL呈金字塔型。傳統的需求管理方式，我們在項目前期要做大量任務的分解WBS(work break-down structure)，消耗好多時間和精力。
E: 估算Product Backlog Item(PBI)的成本大小，規模估算。
E: 擁抱需求變化，PBL的事項列表條目PBI可進可出，不需要走傳統的需求變更(change request)的流程， PO有最終的決定權確定PBL的內容和順序。
P: 排優先級，即排序，注意沒有並列項的PBI。
（2）PBL不同於PRD的一個最大特點：條列式的需求，即 Item by Item. 有兩個好處：一是簡潔化(Simplicity)，另一個是幫助我們排優先級。排優先級的方法，讓我們開始關注那些先做，那些後做，那些不做。實際上是強迫我們關注價值，以價值交付為先，而不是被項目制的範圍時間成本所束縛；PBL轉向產品思維，遵守20-80原則，一個產品80%的價值體現在20%的特性上。另外，PBL的構建形式即條目化，幫助我們容易度量團隊的Sprint交付速率。
（3）PBL的內容大多是以客戶和用戶的問題或價值驅動，也就是對需求的描述專注在what和why，而不像PRD過多重視how的實現。一上來就專註解決方案，會把我們陷入過多細節的技術討論，而忘記這個條目是誰提出的，到底要解決什麼問題，會給客戶帶來什麼樣的價值和影響。用戶故事是PBI的一種推薦方式，會幫助我們思考業務價值和價值創立。理想情況下，PBL的每一個條目都對用戶或客戶的產品帶來價值。PBI的類型有，特性和用戶故事，改進項(enhancement)，bug fix，技術故事，知識獲取項，文檔(doc request)，等等。
（4）PBL的一個最重要的功能，是作為團隊，PO，關係人對話的基地(base)。PBI是一個需求的佔位符，它邀請dev和PO產生實時的對話。用戶故事是PBI的一種形式，用戶故事是指向需求的指針(user story is a pointer to a requirement)，用戶故事它本身不是requirement。PBL格式的不同，會有利於支持或減少PO 和團隊之間結構化的溝通。PRD文檔很容易會被閱讀者誤解，需求文檔成為「傳話」的工具。有了PRD，帶給我們一個錯覺，所有的東西都在文檔里了，這是一個很可怕的假設。更糟糕的是，需求文檔自然地成為「推卸」責任的工具。
（5）PBL是針對一個產品目標對想要的工作(desired work)一個不斷完整的清單，它是開發團隊工作內容的唯一來源(single source)。PBL的內容除了新產品的PBI以外，也可包括運維的需求，PBL作為唯一來源，根本上解決了團隊通常面臨的工作多頭管理，穿插打斷，隨意佈置工作。團隊的感受是一團亂麻，無頭緒，沒有成就感。通常情況下，最緊急的不一定是最重要的， 最重要的也很少是最緊急的，PO對工作內容按價值排序，團隊不看管理者的臉色行事，如果企業能夠真正落地執行這一條，我保證效率會翻倍。PBL的透明性，增強了業務和研發的信任關係：因為工作內容的顆粒度小了，有優先級排序，價值很快會流動起來，產品增量也可見，透明帶來了雙方的信任，改善了關係。
（6）PBL的實時性。PRD是過去式，像是我們開車用後視鏡看駛去的事物。我們面臨的市場，客戶，技術都在變化，需要前瞻性。我們必須響應變化，包括產品的策略調整，PBL就是一個PO擁有的動態的圍繞產品或服務的需求列表，它是開放的，實時的，湧現的，不是封閉的合同，需要我們在產品增量交付過程中及時反饋優化它。而且我們敢於面對和承認：在項目初期，我們對產品的理解，對產品的知識和經驗實際上是最少的，企圖把所有的需求提前都識別出來是不可能，也不現實。即使迫使我們的客戶努力思考(think harder)和長時間思考(think longer)，也是徒勞無逸。總是有一些需求是事先難以預測的，即使我們把做計劃的時間拉長，有些需求是在交付的過程中「湧現」出來的。對待這種「湧現」的需求，我們的策略是：① 多說少寫，如果需要就請寫一些 ② 向用戶及時展示工作的軟件或硬件增量，只有當用戶看到實體或原型時才會說出所需的東西。客戶的反饋會影響PBL未來的內容。PBL一直在圍繞干系人包括客戶的反饋，檢視和調整。
（7）光有PBL足夠嗎？ 不一定，正確的做法是，我們有一個輕量級的文檔，邀請開發團隊與PO「對話」，Scrum框架中設計的持續進行的產品待辦列表梳理活動(PBR)就是一個落地的「對話」的實踐。僅僅依賴於PRD文檔，把文檔扔給團隊的做法是不可取的。正確的姿態，以對話為核心，靈活採用不同的技術和工具，補充豐富完善PBL。可參考的敏捷團隊具體實踐有：
以用戶為中心的設計思維(DT)，用戶故事和用戶故事地圖(MVP)，影響地圖
設計Sprint(來自Google)
Spec Tickets(有一定的模板參考)
交互式原型(UI prototype)，線框圖，視覺模型(Visio diagram)，用戶旅程，工作流(work flow)，流程圖(flow chart)，故事板(storyboard)，Mockup，思維導圖(Mind-map)
與用戶實時交談對話(前期的問卷和調研遠遠不夠)
團隊干系人PO團隊討論的錄音錄像和圖片
Wiki Page形式的支持文檔(support doc)，簡短的討論文案，包括算法和技術要點
PBI驗收標準，客戶滿意條件，test plan和test doc
法律合規文檔等等
我們支持簡潔的PRD，即Minimum Viable PRD概念。冗長的PRD會大大減慢MVP的產出速度。PRD不應該有150頁之多。MVPRD回答類似這些的問題，為什麼要構建該產品，為誰服務，重要的功能是什麼，如何測試開發構建了真正所需的內容等。
最後重申一下，產品需求文檔PRD不應該成為「傳話」或「傳遞」需求的工具。產品待辦列表(PBL)是Scrum框架下最重要的一個工件，PBL的最重要的功能，就是作為團隊，PO，干系人「對話」的基地和開啓。
——Jim Wang王軍, 寫於2022年11月11日
Comments