背景

在道一实习的时候，有一个简单的需求，测试说，【管理员组】选择框可以把它长期保持开启且用户不能进行修改，否则可能造成【流程错误】的问题。
我当时自己在做一个简单的测试的时候，也发现了这个【流程错误】的问题，因为在公司里面规定，这种错误属于主流程没法走通的错误。于是我就决定把这个按钮改成长期开启且用户不能进行修改。

客户反馈

由于当时我请了一个比较长的假期，于是这个需求就给了另一位产品经理继续跟进。于是，当时有一个客户投诉到该产品那里。那位产品找到我，问我当初为什么要改，我就给他解释了【流程错误】的问题。
我看了一下客户的操作，原来客户的配置，客户的操作和我们想象中完全不一样。【管理员组】选择框如果不选的时候，也是可以做到有人去管理的，而这个操作在投诉前我是不知道的。（开发和测试也是不知道的，因为这个应用太久没人反馈问题了）

反思

对于这次的产品改动，我也得出了一些反思。

1. 产品修改前，应该考虑一下，不改是不是也能进行下去。

这次因为没有了解清楚这个【流程错误】是不是必然会发生，也不了解发生的原因是什么，就盲目的把开关给禁止用户修改了。如果作为产品不了解发生bug的原因，就找开发查代码，了解一下为什么会发生，而用户的一些配置是否会导致bug的发生。
另外，其实不是说产品和开发很懒，天天不想改需求，实际上是改动容易改变用户的操作习惯。可能在原型图上的一个小改动，在代码上的一个小改动，对于用户体验可能就会造成非常严重的破坏，这就非常不好。
我们不是从0到1的产品，我们是接手的人，就不能轻易的对人家的产品进行大规模改动，这有可能会造成原始客户的流失，我们要做的是尽力保证保持线上逻辑不变。

2. 修改的时候，需要在原型图中写清楚修改的原因

由于我这次只是请假，我们的产品还能找到我，问我为什么当初原型图这么写，但是如果我离职了，就没人了解为什么当初这么修改。所以，在对一个非核心需求（不是本次修改的核心）修改的时候，建议把修改的原因加上。

3. 做决定的时候，建议对产品全方位了解

这次的修改其实也和我对产品没有完全了解有关系，虽然我们都懂牵一发而动全身的道理，但是有时候做决定就会忽略了某些点。
比如这个开关的问题，后来得知是与客户是否为付费客户也有一定的关系。当然，上一任产品没有在这里做标注也是有问题，而我们也应该询问一下开发这里是否在付费与非付费客户有一定的问题。当然这次的问题只有在灰度测试的时候才发现的问题，这也实在是没办法。