有这样的一个用户场景，我们的渠道产品的某个付费功能，针对某些预付费渠道的用户，需要提供免支付使用的功能，其中有两个需要注意的地方：
- 这些用户是这个渠道的雇员，当这种雇佣关系不存在的时候，需要取消他的账号的免支付功能（也可以注销这个账号）
- 现有的用户名和密码传输过程是不安全的，而且这些用户有相当高的概率设置过于简单的密码。
我们讨论了几种方案：
使用微信登录授权的方式
用户需要登录微信，授权我们的服务器，然后绑定他的账号，在使用付费功能的时候，我们会返回一个需要微信授权的链接的二维码，用户通过微信扫一扫打开链接，就能完成授权流程。这样我们提供的账单就有对应的微信信息，具有公信力。
然而这个方案被Boss否掉了。因为这个方案对我们来说有开发成本，对用户来说有使用成本，操作略显繁琐。
使用定期更新验证码的方式
用户绑定手机号码，我们定期下发（每天或者每4小时）支付验证码到手机上。当用户使用付费功能的时候，就需要输入该支付验证码。考虑到下发短信的成本问题，我们不要求每次支付后更新验证码。
这个方案的开发量很小。但是也是被Boss否定掉了。他提出的理由是，用户的流动性很大，授信给某个手机号还要解除绑定。
使用用户名/密码的方式，但是由我们提供复杂的密码
由我们提供复杂密码，和用户自己设置密码的区别在于，在我们平台上用户容易犯错的概率。我们大大减少了用户使用简单密码的概率。这是由Boss提出来的方法，因为它简单，容易实施。
我的考虑
这个问题涉及的关键点是，如何证明这个账单是由对方的雇员产生的，分别通过微信号来确认，手机号码的所有者来确认，复杂密码的知情人士身份来确认。第三种方式的实施成本是最低的，但是犯错概率是最高的，因为复杂密码的知情人士不限于用户本身，也有可能是中间过程的对方甚至是我方人员。
我认为第二种方案应该是最优的，虽然有一定的运营成本（短信费用），但是开发成本和实施成本都接近最优解。而Boss否定这种方案而提出来的人员流动性问题，是不太可能被任何方案覆盖的。
如果Boss坚持。。。
Boss坚持第三种方案的情况下，我提出增加监控的机制，当某个用户的免费额度达到预定的警戒线的情况下系统报警（不是真的报警，是指发短信给相关人员）。
我学到的一些皮毛
- 不要只提出一种方案，这样自己就会陷入对其中一个方案的执着之中，尤其是做技术出身的很可能有洁癖。
- 头脑中对某些关键因素要有概念：
开发成本,实施成本，运营成本，风险监控等等。规范的流程和术语，可以防止出现某些重大的纰漏，让讨论的进程更有建设性。 - Boss永远是对的，如果你觉得Boss不对，那么是因为你看不到Boss看到的东西！哈哈！
