产品经理如何写文档才能不背锅?

8 评论 5490 浏览 15 收藏 13 分钟

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

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)可移植性需求

括用户的增长和数据量的增长。用户量的增长是指当用户量增加后,系统应能方便地扩容。数据量的增长是指当存储的数量增加后,系统也能很好地支持。而一码通半个月后又出故障,由此可看出其可移植性需求做的并不好。

六、总结

以上就是一码通需定义的主要非功能需求,而这些需求涵盖面又广又重要。除了这些指标外,还有一些次要需求,本文就不再赘述,你可参考《图解产品》继续完善。

其实该系统的实现不算难,实现方案也颇为成熟,甚至优秀的应届生都能搞定,确实不该出问题。

有人可能会问,工作中我没有定义这些内容,研发一样工作。是的,对于互联网公司的自研产品多数不需这么详细,但对于这种关系民生的定制开发则必须明确,从而避免上线失败。

如一些实现细节不清楚,需求方也可列出框架,由开发方填写。

而需求方还应基于以上指标,再定义验收标准,违约责任,并进行压力测试,由此来约束开发方的行为。这样开发方就不至于敢派经验不足的研发来应付事,更可避免扯皮,分清责任。

#专栏作家#

擎苍,微信公众号:图解产品设计,人人都是产品经理专栏作家。《图解产品》作者。专注B端产品,擅长UML建模、领域建模;专注企业数字化,有多个明星数字化产品构建经验;另有多年产品经理、企业数字化企培经验。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 啊这,还是分清责任解决问题吧,问题的解决最重要

    回复
  2. 产品经理:需求 啊 我需求呢
    我头发呢 啊 我头发呢

    回复
  3. 项目出现事故或许双方都难辞其咎,但是作为产品经理需要比常人更明白其中的产品需求、验收标准、违约责任,这样不至于成了一人背锅

    回复
    1. 是这个意思。并反对部分回答中非此即彼的二分法,即“文档无论怎么写,项目出了这种级别的事故,产品经理都难辞其咎”。
      正如俞军所说将一个产品的不成功,就归因为产品,显然是把产品看的太厉害了。而对于该项目也是如此,产品经理只是成功或不成功的一个要素。
      另一方面,本文主要强调写清楚需求,这毋庸置疑是对的,但并没有说这就够了。还应如文中所说要明确“验收标准,违约责任等”工作。如这些都能做到,问题就会少很多,责任也可分清楚,更可依据责任改进工作。显然该产品经理没有做到,就是该背锅的第一责任人,更需要改进其工作。

      回复
  4. 不多做评价,群众的眼睛是雪亮的

    回复
  5. 性能需求要先定义用户访问情况,再定义系统的响应时间、新建数、并发数、吞吐量。

    回复
    1. 学习了哈哈哈哈,就算这个用户访问情况要怎么定义哈哈哈哈哈

      回复
    2. 见文中描述,即多少用户什么时间访问什么应用,该案例的应用就是获取健康信息。

      回复