背锅|西安一码通连续崩溃，产品经理如何写文档才能不背锅？ 58同城|百度|美团|小红书|互联

编辑导语：西安一码通连续崩溃，除了软件开发方有责任，产品经理也需要写清楚要求，否则很有可能“背锅”。本篇文章中，作者分析和解答了产品经理如何定义清楚一码通的非功能需求，以及如何写文档才能不背锅等等问题，推荐想要学习如何写一码通功能需求的群体阅读。

文章插图
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分钟内开始维修。