最近替别人擦屁股擦的很痛苦，具体问题是有个产品被集成，需要加入驱动目录保护，但是没有加全，导致被集成产品老是起不来。
为什么要加自保护呢？
起因是因为QA测试发现这个产品安装目录没有被保护，所以提了一个bug。
RD觉得这确实有问题，应该改一下，而且觉得也就是一行代码的事情，就开始改了。
但现实问题是，产品部署形态多种多样，组合方式也很多，自保护又是一个危险动作，因为一旦先把目录保护了，但是没有把该加白的进程没有加进去，很容易导致软件部署升级多种问题。
最简单的问题：
- 升级场景怎么办
- 卸载场景怎么办
- 被集成产品先安装，我们的产品后安装怎么办，同理反过来，我们的产品先安装，被集成的产品后安装怎么办
- 上面任意一个场景识别，自保护要不要启动，或者撤销，而且升级，安装，卸载从来都不是一个简单操作，任何一步都可能会失败
- 被集成产品内部有没有什么场景需要我们产品考虑一下开启/关闭自保护时机的
光把这些问题想清楚就要花不少时间，可惜当时当成bug修复了。那质量可想而知。
但是，你说QA/RD有问题么，也没啥问题，QA尽到自己责任，提出了bug，RD也很积极配合去修复。我觉得问题出在流程上，软件行业大家似乎一听到流程就很害怕，怕被贴上不够敏捷，还是那种一堆穿着衬衫在手写代码的老咕噜棒子，老气横起。但是我觉得还是要分产品，ToB产品就是要够老咕噜棒子，ToB客户可不想去当小白鼠，不够稳定的产品肯定是不会要的。
所以我觉得ToB产品迭代慢没有什么好丢人的，一个月发一个版本才丢人。最近很火的钉钉，说每天要出一个包解决问题，我觉得这样的心态去做ToB产品有问题。如果做ToC到是没啥问题，用户看到自己的反馈很快被解决或者做到产品里面是一种很开心的体验，但是ToB就搞笑了，毕竟用ToB产品的都是打工仔，好用够稳定的才能让自己早点下班，天天更新，功能不稳定那真是要骂人了