最近有小伙伴问了一个问题：他所在的测试团队规模比较大，有 50 多个人，分成了 4 ~ 5 个小组。这位同学觉得自己的技术能力在团队里应该属于比较不错的，但疑惑的是在几次组织架构调整中，直属领导一直没有让他来管理一个小组，而总是把机会给了别人。为此他感到十分苦恼，觉得是因为平时没有亲近领导的关系。
走上管理岗位是很多人的追求，但大部分人未能如愿以偿。在我的职业生涯中，还遇到过很多类似上面的例子。所以今天我就以自己的经历，结合近十年的管理视角，给大家做个分享，希望能给有这方面困惑的读者带来一些帮助。
11 年 09 月，我加入了某电商领域独角兽企业，整个团队共有十来个人，我的直属领导（后面简称为 W 吧，不喜欢全文用领导这个词）是不久前从一家知名外企跳槽过来的资深测试开发。在我入职短短 3 个月后，我迎来了在该企业的第一次绩效考评：同级别中垫底。
当时确实比较失落，加上年轻气盛，我向 W 提出了离职申请。而他可能也看出我只是因为一时的情绪激动，没有太多的表示，只是让我再好好想想。冷静过后，我也觉得想法的确过于冲动，所以开始思考要如何逆境破局。
很快我就发现了一个机会：由于 W 也是刚加入团队不久，所以希望能够带领团队有一些突破。经过考虑和筛选，W 选中了测试环境这一项。
早期的测试环境是由开发团队来维护的。从测试团队的角度出发，代码提交、环境部署全都不能自主。像测试过程中发现有意外更新，导致测试中断或重头回归的事情更是家常便饭。因此 W 希望能由测试团队来完全承担起测试环境的搭建和维护工作。
当时我对 Linux、Nginx 等运维相关知识的掌握程度几乎为零，而可用的时间仅仅只有一个月。对于我个人而言，成功率可以说不到 10%，但我还是毫不犹豫地主动认领了这个任务。
之后的那一个月里，我每天都要花 4 个小时以上的业余时间（包括周末）疯狂学习相关的技术，边学边试，遇到实在不能理解的知识点，就拉着开发和运维同事请他们给我讲解。另外，部署环境也需要大量的硬件资源，而测试团队拥有的资源同样接近于零，因此不得不硬着头皮从其他团队去“抢”（还为此吵过架，haha...）。最终结果读者应该也猜到了，我按时完成了这项任务。
你以为这样就完了？
后续问题接踵而至。环境是部署好了，也可以正常运行，但是团队里其他测试同学在系统维护方面的技能同样缺乏。虽然我写了自认为很详细的教程，但由于操作不当引起的环境部署错误时有发生，我自己也被迫四处救火，苦不堪言。于是脑子里萌生出一个更大胆的想法：搞一套纯界面化的部署系统（在那个年代这可是稀有物）。
我找 W 合计了一下，他也觉得可行。因为有了前面的“成功”经验，我和 W 已经建立比较好的信任关系，所以他让我全职开展这个事情。又经过两个月的奋斗，属于测试团队的第一套系统顺利发布了。既为测试团队赢得了荣誉，也减轻了我的负担，同时还获得了周边同事的信任。
再往后的事情仿佛都是顺理成章，由于这方面的贡献，我很快就获得了第一次晋升：测试主管，并有了虚线管理的小团队，可以独立负责一块业务。第二年，我又如法炮制，打了几次“硬仗”，再次晋升到测试经理，又有了绩效评议权，自此算是正式走上管理岗位。
当初我的晋升，更多的是“拼出来”的，可以说有“偶然”的成分。而有了这些年的管理经历，也渐渐明白那时候做对的是什么。核心其实就一点：
不是先有再做，而是先做再有。
经过多年的观察，我认为这是许多人无法晋升的主要原因。我们总是在想：如果领导能让我做主管，我肯定能做到怎样怎样，目前我不去做，因为我还不是；或者在跨团队合作的时候，也抱着类似的想法：我做不好是因为我的级别不够，别的团队不愿意配合我；等等。
但是从管理者的视角上看，在你展现出相应的能力之前，他是不会轻易让你负责一个团队的，毕竟这个相对关键的岗位会影响到好几个人的状态。一旦选择错误，就会造成大面积的影响，也会给团队带来一连串的麻烦。这点也就意味着领导在选择管理人员时，往往表现得相当谨慎。因此我们要做的，是先想办法证明自己拥有这样的实力。
比较容易掌握的一个方法是“向上思考”。我们可以先把自己“摆”在更高的位置上：如果我现在就在这个岗位，我应该做什么样的事情，解决什么样的问题。通过这种方法能够以更大的视角去看待自己的工作，提前锻练更高维度的能力。当我们能够证明自己的胜任力，又有新的机会出现时，领导自然会优先考虑你。
最后，我想跟期望走上管理岗位的大伙说一句。管理是一种责任，不是一种权力。当我们承担起这种责任时，要时刻记得自己的一举一动，可能都会给他人带来巨大的影响。好的管理可以成就一个人，坏的管理也会毁灭一个人。我不敢说我是一个很优秀的管理者，但我愿和大家一起砥砺前行。
屠龙勇士，不成恶龙。
文章源自公众号 测试开发修炼之道