对客户负责，为结果买单
对客户负责
谁是你的客户？你的下游就是你的客户，你为他提供服务，他就是你的客户。比如，你是后端同学，给前段提供 API，那么前端就是后端的用户；前端收集埋点数据发给服务端，服务端就是前端的客户。
前段时间我整理某个竞品的数据，给产品提供参考。第一天因为时间紧迫，搞到凌晨 5 点。其实最后出的无非是一个简单的表格。至于怎么做的，没有人关系，哪怕是人肉数，只要能给客户提供数据也是可以的。表格中有一个非常明显的漏洞，就是类型错了，整理这个类型，其实也花了很长时间，各种抓包、最后还 ps 了一张整体的图，但是结果却误导产品标注了错误的类型。这个问题我想产品也是察觉到了，后来我的主管让我 review 一下数据，我也没注意这一点；最后一次机会是周末的时候，我感觉类型可能有问题，但是并没有向产品求证，为了尽快搞定，也就输出了一个我的主管让我做的事情就完事了。
今天更大的老板问起数据类型的问题，我的主管来找我确认，其实不用 review 代码，从业务的角度思考也很容易发现问题，然后又花了一个多小时 fix 这个数据。幸运的是，这个数据目前还是在 P9 那里，P9 要向 P10 汇报，如果拿着这种不能自圆其说的数据向 P10 汇报，搞不好整个团队都要受影响。
中午一块吃饭，我的主管跟我讲了他在携程，梁建章听汇报的事情，给你 30 秒，如果数据有问题，剩下的肯定就不听了。所以他发邮件之前都要检查三遍，确保数据无误。对自己发出去的邮件负责。
这个事情确实要注意，一旦向老板、客户、用户提供了服务，就一定要「无差别」地去完成，不要留下任何瑕疵。行百里者半九十，虽然费了很大的劲，但是很微小的瑕疵就会导致所有的努力都白费。
为结果买单
阿里提倡「为过程喝彩、为结果买单」。一个事情一个人领走了，从这一刻起他就担负着为结果买单的责任。如果做好了，这个人受益最大；如果做不好，这个人也要为不好的结果买单。
前段时间领了一个「如何保障 app 性能稳定性」的任务。我和主管沟通了他的思路，做了一个大概的规划，但是没能识别出「核心矛盾」、「问题重点」。结果就埋头去干了。周五的时候主管问我时间问题，我说下周一吧，结果下周一和主管去喝了杯咖啡，还是没有给他任何输出。
「结果」是迭代出来的，这种思路一定不要忘，我们可以搞一个不好的输出来保底，然后慢慢迭代，这才是正确的思路。
我的主管跟我沟通了他的管理思路：
- 通知你应该做的事情（比如性能、稳定性、规范）
- 在风险可控的情况下「等你犯错」
- 让你「为结果买单」
这样事情就变得很简单，我们把风险分为两个级别：
- 你自己负责的
- 团队负责的
这样我们只需要人为保证那些需要「团队负责的问题」，会有一个保姆帮你 review；对于你自己负责的任务，我们就不需要干预了，到点跟你要结果就是了。