【心得体悟】Say No
在外企工作，发现老外和国人一个很明显的区别就是：老外很懂怎么“say no”。国人大多都很“实在”，一般要么不“say no”，加班加点蒙头肝。要么“say no”了，但是理由半天说不明白，别人只以为你能力不行，故意找茬。
正常接需求
举一个自己的例子。我们做的是数据仓库，来了一个新需求，需要加载一批新的数据文件（外汇交易数据）到系统中来。
在和产品对接需求的时候，我发现一件奇怪的事：一般新进来一批数据，都会做“标准化”，因为我们系统汇集了多个上游的数据，而每个上游的数据格式都不一样。但是这批数据不要求做标准化。而是直接原样加载进来即可，原话是“load as is”。
这个需求和标准的流程不符，但同时又非常简单。我和组内几个同事讨论了一下，最近手头活也不多，决定接下这个需求，新建一个模块，专门处理类似的需求。
Ask Why?
到这里一切都很顺利，开发也很顺利，从需求分析到上线一个月不到就都搞定了。问题在于，后面和英国的架构师“review”这个新项目时，他提了一个问题：“我们为什么要做这个项目？”
这一下我就被问蒙了。我说：“这不是我们要做，而是上/下游需求的呀？”
他说：“但是这个需求不符合我们的标准流程，我们是一个数据仓库，而不是一个文件系统，其他人不能随便扔一个文件过来就要放到我们系统中。”
他继续说，“这件事我们做和下游做，成本是完全一样的，所以对于整个公司而言，谁做都可以。但是我们不能被其他人牵着鼻子走。他想要让我们做，就必须论证其必要性”
角度不同
我仔细地想了下，他说的也很有道理。因为我们两个人的角度不一样。
站在我的角度，我对于需求的态度是“来者不拒”，因为多接需求意味着多产出，多绩效。
站在他的角度，他更在意的是系统的“稳定性”和流程的“标准化”。
在前几年，我们的系统处于扩张阶段，我们当然希望越来越多的上游将数据加载到我们系统中来，同时也有越来越多的下游使用我们的数据。这个时候，当然应该“来者不拒”。
而在最近一两年，不论是外部经济大环境，还是整个公司内部，都处于收缩中，那么，“稳定性”就更重要。
我接受了他的建议，但是我们这边代码测试流程都走完了，怎么办呢？我们决定，现有的先保持不动，后续如有大的修改，需重新论证项目的必要性。
启发
经由这件事，我有两个启发：
- 及时调整战略思想，和公司步调保持一致。
- “say no”是个技术活，是拒绝，但不是不留余地的全盘否定。给对方保留一线余地，后面还有反复拉扯的空间。在拉扯中，找到各方利益最大化的平衡点。
