我经常无法 gauge 工作狂说话的意思。经常在我们讨论项目的时候，甚至在我们刚刚和客户聊过了以后，她会忽然说，“其实没有多少东西要做的是吧？只要改xxx，就好了呢。当然，测试要仔细看一下。” 工作狂这周末生病了，休假了两天。我就把上周她这么说的项目上线了。
今天和她讨论下来，我被她说服了，感觉自己上线的逻辑是错的。现在我很想为自己找借口。
问题简化下来是这样的：有一个 join 的逻辑，历史上一直要用到一个日期的字段。这个的来历是，marketing 的人用一个系统（系统A）决定给哪些用户发优惠券，这个信息会被传到发优惠券的系统里（系统B），有个程序会把一段字符串写在B里一个表的一个字段里，这个字符串包括一段日期，是我们用来 match 两个系统的字段之一。至于为什么用时间字段，而不是搞一个ID字段，可能是十年来没人有空重构这块。现在 marketing 的人请开发做了一个新的系统，那么这个程序也需要存那个字段到 B 系统里。这个系统 deploy 到产品环境后，他们发了几个优惠券测试。从这几条测试数据来看，A系统里有 M，N 两个时间字段，B系统里存的那个时间解析出来一看，有一条和 M 一致，其余的和 M，N 都不一致。这个时间字段对我们来说还有一层意义，就是是这批优惠券发放的时间。可能每个客户收到的时间略有不同 （N），但是对 marketing 的人来说，他们就是这个点发的优惠券（时间 M）。而这两个字段的命名意味着 N 不是一批次的时间。当我们问对方开发的时候，我们问的是，run date （批次时间）是哪个？他说是 M。
概括一下：我们需要搞清楚 1: 系统 A 的 M 还是 N 字段和系统 B 里挖出来的时间字段匹配；2: 这一批次的时间是 M 还是 N。
乍一看有好多理由支持 M 是 run date 而且也可以用来关联：
- 对方开发说了是 M
- 测试数据里有一条是 M 能匹配，其余的记录里 M 和 N 都不符合 （所以 M 比 N 好）
- 从命名来看 M 是批次的日期时间，而 N 是个体的时间戳
接着我观察了两天产品环境的真实数据。观察结果是符合 M 是 run date，也是用来关联的字段。这里有一个疑点是，产品环境的数据里 M 的时间部分都是 00:00:00。但我没有觉得这里有问题，因为系统 B 里用来匹配的字段也都是 00:00:00 为时间的，就这样过了两天，除了几条测试数据以外，所有记录都符合 M 是 run date 也是匹配 B 的字段。
好了，工作狂是怎么说服我我可能错了的呢？第一她说她知道发优惠券一天只能发一个。“那么可以一天给一个用户发多个优惠券吗？”我问道，但是她没有很肯定地回答我（我也不能怪她，因为这种业务的问题其实应该 PM 来搞清楚）。但我觉得她的假设可能是对的，因为我之前在哪里看到 marketing 的人在 target 给哪些用户发优惠券的时候，为了对比组能真实反映优惠券的效果，会回避被别的 marketing campaign target 到的用户。这一点的推论是，B 系统里的那个时间永远是只有日期，时间部分永远是 00:00:00。用这个角度来看，本来看起来 “测试数据里只有一条是 M = B里的时间字段，其余的都 M 和 N 都不匹配 B 里的数据” 从另一个角度看变成了 “所有记录（包括测试数据）都符合 N 的 date 部分 和 B 里的字段相等”。似乎 N 是我们要的字段更有可能。前面的三条变成了：
- 对方开发说了 M 是 run date，但是匹配的字段可能不是 M
- 所有记录都符合 N 的 date 部分 和 B 里的字段相等
- 从命名来看 M 可能是 run date，而用来匹配 B 的可能是 N 的 date 部分
关键是，我没有想到这个匹配规则可以不管时间戳，只管日期。
本来在我看来已经很确定可以上线的逻辑，这么一说又感觉不对了。现在我对我已经上线了感觉很不安。我做事一直是比较保守的风格，比较避讳 risk。但是这次我完全没看见 risk。
当然，上面这个 complication ，是埋在好多细节里的，虽说是比较重要的一个细节。。。
我还是想怪项目没有需求和设计文档。
今天下班前专门发了邮件问那个开发 “你的程序里往系统 B 里写那个字符串里日期的部分是哪个日期/时间？是 M 还是 N？” 这个问题，希望能得到正面回答。
你说我脑力花在这种事情上，是不是很无聊啊？其实本质上是根本没有难度的事情，就需要沟通的时候大家在 same page 上。这一点照理说也是 pm 的事情。