喜欢|你喜欢上PDD上买东西，这里潜藏了对产品开发项目最原始的诉求产品|可靠性|诉求|开发项目|潜

文章插图
项目经理世界（ID:IPMP_WORLD）全文1734字
网上购物，你买东西究竟是喜欢在京东自营还是天猫淘宝，又或是PDD上？这是由你所想要的产品的属性决定的。
首先来看两个有趣的例子：
第一个，在用C语言写a=1+1的时候，你需要考虑可能由于寄存器的某个BIT跳变使得a不等于2？站在软件开发的角度，这太不可思议了，这是对软件基础的怀疑；
第二个，你新买的手机第一次突然开不了机，手机CPU的供应商经过检查告诉你：你的CPU被高能粒子击中（传说中的宇宙射线......），不能正常工作，你会接受这样的说法吗？
看起来很不可思议，实际上以上例子都是在研发项目中遇到的可靠性的问题。
什么是可靠性，简单的来说就是：
之所以从用户体验的角度去考虑，而不是从概念、量化指标去考虑，是因为如果从开发者的角度，宏观指标的参考意义远远不及微观体验和设计，你作为开发人员去告诉客户，我们产品的可靠性达到了99.999%，那0.001%的客户会觉得我是应该要遇到问题吗？
对于用户来说，最直接感受的恰恰是上面的三个层次，研发过程中出现的各种诸如MTTR(mean time to repair)即设备故障平均修复时间、MTBF(mean time between failures)即平均故障间隔时间只是将可靠性进行了量化而已，这些指标终究不可能在开发过程中完全杜绝，这个时候，比较合适的方式是，告诉开发人员，要避免产品的模块问题波及到其它模块，或者考虑某种机制，一旦模块出现异常可以感知和恢复。

文章插图
研发在开发产品的时候，往往更多的关注功能需求，对于可靠性的考虑还是不如功能性的，两者之间存在一些差别。
1. 功能性需求可以由使用者明确提出，但是可靠性需求很难做到
这里说的可靠性需求不是指指标型需求，例如客户要求公司提供的某一项设备的可靠性必须达到5个9，这样的需求提法是可能存在的，但是不适合作为开发项目的需求，因为难以验证，提这样的需求也是没有用的。
2. 功能性的投入产出比基本是线性的，但是可靠性没有明确的规律，可以确定的事越往后投入产出比越差
功能开发在规定时间内，投入1个人可以完成1K的代码量，投入2个人可以完成2K，一般不会有太大的变化。而可靠性呢？初期可靠性特性可能会产生一些代码，随着产品的开发，可靠性功能需要不断地移植和增强，更加普遍的情况是，一种可靠性特性不能覆盖所有模块，这时需要开发另一种可靠性特性来覆盖更多的模块，每次开发都需要一批专家仔细设计和开发，而且可靠性特性之间很容易发生更多的冲突和耦合。
3. 功能是可以验证的，可靠性是难以验证的
不同领域的可靠性具有各自领域的特点，尽管可以归纳出一些相关的分析和验证方法，但是应该说这些方法的性价比很低。
4. 功能一般来说可以无损叠加，可靠性一般不可以
在已有实现上新增一个功能模块，大多数情况下可以直接叠加，对已有模块不会产生影响。在一个已实现上新增一个器件级可靠性一般就会复杂的多，先不论对原有功能的影响，这类可靠性功能至少会影响性能。对于高端设备来说，性能虽然不及功能那么招人关注，但是性能一定会影响多架构和模块的设计。

文章插图
如何解决可靠性的问题？主要看是想设备在前期卖钱还是后期卖钱。
对于市场来说，相对于传统的“卖功能”，产品的可靠性很难包装出去成为卖点，这种情况下，前期还是在靠功能拿单，可靠性在项目初期，对圈钱几乎起不到作用。可到了项目后期，也即全国商用和维护阶段，可靠性的作用就会渐渐体现出来，研发维护人员在后期处理的问题，80%都是可靠性不足导致的问题，如器件故障、硬件故障、异常环境或者异常输入导致的问题等等，因此可以说后期维护成本的高低在很大程度上取决于产品的可靠性。
所以说在项目前期，可靠性不能圈钱，但是在项目后期，可靠性可以省钱。
遗憾的是，我们倾听客户的需求，而客户的需求中最容易实现的就是功能，既然满足客户的功能需求就能拿下项目，又何必再前期去考虑可靠性这样一种虚无缥缈的东西呢？于是可靠性一般直到出现大量问题的时候，才会被正式纳入开发者的议程。