編輯導(dǎo)語：西安一碼通連續(xù)崩潰，除了軟件開發(fā)方有責(zé)任，產(chǎn)品經(jīng)理也需要寫清楚要求，否則很有可能“背鍋”。本篇文章中，作者分析和解答了產(chǎn)品經(jīng)理如何定義清楚一碼通的非功能需求，以及如何寫文檔才能不背鍋等等問題，推薦想要學(xué)習(xí)如何寫一碼通功能需求的群體閱讀。

2022年1 月 4 日9 時，西安一碼通又崩潰了。這是半個月內(nèi)，一碼通第二次出現(xiàn)故障。

一方面，軟件開發(fā)方有責(zé)任，開發(fā)的系統(tǒng)可用性太差。而另一方面，軟件的需求方也需寫清楚要求，這也往往是產(chǎn)品經(jīng)理的工作，具體而言就是定義清楚產(chǎn)品需求、驗收標(biāo)準(zhǔn)、違約責(zé)任。

否則研發(fā)只需一句話——“是產(chǎn)品經(jīng)理沒有定義清楚需求，所以責(zé)任不在我”，這就可將責(zé)任推掉。而我們?nèi)缱龊眠@些工作，就能分清責(zé)任，明確義務(wù)，避免背鍋。

這些工作涉及面很廣，本文僅探討其中的非功能需求的部分，也就是產(chǎn)品經(jīng)理如何定義清楚一碼通的非功能需求。

一碼通的功能需求很簡單，就是查詢自己的核算檢測信息，個人健康信息。難是難在了非功能需求，下面我們就用3000字來逐一說明。

一、需求的全貌

產(chǎn)品經(jīng)理要明確的需求眾多，在我的書《圖解產(chǎn)品》中，我將這些需求做了歸類，并命名為PURPS+模型，具體就是：

• 主要需求（Primary）：體現(xiàn)了功能、內(nèi)容、安全性需求；
• 可用性需求（Usability）：體現(xiàn)了用戶體驗、幫助和培訓(xùn)文檔等需求；
• 可靠性需求（Reliability）：體現(xiàn)了故障率，維修時間等需求；
• 性能需求（Performance）：體現(xiàn)了響應(yīng)時間、并發(fā)數(shù)、吞吐量等需求；
• 可支持性需求（Supportability）：體現(xiàn)了可維護性、可擴展性等需求；
• 其他需求（+）：如數(shù)據(jù)統(tǒng)計、授權(quán)、接口、包裝等需求。

而產(chǎn)品經(jīng)理需逐一定義這些需求，才能將文檔寫全面。下面我們重點說說其中的可用性、可靠性、性能和可支持性需求如何寫，這些內(nèi)容在《圖解產(chǎn)品》中有更多說明。

二、可靠性需求

可靠性定義了系統(tǒng)的健壯性，如可靠性高則說明產(chǎn)品的軟件、硬件故障少，能正常運行。而這些故障常常會嚴(yán)重影響用戶的使用。

具體到西安一碼通則需定義清楚四個指標(biāo)，分別是：平均無故障時間 （MTBF）、可靠性、維護響應(yīng)時間、平均維護時間。

（1）平均無故障時間 （MTBF）

該時間是指產(chǎn)品出現(xiàn)一次故障的平均時間。如電腦的MTBF 為 15 年， 就是說有的電腦第 1 年出故障，有的電腦第 30 年出故障，平均算起來第15 年出故障。一般可用經(jīng)驗數(shù)據(jù)和實驗數(shù)據(jù)，大致預(yù)估硬件的MTBF。

而軟件的故障多是因為軟件BUG，因此很難預(yù)估MTBF值，有時會給個承諾值。

（2）可靠性

軟件的故障次數(shù)越少越好，但如不幸出現(xiàn)了故障，則希望有故障的時間盡可能短，這個指標(biāo)就是可靠性。

如可靠性為99.999%，就是指在1年時間里，該業(yè)務(wù)會中斷5.26分鐘，計算公式為（1-99.999%）× 365 × 24 × 60，其中365 × 24 × 60為全年的分鐘數(shù)。

同樣該值也較難預(yù)估，慣例是廠商會承諾99.99%或99.999%的可靠性。

（3）維護響應(yīng)時間和平均維護時間

當(dāng)產(chǎn)品出現(xiàn)故障后，很多時候要維修，而維修包括維護響應(yīng)時間、平均維護時間。

（4）維護響應(yīng)時間

是指從發(fā)現(xiàn)故障到開始維修所需要的時間。對于西安一碼通業(yè)務(wù)來說，可要求開發(fā)方支持7×24小時的隨時響應(yīng)，并要求10分鐘內(nèi)開始維修。

（5）平均維護時間 （MTTR）

雖然開發(fā)方能夠快速響應(yīng)，但是要修好還需時間，由此需要定義平均維護時間，這個時間包括在途時間（如需要）和到達(dá)現(xiàn)場維修好的時間。該指標(biāo)也需要根據(jù)業(yè)務(wù)情況定義，如要求必須1小時內(nèi)修好。

以上就是平均無故障時間 （MTBF）、可靠性、維護響應(yīng)時間、平均維護時間指標(biāo)的定義和建議值。這些值多數(shù)無法精準(zhǔn)給出，更多地是開發(fā)方對可靠性的一個承諾。

三、可用性需求

可靠性是從系統(tǒng)角度看的，也就是反應(yīng)了軟件有沒有問題；而可用性則是從人的角度看的，也就是人覺得產(chǎn)品可用不可用。有時兩者是一回事，但有時兩者不是一回事。

之前我曾負(fù)責(zé)的一款產(chǎn)品，其可靠性很差，硬件和軟件總出問題。但是有些情況下卻不太影響用戶的使用，因為用戶大不了重新?lián)艽蛞淮坞娫挘蛑匦逻B一次網(wǎng)絡(luò)，也能用。

而所采取的手段是，當(dāng)疑似有問題后，該系統(tǒng)會自動重啟系統(tǒng)或重啟某進程。所以從用戶的角度看，其可用性尚可；但從系統(tǒng)角度看，其可靠性很差，系統(tǒng)總是壞掉。

現(xiàn)在的互聯(lián)網(wǎng)系統(tǒng)也多是分布式部署，從而將單點故障的影響降到最低，提升用戶的可用性。

而西安一碼通也需定義清楚可用性。如當(dāng)軟件、硬件出現(xiàn)故障后，系統(tǒng)應(yīng)盡可能支持一定的恢復(fù)手段，同時也要實現(xiàn)分布式部署等。

但從本次一碼通的故障看，主要是性能問題，此時靠重啟進程等手段是不能解決問題的，由此需要定義清楚性能需求。

四、性能需求

性能需求要先定義用戶訪問情況，再定義系統(tǒng)的響應(yīng)時間、新建數(shù)、并發(fā)數(shù)、吞吐量。

1. 用戶訪問情況

用戶訪問情況需確認(rèn)峰值訪問量、平均訪問量和訪問的業(yè)務(wù)。對于一碼通業(yè)務(wù)，需依據(jù)歷史數(shù)據(jù)做預(yù)估。如預(yù)估每日10點-11點為峰值訪問，且同時使用的人數(shù)是多少人，并應(yīng)盡可能精確到每秒的峰值。

2. 響應(yīng)時間、新建數(shù)、并發(fā)數(shù)和吞吐量

定義清楚了用戶訪問情況后，就要再從軟件角度定義性能指標(biāo)，如能定義清楚這些指標(biāo)，就可避免不合適的軟件架構(gòu)設(shè)計，這些指標(biāo)如下。

（1）響應(yīng)時間

指標(biāo)反映了網(wǎng)站響應(yīng)用戶請求的速度，也就是我們?nèi)粘Ｋf的網(wǎng)絡(luò)快慢。影響響應(yīng)時間的因素有系統(tǒng)延遲、網(wǎng)絡(luò)延遲和用戶端的延遲，一般可由開發(fā)方給個響應(yīng)時間。

（2）新建數(shù)

每個用戶使用一碼通查看信息時，系統(tǒng)都會新建建立一個連接。該指標(biāo)與用戶訪問指標(biāo)比較類似。比如登錄要新建、查詢要新建，這就是兩個新建。有時一次查詢需要幾個新建，需由研發(fā)確認(rèn)。

（3）并發(fā)數(shù)

定義了當(dāng)訪問系統(tǒng)的特定應(yīng)用時，能同時維持的連接數(shù)量。據(jù)統(tǒng)計西安有1300萬人口，按照最大10%的市民同時掃碼（已經(jīng)很大了），也就是要支持百萬的并發(fā)量。

（4）吞吐量

該系統(tǒng)定義清楚吞吐量，很多性能問題就可避免。

按照一些研發(fā)的分析，認(rèn)為一碼通的問題集中在該系統(tǒng)所有的 js/css/img 靜態(tài)資源全都從一個出口進行提供，沒上 CDN。

粗略估算了一下，js/css/img 數(shù)據(jù)總共約 500kB。而按照某個群里得到的數(shù)據(jù)（暫且認(rèn)為是準(zhǔn)的），健康碼的請求量峰值達(dá)到了 3.3w qps，也就是吞吐量要 33000 x 500 x 8 bps ≈ 125Gbps 這個出口量級很難用單機房承載，由此系統(tǒng)掛掉。

該指標(biāo)和系統(tǒng)實現(xiàn)方案有密切關(guān)系，需要由經(jīng)驗豐富的研發(fā)來分析、明確。

五、可維護性需求

可維護性需求可分為可支持性需求和可移植性需求。這些需求涵蓋的內(nèi)容較多，與一碼通相關(guān)度高的需求如下：

（1）可支持性需求

定義了開發(fā)人員是否可以方便地升級系統(tǒng)、用戶是否可以很方便地升級。

而據(jù)每日經(jīng)濟新聞報道，一碼通的升級需要人工刪除小程序，并清除數(shù)據(jù)。這就是沒有做好可支持性需求。

（2）可移植性需求

括用戶的增長和數(shù)據(jù)量的增長。用戶量的增長是指當(dāng)用戶量增加后，系統(tǒng)應(yīng)能方便地擴容。數(shù)據(jù)量的增長是指當(dāng)存儲的數(shù)量增加后，系統(tǒng)也能很好地支持。而一碼通半個月后又出故障，由此可看出其可移植性需求做的并不好。

六、總結(jié)

以上就是一碼通需定義的主要非功能需求，而這些需求涵蓋面又廣又重要。除了這些指標(biāo)外，還有一些次要需求，本文就不再贅述，你可參考《圖解產(chǎn)品》繼續(xù)完善。

其實該系統(tǒng)的實現(xiàn)不算難，實現(xiàn)方案也頗為成熟，甚至優(yōu)秀的應(yīng)屆生都能搞定，確實不該出問題。

有人可能會問，工作中我沒有定義這些內(nèi)容，研發(fā)一樣工作。是的，對于互聯(lián)網(wǎng)公司的自研產(chǎn)品多數(shù)不需這么詳細(xì)，但對于這種關(guān)系民生的定制開發(fā)則必須明確，從而避免上線失敗。

如一些實現(xiàn)細(xì)節(jié)不清楚，需求方也可列出框架，由開發(fā)方填寫。

而需求方還應(yīng)基于以上指標(biāo)，再定義驗收標(biāo)準(zhǔn)，違約責(zé)任，并進行壓力測試，由此來約束開發(fā)方的行為。這樣開發(fā)方就不至于敢派經(jīng)驗不足的研發(fā)來應(yīng)付事，更可避免扯皮，分清責(zé)任。

#專欄作家#

擎蒼，微信公眾號：圖解產(chǎn)品設(shè)計，人人都是產(chǎn)品經(jīng)理專欄作家?！秷D解產(chǎn)品》作者。專注B端產(chǎn)品，擅長UML建模、領(lǐng)域建模；專注企業(yè)數(shù)字化，有多個明星數(shù)字化產(chǎn)品構(gòu)建經(jīng)驗；另有多年產(chǎn)品經(jīng)理、企業(yè)數(shù)字化企培經(jīng)驗。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議