亲们（Dev），天天和PD，QA，PE打交道，有没有仔细想过你和他们的关系是怎样？你们各自own的部分有边界吗？你们应该怎样协同工作？
PD是产品需求的owner，PE是线上环境的owner，QA是产品质量的owner，Dev呢？ Dev是everything的owner（That's why Dev engineer is so Niubility）。
所以准确的说应该是Dev和PD是产品需求的co-owner，Dev和QA是产品质量的co-owner，Dev和PE是线上环境的co-owner。
个么问题来了，既然是co-own那就不是你一个人说了算的，不像代码，你是full-own，你想怎么画就怎么画（当然乱画也是要小心的，不要低估老板code review的能力），所以对co-own的部分，我们不能图方便，图省事，想“敏捷”，有事情的时候，还是要有商有量，知会到相关方，这既是对他人工作的尊重，也是对自己的保护（说白了就是，你不知会co-owner，不协同相关方一起解决问题，出问题就是你一个人兜）。
对于这些co-own部分，除了QA，PE有部分是走约束流程（例如：通过自动化测试，才能走freedom发布上线），其他都是约定流程，而这些约定流程是Dev平时最容易忽略的，其实只要是约定且没有固化的东西都容易被忽略，试想下大家都宣称自己是敏捷的，但对于敏捷开发的那些约定，有多少团队能严格招办呢。因此，我把Dev和其他部门的工作关系总结成以下几个授权：
“动产品，要PD授权；发布上线，要QA授权；动线上机器，要PE授权；法律风险，要法务授权”
希望大家可以经常以此审查自己是不是在用正确的方式做事。
1、PD授权
真实案例：
开发做了一个来自于运营的业务小需求，PD不知晓，在新项目中，PD遗漏该变动点，导致在预发布测试时，才发现有问题，造成不必要的口舌和麻烦。
正确做法：
理论上我们的业务需求接口人是PD，如果有来自非PD的业务需求，也要知悉到PD。
2、PE授权
真实案例：
1）手动重新启动线上服务，因为误使用了老的启动脚本，导致服务不可用，P4故障 。
2）记得我入职不久的时候，也发生过一起因为开发在线上使用jmap导致HSF服务不可用，从而导致交易异常下跌的p3故障。 当时还有过一次激烈的关于Dev是不是应该touch线上机的讨论，最后的结论是大家都比较认可在工具完备的情况下，所有人（Dev和PE）都应该远离线上机，因为只要是人的操作都难免出错，而线上一出错就是故障。 所以标准的运维方式都是朝着自动化、工具化方向发展的，即所有的操作（发布，回滚，重启，监控，日志收集查看，内存快照 等等）都应该工具化，DevOps只需要操作GUI就好了。
正确做法：
让PE协助做线上操作，如果非要自己去操作，至少也要知会到PE。可喜的是PE已经意识到此问题，从PE那边获得的最新反馈，PE工具组已经在着手相应的流程定制和运维工具开发。
3、QA授权
杜撰案例：
自测小需求上线，在有部分自动化测试用例fail的情况下，霸王硬上弓，结果导致线上bug。
正确做法：
当然是在取得QA同意的情况下，再发布了
4、法务授权
真实案例：
一个小二因为误操作查询了客户支付宝，未经授权获取、使用保密信息，违反反保密义务行为，记过处分价值观C。
正确做法：
严纪守法做阿里好公民。
上文主要是对最近几个真实案例有感而发，希望大家引以为戒，提高风险意识，不仅要做正确的事，而且要正确的做事（Do the right thing, Do the thing right）。
