昨天看到David Ko在Scrum Community in Taiwan群组里面提到了如何包装DevOps，让高层觉得它对于业务是有帮助的。我的已经是“绝对不要”，而且我觉得问题的出发点其实值得商榷，有感而发。
首先，DevOps是否对于商业有帮助，应该是用事实和结果来说话的，比如加快了Time to market的频率和速度，提高了客户问题相应的时间等等。有了这些数据，高层自然可以理解这些事情对于商业的价值。而过分把精力放到包装上，反而引来的是很多形而上学，华而不实的改变。
可能会有人说，需要资源支持、需要授权等等。但是回到敏捷思维的一些最根本的那些做法。哪怕引发一个改变，也应该从小步，具体问题开始的，一步一步地逐步解决问题，日积月累酝酿出大的改变（比如：为整个公司引入了DevOps）。所以更重要的是去看看为了DevOps那个目标，手头有哪些资源，有哪几个具体问题需要解决，然后开干就可以了。这些持续被解决的具体问题，应该会产生商业价值。
其次，更深层次的问题，是涉及到一种很常见的“请选我”的思维习惯。工业化时代，社会是层次的，组织也是层次的。过去发表文章，只能去找媒体和印刷厂，发表歌曲只能找唱片公司，因为它们掌握了别人能够看什么的权利，必须被他们选择，才能被看到。因为这种思维习惯，哪怕到了当今互联时代，大家还是花很多精力让大腿、权威去认可，去选择自己，比如买广告成为Google的头条，创业公司是通过参加创业比赛去获得Attention，让大的公司去投资。。。好像自己被选择，与大腿绑定之后就会更安全，更有机会。
随着时代变化，社会结构，连结方式已经发生了革命性的变化，从层次方式变成了网状。比如同样发表文章，FB，Youtube等很多平台，根本不需要依赖大渠道，每个人分分钟都可以发布自己的观点和想法，根本不需要别人的批准。解决问题，也不仅仅限于利用公司资源 （公司内部的资源往往比较老旧），除了公司，完全可以从社群（比如Scrum Community in Taiwan），从GitHub，从社交网络获得更新、更有效的资源和方法。“发不发表”更多是自己的选择，自己的责任。因此，与其把精力放在去获得高层的许可和授权去做某些事情，不如采取更主动、更接地气的方式，从“请选我”转变到“让我来”：
- 不限于个人或者专业角度，从老板角度，从整个公司角度去看，我们整个流程的瓶颈是什么？有哪些具体问题？
- 为了解决这个瓶颈，我手头有哪些能力，工具，资源，我的圈内有哪些人和资源可以求助、学习、利用
- 通过快速学习，寻求帮助，找到并掌握解决问题所需要的那些乐高积木
- 迭代地去把问题解决掉
- 然后再去发现影响瓶颈的下一个问题
不断推进公司的瓶颈问题，自然会给公司带来商业收益，很可能赢得别人的认可和信任。长此以往，就会提高自己的影响力以及公司对于自己的依赖，自己也就获得了与高层和大腿们的议价权。
