起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理如何寫文檔才能不背鍋？
編輯導語：西安一碼通連續崩潰，除了軟件開發方有責任，產品經理也需要寫清楚要求，否則很有可能“背鍋”。本篇文章中，作者分析和解答了產品經理如何定義清楚一碼通的非功能需求，以及如何寫文檔才能不背鍋等等問題，推薦想要學習如何寫一碼通功能需求的群體閱讀。
2022年1 月 4 日9 時，西安一碼通又崩潰了。這是半個月內，一碼通第二次出現故障。
一方面，軟件開發方有責任，開發的系統可用性太差。而另一方面，軟件的需求方也需寫清楚要求，這也往往是產品經理的工作，具體而言就是定義清楚產品需求、驗收標準、違約責任。
否則研發只需一句話——“是產品經理沒有定義清楚需求，所以責任不在我”，這就可將責任推掉。而我們如做好這些工作，就能分清責任，明確義務，避免背鍋。
這些工作涉及面很廣，本文僅探討其中的非功能需求的部分，也就是產品經理如何定義清楚一碼通的非功能需求。
一碼通的功能需求很簡單，就是查詢自己的核算檢測信息，個人健康信息。難是難在了非功能需求，下面我們就用3000字來逐一說明。
一、需求的全貌
產品經理要明確的需求眾多，在我的書《圖解產品》中，我將這些需求做了歸類，并命名為PURPS+模型，具體就是：
- 主要需求（Primary）：體現了功能、內容、安全性需求；
- 可用性需求（Usability）：體現了用戶體驗、幫助和培訓文檔等需求；
- 可靠性需求（Reliability）：體現了故障率，維修時間等需求；
- 性能需求（Performance）：體現了響應時間、并發數、吞吐量等需求；
- 可支持性需求（Supportability）：體現了可維護性、可擴展性等需求；
- 其他需求（+）：如數據統計、授權、接口、包裝等需求。
而產品經理需逐一定義這些需求，才能將文檔寫全面。下面我們重點說說其中的可用性、可靠性、性能和可支持性需求如何寫，這些內容在《圖解產品》中有更多說明。
二、可靠性需求
可靠性定義了系統的健壯性，如可靠性高則說明產品的軟件、硬件故障少，能正常運行。而這些故障常常會嚴重影響用戶的使用。
具體到西安一碼通則需定義清楚四個指標，分別是：平均無故障時間 （MTBF）、可靠性、維護響應時間、平均維護時間。
（1）平均無故障時間 （MTBF）
該時間是指產品出現一次故障的平均時間。如電腦的MTBF 為 15 年， 就是說有的電腦第 1 年出故障，有的電腦第 30 年出故障，平均算起來第15 年出故障。一般可用經驗數據和實驗數據，大致預估硬件的MTBF。
而軟件的故障多是因為軟件BUG，因此很難預估MTBF值，有時會給個承諾值。
（2）可靠性
軟件的故障次數越少越好，但如不幸出現了故障，則希望有故障的時間盡可能短，這個指標就是可靠性。
如可靠性為99.999%，就是指在1年時間里，該業務會中斷5.26分鐘，計算公式為（1-99.999%）× 365 × 24 × 60，其中365 × 24 × 60為全年的分鐘數。
同樣該值也較難預估，慣例是廠商會承諾99.99%或99.999%的可靠性。
（3）維護響應時間和平均維護時間
當產品出現故障后，很多時候要維修，而維修包括維護響應時間、平均維護時間。
（4）維護響應時間
是指從發現故障到開始維修所需要的時間。對于西安一碼通業務來說，可要求開發方支持7×24小時的隨時響應，并要求10分鐘內開始維修。
（5）平均維護時間 （MTTR）
雖然開發方能夠快速響應，但是要修好還需時間，由此需要定義平均維護時間，這個時間包括在途時間（如需要）和到達現場維修好的時間。該指標也需要根據業務情況定義，如要求必須1小時內修好。
以上就是平均無故障時間 （MTBF）、可靠性、維護響應時間、平均維護時間指標的定義和建議值。這些值多數無法精準給出，更多地是開發方對可靠性的一個承諾。
三、可用性需求
可靠性是從系統角度看的，也就是反應了軟件有沒有問題；而可用性則是從人的角度看的，也就是人覺得產品可用不可用。有時兩者是一回事，但有時兩者不是一回事。
之前我曾負責的一款產品，其可靠性很差，硬件和軟件總出問題。但是有些情況下卻不太影響用戶的使用，因為用戶大不了重新撥打一次電話，或重新連一次網絡，也能用。
而所采取的手段是，當疑似有問題后，該系統會自動重啟系統或重啟某進程。所以從用戶的角度看，其可用性尚可；但從系統角度看，其可靠性很差，系統總是壞掉。
現在的互聯網系統也多是分布式部署，從而將單點故障的影響降到最低，提升用戶的可用性。
而西安一碼通也需定義清楚可用性。如當軟件、硬件出現故障后，系統應盡可能支持一定的恢復手段，同時也要實現分布式部署等。
但從本次一碼通的故障看，主要是性能問題，此時靠重啟進程等手段是不能解決問題的，由此需要定義清楚性能需求。
四、性能需求
性能需求要先定義用戶訪問情況，再定義系統的響應時間、新建數、并發數、吞吐量。
1. 用戶訪問情況
用戶訪問情況需確認峰值訪問量、平均訪問量和訪問的業務。對于一碼通業務，需依據歷史數據做預估。如預估每日10點-11點為峰值訪問，且同時使用的人數是多少人，并應盡可能精確到每秒的峰值。
2. 響應時間、新建數、并發數和吞吐量
定義清楚了用戶訪問情況后，就要再從軟件角度定義性能指標，如能定義清楚這些指標，就可避免不合適的軟件架構設計，這些指標如下。
（1）響應時間
指標反映了網站響應用戶請求的速度，也就是我們日常所說的網絡快慢。影響響應時間的因素有系統延遲、網絡延遲和用戶端的延遲，一般可由開發方給個響應時間。
（2）新建數
每個用戶使用一碼通查看信息時，系統都會新建建立一個連接。該指標與用戶訪問指標比較類似。比如登錄要新建、查詢要新建，這就是兩個新建。有時一次查詢需要幾個新建，需由研發確認。
（3）并發數
定義了當訪問系統的特定應用時，能同時維持的連接數量。據統計西安有1300萬人口，按照最大10%的市民同時掃碼（已經很大了），也就是要支持百萬的并發量。
（4）吞吐量
該系統定義清楚吞吐量，很多性能問題就可避免。
按照一些研發的分析，認為一碼通的問題集中在該系統所有的 js/css/img 靜態資源全都從一個出口進行提供，沒上 CDN。
粗略估算了一下，js/css/img 數據總共約 500kB。而按照某個群里得到的數據（暫且認為是準的），健康碼的請求量峰值達到了 3.3w qps，也就是吞吐量要 33000 x 500 x 8 bps ≈ 125Gbps 這個出口量級很難用單機房承載，由此系統掛掉。
該指標和系統實現方案有密切關系，需要由經驗豐富的研發來分析、明確。
五、可維護性需求
可維護性需求可分為可支持性需求和可移植性需求。這些需求涵蓋的內容較多，與一碼通相關度高的需求如下：
（1）可支持性需求
定義了開發人員是否可以方便地升級系統、用戶是否可以很方便地升級。
而據每日經濟新聞報道，一碼通的升級需要人工刪除小程序，并清除數據。這就是沒有做好可支持性需求。
（2）可移植性需求
括用戶的增長和數據量的增長。用戶量的增長是指當用戶量增加后，系統應能方便地擴容。數據量的增長是指當存儲的數量增加后，系統也能很好地支持。而一碼通半個月后又出故障，由此可看出其可移植性需求做的并不好。
六、總結
以上就是一碼通需定義的主要非功能需求，而這些需求涵蓋面又廣又重要。除了這些指標外，還有一些次要需求，本文就不再贅述，你可參考《圖解產品》繼續完善。
其實該系統的實現不算難，實現方案也頗為成熟，甚至優秀的應屆生都能搞定，確實不該出問題。
有人可能會問，工作中我沒有定義這些內容，研發一樣工作。是的，對于互聯網公司的自研產品多數不需這么詳細，但對于這種關系民生的定制開發則必須明確，從而避免上線失敗。
如一些實現細節不清楚，需求方也可列出框架，由開發方填寫。
而需求方還應基于以上指標，再定義驗收標準，違約責任，并進行壓力測試，由此來約束開發方的行為。這樣開發方就不至于敢派經驗不足的研發來應付事，更可避免扯皮，分清責任。
#專欄作家#
擎蒼，微信公眾號：圖解產品設計，人人都是產品經理專欄作家?！秷D解產品》作者。專注B端產品，擅長UML建模、領域建模；專注企業數字化，有多個明星數字化產品構建經驗；另有多年產品經理、企業數字化企培經驗。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
啊這，還是分清責任解決問題吧，問題的解決最重要
產品經理：需求 啊 我需求呢
我頭發呢 啊 我頭發呢
項目出現事故或許雙方都難辭其咎，但是作為產品經理需要比常人更明白其中的產品需求、驗收標準、違約責任，這樣不至于成了一人背鍋
是這個意思。并反對部分回答中非此即彼的二分法，即“文檔無論怎么寫，項目出了這種級別的事故，產品經理都難辭其咎”。
正如俞軍所說將一個產品的不成功，就歸因為產品，顯然是把產品看的太厲害了。而對于該項目也是如此，產品經理只是成功或不成功的一個要素。
另一方面，本文主要強調寫清楚需求，這毋庸置疑是對的，但并沒有說這就夠了。還應如文中所說要明確“驗收標準，違約責任等”工作。如這些都能做到，問題就會少很多，責任也可分清楚，更可依據責任改進工作。顯然該產品經理沒有做到，就是該背鍋的第一責任人，更需要改進其工作。
不多做評價，群眾的眼睛是雪亮的
性能需求要先定義用戶訪問情況，再定義系統的響應時間、新建數、并發數、吞吐量。
學習了哈哈哈哈，就算這個用戶訪問情況要怎么定義哈哈哈哈哈
見文中描述，即多少用戶什么時間訪問什么應用，該案例的應用就是獲取健康信息。