“Bug管理思维”到“缺陷管理思维”的分享

lsekfe

这是一个“万金油”方法论，适用于任何行业、任何产品。无论是软件开发领域、消费品领域，此文中的方法论、理论，适用于绝大多数消费品，即便是服务业也可以参照这个方法论来实施（原谅我没有想到有其他不适用于这个方法的产品）。
　　BTW，此方法的思考源头，来自于我在软件开发（工程）领域的思考及经验，所以最适合的还是软件开发（工程）领域。
　　在软件开发的过程中，我们会遇到各类Bug，有的来自于程序员写的代码有问题，有的可能是程序员没有按照产品设计人员的要求做，有的可能是在一些特定的情况会卡死……
　　过去我们把这些都统称为“Bug”，并且对“Bug”进行管理，但是若是我们对这些“Bug”的成因进行分析，其实他们可以分为几大类。同时，很多“Bug”并不是致命的，甚至是不影响用户正常使用（比如账号登陆后弹出文字提示“未登录”，用户忽略即可）。所以，在这里，我们用“产品缺陷”的思维来替代“Bug管理”的思维。
　　产品缺陷具体可以分为三类：产品设计缺陷、生产管理缺陷、生产缺陷（对于软件来说就是“代码”缺陷，也就是俗称的Bug）。
　　产品设计缺陷
　　成因
　　- 需求洞察不到位、需求分析有误、需求满足的方案不够好。
　　- 限制条件太多：成本限制、工期限制、技术限制。
　　解决方案
　　- 重新进行需求研究、业务流程研究、产品设计，要与技术协商，减少改善成本。
　　生产管理缺陷（生产管理导致的缺陷）
　　成因：
　　- 产品的生产过程管理不到位，导致了产品生产出的样子和设计的样子不同。
　　- 产品与技术信息沟通不到位。
　　- 技术故意不照着产品的方案做。
　　解决方案
　　- 三类缺陷中比较难以解决的，应为是管理过程存在问题，需要优化沟通合作的方式、管理的方式，而人是比较不可控的，甚至是需要上到更高的管理层才能解决问。
　　代码缺陷（Bug）
　　所属范围
　　- 生产管理>开发管理>代码设计>代码编写
　　- 其实也是一种“生产管理缺陷”，但因为足够独特，所以单独拿出来分为了一类，也是软件开发领域最常见的缺陷。
　　成因
　　- 技术人员在代码开发时的错误。
　　- （多）技术人员技术水平不足、或易粗心、或代码逻辑有漏洞。
　　解决方案
　　- 在积累缺陷中最好解决的类别，因为只需要技术人员参与，通常情况下只需要“修正代码”即可。
　　- 当然，少数的情况的救火，可能需要产品人员、运营人员参与，用一些商业化的策略晚会代码Bug导致的损失。（如网游全服发放游戏币，程序员多打了一个0，则需要游戏运营相出办法来处理）
　　修正缺陷是需求
　　- 需求需要被再次提出和管理。
　　- 代码缺陷由产品管理人员与技术人员讨论后决定是否处理，何时处理，进行项目排期，部分缺陷也可以直接交由技术人员处理。
　　- 产品设计缺陷，需要产品管理人员进行深度的评估，与技术人员讨论解决方案，确定是重新设计及开发，还是在现有的基础设进行修改。（往往成本会更低，但是远期收益会更小）
　　- 生产管理缺陷，生产管理导致的缺陷，通常是生产管理流本身存在缺陷导致的，这种缺陷可以根据“修复成本、产品生产流程设计”决定是否修复。需要注意的是，缺陷必然存在，并不一定全不能修复，且修复一定伴随成本。我们要记住的是，在优秀的生产流程（或流水线）都一定存在缺陷。如车间一个机器标准化生产的零件的良品率过低，可以通过人员培训、调试机器等方法解决。但是也许提升至99.999%的良品率时，就很难再提高了，除非花几百万购置精度更高的机器，而这是不需要的。
　　- 优化这样的缺陷，需要产品、技术、项目管理人员、领导人员，多方一起协商解决，优化生产管理机制，评估优化成本。