把我们从错误中总结的教训系统化
前天我们产品环境又出问题了，一天上了3个版本。这真令人担忧。虽然我们有渠道及时发现问题，有人及时跟进并解决问题，但是，大多数情况下：
只有少数人了解这个问题的来龙去脉。
只有更少数人会在紧急解决了问题之后，还自发地去想如何以后避免类似问题。
几乎没有对改进措施是否有效和进一步改进改进措施的长期跟踪。
1.只有少数人了解这个问题的来龙去脉
这是一个问题吗？我们需要所有人都了解每一个产品环境的问题吗？如果不，那么我们认为什么人必须了解某个产品环境的问题？这块代码的负责人？这个小组的负责人？相关的需求人员和测试人员？
似乎，我们并没有这样的机制来明确一个产品环境的问题它具体的必须了解来龙去脉的人的名字。大多数时候是除了改代码的那个人，其它人都是FYI。bug都在系统里，你看或不看，理解或不理解，没规则约束，也没有人监督。
我们不满，我们抱怨他人，但我们自己也并没有去深入地理解背后的原因和尝试建立更好的机制。
2.只有更少数人会在紧急解决了问题之后，还自发地去想如何以后避免类似问题。
职场的人太懂得“优先级”了。所以，很容易理解当产品环境问题已经被紧急解决，而手头又有别的一堆高优先级的事情，复盘就变得可有可无了。
那么，如果我们把产品环境问题的复盘定义为相关人的“仅次于解决产品问题”的第二优先级呢？什么新需求，内部测试bug，这些通通靠边。早会结束，几个人先把昨天产品环境解决的问题复盘。也许，与其期待每个人的“自发”或者某个人的事情做完了正好有空可以想想，还不如在这个问题上统一所有人的优先级。
3.几乎没有对改进措施是否有效和进一步改进改进措施的长期跟踪。
持续改进的价值在于在改进的基础上改进。如果每次都是尝试改进，效果不佳；下次碰到问题又从头开始，就会越来越怀疑改进的方向。殊不知，问题就出在没有去分析原来的改进方案中的问题。而上次停在哪里，从这里开始，比从起点开始更能落地。
问题日志-《原则》读书笔记4
网友评论