§ 推动与拉动
上周和一位以前的领导打电话。他现在就职于bat之一。提到以前的工作倾向于推动，而来到bat，工作重心变动了拉动。大平台提供了很多施展才华的机会，不过，首先你得是个人才，要去深入市场，挖掘用户需求，推敲打磨。当你的想法得到上层管理层的认可后，公司就会给你足够的产研资源。
细品一下，推动与拉动，一字之差，含义却大不同。就像一驾人力车，你推着它，它就向前走。但是方向，你也许控制不住。而引领方向，就得靠拉动。
拿一个企业来说，公司的决策者，就是制定战略目标指引发展方向的。然后，中高层管理者，要根据战略方向，确定中短期阶段性的项目。而基层管理者的任务，更重要的是带领团队，推动一个一个的项目落地。
回归老本行，对于我们的技术组织，成员技术水平不一，初、中、高通常以类似于5：3：2的比例来配置。那么，对于组织的负责人来说，就要依据各成员的技术能力和态度，来区别对待。能力强态度好的人，自然是多多益善。不过，这样的人，常常是可遇不可求。尽管如此，还是要进行分析归类。那些能力强态度好的成员，你可以放心安排任务，定期关注一下进度，稍加推动可能就ok了。对于那些能力偏差的成员，就要采用拉动的策略了。给其分配的任务要足够明确，就是尤其要遵从SMART原则，同时，不断跟进任务的执行过程，多指导，多纠偏。且不可让其做一些技术调研、方案设计这样的工作。
§ 百思得解
百思不得其解？这世上哪有那么多百思不得其解的事情呀！
不是找不到答案，而可能是自己缺乏思考，甚至没有百思。
如何做到优秀？KSA三点，技术/knowledge+技巧/skills+态度/attribute。技术需要通过努力学习。完成一个任务之后，如果还能不断思考更好的处理方式和解决办法，不断改进，就会形成自己的技巧。
btw，早上上班路上，忽然想，百思得解是个多好的词语呀。现在是移动互联网时代了，如果前几年的互联网1.0和2.0时代，注册一个bestjack域名（音译：百思得解）也许还可以挣一笔钱呢。。
§ 学会做事：扭转被动局面
商户做资金下发时，银行返回付款失败，付款单改成失败后，风控系统在释放占用额度时却失败了。一步步排查原因，发现原来是风控系统里的交易表中，商户订单号字段的长度不够导致了这个bug。看似简单的问题，排查的过程却是漫长的。整个过程中商户还在不断的催促问运营要反馈。
当然，如果直接把我们系统的这个bug反馈给商户，显得我们太不专业太不靠谱了。于是，修改反馈的话术：我司风控系统对接收的数据的长度限制比较严格，那笔交易的订单长度是31位，超出风控系统可接受的长度，导致额度控制出现问题。对此，我们已经紧急处理，经过风控运营同事评估之后，将商户订单号长度进行适当扩容，提高对客体验。
之所以能够这么做，还是要感谢以前的老领导李总。他在职时，每当系统出现问题，不管是对公司内部的其他部门的高官，还是对外部的客户，他总能扭转被动的局面，甚至变被动为主动，变不利为有利。记得有一次，客户在差旅系统订完机票，到了机场后，却收到我们系统的航班延误的通知。通常，这种航班延误的通知，至少应该在在出行前一天通知到客户。一个普通用户还好，一个高官用户，或多个用户，可就不好搞定了。李总和运营给出的说法是：上游航司系统故障，不过我司会承担所有后果，包括经济赔付。最后，因为处理的比较巧妙，公司并未为此事惹上麻烦。
§ 大胆假设，小心求证
系统在运行过程中，总是会出现这样那样的问题，无论是小bug或大故障。
而且，往往很多问题并不那么容易找到原因。尤其是当我们掌握的资料有限的情况下，比如生产的数据我们没有查询权限，redis存储的数据难以确认，消息中间件的运行情况我们无法查看，依赖的上下游系统对于我们是个黑盒，等等。
不仅如此，当一个系统的业务链条比较复杂的时候，单从系统内部来排查问题，也是会存在很多可能性因素的。
所以，好的选手，不仅在于可以写出好的代码，还能善于排查问题修复问题，即，拥有超强的解决问题的能力。
大胆假设+小心求证，给我们提供了解决问题的方法论。具体来讲，就是要打破思维，同时，能够自我否认，不局限于某一个点，而是放眼整体，来从各个环节进行怀疑。就是先下结论，罗列出可能出现问题的环节。然后呢，有了存疑，就要小心求证，通过认真、谨慎地分析日志或数据，客观证明这些环节是否有问题。
反例的情况，
如果只拘泥于某个点，可能排查来排查去，都找不到原因。实际上，原因可能隐藏在别处。
如果只是大胆假设，然后就主观的下定结论，不去一探究竟。可能都没找到真正的原因。那么，同样的问题还会再来光顾的。
§ “收到”的重要性
我们拿即时聊天工具比如微信来说，对方告知我们某些信息，我们至少应该礼貌性的回复一个“收到”。“收到”就代表一种信息反馈。当然，信息的反馈远不止于“收到”这么简单。
不管如何，信息总是不对称的。一个项目，我把我这块做完了，需要你继续做，我告知你，你没有反馈。若干时间后，才发现，我告知你时，你并没留意，还在傻傻的等我。。
这就是信息断档，这样的场景在我们的工作中是不是屡屡出现？如果事情的影响范围小，那还有弥补的机会。而一旦事情影响严重了，那岂不是因小失大呀。我们对重要事故的复盘，十之八九得到的结论是源于团队对细节的疏忽。细节决定成败，绝非空谈！
因此，工作中，养成及时反馈的习惯吧，你好，他也好！
§ 如何打破信息不对称
众所周知，信息不对称是不可避免的。
一个开发组里，有的同学知道开发分支，有的同学知道dubbo管理端，有的同学知道配置中心，有的同学知道vue建在哪个项目，有的同学知道需求文档地址，有的同学电脑里保存了设计文档。
需求开发完要提测了，测试同学才知道要介入测试。还有时间编写测试用例吗？被动呀！
尽管有微信、qq、钉钉，大家可以很方便的沟通。不过，正是如此，信息似乎却被打乱了。
你有没有发现，你创建完代码的开发分支后，开始的3天里，你在群里发了好几遍？因为你在发消息的时候，只是问的人在关注。其他成员并没留意。当其他成员忙完手头的任务需要来coding了，他们又来@你问开发分支。
我们谈论孩子的幸福，会用衣来张口饭来伸手来形容。其实，之于每个人，骨子里的惰性皆是如此，有其他人可以问的话，谁都愿意直接去问。
总说效率，我们的效率就是在每天的这种低效抑或无效的沟通中，一步步降低了。
那么，怎么解决这种乱糟糟的情况呢？
俩字————共享。————打破信息孤岛，实现实现共享。————借助于工具。比如公司局域网内部的wiki、confluence。如果没有，那就求助于互联网上公开的共享空间，禅道、worktile、云笔记。办公协作软件很多，只要不用再一遍遍的重复传递，都可以借助用。