重塑影响力

我们在这里不会谈社交媒体上的影响力，这需要动用种类繁多的运营和技术手段。本篇文章里要解决的问题非常简单：如何才能让他人跟随你的建议行动。
影响力无关权力

上级对下级的影响力就一定天然成立吗？虽然权力阶梯存在，但并不意味着权力绝对有效。因为强制力虽然可以保证事情得以发生，执行效果却并不掌握在 leader 手中。我们都明白如果团队成员并不认可和理解接下来的愿景，他们会做的只是取悦般地服从而已：我不会花心思把它做得更好，它的成功与否也与我无关。
我们每个人一定见过一种类型的角色，虽然他们不具有特殊头衔，但是他们的意见总会被认可，他们的建议常常被采纳，甚至你会发现当同事们遇到麻烦时第一时间想到的找他们寻求帮助——这便是影响力的魅力。相反，我相信在我们每个人的职业生涯中，有无数经理以及领导是被我们所厌恶或者阳奉阴违地对待的。我曾经阅读过一本非常好谈领导力的图书：You Don't Need a Title to Be a Leader，这个标题在这里稍作修改依然成立：You don’t need a title to have influence.
我们在影响谁

在讨论如何影响「他们」之前，我们首先要搞清楚「他们」究竟是怎样一类人群——只不过是一群程序员不是吗？——这恰恰是他们的特殊之处。与传统文职人员或者蓝领工人都不尽相同，虽然软件制造如今看来是与劳动密集型产业无异，“极客精神” (geek) 的特质依然保留在他们的骨子里。
如果你在 google 中搜索 ”how to manage geeks”，有一篇经久不衰的文章会出现搜索结果前列:Opinion: The unspoken truth about managing geeks. 这篇发布于09年文章里观察到的现象以及得出的结论现在看来毫不过时。采用文章中的原话一言以蔽之就是：

IT pros will prefer a jerk who is always right over a nice person who is always wrong.

与其他行业的人员相比不同之处在于，程序员服从的并非某个头衔或者某套流程，这里服从的本质上是对他人发自内心的尊重，而尊重来源于对一个事实的判断：你可否把事情做对。这个前提是如此地重要，以至于让工作中的其他内容都显得黯然失色。正如我在引用的原文中所说的那样，哪怕你是个混蛋也无所谓。在该前提下程序员的种种行为用传统的职场观念来衡量起来是匪夷所思的，例如程序员之间的争吵通常围绕的是更好的解决方案是什么，而不是谁来做以及如何能干得更少；上级的建议也不会是必须遵循的金科玉律，他们会按照自己的想法实施，不幸的是他们的想法永远都是对的。
与需要巧言令色讨好其他职位的角色不同，赢得程序员尊重的标准答案仅此而已。然而对于外行而言如果你意识不到这条潜规则的存在，你会在和程序员打交道的过程中步履维艰。
当我们意识到这个事实之后，便有了塑造影响力的方向。
塑造影响力

把事情做对并无诀窍可言，它等同于在考验你的综合能力。你对业务理解要正确，用代码表达业务要到位。然而这听上去像是人人都应该做到及格线，只是昭示着你来到了这个圈子而已。我们如何借此来扩大我们的影响力呢？
我的建议是「专精」：你的答案要比他人更接近正确才行。
刚刚我们一直在回避一个问题，即对于「正确」的定义。当我们在聊「正确」的时候，我们其实聊的是实实在在的东西，代码的正确性包含它的复杂度、可维护性以及执行效率等等。并且它们是绝对的，在解决同一个问题时如果你的代码行数更少、运行时间更快、可读性更好，那胜出便当之无愧。
如果上面的叙述还过于抽象的话我们不妨看这么一个例子：如果有人建议在你所在的前端项目中引入端到端测试，你会如何考虑？「正确」要解决的第一重问题是要不要做；第二重问题是我应该如何去做。
在解决第一重问题时，我们需要知道：

• 端到端测试是什么？
  
• 项目中有什么问题是必须使用端到端测试来解决的？
  
• 端到端测试是唯一的方案吗？单元测试是否也能达到同样的效果？
  
• 端到端测试是否适用于我们的项目？
  

这四个问题看起来平平无奇，但每一个问题的背后都涵盖巨大的信息量。例如最后一个问题当在考量端到端测试在项目中的可行性时，我们既需要对这项技术的横向（与其他测试技术之间的差异）和纵向（目前的技术生态和业内实践）知识都有所了解，对当前项目的现状也要掌握得一清二楚，因为维护成本高昂的端到端测试并不适用于快节奏的交付项目。
如果提出建议的人只是偶然间在某篇文章中读到了「端到端测试」这么一个时髦的技术词汇（buzzword）而抛出来讨论，恰巧你又有实践端到端测试的经验，并且不认为当下是一个引入端到端测试恰当时机，那么你便可以有理有据的反驳他，影响力于是在此彰显。
从这个影响力落地的例子不难看出达成「专精」并无他法，它等同于你在某个领域内知识积累的厚度。而如何达成这个目标呢？我们其实是在尝试回答一个纯粹又古老的问题：如何让自己从新手成长为专家？每个人都有自己的答案。
让声音被听见

去他的“酒香不怕巷子深”——如果你现在已经「身怀绝技」，请务必要让别人看见。没有对话施加影响力自然也就无从谈起。那如何被看见呢？每天的工作按部就班，团队内的技术趋于稳定，没有机会给到我。
我的建议是不要被动地等待机会，而是为自己创造机会。
你要相信缺陷是永远存在的，我们每个人都在编码过程中经历过妥协，过去的妥协便是未来的改进之处。作为每天接触代码一线人员识别到它们并不难，识别并修复它们是最好的机会。你不妨选择一些你擅长的领域先把自己投资进去：之所以称之为「投资」是因为你可能需要动用到工作之外的时间去整理它们、寻找解决方案以及准备材料说服大家。
并非每一次提议都会得到支持，你的预期是应该把拒绝作为常态。这种拒绝大部分时候不是来自对于你建议的否定，而是没有足够的资源把你的提议落地。但是没有关系，在和团队分享的过程中正确性已经得到了大家的肯定，影响已经发生。反观整个过程也是你技术成长的痕迹。
如果你宁愿等待机会，那么你需要考虑这样一个问题，当机会来临时你可否抓住它？现状并不是看到机会之后我再去完善我的知识体系，而是我不断地积累知识体系去静候每个机会的降临。

• 测试覆盖率治不好你的精神内耗
  
• 昂贵的质量
  
• 理解流程
  
• 帮助团队成长是唯一的出路
  
• 开源社区的暗面
  
• 去年做 Tech Leader 犯过最大的错
  
• 技术写作的困境
  
• 拥抱原则与面对现实
  
• 代码与质量的思考与随笔
  
• 从对 Vue 中 mixin 的批评，到对模块间依赖关系的探讨
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！